[PATCH] for the 'firewalls' chapter
Tom Rhodes
trhodes at FreeBSD.org
Fri Apr 24 06:23:49 UTC 2009
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 at 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
More information about the freebsd-doc
mailing list