Attachment 49379 Details for Bug 75422 – file.diff

[patch] file.diff

file.diff (text/plain), 42.61 KB, created by Matteo Riondato on 2004-12-23 07:50:21 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Matteo Riondato

Created: 2004-12-23 07:50:21 UTC

Size: 42.61 KB

patch

obsolete

>--- chapter.sgml.orig   Wed Dec 22 19:38:28 2004
>+++ chapter.sgml        Wed Dec 22 21:18:52 2004
>@@ -114,7 +114,7 @@
>     <para>There are two basic ways to create firewall rulesets:
>       <quote>inclusive</quote> or <quote>exclusive</quote>.  An
>       exclusive firewall allows all traffic through except for the
>-      traffic matching the ruleset.  An inclusive firewall does the
>+      traffic matching the rule set.  An inclusive firewall does the
>       reverse.  It only allows traffic matching the rules through and
>       blocks everything else.</para>
> 
>@@ -137,18 +137,18 @@
>   <sect1 id="firewalls-apps">
>     <title>Firewall Software Applications</title>
> 
>-    <para>&os; has three different firewall software products built into
>-      the base system. They are IPFILTER (also known as IPF),
>-      IPFIREWALL (also known as IPFW) and PF (OpenBSD's PacketFilter).  IPFIREWALL has the built
>-      in DUMMYNET traffic shaper facilities for controlling bandwidth
>-      usage. IPFILTER does not have a built in traffic shaper facility
>-      for controlling bandwidth usage, but the ALTQ port application
>-      can be used to accomplish the same function.  The DUMMYNET
>-      feature and <acronym>ALTQ</acronym> is generally useful only to
>-      large ISPs or commercial users.  IPF, IPFW and PF use rules to
>-      control the access of packets to and from your system, although
>-      they go about it different ways and have different rule
>-      syntaxes.</para>
>+    <para>&os; has three different firewall software products built
>+      into the base system. They are IPFILTER (also known as IPF),
>+      IPFIREWALL (also known as IPFW) and PF (OpenBSD's PacketFilter).
>+      IPFIREWALL has the built in DUMMYNET traffic shaper facilities
>+      for controlling bandwidth usage. IPFILTER does not have a built
>+      in traffic shaper facility for controlling bandwidth usage, but
>+      the ALTQ framework can be used to accomplish the same
>+      function.  The DUMMYNET feature and <acronym>ALTQ</acronym> is
>+      generally useful only to large ISPs or commercial users.  IPF,
>+      IPFW and PF use rules to control the access of packets to and
>+      from your system, although they go about it different ways and
>+      have different rule syntaxes.</para>
> 
>     <para>The IPFW sample rule set (found in
>       <filename>/etc/rc.firewall</filename>) delivered in the basic
>@@ -197,9 +197,9 @@
>       known as <acronym>PF</acronym> was ported to &os;&nbsp;5.3.
>       <acronym>PF</acronym> is a complete, fully featured firewall
>       that contains <acronym>ALTQ</acronym> for bandwidth usage
>-      management in a way similar to the dummynet provides in
>+      management in a way similar to what DUMMYNET provides for
>       <acronym>IPFW</acronym>.  The OpenBSD project does an
>-      outstanding job of maintaining the PF users' guide that it will
>+      outstanding job of maintaining the PF user's guide that it will
>       not be made part of this handbook firewall section as that would
>       just be duplicated effort.</para>
> 
>@@ -223,9 +223,9 @@
>     <sect2>
>       <title>Enabling PF</title>
>       <para>PF is included in the basic &os; install for versions newer than
>-        5.3 as a separate run time loadable module. PF will dynamically load
>-               its kernel loadable module when the rc.conf statement
>-        <literal>pf_enable="YES"</literal> is used. The
>+        5.3 as a separate run time loadable module. The system will
>+        dynamically load PF kernel loadable module when the rc.conf
>+        statement <literal>pf_enable="YES"</literal> is used. The
>         loadable module was created with &man.pflog.4; logging
>         enabled.</para>
>     </sect2>
>@@ -256,7 +256,7 @@
>       <para><literal>device pfsync</literal> enables the optional
>         &man.pfsync.4; pseudo network device that is used to monitor
>         <quote>state changes</quote>. As this is not part of the loadable
>-        module one has to build a custom kernel to use it.</para>
>+        module a custom kernel is needed to use it.</para>
> 
>       <para>These settings will take affect only after you have built and
>                 installed a kernel with them set.</para>
>@@ -288,11 +288,10 @@
>     <title>The IPFILTER (IPF) Firewall</title>
> 
>     <para>The author of IPFILTER is Darren Reed. IPFILTER is not
>-      operating system dependent. IPFILTER is a open source
>-      application and has been ported to &os;, NetBSD, OpenBSD, SunOS,
>-      HP/UX, and Solaris operating systems. IPFILTER is actively being
>-      supported and maintained, with updated versions being released
>-      regularly.</para>
>+      operating system dependent: is a open source application and has
>+      been ported to &os;, NetBSD, OpenBSD, SunOS, HP/UX, and Solaris
>+      operating systems. IPFILTER is actively being supported and
>+      maintained, with updated versions being released regularly.</para>
> 
>     <para>IPFILTER is based on a kernel-side firewall and
>       <acronym>NAT</acronym> mechanism that can be controlled and
>@@ -326,10 +325,10 @@
>       and also control the services which can originate from the
>       public Internet accessing your private network. Everything else
>       is blocked and logged by default design. Inclusive firewalls are
>-      much, much more secure than exclusive firewall rule sets and is
>-      the only rule set type covered here in.</para>
>+      much, much more secure than exclusive ones and only this rule
>+      set type is covered here.</para>
> 
>-    <para>For detailed explanation of the legacy rules processing
>+    <para>For a detailed explanation of the legacy rules processing
>       method see: <ulink
>       url="http://www.obfuscation.org/ipf/ipf-howto.html#TOC_1"></ulink>
>       and <ulink
>@@ -340,16 +339,16 @@
>       url="http://www.phildev.net/ipf/index.html"></ulink>.</para>
> 
>     <sect2>
>-      <title>Enabling IPF</title>
>+      <title>Enabling IPF</title> 
>       <para>IPF is included in the basic &os; install as a separate
>-        run time loadable module. IPF will dynamically load its kernel
>-        loadable module when the rc.conf statement <literal>
>-        ipfilter_enable="YES"</literal> is used. The loadable
>-        module was created with logging enabled and the <literal>default
>-        pass all</literal> options. You do not need to compile IPF into
>-        the &os; kernel just to change the default to <literal>block all
>-        </literal>, you can do that by just coding a block all rule at
>-        the end of your rule set.</para>
>+        run time loadable module. The system will dynamically load IPF
>+        kernel loadable module when the rc.conf statement <literal>
>+        ipfilter_enable="YES"</literal> is used. The loadable module
>+        was created with logging enabled and the <literal>default pass
>+        all</literal> option. You do not need to compile IPF into the
>+        &os; kernel just to change the default to <literal>block all
>+        </literal>, you can do that by just coding a <literal>block
>+        all</literal> rule at the end of your rule set.</para> 
>     </sect2>
> 
>     <sect2>
>@@ -369,8 +368,8 @@
> options IPFILTER_LOG
> options IPFILTER_DEFAULT_BLOCK</programlisting>
> 
>-      <para><literal>options IPFILTER</literal> tells the compile
>-        to include IPFILTER as part of its core kernel.</para>
>+      <para><literal>options IPFILTER</literal> enables support for
>+      the <quote>IPFILTER</quote> firewall.</para>
> 
>       <para><literal>options IPFILTER_LOG</literal> enables the
>         option to have IPF log traffic by writing to the ipl packet
>@@ -416,15 +415,16 @@
> 
>      <programlisting><command>ipf -Fa -f /etc/ipf.rules</command></programlisting>
> 
>-     <para><option>-Fa</option> means flush all internal rules tables.</para>
>-     <para><option>-f</option> means this is the file to read for the rules to load.</para>
>+     <para><option>-Fa</option> means "flush all internal rules tables".</para>
>+     <para><option>-f</option> means "this is the file to read for the
>+     rules to load".</para>
> 
>-     <para>This gives you the ability to make changes to their custom
>-       rules file, run the above IPF command thus updating the running
>+     <para>This gives you the ability to make changes to a custom
>+       rules file. Run the above IPF command thus updating the running
>        firewall with a fresh copy of all the rules without having to
>-       reboot the system. This method is very convenient for testing new
>-       rules as the procedure can be executed as many times as needed.
>-       </para>
>+       reboot the system. This method is very convenient for testing
>+       new rules as the procedure can be executed as many times as
>+       needed.  </para>
>      <para>See the &man.ipf.8; manual page for details on the other flags
>        available with this command.</para>
>@@ -433,7 +433,7 @@
>        standard text file. It will not accept a rules file written as a
>        script with symbolic substitution.</para>
> 
>-     <para>There is a way to build IPF rules that utilities the power of
>+     <para>There is a way to build IPF rules that use the power of
>        script symbolic substitution.  For more information, see <xref
>        linkend="firewalls-ipfw-rules-script">.</para>
>      </sect2>
>@@ -557,7 +557,7 @@
>      <sect2>
>        <title>IPMON Logging</title>
> 
>-       <para>Syslogd uses its own special method for segregation of log
>+       <para>Syslogd uses its own special method for aggregation of log
>          data. It uses special grouping called <quote>facility</quote>
>          and <quote>level.</quote> IPMON in <option>-Ds</option> mode uses Local0 as the
>          <quote>facility</quote> name. All IPMON logged data goes to
>@@ -575,8 +575,9 @@
> 
>        <programlisting><command>touch /var/log/ipfilter.log</command></programlisting>
> 
>-       <para>The syslog function is controlled by definition statements
>-         in the <filename>/etc/syslog.conf</filename> file. The <filename>syslog.conf</filename> file offers
>+       <para>The syslog function is controlled by definition
>+         statements in the <filename>/etc/syslog.conf</filename>
>+         file. The <filename>syslog.conf</filename> file offers
>          considerable flexibility in how syslog will deal with system
>          messages issued by software applications like IPF.</para>
> 
>@@ -585,16 +586,18 @@
> 
>        <programlisting>Local0.* /var/log/ipfilter.log</programlisting>
> 
>-       <para>The <literal>Local0.*</literal> means to write all the logged messages to the
>-         coded file location.</para>
>+       <para>The <literal>Local0.*</literal> means to write all the
>+         logged messages to the coded file location.</para>
> 
>-       <para>To activate the changes to <filename>/etc/syslog.conf
>-         </filename> you can reboot or bump the syslog task into
>-         re-reading <filename>/etc/syslog.conf</filename> by <command>
>-         kill -HUP &lt;pid&gt;</command>. You get the pid (i.e. process
>-         number) by listing the tasks with the <command>ps -ax</command>
>-         command. Find syslog in the display and the pid is the number
>-         in the left column.</para>
>+       <para>To activate the changes made to
>+         <filename>/etc/syslog.conf </filename> you can reboot or bump
>+         the syslog task into re-reading
>+         <filename>/etc/syslog.conf</filename> by
>+         <command>/etc/rc.d/syslogd restart</command> or <command>kill
>+         -HUP <literal>pid</literal></command> on &os; 4.X systems. You
>+         get the pid (i.e. process number) by listing the tasks with
>+         the <command>ps -ax</command> command. Find syslog in the
>+         display and the pid is the number in the left column.</para>
> 
>        <para>Do not forget to change <filename>/etc/newsyslog.conf
>          </filename> to rotate the new log you just created above.
>@@ -643,7 +646,7 @@
>          </listitem>
> 
>          <listitem>
>-           <para>The addresses. This is actually three fields: the
>+           <para>The addresses. This is actuactually three fields: the
>              source address and port (separated by a comma), the ->
>              symbol, and the destination address and port.
>              209.53.17.22,80 -> 198.73.220.17,1722.</para>
>@@ -703,7 +706,7 @@
> <programlisting>############# Start of IPF rules script ########################
> 
> oif="dc0"            # name of the outbound interface
>-odns="192.0.2.11"    # ISP's dns server IP address Symbolic&gt;
>+odns="192.0.2.11"    # ISP's DNS server IP address
> myip="192.0.2.7"     # My Static IP address from ISP
> ks="keep state"
> fks="flags S keep state"
>@@ -716,7 +719,7 @@
> # after the EOF line to work correctly.
> /sbin/ipf -Fa -f - &lt;&lt; EOF
> 
>-# Allow out access to my ISP's Domain name server.
>+# Allow out access to my ISP's Domain Name server.
> pass out quick on &dollar;oif proto tcp from any to &dollar;odns port = 53 &dollar;fks
> pass out quick on &dollar;oif proto udp from any to &dollar;odns port = 53 &dollar;ks
> 
>@@ -728,10 +731,11 @@
> EOF
> ################## End of IPF rules script ########################</programlisting>
> 
>-       <para>That is all there is to it. The rules are not important in
>-         this example, how the Symbolic substitution field are populated
>-         and used are. If the above example was in <filename>/etc/ipf.rules.script</filename>
>-         file, you could reload these rules by entering this on the command
>+       <para>That is all there is to it. The rules are not important
>+         in this example, how the Symbolic substitution field are
>+         populated and used are. If the above example was in
>+         <filename>/etc/ipf.rules.script</filename> file, you could
>+         reload these rules by entering the following on the command
>          line:</para>
> 
>        <programlisting><command>sh /etc/ipf.rules.script</command>
>@@ -761,7 +765,7 @@
> 
>        <programlisting><command>chmod 700 /usr/local/etc/rc.d/ipf.loadrules.sh</command></programlisting>
> 
>-       <para>Now when you system boots your IPF rules will be loaded
>+       <para>Now when your system boots, your IPF rules will be loaded
>          using the script.</para>
> 
>      </sect2>
>@@ -774,7 +778,7 @@
>          session conversation. The firewall rule set processes the
>          packet 2 times, once on its arrival from the public Internet
>          host and again as it leaves for its return trip back to the
>-         public Internet host. Each tcp/ip service (i.e. telnet, www,
>+         public Internet host. Each TCP/IP service (i.e. telnet, www,
>          mail, etc.) is predefined by its protocol, source and
>          destination IP address, or the source and destination port
>          number. This is the basic selection criteria used to create
>@@ -814,9 +818,9 @@
>          rule wins</quote> logic. For the complete legacy rule syntax
>          description see the &man.ipf.8; manual page.</para>
> 
>-       <para><literal>#</literal> is used to mark the start of a comment and may appear at
>-         the end of a rule line or on its own lines. Blank lines are
>-         ignored.</para>
>+       <para><literal>#</literal> is used to mark the start of a
>+         comment and may appear at the end of a rule line or on its
>+         own lines. Blank lines are ignored.</para>
> 
>        <para>Rules contain keywords, These keywords have to be coded in
>          a specific order from left to right on the line. Keywords are
>@@ -859,8 +863,9 @@
>            <title>ACTION</title>
> 
>            <para>The action indicates what to do with the packet if it
>-             matches the rest of the filter rule. Each rule <emphasis>must</emphasis> have a
>-             action. The following actions are recognized:</para>
>+             matches the rest of the filter rule. Each rule
>+             <emphasis>must</emphasis> have a action. The following
>+             actions are recognized:</para>
> 
>            <para>block indicates that the packet should be dropped if
>              the selection parameters match the packet.</para>
>@@ -877,11 +882,11 @@
>              other has to be coded or the rule will not pass syntax
>              check.</para>
> 
>-           <para>in means this rule is being applied against an inbound
>+           <para>"in" means this rule is being applied against an inbound
>              packet which has just been received on the interface
>              facing the public Internet.</para>
> 
>-           <para>out means this rule is being applied against an
>+           <para>"out" means this rule is being applied against an
>              outbound packet destined for the interface facing the public
>              Internet.</para>
>          </sect3>
>@@ -893,18 +898,18 @@
>                </para>
>            </note>
> 
>-           <para>log indicates that the packet header will be written to
>+           <para>"log" indicates that the packet header will be written to
>              the ipl log (as described in the LOGGING section below) if
>              the selection parameters match the packet.</para>
> 
>-           <para>quick indicates that if the selection parameters match
>+           <para>"quick" indicates that if the selection parameters match
>              the packet, this rule will be the last rule checked,
>              allowing a "short-circuit" path to avoid processing any
>              following rules for this packet. This option is a mandatory
>              requirement for the modernized rules processing logic.
>              </para>
> 
>-           <para>on indicates the interface name to be incorporated into
>+           <para>"on" indicates the interface name to be incorporated into
>              the selection parameters. Interface names are as displayed
>              by ifconfig. Using this option, the rule will only match if
>              the packet is going through that interface in the specified
>@@ -916,10 +921,10 @@
>              Immediately following the log keyword, the following
>              qualifiers may be used (in this order):</para>
> 
>-           <para>body indicates that the first 128 bytes of the packet
>+           <para>"body" indicates that the first 128 bytes of the packet
>              contents will be logged after the headers.</para>
> 
>-           <para>first If the 'log' keyword is being used in conjunction
>+           <para>"first" If the 'log' keyword is being used in conjunction
>              with a "keep state" option, it is recommended that this
>              option is also applied so that only the triggering packet
>              is logged and not every packet which there after matches
>@@ -958,7 +963,7 @@
>            <para>The 'all' keyword is essentially a synonym for "from
>              any to any" with no other match parameters.</para>
> 
>-           <para>from src to dst The from and to keywords are used to
>+           <para>"from src to dst" The from and to keywords are used to
>              match against IP addresses. Rules must specify BOTH source
>              and destination parameters. .any. is a special keyword that
>              matches any IP address. As in 'from any to any' or 'from
>@@ -1042,12 +1047,13 @@
>           do not properly fit the session conversation template are
>           automatically rejected as impostors.</para>
> 
>-        <para>Keep state will also allow ICMP packets related to a <acronym>TCP</acronym>
>-          or UDP session through. So if you get ICMP type 3 code 4 in
>-          response to some web surfing allowed out by a keep state rule,
>-          they will be automatically allowed in. Any packet that IPF can
>-          be certain is part of a active session, even if it is a
>-          different protocol, will be let in.</para>
>+        <para>Keep state will also allow ICMP packets related to a
>+          <acronym>TCP</acronym> or UDP session through. So if you get
>+          ICMP type 3 code 4 in response to some web surfing allowed
>+          out by a keep state rule, they will be automatically allowed
>+          in. Any packet that IPF can be certain is part of a active
>+          session, even if it is a different protocol, will be let
>+          in.</para>
> 
>         <para>What happens is:</para>
> 
>@@ -1090,16 +1096,16 @@
>         interfaces which have to have rules to allow the firewall to
>         function.</para>
> 
>-      <para>All Unix flavored systems including &os; are designed to
>-        use interface l0 and IP address 127.0.0.1 for internal
>-        communication with in the &os; operating system. The firewall
>+      <para>All &unix; flavored systems including &os; are designed to
>+        use interface lo0 and IP address 127.0.0.1 for internal
>+        communication with in the operating system. The firewall
>         rules must contain rules to allow free unmolested movement of
>         these special internally used packets.</para>
> 
>       <para>The interface which faces the public Internet, is the one
>         which you code your rules to authorize and control access out
>         to the public Internet and access requests arriving from the
>-        public Internet. This can be your .user ppp. tun0 interface or
>+        public Internet. This can be your 'user ppp' tun0 interface or
>         your NIC card that is cabled to your DSL or cable modem.</para>
> 
>       <para>In cases where one or more than one NICs are cabled to
>@@ -1107,7 +1113,7 @@
>         interfaces must have a rule coded to allow free unmolested
>         movement of packets originating from those LAN interfaces.</para>
> 
>-      <para>The rules should be first organized into three major
>+      <para>The rule set should be first organized into three major
>         sections, all the free unmolested interfaces, public interface
>         outbound, and the public interface inbound.</para>
> 
>@@ -1139,13 +1145,13 @@
>         create the legal evidence needed to prosecute the people who
>         are attacking your system.</para>
> 
>-      <para>Another thing you should take note of, is there is no
>+      <para>There is another thing you should take note of: there is no
>         response returned for any of the undesirable stuff, their
>         packets just get dropped and vanish. This way the attackers
>         has no knowledge if his packets have reached your system.  The
>         less the attackers can learn about your system the more secure
>         it is. The inbound 'nmap OS fingerprint' attempts rule I log
>-        the first occurrence because this is something a attacker
>+        the first occurrence because this is something an attacker
>         would do.</para>
> 
>       <para>Any time you see log messages on a rule with .log first.
>@@ -1182,8 +1188,8 @@
>         <filename>/etc/ipf.rules</filename>:</para>
> 
>       <programlisting>#################################################################
>-# No restrictions on Inside Lan Interface for private network
>-# Not needed unless you have Lan
>+# No restrictions on Inside LAN Interface for private network
>+# Not needed unless you have LAN
> #################################################################
> 
> #pass out quick on xl0 all
>@@ -1203,7 +1209,7 @@
> #################################################################
> 
> # Allow out access to my ISP's Domain name server.
>-# xxx must be the IP address of your ISP.s DNS.
>+# xxx must be the IP address of your ISP's DNS.
> # Dup these lines if your ISP has more than one DNS server
> # Get the IP addresses from /etc/resolv.conf file
> pass out quick on dc0 proto tcp from any to xxx port = 53 flags S keep state
>@@ -1322,7 +1328,7 @@
> # used in the outbound section.
> pass in quick on dc0 proto udp from z.z.z.z to any port = 68 keep state
> 
>-# Allow in standard www function because I have apache server
>+# Allow in standard www function because I have Apache server
> pass in quick on dc0 proto tcp from any to any port = 80 flags S keep state
> 
> # Allow in non-secure Telnet session from public Internet
>@@ -1336,7 +1342,7 @@
> 
> # Block and log only first occurrence of all remaining traffic
> # coming into the firewall. The logging of only the first
>-# occurrence stops a .denial of service. attack targeted
>+# occurrence stops a 'Denial of Service' attack targeted
> # at filling up your log file space.
> # This rule enforces the block all by default logic.
> block in log first quick on dc0 all
>@@ -1370,7 +1376,7 @@
>         lines.</para>
> 
>       <para>With <acronym>NAT</acronym> you only need a single account
>-        with your ISP, then cable your other 4 PC.s to a switch and
>+        with your ISP, then cable your other 4 PC's to a switch and
>         the switch to the NIC in your &os; system which is going to
>         service your LAN as a gateway. <acronym>NAT</acronym> will
>         automatically translate the private LAN IP address for each
>@@ -1436,13 +1442,13 @@
>         for details.</para>
> 
>       <para>When changing the <acronym>NAT</acronym> rules after
>-        <acronym>NAT</acronym> has been started, Make your changes to
>+        <acronym>NAT</acronym> has been started, make your changes to
>         the file containing the nat rules, then run ipnat command with
>         the <option>-CF</option> flags to delete the internal in use
>         <acronym>NAT</acronym> rules and flush the contents of the
>         translation table of all active entries.</para>
> 
>-      <para>To reload the <acronym>NAT</acronym> rules issue a command
>+      <para>To reload the <acronym>NAT</acronym> rules, issue a command
>         like this:</para>
> 
>       <programlisting>ipnat -CF -f /etc/ipnat.rules</programlisting>
>@@ -1554,7 +1560,7 @@
>       <sect3>
>         <title>Assigning Ports to Use</title>
> 
>-        <para>XXXBLAH</para>
>+        <para></para>
> 
>         <programlisting>map dc0 192.168.1.0/24 -> 0.32</programlisting>
> 
>@@ -1731,7 +1737,7 @@
> 
>     <para>The IPFIREWALL (IPFW) is a &os; sponsored firewall software
>       application authored and maintained by &os; volunteer staff
>-      members. It uses the legacy Stateless rules and a legacy rule
>+      members. It uses the legacy stateless rules and a legacy rule
>       coding technique to achieve what is referred to as Simple
>       Stateful logic.</para>
> 
>@@ -1748,21 +1754,23 @@
> 
>     <para>IPFW is composed of 7 components, the primary component is
>       the kernel firewall filter rule processor and its integrated
>-      packet accounting facility, the logging facility, the 'divert'
>-      rule which triggers the <acronym>NAT</acronym> facility, and the
>-      advanced special purpose facilities, the dummynet traffic shaper
>-      facilities, the 'fwd rule' forward facility, the bridge
>-      facility, and the ipstealth facility.</para>
>+      packet accounting facility, then come the logging facility, the
>+      'divert' rule which triggers the <acronym>NAT</acronym>
>+      facility, and the advanced special purpose facilities, the
>+      dummynet traffic shaper facilities, the 'fwd rule' forward
>+      facility, the bridge facility, and the ipstealth
>+      facility.</para>
> 
>     <sect2 id="firewalls-ipfw-enable">
>       <title>Enabling IPFW</title>
> 
>       <para>IPFW is included in the basic &os; install as a separate
>-        run time loadable module. IPFW will dynamically load the
>-        kernel module when the <filename>rc.conf</filename> statement
>-        <literal>firewall_enable="YES"</literal> is used. You do not
>-        need to compile IPFW into the &os; kernel unless you want
>-        <acronym>NAT</acronym> function enabled.</para>
>+        run time loadable module. The system will dynamically load
>+        IPFW kernel module when the <filename>rc.conf</filename>
>+        statement <literal>firewall_enable="YES"</literal> is
>+        used. You do not need to compile IPFW into the &os; kernel
>+        unless you want <acronym>NAT</acronym> function
>+        enabled.</para>
> 
>       <para>After rebooting your system with
>         <literal>firewall_enable="YES"</literal> in
>@@ -1870,7 +1878,7 @@
>         firewall rules with changes you made to the files content is
>         the recommended method used here.</para>
> 
>-      <para>The IPFW command is still a very useful to display the
>+      <para>The ipfw command is still very useful to display the
>         running firewall rules to the console screen. The IPFW
>         accounting facility dynamically creates a counter for each
>         rule that counts each packet that matches the rule. During the
>@@ -2063,11 +2071,11 @@
> 
>           <para>The from and to keywords are used to match against IP
>             addresses. Rules must specify BOTH source and destination
>-            parameters. any is a special keyword that matches any IP
>-            address. me is a special keyword that matches any IP
>+            parameters. 'any' is a special keyword that matches any IP
>+            address. 'me' is a special keyword that matches any IP
>             address configured on an interface in your &os; system to
>-            represent the PC the firewall is running on. (i.e. this
>-            box) As in from me to any or from any to me or from
>+            represent the PC the firewall is running on (i.e. this
>+            box). As in from me to any or from any to me or from
>             0.0.0.0/0 to any or from any to 0.0.0.0/0 or from 0.0.0.0
>             to any or from any to 0.0.0.0 or from me to 0.0.0.0. IP
>             addresses are specified as a dotted IP address numeric
>@@ -2225,7 +2233,7 @@
>           <para>The script syntax used here is compatible with the 'sh',
>             'csh', 'tcsh' shells. Symbolic substitution fields are
>             prefixed with a dollar sign &dollar;. Symbolic fields do not have
>-            the &dollar; prefix. The value to populate the Symbolic field must
>+            the &dollar; prefix. The value to populate the symbolic field must
>             be enclosed to "double quotes".</para>
> 
>           <para>Start your rules file like this:</para>
>@@ -2235,7 +2243,7 @@
> ipfw -q -f flush       # Delete all rules
> # Set defaults
> oif="tun0"             # out interface
>-odns="192.0.2.11"      # ISP's dns server IP address
>+odns="192.0.2.11"      # ISP's DNS server IP address
> cmd="ipfw -q add "     # build rule prefix
> ks="keep-state"        # just too lazy to key this each time
> &dollar;cmd 00500 check-state
>@@ -2247,7 +2255,7 @@
> ################### End of example ipfw rules script ############</programlisting>
> 
>           <para>That is all there is to it. The rules are not important
>-            in this example, how the Symbolic substitution field are
>+            in this example, how the symbolic substitution field are
>             populated and used are.</para>
> 
>           <para>If the above example was in
>@@ -2274,7 +2282,7 @@
> 
>         </sect3>
>         <sect3>
>-          <title>Stateful Ruleset</title>
>+          <title>Stateful Rule Set</title>
>           <para>The following non-<acronym>NAT</acronym>ed rule set is a example of how to
>             code a very secure 'inclusive' type of firewall. An
>             inclusive firewall only allows services matching pass rules
>@@ -2283,7 +2291,7 @@
>             allow the firewall to function.</para>
> 
>           <para>All &unix; flavored operating systems, &os; included, are designed to
>-            use interface lo and IP address
>+            use interface lo0 and IP address
>             <hostid role="ipaddr">127.0.0.1</hostid> for internal
>             communication with in &os;. The firewall rules must contain
>             rules to allow free unmolested movement of these special
>@@ -2292,9 +2300,9 @@
>           <para>The interface which faces the public Internet, is the
>             one which you code your rules to authorize and control
>             access out to the public Internet and access requests
>-            arriving from the public Internet. This can be your ppp tun0
>-            interface or your NIC that is connected to your DSL or cable
>-            modem.</para>
>+            arriving from the public Internet. This can be your 'user
>+            ppp' tun0 interface or your NIC that is connected to your
>+            DSL or cable modem.</para>
> 
>           <para>In cases where one or more than one NIC are connected to
>             a private LANs behind the firewall, those interfaces must
>@@ -2349,9 +2357,9 @@
>             .</para>
>         </sect3>
>         <sect3>
>-          <title>An Example Inclusive Ruleset</title>
>+          <title>An Example Inclusive Rule Set</title>
>           <para>The following non-<acronym>NAT</acronym>ed rule set is a complete inclusive
>-            type ruleset. You can not go wrong using this rule set for
>+            type rule set. You can not go wrong using this rule set for
>             you own.  Just comment out any pass rules for services you
>             do not want.  If you see messages in your log that you want to
>             stop seeing just add a deny rule in the inbound section. You
>@@ -2398,7 +2406,7 @@
>                         # facing the public Internet
> 
> #################################################################
>-# No restrictions on Inside Lan Interface for private network
>+# No restrictions on Inside LAN Interface for private network
> # Not needed unless you have Lan.
> # Change xl0 to your Lan Nic card interface name
> #################################################################
>@@ -2540,15 +2548,18 @@
>         </sect3>
> 
>         <sect3>
>-          <title>An Example <acronym>NAT</acronym> and Stateful Ruleset</title>
>-          <para>There are some additional configuration statements that
>-            need to be enabled to activate the <acronym>NAT</acronym> function of IPFW. The
>-            kernel source needs 'option divert' statement added to the
>-            other IPFIREWALL statements compiled into a custom kernel.
>+          <title>An Example <acronym>NAT</acronym> and Stateful Rule
>+          Set</title> 
>+
>+          <para>There are some additional configuration statements
>+            that need to be enabled to activate the
>+            <acronym>NAT</acronym> function of IPFW. The kernel
>+            needs 'option divert' statement added to the other
>+            IPFIREWALL statements compiled into a custom kernel.
>             </para>
> 
>           <para>In addition to the normal IPFW options in
>-            <filename>/etc/rc.conf</filename>, the following are needed.
>+            <filename>/etc/rc.conf</filename>, the following are needed:
>             </para>
> 
>           <programlisting>natd_enable="YES"                   # Enable <acronym>NAT</acronym>D function
>@@ -2571,70 +2582,73 @@
> 
>           <para>The processing flow starts with the first rule from the
>             top of the rule file and progress one rule at a time deeper
>-            into the file until the end is reach or the packet being
>+            into the file until the end is reached or the packet being
>             tested to the selection criteria matches and the packet is
>             released out of the firewall.  It is important to take notice
>             of the location of rule numbers 100 101, 450, 500, and 510.
>             These rules control the translation of the outbound and
>             inbound packets so their entries in the keep-state dynamic
>-            table always register the private Lan IP address. Next
>+            table always register the private LAN IP address. Next
>             notice that all the allow and deny rules specified the
>             direction the packet is going (IE outbound or inbound) and
>             the interface. Also notice that all the start outbound
>             session requests all skipto rule 500 for the network address
>             translation.</para>
> 
>-          <para>Lets say a LAN user uses their web browser to get a web
>-            page. Web pages use port 80 to communicate over. So the
>-            packet enters the firewall, It does not match 100 because
>-            it is headed out not in. It passes rule 101 because this is
>-            the first packet so it has not been posted to the keep-state
>-            dynamic table yet. The packet finally comes to rule 125 a
>-            matches.  It is outbound through the NIC facing the public
>-            Internet. The packet still has it's source IP address as a
>-            private Lan IP address. On the match to this rule, two
>-            actions take place.  The keep-state option will post this rule
>-            into the keep-state dynamic rules table and the specified
>-            action is executed. The action is part of the info posted to
>-            the dynamic table.  In this case it is "skipto rule 500".  Rule
>-            500 <acronym>NAT</acronym>s the packet IP address and out it goes. Remember
>-            this, this is very important. This packet makes it's way to
>-            the destination and returns and enters the top of the rule
>-            set. This time it does match rule 100 and has it destination
>-            IP address mapped back to it's corresponding Lan IP address.
>-            It then is processed by the check-state rule, it's found in
>-            the table as an existing session conversation and released
>-            to the LAN. It goes to the LAN PC that sent it and a new
>-            packet is sent requesting another segment of the data from
>-            the remote server. This time it gets checked by the
>-            check-state rule and it's outbound entry is found,  the
>+          <para>Lets say a LAN user uses their web browser to get a
>+            web page. Web pages use port 80 to communicate over. So
>+            the packet enters the firewall. It does not match 100
>+            because it is headed out not in. It passes rule 101
>+            because this is the first packet so it has not been posted
>+            to the keep-state dynamic table yet. The packet finally
>+            comes to rule 125 a matches. It is outbound through the
>+            NIC facing the public Internet. The packet source IP
>+            address is still a private LAN IP address. On the match to
>+            this rule, two actions take place. The keep-state option
>+            will post this rule into the keep-state dynamic rules
>+            table and the specified action is executed. The action is
>+            part of the info posted to the dynamic table.  In this
>+            case it is "skipto rule 500".  Rule 500
>+            <acronym>NAT</acronym>s the packet IP address and out it
>+            goes. Remember this, this is very important. This packet
>+            makes its way to the destination and returns and enters
>+            the top of the rule set. This time it does match rule 100
>+            and has it destination IP address mapped back to it's
>+            corresponding Lan IP address.  Then it is processed by the
>+            check-state rule, it's found in the table as belonging to
>+            an existing session conversation and released to the
>+            LAN. It goes to the LAN PC that sent it and a new packet
>+            is sent requesting another segment of the data from the
>+            remote server. This time it gets checked by the
>+            check-state rule and, as its outbound entry is found, the
>             associated action, 'skipto 500', is executed.  The packet
>-            jumps to rule 500 gets <acronym>NAT</acronym>ed and released on it's way out.
>-            </para>
>+            jumps to rule 500 gets <acronym>NAT</acronym>ed and
>+            released on it's way out.  </para>
> 
>           <para>On the inbound side, everything coming in that is part
>             of an existing session conversation is being automatically
>             handled by the check-state rule and the properly placed
>-            divert natd rules. All we have to address is denying all the
>-            bad packets and only allowing in the authorized services.
>-            Lets say there is a apache server running on the firewall
>-            box and we want people on the public Internet to be able to
>-            access the local web site. The new inbound start request
>-            packet matches rule 100 and its IP address is mapped to LAN
>-            IP for the firewall box. The packet is them matched against
>-            all the nasty things we want to check for and finally
>-            matches against rule 425. On a match two things occur, the
>-            limit option is an extension to keep-state. The packet rule
>-            is posted to the keep-state dynamic table but this time any
>-            new session requests originating from that source IP address
>-            is limited to 2. This defends against DoS attacks of service
>-            IP for the firewall box. The packet is them matched against
>-            all the nasty things we want to check for and finally
>-            matches against rule 425. On a match two things occur, the
>-            limit option is an extension to keep-state. The packet rule
>-            is posted to the keep-state dynamic table but this time any
>-            new session requests originating from that source IP address
>-            is limited to 2. This defends against DoS attacks of service
>-            running on the specified port number. The action is allow so
>-            the packet is released to the LAN. On return the check-state
>-            rule recognizes the packet as belonging to an existing
>-            session conversation sends it to rule 500 for <acronym>NAT</acronym>ing and
>-            released to outbound interface.</para>
>+            divert natd rules. All we have to address is denying all
>+            the bad packets and only allowing in the authorized
>+            services.  Lets say there is a apache server running on
>+            the firewall box and we want people on the public Internet
>+            to be able to access the local web site. The new inbound
>+            start request packet matches rule 100 and its IP address
>+            is mapped to LAN IP for the firewall box. The packet is
>+            them matched against all the nasty things we want to check
>+            for and finally matches against rule 425. On a match two
>+            things occur. The packet rule is posted to the keep-state
>+            dynamic table but this time the number of new session
>+            requests originating from that source IP address is
>+            limited to 2. This defends against DoS attacks of service
>+            running on the specified port number. The action is allow
>+            so the packet is released to the LAN. On return the
>+            check-state rule recognizes the packet as belonging to an
>+            existing session conversation sends it to rule 500 for
>+            <acronym>NAT</acronym>ing and released to outbound
>+            interface.</para>
> 
>-          <para>Example Ruleset #1:</para>
>+          <para>Example Rule Set #1:</para>
> 
>           <programlisting>#!/bin/sh
> cmd="ipfw -q add"
>@@ -2645,7 +2659,7 @@
> 
> ipfw -q -f flush
> 
>-&dollar;cmd 002 allow all from any to any via xl0  # exclude Lan traffic
>+&dollar;cmd 002 allow all from any to any via xl0  # exclude LAN traffic
> &dollar;cmd 003 allow all from any to any via lo0  # exclude loopback traffic
> 
> &dollar;cmd 100 divert natd ip from any to any in via &dollar;pif
>@@ -2688,7 +2702,7 @@
>             to help the inexperienced IPFW rule writer to better
>             understand what the rules are doing.</para>
> 
>-          <para>Example Ruleset #2:</para>
>+          <para>Example Rule Set #2:</para>
> 
>           <programlisting>
> #!/bin/sh

Actions: View | Diff

Attachments on bug 75422: 49379