Date: Fri, 24 Apr 2009 02:23:36 -0400 From: Tom Rhodes <trhodes@FreeBSD.org> To: Manolis Kiagias <sonic2000gr@gmail.com> Cc: pepper@cbio.mskcc.org, pgj@FreeBSD.org, freebsd-doc@FreeBSD.org, trhodes@FreeBSD.org, keramida@FreeBSD.org, gabor@FreeBSD.org Subject: Re: [PATCH] for the 'firewalls' chapter Message-ID: <20090424022336.3f4c6792.trhodes@FreeBSD.org> In-Reply-To: <49E796E6.70709@gmail.com> References: <49E796E6.70709@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hey Manolis, My review, as promised, please see comments in line. I'm sorry it came so late! Thanks! On Thu, 16 Apr 2009 23:36:54 +0300 Manolis Kiagias <sonic2000gr@gmail.com> wrote: > Hey all, > > Once again, calling all my usual reviewers (as well as anyone else who > wishes to comment) on this (unfortunately long) patch for the > 'firewalls' chapter. > I've been writing and rewriting this for quite some time now, partly > while I was translating the chapter to Greek but also for quite some > time afterwards. It has gone through many changes and also includes > relevant parts from PR docs/131568 (author CCed). I will try to > summarize some of the changes, although this is as huge a task as the > patch itself! > > - Attempt to reduce some duplication. An identical paragraph on what is > an inclusive firewall was removed from each section, rephrased and added > at the beginning of the chapter. There are still more sections that > contain duplicate information. > - Convert to passive voice where possible and reduce amount of 'you' > (and in some cases 'I') references > - Rephrase several paragraphs (some were already commented as > problematic in the source). There were cases were the information was > clearly wrong (i.e. it was referenced that a packet exits the network, > reaches the destination and returns. Clearly, this is not the same > packet). Also not all firewalls need to have two interfaces (this was > submitted in the above PR). > - Attempt to improve markup. Originally I was planning to use <acronym>s > everywhere, but the chapter is so full of them, that even the subtle > dotted line HTML rendering becomes tiring after a while. I did insert > <acronym>s for consistency, where some terms were already marked (i.e. > TCP) and adjacent terms were not (i.e. UDP). If people feel we should > markup all of them, I'll gladly do it. I also inserted/fixed numerous > other tags (mostly <literal>) > - Fix grammar / syntax / spelling in several cases > - Numerous other changes that will hopefully become clear while reading > the patch itself > > Here is the diff: > > http://people.freebsd.org/~manolis/firewalls.diff > > If you prefer to read the HTML build: > > http://www.freebsdgr.org/handbook-mine/firewalls.html > > Plase take all the time you need to read this - I will try to integrate > any suggested changes as they are coming, and obviously this is not > going in soon :) diff -r 126c435025de -r f6a8c68b044d en_US.ISO8859-1/books/handbook/firewalls/chapter.sgml --- a/en_US.ISO8859-1/books/handbook/firewalls/chapter.sgml Sun Feb 01 15:17:37 2009 +0200 +++ b/en_US.ISO8859-1/books/handbook/firewalls/chapter.sgml Thu Apr 16 22:46:31 2009 +0300 @@ -124,12 +124,22 @@ reverse. It only allows traffic matching the rules through and blocks everything else.</para> - <para>Inclusive firewalls are generally safer than exclusive + <para>An inclusive firewall offers much better control of the outgoing + traffic, making it a better choice for systems that offer services to + the public Internet. It also controls the type of traffic originating + from the public Internet that can gain access to your private network. + All traffic that does not match the rules, is blocked and logged by + default design. Inclusive firewalls are generally safer than exclusive I don't like "by default design" here. It just kind of sounds a tad bit off. How about "by design" instead? firewalls because they significantly reduce the risk of allowing - unwanted traffic to pass through the firewall.</para> + unwanted traffic to pass through them.</para> + + <note> + <para>Unless noted otherwise, all the configurations and example + rulesets in this chapter, create inclusive type firewalls.</para> "all configuration and example rulesets in" + </note> <para>Security can be tightened further using a <quote>stateful - firewall</quote>. With a stateful firewall the firewall keeps + firewall</quote>. This type of firewall keeps track of which connections are opened through the firewall and will only allow traffic through which either matches an existing connection or opens a new one. The disadvantage of a stateful @@ -153,14 +163,14 @@ &man.altq.4; and &man.dummynet.4;. Dummynet has traditionally been closely tied with <acronym>IPFW</acronym>, and <acronym>ALTQ</acronym> with - <acronym>PF</acronym>. Traffic shaping for <acronym>IPFILTER</acronym> can currently - be done with <acronym>IPFILTER</acronym> for NAT and filtering and + <acronym>PF</acronym>. Traffic shaping for IPFILTER can currently + be done with IPFILTER for NAT and filtering and <acronym>IPFW</acronym> with &man.dummynet.4; Too many "and" in this sentence. How about: "Traffic shaping for IPFILTER can currently be done with IPFILTER for NAT. IPFW filtering is handled via the &man.dummynet.4; driver ..." Perhaps the entire paragraph should be re-worded after we commit these other changes? <emphasis>or</emphasis> by using <acronym>PF</acronym> with <acronym>ALTQ</acronym>. IPFW, and PF all 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> + have different rule syntax.</para> "have a different rule syntax." <para>The reason that &os; has multiple built in firewall packages is that different people have different requirements and @@ -174,7 +184,7 @@ <para>Since all firewalls are based on inspecting the values of selected packet control fields, the creator of the firewall rulesets must have an understanding of how - <acronym>TCP</acronym>/IP works, what the different values in + <acronym>TCP/IP</acronym> works, what the different values in the packet control fields are and how these values are used in a normal session conversation. For a good explanation go to: <ulink @@ -233,7 +243,7 @@ system will dynamically load the PF kernel module when the &man.rc.conf.5; statement <literal>pf_enable="YES"</literal> is present. However, the <acronym>PF</acronym> module will - not load if the system cannot find a <acronym>PF</acronym> + not be loaded if the system cannot find a <acronym>PF</acronym> ruleset configuration file. The default location is <filename>/etc/pf.conf</filename>. If your <acronym>PF</acronym> ruleset is located somewhere else put @@ -291,7 +301,7 @@ paired with &man.carp.4; to create failover firewalls using <acronym>PF</acronym>. More information on <acronym>CARP</acronym> can be found in - <link linkend="carp">chapter 29</link> of the handbook.</para> + <xref linkend="carp"> of the Handbook.</para> <para>The <acronym>PF</acronym> kernel options can be found in <filename>/usr/src/sys/conf/NOTES</filename> and are reproduced @@ -448,14 +458,14 @@ <para><literal>options ALTQ</literal> enables the <acronym>ALTQ</acronym> framework.</para> - <para><literal>options ALTQ_CBQ</literal> enables Class Based - Queuing (<acronym>CBQ</acronym>). <acronym>CBQ</acronym> + <para><literal>options ALTQ_CBQ</literal> enables <emphasis>Class Based + Queuing</emphasis> (<acronym>CBQ</acronym>). <acronym>CBQ</acronym> allows you to divide a connection's bandwidth into different classes or queues to prioritize traffic based on filter rules.</para> - <para><literal>options ALTQ_RED</literal> enables Random Early - Detection (<acronym>RED</acronym>). <acronym>RED</acronym> is + <para><literal>options ALTQ_RED</literal> enables <emphasis>Random Early + Detection</emphasis> (<acronym>RED</acronym>). <acronym>RED</acronym> is used to avoid network congestion. <acronym>RED</acronym> does this by measuring the length of the queue and comparing it to the minimum and maximum thresholds for the queue. If the @@ -463,16 +473,16 @@ True to its name, <acronym>RED</acronym> drops packets from different connections randomly.</para> - <para><literal>options ALTQ_RIO</literal> enables Random Early - Detection In and Out.</para> + <para><literal>options ALTQ_RIO</literal> enables <emphasis>Random Early + Detection In and Out</emphasis>.</para> <para><literal>options ALTQ_HFSC</literal> enables the - Hierarchical Fair Service Curve Packet Scheduler. For more + <emphasis>Hierarchical Fair Service Curve Packet Scheduler</emphasis>. For more information about <acronym>HFSC</acronym> see: <ulink url="http://www-2.cs.cmu.edu/~hzhang/HFSC/main.html"></ulink>.</para>; - <para><literal>options ALTQ_PRIQ</literal> enables Priority - Queuing (<acronym>PRIQ</acronym>). <acronym>PRIQ</acronym> + <para><literal>options ALTQ_PRIQ</literal> enables <emphasis>Priority + Queuing</emphasis> (<acronym>PRIQ</acronym>). <acronym>PRIQ</acronym> will always pass traffic that is in a higher queue first.</para> @@ -492,11 +502,6 @@ <secondary>IPFILTER</secondary> </indexterm> - <note> - <para>This section is work in progress. The contents might - not be accurate at all times.</para> - </note> - <para>The author of IPFILTER is Darren Reed. IPFILTER is not operating system dependent: it is an open source application and has been ported to &os;, NetBSD, OpenBSD, &sunos;, HP/UX, and @@ -519,30 +524,17 @@ stateless type of rules. Over time IPF has been enhanced to include a <quote>quick</quote> option and a stateful <quote>keep state</quote> option which drastically modernized the rules - processing logic. IPF's official documentation covers the legacy - rule coding parameters and the legacy rule file processing + processing logic. IPF's official documentation covers only the legacy + rule coding parameters and rule file processing logic. The modernized functions are only included as additional options, completely understating their benefits in producing a - far superior secure firewall.</para> + far superior and more secure firewall.</para> <para>The instructions contained in this section are based on using rules that contain the <quote>quick</quote> option and the stateful <quote>keep state</quote> option. This is the basic framework for coding an inclusive firewall rule set.</para> - <!-- XXX: something like this already in - <xref linkend="firewalls-concepts"> - AND: the para below is repeated 3 times in this chapter--> - - <para>An inclusive firewall only allows packets matching the rules - to pass through. This way you can control what services can - originate behind the firewall destined for the public Internet - 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 herein.</para> - <para>For detailed explanation of the legacy rules processing method see: <ulink url="http://www.obfuscation.org/ipf/ipf-howto.html#TOC_1"></ulink>; @@ -567,13 +559,13 @@ <para>IPF is included in the basic &os; install as a separate run time loadable module. The system will dynamically load the IPF - kernel loadable module when the rc.conf statement + kernel loadable module when the <filename>rc.conf</filename> 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 + <literal>default pass all</literal> options. There is no 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> + to <literal>block all</literal>. This can be done just by adding + a <literal>block all</literal> rule at the end of your rule set.</para> </sect2> <sect2> @@ -603,7 +595,7 @@ <secondary>kernel options</secondary> </indexterm> - <para>It is not a mandatory requirement that you enable IPF by + <para>It is not a mandatory requirement to enable IPF by compiling the following options into the &os; kernel. It is only presented here as background information. Compiling IPF into the kernel causes the loadable module to never be @@ -630,16 +622,15 @@ the default behavior so any packet not matching a firewall <literal>pass</literal> rule gets blocked.</para> - <para>These settings will take effect only after you have built - and installed a kernel with them set.</para> + <para>These settings will take effect only after installing a kernel + that has been built with the above options set.</para> </sect2> <sect2> <title>Available rc.conf Options</title> - <para>You need the following statements in - <filename>/etc/rc.conf</filename> to activate IPF at boot - time:</para> + <para>To activate IPF at boot time, the following statements need to + be added to <filename>/etc/rc.conf</filename>:</para> <programlisting>ipfilter_enable="YES" # Start ipf firewall ipfilter_rules="/etc/ipf.rules" # loads rules definition text file @@ -649,9 +640,9 @@ # v = log tcp window, ack, seq # n = map IP & port to names</programlisting> - <para>If you have a LAN behind this firewall that uses the - reserved private IP address ranges, then you need to add the - following to enable <acronym>NAT</acronym> + <para>If there is a LAN behind this firewall that uses the + reserved private IP address ranges, the following lines will have to + be added to enable <acronym>NAT</acronym> functionality:</para> <programlisting>gateway_enable="YES" # Enable as LAN gateway @@ -664,10 +655,10 @@ <indexterm><primary><command>ipf</command></primary></indexterm> - <para>The ipf command is used to load your rules file. Normally - you create a file containing your custom rules and use this - command to replace in mass the currently running firewall - internal rules:</para> + <para>The &man.ipf.8; command is used to load your rules file. "ruleset file." ? + Your custom rules would normally be placed in a file, and the + following command could then be used to replace in mass the + currently running firewall rules:</para> <screen>&prompt.root; <userinput>ipf -Fa -f /etc/ipf.rules</userinput></screen> @@ -738,7 +729,7 @@ Packet log flags set: (0)</screen> <para>When supplied with either <option>-i</option> for inbound - or <option>-o</option> for outbound, it will retrieve and + or <option>-o</option> for outbound, the command will retrieve and display the appropriate list of filter rules currently installed and in use by the kernel.</para> @@ -772,7 +763,7 @@ <command>ipfstat</command> command is the <option>-t</option> flag which displays the state table in a way similar to the way &man.top.1; shows the &os; running process table. When your - firewall is under attack this function gives you the ability to + firewall is under attack, this function gives you the ability to identify, drill down to, and see the attacking packets. The optional sub-flags give the ability to select the destination or source IP, port, or protocol that you want to monitor in @@ -792,19 +783,19 @@ </indexterm> <para>In order for <command>ipmon</command> to work properly, the - kernel option IPFILTER_LOG must be turned on. This command has + kernel option <literal>IPFILTER_LOG</literal> must be turned on. This command has two different modes that it can be used in. Native mode is the - default mode when you type the command on the command line + default mode when the command is typed on the command line without the <option>-D</option> flag.</para> - <para>Daemon mode is for when you want to have a continuous - system log file available so that you can review logging of - past events. This is how &os; and IPFILTER are configured to + <para>Daemon mode is for when a continuous + system log file is desired, so that logging of past events may be + reviewed. This is how &os; and IPFILTER are configured to work together. &os; has a built in facility to automatically rotate system logs. That is why outputting the log information - to syslogd is better than the default of outputting to a - regular file. In the default <filename>rc.conf</filename> file - you see the ipmon_flags statement uses the <option>-Ds</option> + to &man.syslogd.8; is better than the default of outputting to a + regular file. In the default <filename>rc.conf</filename> file, + the <literal>ipmon_flags</literal> statement uses the <option>-Ds</option> flags:</para> <programlisting>ipmon_flags="-Ds" # D = start as daemon @@ -815,7 +806,7 @@ <para>The benefits of logging are obvious. It provides the ability to review, after the fact, information such as which packets had been dropped, what addresses they came from and - where they were going. These all give you a significant edge + where they were going. These all can provide a significant edge "These can all provide" if we're making the change here. :) in tracking down attackers.</para> <para>Even with the logging facility enabled, IPF will not @@ -826,7 +817,7 @@ <para>It is very customary to include a default deny everything rule with the log keyword included as your last rule in the - rule set. This way you get to see all the packets that did not + rule set. This makes possible to see all the packets that did not "This makes it possible" match any of the rules in the rule set.</para> </sect2> @@ -850,15 +841,15 @@ <!-- XXX: "can be considered short" == "with incomplete header" --> <para>To setup IPFILTER to log all data to - <filename>/var/log/ipfilter.log</filename>, you will need to - create the file. The following command will do that:</para> + <filename>/var/log/ipfilter.log</filename>, the file will need to be + created beforehand. The following command will do that:</para> <screen>&prompt.root; <userinput>touch /var/log/ipfilter.log</userinput></screen> - <para>The syslog function is controlled by definition statements + <para>The &man.syslogd.8; 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 + flexibility in how <application>syslog</application> will deal with system messages issued by software applications like IPF.</para> <para>Add the following statement to @@ -871,13 +862,13 @@ file location.</para> <para>To activate the changes to <filename>/etc/syslog.conf - </filename> you can reboot or bump the syslog task into + </filename> you can reboot or bump the &man.syslogd.8; daemon into re-reading <filename>/etc/syslog.conf</filename> by running <command>/etc/rc.d/syslogd reload</command></para> <para>Do not forget to change <filename>/etc/newsyslog.conf</filename> to rotate the new log - you just created above.</para> + just created above.</para> s/just // </sect2> <sect2> @@ -924,18 +915,18 @@ <listitem> <para>The addresses. This is actually 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> + symbol, and the destination address and port, e.g. "e.g.:" + <literal>209.53.17.22,80 -> 198.73.220.17,1722</literal>.</para> </listitem> <listitem> <para><literal>PR</literal> followed by the protocol name or - number, e.g. PR tcp.</para> + number, e.g. <literal>PR tcp</literal>.</para> "e.g.:" </listitem> <listitem> <para><literal>len</literal> followed by the header length - and total length of the packet, e.g. len 20 40.</para> + and total length of the packet, e.g. <literal>len 20 40</literal>.</para> "e.g.:" here too please. :) </listitem> </orderedlist> @@ -958,15 +949,15 @@ <para>Some experienced IPF users create a file containing the rules and code them in a manner compatible with running them as a script with symbolic substitution. The major benefit of - doing this is that you only have to change the value associated - with the symbolic name and when the script is run all the rules + doing this is that only the value associated + with the symbolic name needs to be changed, and when the script is run all the rules containing the symbolic name will have the value substituted in - the rules. Being a script, you can use symbolic substitution + the rules. Being a script, symbolic substitution can be used to code frequently used values and substitute them in multiple - rules. You will see this in the following example.</para> + rules. This can be seen in the following example.</para> - <para>The script syntax used here is compatible with the sh, csh, - and tcsh shells.</para> + <para>The script syntax used here is compatible with the &man.sh.1;, &man.csh.1;, + and &man.tcsh.1; shells.</para> <para>Symbolic substitution fields are prefixed with a dollar sign: <literal>$</literal>.</para> @@ -1012,8 +1003,8 @@ <para>That is all there is to it. The rules are not important in this example; how the symbolic substitution fields are populated and used are. If the above example was in a file - named <filename>/etc/ipf.rules.script</filename>, you could - reload these rules by entering the following command:</para> + named <filename>/etc/ipf.rules.script</filename>, these rules could be + reloaded by entering the following command:</para> <screen>&prompt.root; <userinput>sh /etc/ipf.rules.script</userinput></screen> @@ -1040,7 +1031,7 @@ value) into <filename>/etc/rc.conf</filename> file.</para> <para>Add a script like the following to your - <filename>/usr/local/etc/rc.d/</filename> startup + <filename class="directory">/usr/local/etc/rc.d/</filename> startup directory. The script should have an obvious name like <filename>ipf.loadrules.sh</filename>. The <filename>.sh</filename> extension is mandatory.</para> @@ -1062,25 +1053,19 @@ <sect2> <title>IPF Rule Sets</title> - <!-- XXX: looks incorrect (and duplicated 2 times in this chapter): - 1. Packet can be processed two times depend of firewall - firewall configuration, but "return trip back" is - another packet. - 2. "Each TCP/IP service ... is predefined by its protocol ..." - - this shold be about packet and it's parameters - (source/destination address and port). --> - - <para>A rule set is a group of ipf rules coded to pass or block + <para>A rule set is a group of IPF rules coded to pass or block packets based on the values contained in the packet. The bi-directional exchange of packets between hosts comprises a - session conversation. The firewall rule set processes the - packet two 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, - 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 - rules which will pass or block services.</para> + session conversation. The firewall rule set processes both the Are we using "rule set" or "ruleset" because up above it was just one word. We should come to a conclusion and run a %s/one/right one/g across this chapter then. :) + packets arriving from the public Internet, as well as the packets + produced by the system as a response to them. + Each <acronym>TCP/IP</acronym> service (i.e. telnet, www, "i.e.: " + mail, etc.) is predefined by its protocol and privileged (listening) + port. Packets destined for a specific service, originate from the + source address using an unprivileged (high order) port and target the + specific service port on the destination address. All the above + parameters (i.e. ports and addresses) can be used as selection "i.e.: " again. :) + criteria to create rules which will pass or block services.</para> <indexterm> <primary>IPFILTER</primary> @@ -1101,19 +1086,6 @@ basic framework for coding an inclusive firewall rule set.</para> - <!-- XXX: something like this already in - <xref linkend="firewalls-concepts"> - AND: the para below is repeated 3 times in this chapter--> - - <para>An inclusive firewall only allows services matching the - rules through. This way you can control what services can - originate behind the firewall destined for the public Internet - 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 securer than exclusive firewall rule - sets and is the only rule set type covered herein.</para> - All this removal is key. Seriously, this has needed to be done for some time. Thanks!! <warning> <para>When working with the firewall rules, be <emphasis>very careful</emphasis>. Some configurations <emphasis>will @@ -1187,7 +1159,7 @@ <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 + <emphasis>must</emphasis> have an action. The following actions are recognized:</para> <para><literal>block</literal> indicates that the packet should @@ -1204,7 +1176,7 @@ <para>A mandatory requirement is that each filter rule explicitly state which side of the I/O it is to be used on. - The next keyword must be either in or out and one or the + The next keyword must be either <literal>in</literal> or <literal>out</literal> and one or the other has to be coded or the rule will not pass syntax checks.</para> @@ -1250,8 +1222,8 @@ processing logic.</para> <para>When a packet is logged, the headers of the packet are - written to the IPL packet logging pseudo-device. - Immediately following the log keyword, the following + written to the <acronym>IPL</acronym> packet logging pseudo-device. + Immediately following the <literal>log</literal> keyword, the following qualifiers may be used (in this order):</para> <para><literal>body</literal> indicates that the first 128 @@ -1259,8 +1231,8 @@ headers.</para> <para><literal>first</literal> If the <literal>log</literal> - keyword is being used in conjunction with a <quote>keep - state</quote> option, it is recommended that this option is + keyword is being used in conjunction with a <literal>keep + state</literal> option, it is recommended that this option is also applied so that only the triggering packet is logged and not every packet which thereafter matches the <quote>keep state</quote> information.</para> @@ -1270,7 +1242,7 @@ <title>SELECTION</title> <para>The keywords described in this section are used to - describe attributes of the packet to be interrogated when + describe attributes of the packet to be checked when determining whether rules match or not. There is a keyword subject, and it has sub-option keywords, one of which has to be selected. The following general-purpose @@ -1291,7 +1263,7 @@ protocol names found in <filename>/etc/protocols</filename> are recognized and may be used. The special protocol keyword <literal>tcp/udp</literal> may be used to match either a - <acronym>TCP</acronym> or a UDP packet, and has been added as + <acronym>TCP</acronym> or a <acronym>UDP</acronym> packet, and has been added as a convenience to save duplication of otherwise identical rules.</para> </sect3> @@ -1303,23 +1275,19 @@ synonym for <quote>from any to any</quote> with no other match parameters.</para> - <para><literal>from src to dst</literal>: the from and to + <para><literal>from src to dst</literal>: the <literal>from</literal> and <literal>to</literal> keywords are used to match against IP addresses. Rules must - specify BOTH source and destination parameters. + specify <emphasis>both</emphasis> source and destination parameters. <literal>any</literal> is a special keyword that matches any - IP address. Examples of use: <quote>from any to any</quote> - or <quote>from 0.0.0.0/0 to any</quote> or <quote>from any to - 0.0.0.0/0</quote> or <quote>from 0.0.0.0 to any</quote> or - <quote>from any to 0.0.0.0</quote>.</para> + IP address. Examples of use: <literal>from any to any</literal> + or <literal>from 0.0.0.0/0 to any</literal> or <literal>from any to + 0.0.0.0/0</literal> or <literal>from 0.0.0.0 to any</literal> or + <literal>from any to 0.0.0.0</literal>.</para> - <!-- XXX: Needs rewording --> - - <para>IP addresses may be specified as a dotted IP address - numeric form/mask-length, or as single dotted IP address - numeric form.</para> <para>There is no way to match ranges of IP addresses which - do not express themselves easily as mask-length. See this + do not express themselves easily using the dotted numeric + form / mask-length notation. See this web page for help on writing mask-length: <ulink url="http://jodies.de/ipcalc"></ulink>.</para>; It's a port too, that ipcalc utility. :) </sect3> @@ -1329,21 +1297,21 @@ <para>If a port match is included, for either or both of source and destination, then it is only applied to - <acronym>TCP</acronym> and UDP packets. When composing port + <acronym>TCP</acronym> and <acronym>UDP</acronym> packets. When composing port comparisons, either the service name from <filename>/etc/services</filename> or an integer port number - may be used. When the port appears as part of the from + may be used. When the port appears as part of the <literal>from</literal> object, it matches the source port number; when it appears - as part of the to object, it matches the destination port + as part of the <literal>to</literal> object, it matches the destination port number. The use of the port option with the <literal>to</literal> object is a mandatory requirement for the modernized rules processing logic. Example of use: - <quote>from any to any port = 80</quote></para> + <literal>from any to any port = 80</literal></para> - <!-- XXX: Needs rewriting --> + <!-- XXX: Rewritten, but probably needs more changes --> - <para>Port comparisons may be done in a number of forms, with - a number of comparison operators, or port ranges may be + <para>Single port comparisons may be done in a number of ways, using + a number of different comparison operators. Port ranges may also be specified.</para> <para>port "=" | "!=" | "<" | ">" | "<=" | ">=" | @@ -1364,8 +1332,8 @@ <title><acronym>TCP</acronym>_FLAG</title> <para>Flags are only effective for <acronym>TCP</acronym> - filtering. The letters represents one of the possible flags - that can be interrogated in the <acronym>TCP</acronym> packet + filtering. The letters represent one of the possible flags + that can be matched against the <acronym>TCP</acronym> packet header.</para> <para>The modernized rules processing logic uses the @@ -1402,15 +1370,15 @@ exchange of packets comprising a session conversation. When activated, keep-state dynamically generates internal rules for each anticipated packet being exchanged during the - bi-directional session conversation. It has the interrogation - abilities to determine if the session conversation between the + bi-directional session conversation. It has sufficient matching + capabilities to determine if the session conversation between the originating sender and the destination are following the valid procedure of bi-directional packet exchange. Any packets that 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 + <para>Keep state will also allow <acronym>ICMP</acronym> packets related to a + <acronym>TCP</acronym> or <acronym>UDP</acronym> session through. So if you get ICMP type 3 code 4 in response to some web surfing allowed out Missed <acronym> tag. :) by a keep state rule, they will be automatically allowed in. Any packet that IPF can be certain is part of an active @@ -1419,21 +1387,22 @@ <para>What happens is:</para> - <para>Packets destined to go out the interface connected to the + <para>Packets destined to go out through the interface connected to the public Internet are first checked against the dynamic state - table, if the packet matches the next expected packet - comprising in a active session conversation, then it exits the + table. If the packet matches the next expected packet + comprising an active session conversation, then it exits the firewall and the state of the session conversation flow is - updated in the dynamic state table, the remaining packets get - checked against the outbound rule set.</para> + updated in the dynamic state table. Packets that do not belong to + an already active session, are simply checked against the outbound + rule set.</para> - <para>Packets coming in to the interface connected to the public - Internet are first checked against the dynamic state table, if - the packet matches the next expected packet comprising a + <para>Packets coming in from the interface connected to the public + Internet are first checked against the dynamic state table. If + the packet matches the next expected packet comprising an active session conversation, then it exits the firewall and the state of the session conversation flow is updated in the - dynamic state table, the remaining packets get checked against - the inbound rule set.</para> + dynamic state table. Packets that do not belong to an already active + session, are simply checked against the inbound rule set.</para> <para>When the conversation completes it is removed from the dynamic state table.</para> @@ -1443,7 +1412,7 @@ packets will be allowed through automatically and any impostors automatically rejected. If a new session is blocked, none of its subsequent packets will be allowed through. Stateful - filtering has technically advanced interrogation abilities + filtering has technically advanced matching abilities capable of defending against the flood of different attack methods currently employed by attackers.</para> </sect2> @@ -1455,10 +1424,15 @@ <para>The following rule set is an example of how to code a very secure inclusive type of firewall. An inclusive firewall only - allows services matching pass rules through and blocks all - other by default. All firewalls have at the minimum two - interfaces which have to have rules to allow the firewall to - function.</para> + allows services matching <literal>pass</literal> rules through, and blocks all + other by default. Firewalls intended to protect other machines, "others by default." + also called <quote>network firewalls</quote>, should have at least + two interfaces, which are generally configured to trust one side + (the LAN) and not the other (the public Internet). Alternatively, Perhaps <acronym> around LAN? + a firewall might be configured to protect only the system running the + firewall software—this is called a "only the system it is running on—this is called a" Mainly to avoid saying "firewall" twice in the same sentence. + <quote>host based firewall</quote>, and is particularly appropriate + for servers on an untrusted network.</para> <para>All &unix; flavored systems including &os; are designed to use interface <devicename>lo0</devicename> and IP address @@ -1468,20 +1442,19 @@ special internally used packets.</para> <para>The interface which faces the public Internet is the one - where you place 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 + to place the rules that authorize and control access of the outbound + and inbound connections. This can be your user PPP <devicename>tun0</devicename> interface or your NIC that is connected to your DSL or cable modem.</para> - <para>In cases where one or more NICs are cabled to private LANs - behind the firewall, those interfaces must have a rule coded to - allow free unmolested movement of packets originating from - those LAN interfaces.</para> + <para>In cases where one or more NICs are cabled to private network + segments, those interfaces may require rules to allow packets + originating from those LAN interfaces transit to each other and/or + to the outside (Internet).</para> - <para>The rules should be first organized into three major - sections: all the free unmolested interfaces, the public - interface outbound, and the public interface inbound.</para> + <para>The rules should be organized into three major + sections: first trusted interfaces, then the public + interface outbound, and last the public untrusted interface inbound.</para> <para>The rules in each of the public interface sections should have the most frequently matched rules placed before less @@ -1490,66 +1463,65 @@ direction.</para> <para>The Outbound section in the following rule set only - contains 'pass' rules which contain selection values that + contains <literal>pass</literal> rules which contain selection values that uniquely identify the service that is authorized for public - Internet access. All the rules have the 'quick', 'on', - 'proto', 'port', and 'keep state' option coded. The 'proto - tcp' rules have the 'flag' option included to identify the + Internet access. All the rules have the <literal>quick</literal>, <literal>on</literal>, + <literal>proto</literal>, <literal>port</literal>, and <literal>keep state</literal> options set. The <literal>proto + tcp</literal> rules have the <literal>flag</literal> option included to identify the session start request as the triggering packet to activate the stateful facility.</para> <para>The Inbound section has all the blocking of undesirable packets first, for two different reasons. The first is that - these things being blocked may be part of an otherwise valid - packet which may be allowed in by the later authorized service - rules. The second reason is that by having a rule that - explicitly blocks selected packets that I receive on an - infrequent basis and that I do not want to see in the log, they - will not be caught by the last rule in the section which blocks - and logs all packets which have fallen through the rules. The - last rule in the section which blocks and logs all packets is - how you create the legal evidence needed to prosecute the - people who are attacking your system.</para> + malicious packets may be partial matches for legitimate traffic. + These packets have to be discarded rather than allowed in, based on + their partial matches against <literal>allow</literal> rules. + The second reason is that known and uninteresting rejects may be + blocked silently, rather than being caught and logged by the last + rules in the section. The final rule in each section, blocks and + logs all packets and can be used to 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 - response returned for any of the undesirable stuff, their - packets just get dropped and vanish. This way the attacker + <para>Another thing that should be taken care of, is to insure there is no + response returned for any of the undesirable traffic. Invalid + packets should just get dropped and vanish. This way the attacker has no knowledge if his packets have reached your system. The less the attackers can learn about your system, the more time they must invest before actually doing something bad. - The inbound 'nmap OS fingerprint' attempts rule I log + Rules that include a <literal>log first</literal> option, will only + log the event the first time they are triggered. This option is + included in the sample <literal>nmap OS fingerprint</literal> rule. + The <filename role="package">security/nmap</filename> utility is + commonly used by attackers who attempt to identify the operating + system of your server.</para> - <!-- XXX: what? --> + <para>Any time there are logged messages on a rule with + the <literal>log first</literal> option, an <command>ipfstat -hio</command> + command should be executed to evaluate how many times the rule has + actually matched. Large number of matches usually indicate that the + system is being flooded (i.e. under attack).</para> "i.e.: " again. :) - the first occurrence because this is something a attacker - would do.</para> - - <para>Any time you see log messages on a rule with 'log first'. - You should do an <command>ipfstat -hio</command> command to see - the number of times the rule has been matched so you know if - you are being flooded, i.e. under attack.</para> - - <para>When you log packets with port numbers you do not - recognize, look it up in <filename>/etc/services</filename> or - go to <ulink + <para>The <filename>/etc/services</filename> file may be used to + lookup unknown port numbers. Alternatively, + visit <ulink url="http://www.securitystats.com/tools/portsearch.php"></ulink>; - and do a port number lookup to find what the purpose of that - port number is.</para> + and do a port number lookup to find the purpose of a particular + port number.</para> <para>Check out this link for port numbers used by Trojans <ulink url="http://www.simovits.com/trojans/trojans.html"></ulink>.</para>; - <para>The following rule set is a complete very secure - 'inclusive' type of firewall rule set that I have used on my - system. You can not go wrong using this rule set for your own. - Just comment out any pass rules for services that you do not - want to authorize.</para> + <para>The following rule set creates a complete and very secure + <literal>inclusive</literal> type of firewall rule set that has been + tested on production systems. It can be easily modified for your + own system. Just comment out any <literal>pass</literal> rules for + services that should not be authorized.</para> - <para>If you see messages in your log that you want to stop - seeing just add a block rule in the inbound section.</para> + <para>To avoid logging unwanted messages, + just add a <literal>block</literal> rule in the inbound section.</para> - <para>You have to change the <devicename>dc0</devicename> - interface name in every rule to the interface name of the Nic + <para>The <devicename>dc0</devicename> interface name has to be changed + in every rule to the real interface name of the NIC card that connects your system to the public Internet. For user PPP it would be <devicename>tun0</devicename>.</para> @@ -1572,9 +1544,9 @@ ################################################################# # Interface facing Public Internet (Outbound Section) -# Interrogate session start requests originating from behind the +# Match session start requests originating from behind the # firewall on the private network -# or from this gateway server destine for the public Internet. +# or from this gateway server destined for the public Internet. ################################################################# # Allow out access to my ISP's Domain name server. @@ -1609,38 +1581,38 @@ # Allow out nntp news pass out quick on dc0 proto tcp from any to any port = 119 flags S keep state -# Allow out gateway & LAN users non-secure FTP ( both passive & active modes) +# Allow out gateway & LAN users' non-secure FTP ( both passive & active modes) # This function uses the IP<acronym>NAT</acronym> built in FTP proxy function coded in # the nat rules file to make this single rule function correctly. # If you want to use the pkg_add command to install application packages # on your gateway system you need this rule. pass out quick on dc0 proto tcp from any to any port = 21 flags S keep state -# Allow out secure FTP, Telnet, and SCP +# Allow out ssh/sftp/scp (telnet/rlogin/FTP replacements) # This function is using SSH (secure shell) pass out quick on dc0 proto tcp from any to any port = 22 flags S keep state -# Allow out non-secure Telnet +# Allow out insecure Telnet pass out quick on dc0 proto tcp from any to any port = 23 flags S keep state -# Allow out FBSD CVSUP function +# Allow out FreeBSD CVSup pass out quick on dc0 proto tcp from any to any port = 5999 flags S keep state # Allow out ping to public Internet pass out quick on dc0 proto icmp from any to any icmp-type 8 keep state -# Allow out whois for LAN PC to public Internet +# Allow out whois from LAN to public Internet pass out quick on dc0 proto tcp from any to any port = 43 flags S keep state # Block and log only the first occurrence of everything # else that's trying to get out. -# This rule enforces the block all by default logic. +# This rule implements the default block block out log first quick on dc0 all ################################################################# # Interface facing Public Internet (Inbound Section) -# Interrogate packets originating from the public Internet -# destine for this gateway server or the private network. +# Match packets originating from the public Internet +# destined for this gateway server or the private network. ################################################################# # Block all inbound traffic from non-routable or reserved address spaces @@ -1711,9 +1683,8 @@ # 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 -# at filling up your log file space. -# This rule enforces the block all by default logic. +# occurrence avoids filling up disk with Denial of Service logs. +# This rule implements the default block. block in log first quick on dc0 all ################### End of rules file #####################################</programlisting> </sect2> @@ -1735,8 +1706,8 @@ <see>NAT</see> </indexterm> - <para><acronym>NAT</acronym> stands for Network Address - Translation. To those familiar with &linux;, this concept is + <para><acronym>NAT</acronym> stands for <emphasis>Network Address + Translation</emphasis>. To those familiar with &linux;, this concept is called IP Masquerading; <acronym>NAT</acronym> and IP Masquerading are the same thing. One of the many things the IPF <acronym>NAT</acronym> function enables is the ability to @@ -1748,17 +1719,16 @@ normally assign a dynamic IP address to their non-commercial users. Dynamic means that the IP address can be different each time you dial in and log on to your ISP, or for cable and DSL - modem users when you power off and then power on your modems - you can get assigned a different IP address. This IP address - is how you are known to the public Internet.</para> + modem users, when the modem is power cycled. This dynamic IP + address is used to identify your system to the public Internet.</para> <para>Now lets say you have five PCs at home and each one needs Internet access. You would have to pay your ISP for an individual Internet account for each PC and have five phone lines.</para> - <para>With <acronym>NAT</acronym> you only need a single account - with your ISP, then cable your other four PCs to a switch and + <para>With <acronym>NAT</acronym> only a single account is needed + with your ISP. The other four PCs may then be cabled 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 @@ -1766,18 +1736,9 @@ exits the firewall bound for the public Internet. It also does the reverse translation for returning packets.</para> - <para><acronym>NAT</acronym> is most often accomplished without - the approval, or knowledge, of your ISP and in most cases is - grounds for your ISP terminating your account if found out. - Commercial users pay a lot more for their Internet connection - and usually get assigned a block of static IP address which - never change. The ISP also expects and consents to their - Commercial customers using <acronym>NAT</acronym> for their - internal private LANs.</para> - <para>There is a special range of IP addresses reserved for - <acronym>NAT</acronym>ed private LAN IP address. According to - RFC 1918, you can use the following IP ranges for private nets + <acronym>NAT</acronym>ed private LANs. According to + RFC 1918, the following IP ranges may be used for private nets which will never be routed directly to the public Internet:</para> @@ -1837,7 +1798,7 @@ <para>When changing the <acronym>NAT</acronym> rules after <acronym>NAT</acronym> has been started, make your changes to - the file containing the NAT rules, then run ipnat command with + the file containing the NAT rules, then run the <command>ipnat</command> 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> @@ -1901,18 +1862,18 @@ <para>A packet arrives at the firewall from the LAN with a public destination. It passes through the outbound filter rules, - <acronym>NAT</acronym> gets his turn at the packet and applies + <acronym>NAT</acronym> gets its turn at the packet and applies its rules top down, first matching rule wins. <acronym>NAT</acronym> tests each of its rules against the - packets interface name and source IP address. When a packets + packet's interface name and source IP address. When a packet's interface name matches a <acronym>NAT</acronym> rule then the - [source IP address, i.e. private LAN IP address] of the packet + source IP address (i.e. private LAN IP address) of the packet i.e.: again please. is checked to see if it falls within the IP address range specified to the left of the arrow symbol on the <acronym>NAT</acronym> rule. On a match the packet has its source IP address rewritten with the public IP address obtained by the <literal>0/32</literal> keyword. - <acronym>NAT</acronym> posts a entry in its internal + <acronym>NAT</acronym> posts an entry in its internal <acronym>NAT</acronym> table so when the packet returns from the public Internet it can be mapped back to its original private IP address and then passed to the filter rules for @@ -1965,11 +1926,11 @@ <para>In the above rule the packet's source port is unchanged as the packet passes through IP<acronym>NAT</acronym>. By - adding the portmap keyword you can tell - IP<acronym>NAT</acronym> to only use source ports in a range. + adding the <literal>portmap</literal> keyword, + IP<acronym>NAT</acronym> can be directed to only use source ports in the specified range. For example the following rule will tell IP<acronym>NAT</acronym> to modify the source port to be - within that range:</para> + within the range shown:</para> <programlisting>map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:60000</programlisting> @@ -1982,12 +1943,12 @@ </sect3> <sect3> - <title>Using a pool of public addresses</title> + <title>Using a Pool of Public Addresses</title> <para>In very large LANs there comes a point where there are just too many LAN addresses to fit into a single public address. If a block - of public IP addresses is available, you can use these addresses as - a <quote>pool</quote>, and let IP<acronym>NAT</acronym> pick one of + of public IP addresses is available, these addresses can be used as + a <quote>pool</quote>, and IP<acronym>NAT</acronym> may pick one of the public IP addresses as packet-addresses are mapped on their way out.</para> @@ -2017,10 +1978,10 @@ has to be some way to direct the inbound traffic to the correct LAN PCs. IP<acronym>NAT</acronym> has the redirection facilities of <acronym>NAT</acronym> to solve this problem. - Lets say you have your web server on LAN address <hostid - role="ipaddr">10.0.10.25</hostid> and your single public IP - address is <hostid role="ipaddr">20.20.20.5</hostid> you would - code the rule like this:</para> + For example, assuming a web server operating on LAN address <hostid + role="ipaddr">10.0.10.25</hostid> and using a single public IP + address of <hostid role="ipaddr">20.20.20.5</hostid> the rule would + be coded as follows:</para> <programlisting>rdr dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80</programlisting> @@ -2048,7 +2009,7 @@ changed to address new security concerns. FTP has two flavors, it can run in active mode or passive mode. The difference is in how the data channel is acquired. Passive mode is more - secure as the data channel is acquired be the ordinal ftp + secure as the data channel is acquired by the ordinal ftp session requester. For a real good explanation of FTP and the different modes see <ulink url="http://www.slacksite.com/other/ftp.html"></ulink>.</para>; @@ -2099,8 +2060,8 @@ <para>Only one filter rule is needed for FTP if the <acronym>NAT</acronym> FTP proxy is used.</para> - <para>Without the FTP Proxy you will need the following three - rules:</para> + <para>Without the FTP Proxy, the following three rules will be + needed:</para> <programlisting># Allow out LAN PC client FTP to public Internet # Active and passive modes @@ -2124,7 +2085,7 @@ <secondary>IPFW</secondary> </indexterm> - <para>The IPFIREWALL (IPFW) is a &os; sponsored firewall software + <para>The IPFIREWALL (<acronym>IPFW</acronym>) 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 coding technique to achieve what is referred to as Simple @@ -2133,7 +2094,7 @@ <para>The IPFW sample rule set (found in <filename>/etc/rc.firewall</filename> and <filename>/etc/rc.firewall6</filename>) in the standard &os; - install is rather simple and it is not expected that it used + install is rather simple and it is not expected to be used directly without modifications. The example does not use stateful filtering, which is beneficial in most setups, so it will not be used as base for this section.</para> @@ -2147,14 +2108,14 @@ different protocols use and create their unique packet header information is necessary before the power of the IPFW rules can be unleashed. Providing that level of explanation is out of the - scope of this section of the handbook.</para> + scope of this section of the Handbook.</para> <para>IPFW is composed of seven components, the primary component is the kernel firewall filter rule processor and its integrated - packet accounting facility, the logging facility, the 'divert' + packet accounting facility, the logging facility, the <literal>divert</literal> 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 + facilities, the <literal>fwd rule</literal> forward facility, the bridge facility, and the ipstealth facility. IPFW supports both IPv4 and IPv6.</para> @@ -2170,9 +2131,9 @@ <para>IPFW is included in the basic &os; install as a separate run time loadable module. The system 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> + <literal>firewall_enable="YES"</literal> is used. There is no + need to compile IPFW into the &os; kernel unless + <acronym>NAT</acronym> functionality is desired.</para> <para>After rebooting your system with <literal>firewall_enable="YES"</literal> in @@ -2184,8 +2145,8 @@ <para>The loadable module does have logging ability compiled in. To enable logging and set the verbose logging - limit, there is a knob you can set in - <filename>/etc/sysctl.conf</filename> by adding these + limit, there is a knob that can be set in + <filename>/etc/sysctl.conf</filename>. By adding these statements, logging will be enabled on future reboots:</para> <programlisting>net.inet.ip.fw.verbose=1 @@ -2219,9 +2180,9 @@ <secondary>kernel options</secondary> </indexterm> - <para>It is not a mandatory requirement that you enable IPFW by - compiling the following options into the &os; kernel unless - you need <acronym>NAT</acronym> function. It is presented here + <para>It is not a mandatory requirement to enable IPFW by + compiling the following options into the &os; kernel, unless + <acronym>NAT</acronym> functionality is required. It is presented here as background information.</para> <programlisting>options IPFIREWALL</programlisting> @@ -2231,13 +2192,13 @@ <programlisting>options IPFIREWALL_VERBOSE</programlisting> <para>Enables logging of packets that pass through IPFW and have - the 'log' keyword specified in the rule set.</para> + the <literal>log</literal> keyword specified in the rule set.</para> <programlisting>options IPFIREWALL_VERBOSE_LIMIT=5</programlisting> <para>Limits the number of packets logged through &man.syslogd.8; - on a per entry basis. You may wish to use this option in - hostile environments which you want to log firewall activity. + on a per entry basis. This option may be used in + hostile environments, when firewall activity logging is desired. This will close a possible denial of service attack via syslog flooding.</para> @@ -2250,8 +2211,8 @@ <programlisting>options IPFIREWALL_DEFAULT_TO_ACCEPT</programlisting> <para>This option will allow everything to pass through the - firewall by default, which is a good idea when you are first - setting up your firewall.</para> + firewall by default, which is a good idea when the firewall is being + set up for the first time.</para> <indexterm> <primary>kernel options</primary> @@ -2265,9 +2226,10 @@ functionality.</para> <note> - <para>If you do not include IPFIREWALL_DEFAULT_TO_ACCEPT or set - your rules to allow incoming packets you will block all - packets going to and from this machine.</para> + <para>If the option <literal>IPFIREWALL_DEFAULT_TO_ACCEPT</literal> + is not included, and there are also no rules to allow incoming + packets, the firewall will block all incoming and outgoing Double negative here (use of no and not in the same sentence). Perhaps: "The firewall will block all incoming and outgoing packets if either the IPFIREWALL_DEFAULT_TO_ACCEPT kernel option or a rule to explicily allow these connections are missing." + connections.</para> </note> </sect2> @@ -2308,7 +2270,7 @@ of firewall rules.</para> </listitem> <listitem> - <para><filename>filename</filename> — absolute path of + <para><filename><replaceable>filename</replaceable></filename> — absolute path of file containing firewall rules.</para> </listitem> </itemizedlist> @@ -2323,12 +2285,12 @@ <programlisting>add block in all add block out all</programlisting> - <para>On the other hand, it is possible to set - <literal>firewall_script</literal> variable to absolute path of + <para>On the other hand, it is possible to set the + <literal>firewall_script</literal> variable to the absolute path of an executable script that includes <command>ipfw</command> commands being executed at system boot time. A valid ruleset script that would be equivalent to the ruleset file shown above would - be following:</para> + be the following:</para> <programlisting>#!/bin/sh @@ -2376,22 +2338,22 @@ <indexterm><primary><command>ipfw</command></primary></indexterm> - <para>The ipfw command is the normal vehicle for making manual - single rule additions or deletions to the firewall active + <para>The <command>ipfw</command> command is the normal vehicle for making manual + single rule additions or deletions to the active firewall internal rules while it is running. The problem with using this method is once your system is shutdown or halted all the - rules you added or changed or deleted are lost. Writing all + rules that were added, changed or deleted are lost. Writing all your rules in a file and using that file to load the rules at boot time, or to replace in mass the currently running firewall - rules with changes you made to the files content is the + 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 <command>ipfw</command> command is still a very useful way 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 process of testing a rule, listing the rule with its counter - is the one of the ways of determining if the rule is + is one of the ways of determining if the rule is functioning.</para> <para>To list all the rules in sequence:</para> @@ -2403,7 +2365,7 @@ <screen>&prompt.root; <userinput>ipfw -t list</userinput></screen> - <para>To list the accounting information, packet count for + <para>The next example lists accounting information, the packet count for matched rules along with the rules themselves. The first column is the rule number, followed by the number of outgoing matched packets, followed by the number of incoming matched @@ -2424,33 +2386,30 @@ <screen>&prompt.root; <userinput>ipfw zero</userinput></screen> - <para>Zero the counters for just rule + <para>Zero the counters for just the rule with number <replaceable>NUM</replaceable>:</para> - <screen>&prompt.root; <userinput>ipfw zero NUM</userinput></screen> + <screen>&prompt.root; <userinput>ipfw zero <replaceable>NUM</replaceable></userinput></screen> </sect2> <sect2 id="firewalls-ipfw-rules"> <title>IPFW Rule Sets</title> - <!-- XXX: looks incorrect (and duplicated 2 times in this chapter): - 1. Packet can be processed two times depend of firewall - firewall configuration, but "return trip back" is - another packet. - 2. "Each TCP/IP service ... is predefined by its protocol ..." - - this shold be about packet and it's parameters - (source/destination address and port). --> + <!-- This has already appeared once --> - <para>A rule set is a group of ipfw rules coded to allow or deny + <para>A rule set is a group of IPFW rules coded to allow or deny packets based on the values contained in the packet. The bi-directional exchange of packets between hosts comprises a - session conversation. The firewall rule set processes the - packet twice: 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, mail, - etc.) is predefined by its protocol, and port number. This is - the basic selection criteria used to create rules which will - allow or deny services.</para> + session conversation. The firewall rule set processes both the + packets arriving from the public Internet, as well as the packets + originating from the system as a response to them. + Each <acronym>TCP/IP</acronym> service (i.e. telnet, www, The "i.e.: " thing again. + mail, etc.) is predefined by its protocol and privileged (listening) + port. Packets destined for a specific service, originate from the + source address using an unprivileged (high order) port and target + the specific service port on the destination address. All the above + parameters (i.e. ports and addresses) can be used as selection + criteria to create rules which will pass or block services.</para> <indexterm> <primary>IPFW</primary> @@ -2461,14 +2420,14 @@ <!-- Needs rewording to include note below --> <para>When a packet enters the firewall it is compared against - the first rule in the rule set and progress one rule at a time + the first rule in the rule set and progresses one rule at a time moving from top to bottom of the set in ascending rule number - sequence order. When the packet matches a rule selection - parameters, the rules action field value is executed and the + sequence order. When the packet matches the selection parameters + of a rule, the rules' action field value is executed and the search of the rule set terminates for that packet. This is referred to as <quote>the first match wins</quote> search method. If the packet does not match any of the rules, it gets - caught by the mandatory ipfw default rule, number 65535 which + caught by the mandatory IPFW default rule, number 65535 which denies all packets and discards them without any reply back to the originating destination.</para> @@ -2479,26 +2438,13 @@ </note> <para>The instructions contained here are based on using rules - that contain the stateful 'keep state', 'limit', 'in'/'out', - and via options. This is the basic framework for coding an + that contain the stateful <literal>keep state</literal>, <literal>limit</literal>, <literal>in</literal>, <literal>out</literal> + and <literal>via</literal> options. This is the basic framework for coding an inclusive type firewall rule set.</para> - <!-- XXX: something like this already in - <xref linkend="firewalls-concepts"> - AND: the para below is repeated 3 times in this chapter. --> - - <para>An inclusive firewall only allows services matching the - rules through. This way you can control what services can - originate behind the firewall destine for the public Internet - and also control the services which can originate from the - public Internet accessing your private network. Everything - else is denied 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> - <warning> - <para>When working with the firewall rules be careful, you can - end up locking your self out.</para> + <para>Be careful when working with firewall rules, as it is easy to + end up locking yourself out.</para> </warning> <sect3 id="firewalls-ipfw-rules-syntax"> @@ -2580,17 +2526,17 @@ <para><parameter>log</parameter> or <parameter>logamount</parameter></para> - <para>When a packet matches a rule with the log keyword, a - message will be logged to syslogd with a facility name of + <para>When a packet matches a rule with the <literal>log</literal> keyword, a + message will be logged to &man.syslogd.8; with a facility name of SECURITY. The logging only occurs if the number of packets logged so far for that particular rule does not - exceed the logamount parameter. If no logamount is + exceed the <literal>logamount</literal> parameter. If no <literal>logamount</literal> is specified, the limit is taken from the sysctl variable - net.inet.ip.fw.verbose_limit. In both cases, a value of + <literal>net.inet.ip.fw.verbose_limit</literal>. In both cases, a value of zero removes the logging limit. Once the limit is reached, logging can be re-enabled by clearing the logging counter or the packet counter for that rule, see - the ipfw reset log command.</para> + the <command>ipfw reset log</command> command.</para> <note> <para>Logging is done after @@ -2605,50 +2551,50 @@ <title>Selection</title> <para>The keywords described in this section are used to - describe attributes of the packet to be interrogated when + describe attributes of the packet to be checked when determining whether rules match the packet or not. The following general-purpose attributes are provided for matching, and must be used in this order:</para> <para><parameter>udp | tcp | icmp</parameter></para> - <para>or any protocol names found in - <filename>/etc/protocols</filename> are recognized and may - be used. The value specified is protocol to be matched + <para>Any other protocol names found in + <filename>/etc/protocols</filename> are also recognized and may + be used. The value specified is the protocol to be matched against. This is a mandatory requirement.</para> <para><parameter>from src to dst</parameter></para> - <para>The from and to keywords are used to match against IP - addresses. Rules must specify BOTH source and destination + <para>The <literal>from</literal> and <literal>to</literal> keywords are used to match against IP + addresses. Rules must specify <emphasis>both</emphasis> source and destination parameters. <literal>any</literal> is a special keyword that matches any IP address. <literal>me</literal> 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 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 form/mask-length, + firewall is running on (i.e. this box) as in <literal>from me to Again "i.e.: " + any</literal> or <literal>from any to me</literal> or <literal>from 0.0.0.0/0 to any</literal> or + <literal>from any to 0.0.0.0/0</literal> or <literal>from 0.0.0.0 to any</literal> or <literal>from + any to 0.0.0.0</literal> or <literal>from me to 0.0.0.0</literal>. IP addresses are + specified as a dotted IP address numeric form/mask-length (CIDR notation), or as single dotted IP address numeric form. This is a - mandatory requirement. See this link for help on writing - mask-lengths. <ulink + mandatory requirement. See the following link for help on writing + mask-lengths: <ulink url="http://jodies.de/ipcalc"></ulink></para>; <para><parameter>port number</parameter></para> <para>For protocols which support port numbers (such as - <acronym>TCP</acronym> and UDP). It is mandatory that you - code the port number of the service you want to match - on. Service names (from + <acronym>TCP</acronym> and <acronym>UDP</acronym>), it is mandatory to + code the port number of the service that will be matched. + Service names (from <filename>/etc/services</filename>) may be used instead of numeric port values.</para> <para><parameter>in | out</parameter></para> <para>Matches incoming or outgoing packets, respectively. - The in and out are keywords and it is mandatory that you - code one or the other as part of your rule matching + The <literal>in</literal> and <literal>out</literal> are keywords and it is mandatory that + one or the other is coded as part of your rule matching criterion.</para> <para><parameter>via IF</parameter></para> @@ -2677,9 +2623,9 @@ <replaceable>N</replaceable> connections with the same set of parameters as specified in the rule. One or more of source and destination addresses and ports can be - specified. The 'limit' and 'keep-state' can not be used on - same rule. Limit provides the same stateful function as - 'keep-state' plus its own functions.</para> + specified. The <literal>limit</literal> and <literal>keep-state</literal> can not be used on the + same rule. The <literal>limit</literal> option provides the same stateful function as + <literal>keep-state</literal>, plus its own functions.</para> </sect4> </sect3> @@ -2696,17 +2642,17 @@ <para>Stateful filtering treats traffic as a bi-directional exchange of packets comprising a session conversation. It - has the interrogation abilities to determine if the session + has the matching capabilities to determine if the session conversation between the originating sender and the destination are following the valid procedure of bi-directional packet exchange. Any packets that do not properly fit the session conversation template are automatically rejected as impostors.</para> - <para>'check-state' is used to identify where in the IPFW rules + <para>The <literal>check-state</literal> option is used to identify where in the IPFW rules set the packet is to be tested against the dynamic rules facility. On a match the packet exits the firewall to - continue on its way and a new rule is dynamic created for + continue on its way and a new rule is dynamically created for the next anticipated packet being exchanged during this bi-directional session conversation. On a no match the packet advances to the next rule in the rule set for @@ -2715,14 +2661,14 @@ <para>The dynamic rules facility is vulnerable to resource depletion from a SYN-flood attack which would open a huge number of dynamic rules. To counter this attack, &os; - added another new option named limit. This + added another new option named <literal>limit</literal>. This option is used to limit the number of simultaneous session - conversations by interrogating the rules source or - destinations fields as directed by the limit option and + conversations by checking the rules source or + destinations fields as directed by the <literal>limit</literal> option and using the packet's IP address found there, in a search of the open dynamic rules counting the number of times this rule and IP address combination occurred, if this count is - greater that the value specified on the limit option, the + greater that the value specified on the <literal>limit</literal> option, the packet is discarded.</para> </sect3> @@ -2738,41 +2684,41 @@ <para>The benefits of logging are obvious: it provides the ability to review after the fact the rules you activated logging on which provides information like, what packets had - been dropped, what addresses they came from, where they were + been dropped, what addresses they came from and where they were going, giving you a significant edge in tracking down "were going" could probably be "went" here. But that is outside scope of the patch so we could just classify that as a later fix up. attackers.</para> <para>Even with the logging facility enabled, IPFW will not generate any rule logging on it's own. The firewall - administrator decides what rules in the rule set he wants - to log and adds the log verb to those rules. Normally only + administrator decides what rules in the rule set will be + logged, and adds the <literal>log</literal> verb to those rules. Normally only deny rules are logged, like the deny rule for incoming <acronym>ICMP</acronym> pings. It is very customary to - duplicate the ipfw default deny everything rule with the - log verb included as your last rule in the rule set. This - way you get to see all the packets that did not match any + duplicate the <quote>ipfw default deny everything</quote> rule with the + <literal>log</literal> verb included as your last rule in the rule set. This + way it is possible to see all the packets that did not match any of the rules in the rule set.</para> <para>Logging is a two edged sword, if you are not careful, you can lose yourself in the over abundance of log data and fill your disk up with growing log files. DoS attacks that fill up disk drives is one of the oldest attacks around. These - log message are not only written to syslogd, but also are + log messages are not only written to <application>syslogd</application>, but also are displayed on the root console screen and soon become very annoying.</para> <para>The <literal>IPFIREWALL_VERBOSE_LIMIT=5</literal> kernel option limits the number of consecutive messages - sent to the system logger syslogd, concerning the packet + sent to the system logger &man.syslogd.8;, concerning the packet matching of a given rule. When this option is enabled in the kernel, the number of consecutive messages concerning a particular rule is capped at the number specified. There is nothing to be gained from 200 log messages saying the same identical thing. For instance, five consecutive messages concerning a particular rule would be logged to - syslogd, the remainder identical consecutive messages would - be counted and posted to the syslogd with a phrase like - this:</para> + <application>syslogd</application>, the remainder identical consecutive messages would + be counted and posted to <application>syslogd</application> with a phrase like + the following:</para> <programlisting>last message repeated 45 times</programlisting> @@ -2788,18 +2734,18 @@ rules and code them in a manner compatible with running them as a script. The major benefit of doing this is the firewall rules can be refreshed in mass without the need of rebooting - the system to activate the new rules. This method is very + the system to activate them. This method is very convenient in testing new rules as the procedure can be - executed as many times as needed. Being a script, you can - use symbolic substitution to code frequent used values and - substitution them in multiple rules. You will see this in + executed as many times as needed. Being a script, + symbolic substitution can be used to code frequent used values and + substitute them in multiple rules. This is shown in the following example.</para> - <para>The script syntax used here is compatible with the 'sh', - 'csh', 'tcsh' shells. Symbolic substitution fields are + <para>The script syntax used here is compatible with the &man.sh.1;, + &man.csh.1;, &man.tcsh.1; 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 be enclosed to "double quotes".</para> + have the $ prefix. The value to populate the symbolic + field must be enclosed in "double quotes".</para> <para>Start your rules file like this:</para> @@ -2820,12 +2766,12 @@ ################### 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 - <filename>/etc/ipfw.rules</filename> file, you could reload - these rules by entering on the command line.</para> + <para>If the above example was in the + <filename>/etc/ipfw.rules</filename> file, the rules could be + reloaded by entering the following on the command line.</para> <screen>&prompt.root; <userinput>sh /etc/ipfw.rules</userinput></screen> @@ -2852,8 +2798,8 @@ example of how to code a very secure 'inclusive' type of firewall. An inclusive firewall only allows services matching pass rules through and blocks all other by default. - All firewalls have at the minimum two interfaces which have - to have rules to allow the firewall to function.</para> + Firewalls designed to protect entire network segments, have at minimum two interfaces which must + have rules to allow the firewall to function.</para> <para>All &unix; flavored operating systems, &os; included, are designed to use interface <devicename>lo0</devicename> and IP @@ -2862,15 +2808,15 @@ 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 ppp + <para>The interface which faces the public Internet is the one + to place the rules that authorize and control access of the + outbound and inbound connections. This can be your user + <acronym>PPP</acronym> <devicename>tun0</devicename> 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 + <para>In cases where one or more than one NICs are connected to + a private LAN behind the firewall, those interfaces must have rules coded to allow free unmolested movement of packets originating from those LAN interfaces.</para> @@ -2881,41 +2827,38 @@ <para>The order of the rules in each of the public interface sections should be in order of the most used rules being placed before less often used rules with the last rule in - the section being a block log all packets on that interface + the section blocking and logging all packets on that interface and direction.</para> <para>The Outbound section in the following rule set only - contains 'allow' rules which contain selection values that + contains <literal>allow</literal> rules which contain selection values that uniquely identify the service that is authorized for public - Internet access. All the rules have the, proto, port, - in/out, via and keep state option coded. The 'proto tcp' - rules have the 'setup' option included to identify the start + Internet access. All the rules have the <literal>proto</literal>, <literal>port</literal>, + <literal>in/out</literal>, <literal>via</literal> and <literal>keep state</literal> option coded. The <literal>proto tcp</literal> + rules have the <literal>setup</literal> option included to identify the start session request as the trigger packet to be posted to the keep state stateful table.</para> <para>The Inbound section has all the blocking of undesirable - packets first for two different reasons. First is these - things being blocked may be part of an otherwise valid packet - which may be allowed in by the later authorized service - rules. Second reason is that by having a rule that - explicitly blocks selected packets that I receive on an - infrequent bases and do not want to see in the log, this - keeps them from being caught by the last rule in the section - which blocks and logs all packets which have fallen through - the rules. The last rule in the section which blocks and - logs all packets is how you create the legal evidence needed + packets first, for two different reasons. The first is that + malicious packets may be partial matches for legitimate traffic. + These packets have to be discarded rather than allowed in, based on + their partial matches against <literal>allow</literal> rules. + The second reason is that known and uninteresting rejects may be + blocked silently, rather than being caught and logged by the last + rules in the section. The final rule in each section, blocks and + logs all packets and can be used to 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 - response returned for any of the undesirable stuff, their - packets just get dropped and vanish. This way the attackers + <para>Another thing that should be taken care of, is to insure there + is no response returned for any of the undesirable stuff. Invalid + packets should just get dropped and vanish. This way the attacker has no knowledge if his packets have reached your system. - The less the attackers can learn about your system the more - secure it is. When you log packets with port numbers you do - not recognize, look the numbers up in - <filename>/etc/services/</filename> or go to <ulink + The less the attackers can learn about your system, the more + secure it is. Packets with unrecognized port numbers may be looked + up in <filename>/etc/services/</filename> or go to <ulink url="http://www.securitystats.com/tools/portsearch.php"></ulink>; - and do a port number lookup to find what the purpose of that + and do a port number lookup to find the purpose of the particular port number is. Check out this link for port numbers used by Trojans: <ulink url="http://www.simovits.com/trojans/trojans.html"></ulink>.</para>; @@ -2925,36 +2868,37 @@ <title>An Example Inclusive Ruleset</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 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 have to change the 'dc0' interface name - in every rule to the interface name of the NIC that connects - your system to the public Internet. For user ppp it would be - 'tun0'.</para> + complete inclusive type ruleset. It is safe to use this rule set + on your own systems. Just comment out any <literal>pass</literal> + rules for services that are not required. To avoid logging + undesired messages, add a <literal>deny</literal> rule in the + inbound section. The <devicename>dc0</devicename> interface will + will have to be changed in every rule, with the actual name of the + interface (NIC) that connects your system to the public Internet. + For user <acronym>PPP</acronym>, this would be + <devicename>tun0</devicename>.</para> - <para>You will see a pattern in the usage of these + <para>There is a noticeable pattern in the usage of these rules.</para> <itemizedlist> <listitem> <para>All statements that are a request to start a session - to the public Internet use keep-state.</para> + to the public Internet use <literal>keep-state</literal>.</para> </listitem> <listitem> <para>All the authorized services that originate from the - public Internet have the limit option to stop + public Internet have the <literal>limit</literal> option to stop flooding.</para> </listitem> <listitem> - <para>All rules use in or out to clarify direction.</para> + <para>All rules use <literal>in</literal> or <literal>out</literal> to clarify direction.</para> </listitem> <listitem> - <para>All rules use via interface name to specify the + <para>All rules use <literal>via</literal> <replaceable>interface-name</replaceable> to specify the interface the packet is traveling over.</para> </listitem> </itemizedlist> @@ -3047,8 +2991,8 @@ ################################################################# # Interface facing Public Internet (Inbound Section) -# Interrogate packets originating from the public Internet -# destine for this gateway server or the private network. +# Check packets originating from the public Internet +# destined for this gateway server or the private network. ################################################################# # Deny all inbound traffic from non-routable reserved address spaces @@ -3124,7 +3068,7 @@ <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 IPDIVERT' + function of IPFW. The kernel source needs <literal>option IPDIVERT</literal> I've always used: <programlisting>option SOMEOPTION</programlisting> But that's probably not a huge deal. statement added to the other IPFIREWALL statements compiled into a custom kernel.</para> @@ -3136,14 +3080,14 @@ natd_interface="rl0" # interface name of public Internet NIC natd_flags="-dynamic -m" # -m = preserve port numbers if possible</programlisting> - <para>Utilizing stateful rules with divert natd rule (Network + <para>Utilizing stateful rules with <literal>divert natd</literal> rule (Network Address Translation) greatly complicates the rule set coding - logic. The positioning of the check-state, and 'divert natd' + logic. The positioning of the <literal>check-state</literal>, and <literal>divert natd</literal> rules in the rule set becomes very critical. This is no longer a simple fall-through logic flow. A new action type - is used, called 'skipto'. To use the skipto command it is - mandatory that you number each rule so you know exactly - where the skipto rule number is you are really jumping + is used, called <literal>skipto</literal>. To use the <literal>skipto</literal> command it is + mandatory that each rule is numbered, so the + <literal>skipto</literal> rule number knows exactly where it is jumping to.</para> <para>The following is an uncommented example of one coding @@ -3152,67 +3096,69 @@ <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 - 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 + notice that all the allow and deny rules specify the + direction the packet is going (i.e. outbound or inbound) and i.e.: again. ;) + the interface. Also notice that the start outbound + session requests, all <literal>skipto rule 500</literal> 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 + page. Web pages are transmitted over port 80. So the + packet enters the firewall. It does not match rule 100 because it + is headed out rather than 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 + actions take place. The <literal>keep-state</literal> 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 + posted to the dynamic table. In this case it is <literal>skipto rule + 500</literal>. 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 + This packet makes its way to the destination, where a response + packet is generated and sent back. This new packet enters the top of the rule set. This time it does match rule 100 and has it destination IP address mapped back to its corresponding LAN IP address. It then is processed by the - check-state rule, it's found in the table as an existing + <literal>check-state</literal> rule, it is 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 its outbound - entry is found, the associated action, 'skipto 500', is + time it gets checked by the <literal>check-state</literal> rule and its outbound + entry is found, the associated action, <literal>skipto 500</literal>, is executed. The packet 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 + handled by the <literal>check-state</literal> rule and the properly placed + <literal>divert natd</literal> 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 + Lets say there is an 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 + all the nasty things that need to be checked 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 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 + <literal>allow</literal> so the packet is released to the LAN. + The packet generated as a response, is recognized by the + <literal>check-state</literal> as belonging to an + existing session conversation. It is then sent to rule 500 for + <acronym>NAT</acronym>ing and released to the outbound interface.</para> <para>Example Ruleset #1:</para> @@ -3306,9 +3252,9 @@ ################################################################# # Interface facing Public Internet (Outbound Section) -# Interrogate session start requests originating from behind the +# Check session start requests originating from behind the # firewall on the private network or from this gateway server -# destine for the public Internet. +# destined for the public Internet. ################################################################# # Allow out access to my ISP's Domain name server. @@ -3356,8 +3302,8 @@ ################################################################# # Interface facing Public Internet (Inbound Section) -# Interrogate packets originating from the public Internet -# destine for this gateway server or the private network. +# Check packets originating from the public Internet +# destined for this gateway server or the private network. ################################################################# # Deny all inbound traffic from non-routable reserved address spaces -- Tom Rhodes
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090424022336.3f4c6792.trhodes>