Date: Wed, 19 Jun 2002 14:40:31 +0200 (CEST) From: Alex Dupre <sysadmin@alexdupre.com> To: FreeBSD-gnats-submit@FreeBSD.org Subject: docs/39509: [Whitespace fixes] Filtering bridges article Message-ID: <200206191240.g5JCeVk9000651@vaio.alexdupre.com>
next in thread | raw e-mail | index | archive | help
>Number: 39509
>Category: docs
>Synopsis: [Whitespace fixes] Filtering bridges article
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-doc
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: maintainer-update
>Submitter-Id: current-users
>Arrival-Date: Wed Jun 19 05:30:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator: Alex Dupre
>Release: FreeBSD 4.5-ALEXDUPRE i386
>Organization:
>Environment:
System: FreeBSD vaio.alexdupre.com 4.5-ALEXDUPRE FreeBSD 4.5-ALEXDUPRE #0: Fri Apr 12 14:12:57 CEST 2002 alex@vaio.alexdupre.com:/usr/obj/usr/src/sys/VAIO i386
>Description:
whitespace fixes, no more, no less :)
>How-To-Repeat:
>Fix:
--- article_en.diff begins here ---
--- en_US.ISO8859-1/articles/filtering-bridges/article.sgml.orig Wed Jun 19 14:34:43 2002
+++ en_US.ISO8859-1/articles/filtering-bridges/article.sgml Wed Jun 19 14:34:50 2002
@@ -22,7 +22,7 @@
<abstract>
<para>Often it is useful to divide one physical network (like an
Ethernet) into two separate segments without having to create subnets,
- and use a router to link them together. The device that connects the
+ and use a router to link them together. The device that connects the
two networks in this way is called a bridge. A FreeBSD system with
two network interfaces is enough in order to act as a bridge.</para>
@@ -30,7 +30,7 @@
level (Ethernet addresses) of the devices connected to each of its
network interfaces and then forwarding the traffic between the two
networks only if the source and the destination are on different
- segments. Under many points of view a brigde is similar to an Ethernet
+ segments. Under many points of view a brigde is similar to an Ethernet
switch with only two ports.</para>
</abstract>
</articleinfo>
@@ -42,12 +42,12 @@
Internet connections (xDSL) and also because of the reduction of
available IPv4 addresses, many companies are connected to the Internet
24 hours on 24 and with few (sometimes not even a power of 2) IP
- addresses. In these situations it is often desirable to have a firewall
+ addresses. In these situations it is often desirable to have a firewall
that filters incoming and outgoing traffic from and towards Internet,
but a packet filtering solution based on router may not be applicable,
either due to subnetting issues, the router is owned by the connectivity
supplier (<acronym>ISP</acronym>), or because it doesn't support such
- functionalities. In these scenarios the use of a filtering bridge is
+ functionalities. In these scenarios the use of a filtering bridge is
highly advised.</para>
<para>A bridge-based firewall can be configured and inserted between the
@@ -61,7 +61,7 @@
<para>Adding bridge functionalities to a FreeBSD system is not difficult.
Since 4.5 release it is possible to load such functionalities as modules
instead of having to rebuild the kernel, simplifying the procedure a
- great deal. In the following subsections I will explain both
+ great deal. In the following subsections I will explain both
installation ways.</para>
<important>
@@ -73,9 +73,9 @@
<para>Before going on, be sure to have at least two Ethernet cards that
support the promiscuous mode for both reception and transmission, since
they must be able to send Ethernet packets with any address, not just
- their own. Moreover, to have a good throughput, the cards should be PCI
- bus mastering cards. The best choices are still the Intel EtherExpress
- Pro, followed by the 3Com 3c9xx series. To simplify the firewall
+ their own. Moreover, to have a good throughput, the cards should be PCI
+ bus mastering cards. The best choices are still the Intel EtherExpress
+ Pro, followed by the 3Com 3c9xx series. To simplify the firewall
configuration it may be useful to have two cards of different
manufacturers (using different drivers) in order to distinguish clearly
which interface is connected to the router and which to the inner
@@ -85,7 +85,7 @@
<title>Kernel Configuration</title>
<para>So you have decided to use the older but well tested installation
- method. To begin, you have to add the following rows to your kernel
+ method. To begin, you have to add the following rows to your kernel
configuration file:</para>
<programlisting>options BRIDGE
@@ -114,7 +114,7 @@
<para>In this way, during the system startup, the
<filename>bridge.ko</filename> module will be loaded together with the
- kernel. It is not required to add a similar row for the
+ kernel. It is not required to add a similar row for the
<filename>ipfw.ko</filename> module, since it will be loaded
automatically after the execution of the steps in the following
section.</para>
@@ -127,12 +127,12 @@
<para>Before rebooting in order to load the new kernel or the required
modules (according to the previously choosen installation method), you
have to make some changes to the <filename>/etc/rc.conf</filename>
- configuration file. The default rule of the firewall is to reject all IP
- packets. Initially we will set up an <option>open</option> firewall, in order to verify
- its operation without any issue related to packet filtering (in case you
- are going to execute this procedure remotely, such configuration will
- avoid you to remain isolated from the network). Put these lines in
- <filename>/etc/rc.conf</filename>:</para>
+ configuration file. The default rule of the firewall is to reject all IP
+ packets. Initially we will set up an <option>open</option> firewall, in
+ order to verify its operation without any issue related to packet
+ filtering (in case you are going to execute this procedure remotely, such
+ configuration will avoid you to remain isolated from the network). Put
+ these lines in <filename>/etc/rc.conf</filename>:</para>
<programlisting>firewall_enable="YES"
firewall_type="open"
@@ -147,7 +147,7 @@
<para>About the configuration of the network interfaces, the most used way
is to assign an IP to only one of the network cards, but the bridge will
- work equally even if both interfaces or none has a configured IP. In the
+ work equally even if both interfaces or none has a configured IP. In the
last case (IP-less) the bridge machine will be still more hidden, as
inaccessible from the network: to configure it, you have to login from
console or through a third network interface separated from the bridge.
@@ -155,21 +155,21 @@
access, say for domain resolution: in this case it is necessary to
assign an IP to the external interface (the one connected to Internet,
where <acronym>DNS</acronym> server resides), since the bridge will be
- activated at the end of the startup procedure. It means that the
+ activated at the end of the startup procedure. It means that the
<devicename>fxp0</devicename> interface (in our case) must be mentioned
in the ifconfig section of the <filename>/etc/rc.conf</filename> file,
- while the <devicename>xl0</devicename> is not. Assigning an IP to both
+ while the <devicename>xl0</devicename> is not. Assigning an IP to both
the network cards does not make much sense, unless, during the start
procedure, applications should access to services on both Ethernet
segments.</para>
- <para>There is another important thing to know. When running IP over
+ <para>There is another important thing to know. When running IP over
Ethernet, there are actually two Ethernet protocols in use: one is IP,
the other is <acronym>ARP</acronym>. <acronym>ARP</acronym> does the
conversion of the IP address of a host into its Ethernet address
(<acronym>MAC</acronym> layer). In order to allow the communication
between two hosts separated by the bridge, it is necessary that the
- bridge will forward <acronym>ARP</acronym> packets. Such protocol is not
+ bridge will forward <acronym>ARP</acronym> packets. Such protocol is not
included in the IP layer, since it exists only with IP over Ethernet.
The FreeBSD firewall filters exclusively on the IP layer and therefore
all non-IP packets (<acronym>ARP</acronym> included) will be forwarded
@@ -178,8 +178,8 @@
<para>Now it's time to reboot the system and use it as before: there will
be some new messages about the bridge and the firewall, but the bridge
- will not be activated and the firewall, being in <option>open</option> mode, will not
- avoid any operations.</para>
+ will not be activated and the firewall, being in <option>open</option>
+ mode, will not avoid any operations.</para>
<para>If there are any problems, you should sort them out now
before proceeding.</para>
@@ -203,7 +203,7 @@
<para>At this point you should be able to insert the machine between two
sets of hosts without compromising any communication abilities between
- them. If so, the next step is to add the
+ them. If so, the next step is to add the
<literal>net.link.ether.<replaceable>[blah]</replaceable>=<replaceable>[blah]</replaceable></literal>
portions of these rows to the <filename>/etc/sysctl.conf</filename>
file, in order to have them execute at startup.</para>
@@ -213,43 +213,45 @@
<title>Configuring The Firewall</title>
<para>Now it is time to create your own file with custom firewall rules,
- in order to secure the inside network. There will be some complication
+ in order to secure the inside network. There will be some complication
in doing this because not all of the firewall functionalities are
- available on bridged packets. Furthermore, there is a difference between
+ available on bridged packets. Furthermore, there is a difference between
the packets that are in the process of being forwarded and packets that
- are being received by the local machine. In general, incoming packets
+ are being received by the local machine. In general, incoming packets
are run through the firewall only once, not twice as is normally the
case; in fact they are filtered only upon receipt, so rules that use
- <option>out</option> or <option>xmit</option> will never match. Personally, I use <option>in via</option> which is an
- older syntax, but one that has a sense when you read it. Another
- limitation is that you are restricted to use only <option>pass</option> or <option>drop</option>
+ <option>out</option> or <option>xmit</option> will never match.
+ Personally, I use <option>in via</option> which is an older syntax, but
+ one that has a sense when you read it. Another limitation is that you are
+ restricted to use only <option>pass</option> or <option>drop</option>
commands for packets filtered by a bridge. Sophisticated things like
- <option>divert</option>, <option>forward</option> or <option>reject</option> are not available. Such options can
- still be used, but only on traffic to or from the bridge machine itself
- (if it has an IP address).</para>
+ <option>divert</option>, <option>forward</option> or
+ <option>reject</option> are not available. Such options can still be
+ used, but only on traffic to or from the bridge machine itself (if it has
+ an IP address).</para>
<para>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
+ 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's possible to do the same thing
- with <acronym>TCP</acronym> packets. This allows you to avoid some
+ 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's 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.</para>
- <para>Let's look at an example setup. Note first that at the top of
+ <para>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 <devicename>lo0</devicename>, so we shouldn't
- have to care for them anymore. Custom rules should be put in a separate
+ 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:</para>
+ <filename>/etc/rc.conf</filename> where we defined the
+ <option>open</option> firewall:</para>
<programlisting>firewall_type="/etc/rc.firewall.local"</programlisting>
@@ -315,63 +317,63 @@
add drop log all from any to any</programlisting>
<para>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
+ missing. In particular, there are no anti-spoofing rules, in fact we did
<emphasis>not</emphasis> add:</para>
<programlisting>add deny all from 1.2.3.4/8 to any in via fxp0</programlisting>
<para>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
+ 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. But usually, the <acronym>ISP</acronym> anti-spoofs at their
router, so we do not need to bother that much.</para>
<para>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
+ that is, do not let anything pass that is not specifically allowed. But
there is a difference: all suspected traffic will be logged.</para>
<para>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
+ 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 &man.ipfw.8; 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).</para>
+ is described accurately in the &man.ipfw.8; 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).</para>
<para>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
+ 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).</para>
<para>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
+ 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
- <devicename>fxp0</devicename></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.</para>
+ 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
+ <devicename>fxp0</devicename></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.</para>
</sect1>
<sect1 id="filtering-bridges-contributors">
<title>Contributors</title>
<para>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
+ an old text about bridging, edited by Nick Sayer. A pair of inspirations
are due to an introduction on bridging by Steve Peterson.</para>
<para>A big thanks to Luigi Rizzo for the implementation of the bridge
--- article_en.diff ends here ---
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206191240.g5JCeVk9000651>