Attachment 22830 Details for Bug 39509 – article_en.diff

[patch] article_en.diff

article_en.diff (text/plain), 18.79 KB, created by Alex Dupre on 2002-06-19 13:30:01 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Alex Dupre

Created: 2002-06-19 13:30:01 UTC

Size: 18.79 KB

patch

obsolete

>--- 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

Actions: View | Diff

Attachments on bug 39509: 22830