The translation is temporarily closed for contributions due to maintenance, please come back later.

Source string Read only

(itstool) path: sect1/para
Context English State
New in FreeBSD 4.0, is the concept of stateful filtering. This is a big improvement for <acronym>UDP</acronym> traffic, which typically is a request going out, followed shortly thereafter by a response with the exact same set of IP addresses and port numbers (but with source and destination reversed, of course). For firewalls that have no statekeeping, there is almost no way to deal with this sort of traffic as a single session. But with a firewall that can <quote>remember</quote> an outgoing <acronym>UDP</acronym> packet and, for the next few minutes, allow a response, handling <acronym>UDP</acronym> services is trivial. The following example shows how to do it. It is possible to do the same thing with <acronym>TCP</acronym> packets. This allows you to avoid some denial of service attacks and other nasty tricks, but it also typically makes your state table grow quickly in size.
Let's look at an example setup. Note first that at the top of <filename>/etc/rc.firewall</filename> there are already standard rules for the loopback interface <filename>lo0</filename>, so we should not have to care for them anymore. Custom rules should be put in a separate file (say <filename>/etc/rc.firewall.local</filename>) and loaded at system startup, by modifying the row of <filename>/etc/rc.conf</filename> where we defined the <option>open</option> firewall:
You have to specify the <emphasis>full</emphasis> path, otherwise it will not be loaded with the risk to remain isolated from the network.
For our example imagine to have the <filename>fxp0</filename> interface connected towards the outside (Internet) and the <filename>xl0</filename> towards the inside (<acronym>LAN</acronym>). The bridge machine has the IP <systemitem class="ipaddress"></systemitem> (it is not possible that your <acronym>ISP</acronym> can give you an address quite like this, but for our example it is good).
# Things that we have kept state on before get to go through in a hurry
add check-state

# Throw away RFC 1918 networks
add drop all from to any in via fxp0
add drop all from to any in via fxp0
add drop all from to any in via fxp0

# Allow the bridge machine to say anything it wants
# (if the machine is IP-less do not include these rows)
add pass tcp from to any setup keep-state
add pass udp from to any keep-state
add pass ip from to any

# Allow the inside hosts to say anything they want
add pass tcp from any to any in via xl0 setup keep-state
add pass udp from any to any in via xl0 keep-state
add pass ip from any to any in via xl0

# TCP section
# Allow SSH
add pass tcp from any to any 22 in via fxp0 setup keep-state
# Allow SMTP only towards the mail server
add pass tcp from any to relay 25 in via fxp0 setup keep-state
# Allow zone transfers only by the slave name server []
add pass tcp from to ns 53 in via fxp0 setup keep-state
# Pass ident probes. It is better than waiting for them to timeout
add pass tcp from any to any 113 in via fxp0 setup keep-state
# Pass the "quarantine" range
add pass tcp from any to any 49152-65535 in via fxp0 setup keep-state

# UDP section
# Allow DNS only towards the name server
add pass udp from any to ns 53 in via fxp0 keep-state
# Pass the "quarantine" range
add pass udp from any to any 49152-65535 in via fxp0 keep-state

# ICMP section
# Pass 'ping'
add pass icmp from any to any icmptypes 8 keep-state
# Pass error messages generated by 'traceroute'
add pass icmp from any to any icmptypes 3
add pass icmp from any to any icmptypes 11

# Everything else is suspect
add drop log all from any to any
Those of you who have set up firewalls before may notice some things missing. In particular, there are no anti-spoofing rules, in fact we did <emphasis>not</emphasis> add:
add deny all from to any in via fxp0
That is, drop packets that are coming in from the outside claiming to be from our network. This is something that you would commonly do to be sure that someone does not try to evade the packet filter, by generating nefarious packets that look like they are from the inside. The problem with that is that there is <emphasis>at least</emphasis> one host on the outside interface that you do not want to ignore: the router. But usually, the <acronym>ISP</acronym> anti-spoofs at their router, so we do not need to bother that much.
The last rule seems to be an exact duplicate of the default rule, that is, do not let anything pass that is not specifically allowed. But there is a difference: all suspected traffic will be logged.
There are two rules for passing <acronym>SMTP</acronym> and <acronym>DNS</acronym> traffic towards the mail server and the name server, if you have them. Obviously the whole rule set should be flavored to personal taste, this is only a specific example (rule format is described accurately in the <citerefentry><refentrytitle>ipfw</refentrytitle><manvolnum>8</manvolnum></citerefentry> man page). Note that in order for <quote>relay</quote> and <quote>ns</quote> to work, name service lookups must work <emphasis>before</emphasis> the bridge is enabled. This is an example of making sure that you set the IP on the correct network card. Alternatively it is possible to specify the IP address instead of the host name (required if the machine is IP-less).
People that are used to setting up firewalls are probably also used to either having a <option>reset</option> or a <option>forward</option> rule for ident packets (<acronym>TCP</acronym> port 113). Unfortunately, this is not an applicable option with the bridge, so the best thing is to simply pass them to their destination. As long as that destination machine is not running an ident daemon, this is relatively harmless. The alternative is dropping connections on port 113, which creates some problems with services like <acronym>IRC</acronym> (the ident probe must timeout).
The only other thing that is a little weird that you may have noticed is that there is a rule to let the bridge machine speak, and another for internal hosts. Remember that this is because the two sets of traffic will take different paths through the kernel and into the packet filter. The inside net will go through the bridge, while the local machine will use the normal IP stack to speak. Thus the two rules to handle the different cases. The <literal>in via fxp0</literal> rules work for both paths. In general, if you use <option>in via</option> rules throughout the filter, you will need to make an exception for locally generated packets, because they did not come in via any of our interfaces.
Many parts of this article have been taken, updated and adapted from an old text about bridging, edited by Nick Sayer. A pair of inspirations are due to an introduction on bridging by Steve Peterson.
A big thanks to Luigi Rizzo for the implementation of the bridge code in FreeBSD and for the time he has dedicated to me answering all of my related questions.
A thanks goes out also to Tom Rhodes who looked over my job of translation from Italian (the original language of this article) into English.


No matching activity found.

Browse all component changes

Source information

Source string comment
(itstool) path: sect1/para
Source string location
String age
a year ago
Source string age
a year ago
Translation file
articles/filtering-bridges.pot, string 58