Date: Thu, 23 Dec 2004 08:43:41 +0100 (CET) From: Matteo Riondato <rionda@gufi.org> To: FreeBSD-gnats-submit@FreeBSD.org Subject: docs/75422: [patch] syntax mistakes and obscurity in firewall chapter Message-ID: <200412230743.iBN7hfEa084858@utenti.gufi.org> Resent-Message-ID: <200412230750.iBN7oLwM043681@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 75422 >Category: docs >Synopsis: [patch] syntax mistakes and obscurity in firewall chapter >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Thu Dec 23 07:50:21 GMT 2004 >Closed-Date: >Last-Modified: >Originator: Matteo Riondato >Release: FreeBSD 6.0-CURRENT i386 >Organization: GUFI >Environment: FreeBSD kaiser.sig11.org 6.0-CURRENT FreeBSD 6.0-CURRENT #1: Fri Dec 10 15:41:10 CET 2004 root@kaiser.sig11.org:/usr/obj/usr/src/sys/KAISER i386 >Description: Handbook Firewall chapter is a bit confused and obscure. There are many syntax mistakes (such as "it's" instead of "its") >How-To-Repeat: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls.html >Fix: --- 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; 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 <pid></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> +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 - << 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 $oif proto tcp from any to $odns port = 53 $fks pass out quick on $oif proto udp from any to $odns port = 53 $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 $. Symbolic fields do not have - the $ prefix. The value to populate the Symbolic field must + the $ 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 $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 -$cmd 002 allow all from any to any via xl0 # exclude Lan traffic +$cmd 002 allow all from any to any via xl0 # exclude LAN traffic $cmd 003 allow all from any to any via lo0 # exclude loopback traffic $cmd 100 divert natd ip from any to any in via $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 >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200412230743.iBN7hfEa084858>