Date: Fri, 18 Jan 2013 15:23:28 -0800 (PST) From: Dru Lavigne <dru.lavigne@att.net> To: freebsd-doc@freebsd.org Subject: [patch] white space fix for Firewalls chapter Message-ID: <1358551408.34925.YahooMailClassic@web184905.mail.gq1.yahoo.com>
index | next in thread | raw e-mail
[-- Attachment #1 --]
This is a white fix only patch for Chapter 31 Firewalls. I did not fix the missing comma in line 918 nor the misuse of "it's" or "Lets".
Cheers,
Dru
[-- Attachment #2 --]
Index: firewalls/chapter.xml
===================================================================
--- firewalls/chapter.xml (revision 40679)
+++ firewalls/chapter.xml (working copy)
@@ -125,18 +125,20 @@
reverse. It only allows traffic matching the rules through and
blocks everything else.</para>
- <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
- design. Inclusive firewalls are generally safer than exclusive
- firewalls because they significantly reduce the risk of allowing
- unwanted traffic to pass through them.</para>
+ <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 design. Inclusive
+ firewalls are generally safer than exclusive firewalls because
+ they significantly reduce the risk of allowing unwanted traffic
+ to pass through them.</para>
<note>
<para>Unless noted otherwise, all configuration and example
- rulesets in this chapter, create inclusive type firewalls.</para>
+ rulesets in this chapter, create inclusive type
+ firewalls.</para>
</note>
<para>Security can be tightened further using a <quote>stateful
@@ -157,21 +159,22 @@
<para>&os; has three different firewall packages built
into the base system. They are: <emphasis>IPFILTER</emphasis>
(also known as <acronym>IPF</acronym>),
- <emphasis>IPFIREWALL</emphasis> (also known as <acronym>IPFW</acronym>),
- and <emphasis>OpenBSD's PacketFilter</emphasis> (also known as
- <acronym>PF</acronym>). &os; also has two built in packages for
- traffic shaping (basically controlling bandwidth usage):
- &man.altq.4; and &man.dummynet.4;. Dummynet has traditionally been
- closely tied with <acronym>IPFW</acronym>, and
+ <emphasis>IPFIREWALL</emphasis> (also known as
+ <acronym>IPFW</acronym>), and <emphasis>OpenBSD's
+ PacketFilter</emphasis> (also known as <acronym>PF</acronym>).
+ &os; also has two built in packages for traffic shaping
+ (basically controlling bandwidth usage): &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 IPFILTER can currently
- be done with IPFILTER 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;
<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 a different rule syntax.</para>
+ 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 a different rule syntax.</para>
<para>The reason that &os; has multiple built in firewall packages
is that different people have different requirements and
@@ -193,16 +196,16 @@
</sect1>
<sect1 id="firewalls-pf">
- <sect1info>
- <authorgroup>
- <author>
- <firstname>John</firstname>
- <surname>Ferrell</surname>
- <contrib>Revised and updated by </contrib>
- <!-- 24 March 2008 -->
- </author>
- </authorgroup>
- </sect1info>
+ <sect1info>
+ <authorgroup>
+ <author>
+ <firstname>John</firstname>
+ <surname>Ferrell</surname>
+ <contrib>Revised and updated by </contrib>
+ <!-- 24 March 2008 -->
+ </author>
+ </authorgroup>
+ </sect1info>
<title>The OpenBSD Packet Filter (PF) and
<acronym>ALTQ</acronym></title>
@@ -239,36 +242,35 @@
<sect2>
<title>Using the PF Loadable Kernel Modules</title>
- <para>To load the PF Kernel Module add the following line to
- <filename>/etc/rc.conf</filename>:</para>
+ <para>To load the PF Kernel Module add the following line to
+ <filename>/etc/rc.conf</filename>:</para>
<programlisting>pf_enable="YES"</programlisting>
- <para>Then run the startup script to load the module:</para>
+ <para>Then run the startup script to load the module:</para>
<screen>&prompt.root; <userinput>/etc/rc.d/pf start</userinput></screen>
<para>Note that the PF Module will not load if it cannot find
the ruleset config file. The default location is
<filename>/etc/pf.conf</filename>. If the PF ruleset is
- located somewhere else, PF can be instructed to look there by
- adding a line like the following to
+ located somewhere else, PF can be instructed to look there
+ by adding a line like the following to
<filename>/etc/rc.conf</filename>:</para>
<programlisting>pf_rules="<replaceable>/path/to/pf.conf</replaceable>"</programlisting>
<para>The sample <filename>pf.conf</filename>
can be found in <filename
- class="directory">/usr/share/examples/pf/</filename>.
- </para>
+ class="directory">/usr/share/examples/pf/</filename>.</para>
- <para>The <acronym>PF</acronym> module can also be loaded manually
- from the command line:</para>
+ <para>The <acronym>PF</acronym> module can also be loaded
+ manually from the command line:</para>
<screen>&prompt.root; <userinput>kldload pf.ko</userinput></screen>
<para>Logging support for PF is provided by the
- <literal>pflog.ko</literal> and can be loaded by adding the
+ <literal>pflog.ko</literal> and can be loaded by adding the
following line to <filename>/etc/rc.conf</filename>:</para>
<programlisting>pflog_enable="YES"</programlisting>
@@ -278,7 +280,8 @@
<screen>&prompt.root; <userinput>/etc/rc.d/pflog start</userinput></screen>
<para>If you need other <acronym>PF</acronym> features you will
- need to compile <acronym>PF</acronym> support into the kernel.</para>
+ need to compile <acronym>PF</acronym> support into the
+ kernel.</para>
</sect2>
<sect2>
@@ -303,33 +306,36 @@
</indexterm>
<para>While it is not necessary that you compile
- <acronym>PF</acronym> support into the &os; kernel, you may want
- to do so to take advantage of one of PF's advanced features that
- is not included in the loadable module, namely &man.pfsync.4;, which
- is a pseudo-device that exposes certain changes to
- the state table used by <acronym>PF</acronym>. It can be
- paired with &man.carp.4; to create failover firewalls using
- <acronym>PF</acronym>. More information on
+ <acronym>PF</acronym> support into the &os; kernel, you may
+ want to do so to take advantage of one of PF's advanced
+ features that is not included in the loadable module, namely
+ &man.pfsync.4;, which is a pseudo-device that exposes certain
+ changes to the state table used by <acronym>PF</acronym>.
+ It can be paired with &man.carp.4; to create failover
+ firewalls using <acronym>PF</acronym>. More information on
<acronym>CARP</acronym> can be found in
<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
- below:</para>
+ <filename>/usr/src/sys/conf/NOTES</filename> and are
+ reproduced below:</para>
<programlisting>device pf
device pflog
device pfsync</programlisting>
- <para>The <literal>device pf</literal> option enables support for the
- <quote>Packet Filter</quote> firewall (&man.pf.4;).</para>
+ <para>The <literal>device pf</literal> option enables support
+ for the <quote>Packet Filter</quote> firewall
+ (&man.pf.4;).</para>
- <para>The <literal>device pflog</literal> option enables the optional
- &man.pflog.4; pseudo network device which can be used to log
- traffic to a &man.bpf.4; descriptor. The &man.pflogd.8; daemon
- can be used to store the logging information to disk.</para>
+ <para>The <literal>device pflog</literal> option enables the
+ optional &man.pflog.4; pseudo network device which can be
+ used to log traffic to a &man.bpf.4; descriptor. The
+ &man.pflogd.8; daemon can be used to store the logging
+ information to disk.</para>
- <para>The <literal>device pfsync</literal> option enables the optional
+ <para>The <literal>device pfsync</literal> option enables the
+ optional
&man.pfsync.4; pseudo-network device that is used to monitor
<quote>state changes</quote>.</para>
</sect2>
@@ -359,23 +365,24 @@
<para><acronym>PF</acronym> reads its configuration rules from
&man.pf.conf.5; (<filename>/etc/pf.conf</filename> by
- default) and it modifies, drops, or passes packets according to
- the rules or definitions specified there. The &os;
+ default) and it modifies, drops, or passes packets according
+ to the rules or definitions specified there. The &os;
installation includes several sample files located in
- <filename>/usr/share/examples/pf/</filename>. Please refer to
- the <ulink url="http://www.openbsd.org/faq/pf/">PF FAQ</ulink>
- for complete coverage of <acronym>PF</acronym> rulesets.</para>
+ <filename>/usr/share/examples/pf/</filename>. Please refer
+ to the <ulink url="http://www.openbsd.org/faq/pf/">PF
+ FAQ</ulink> for complete coverage of <acronym>PF</acronym>
+ rulesets.</para>
<warning>
<para>When browsing the <ulink
- url="http://www.openbsd.org/faq/pf/">PF FAQ</ulink>,
+ url="http://www.openbsd.org/faq/pf/">PF FAQ</ulink>,
please keep in mind that different versions of &os; can
contain different versions of PF. Currently,
&os; 8.<replaceable>X</replaceable> and prior is
using the same version of <acronym>PF</acronym> as
- OpenBSD 4.1. &os; 9.<replaceable>X</replaceable> and
- later is using the same version of <acronym>PF</acronym> as
- OpenBSD 4.5.</para>
+ OpenBSD 4.1. &os; 9.<replaceable>X</replaceable>
+ and later is using the same version of <acronym>PF</acronym>
+ as OpenBSD 4.5.</para>
</warning>
<para>The &a.pf; is a good place to ask questions about
@@ -402,31 +409,37 @@
<tbody>
<row>
- <entry><command>pfctl <option>-e</option></command></entry>
+ <entry><command>pfctl
+ <option>-e</option></command></entry>
<entry>Enable PF</entry>
</row>
<row>
- <entry><command>pfctl <option>-d</option></command></entry>
+ <entry><command>pfctl
+ <option>-d</option></command></entry>
<entry>Disable PF</entry>
</row>
<row>
- <entry><command>pfctl <option>-F</option> all <option>-f</option> /etc/pf.conf</command></entry>
- <entry>Flush all rules (nat, filter, state, table, etc.) and
- reload from the file <filename>/etc/pf.conf</filename></entry>
+ <entry><command>pfctl <option>-F</option> all
+ <option>-f</option> /etc/pf.conf</command></entry>
+ <entry>Flush all rules (nat, filter, state, table, etc.)
+ and reload from the file
+ <filename>/etc/pf.conf</filename></entry>
</row>
<row>
- <entry><command>pfctl <option>-s</option> [ rules | nat | state ]</command></entry>
+ <entry><command>pfctl <option>-s</option> [ rules | nat
+ state ]</command></entry>
<entry>Report on the filter rules, nat rules, or state
table</entry>
</row>
<row>
- <entry><command>pfctl <option>-vnf</option> /etc/pf.conf</command></entry>
- <entry>Check <filename>/etc/pf.conf</filename> for errors,
- but do not load ruleset</entry>
+ <entry><command>pfctl <option>-vnf</option>
+ /etc/pf.conf</command></entry>
+ <entry>Check <filename>/etc/pf.conf</filename> for
+ errors, but do not load ruleset</entry>
</row>
</tbody>
</tgroup>
@@ -437,13 +450,14 @@
<title>Enabling <acronym>ALTQ</acronym></title>
<para><acronym>ALTQ</acronym> is only available by compiling
- support for it into the &os; kernel. <acronym>ALTQ</acronym> is
- not supported by all of the available network card drivers.
+ support for it into the &os; kernel. <acronym>ALTQ</acronym>
+ is not supported by all of the available network card drivers.
Please see the &man.altq.4; manual page for a list of drivers
that are supported in your release of &os;.</para>
<para>The following kernel options will enable
- <acronym>ALTQ</acronym> and add additional functionality:</para>
+ <acronym>ALTQ</acronym> and add additional
+ functionality:</para>
<programlisting>options ALTQ
options ALTQ_CBQ # Class Bases Queuing (CBQ)
@@ -456,33 +470,36 @@
<para><literal>options ALTQ</literal> enables the
<acronym>ALTQ</acronym> framework.</para>
- <para><literal>options ALTQ_CBQ</literal> enables <emphasis>Class Based
- Queuing</emphasis> (<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 <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
- queue is over the maximum all new packets will be dropped.
+ <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 queue is over the maximum all new packets will be dropped.
True to its name, <acronym>RED</acronym> drops packets from
different connections randomly.</para>
- <para><literal>options ALTQ_RIO</literal> enables <emphasis>Random Early
- Detection In and Out</emphasis>.</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
- <emphasis>Hierarchical Fair Service Curve Packet Scheduler</emphasis>. For more
- information about <acronym>HFSC</acronym> see: <ulink
+ <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 <emphasis>Priority
- Queuing</emphasis> (<acronym>PRIQ</acronym>). <acronym>PRIQ</acronym>
- will always pass traffic that is in a higher queue
- first.</para>
+ <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>
<para><literal>options ALTQ_NOPCC</literal> enables
<acronym>SMP</acronym> support for <acronym>ALTQ</acronym>.
@@ -509,24 +526,24 @@
<para>IPFILTER is based on a kernel-side firewall and
<acronym>NAT</acronym> mechanism that can be controlled and
- monitored by userland interface programs. The firewall rules can
- be set or deleted with the &man.ipf.8; utility. The
+ monitored by userland interface programs. The firewall rules
+ can be set or deleted with the &man.ipf.8; utility. The
<acronym>NAT</acronym> rules can be set or deleted with the
&man.ipnat.8; utility. The &man.ipfstat.8; utility can print
run-time statistics for the kernel parts of IPFILTER. The
- &man.ipmon.8; program can log IPFILTER actions to the system log
- files.</para>
+ &man.ipmon.8; program can log IPFILTER actions to the system
+ log files.</para>
- <para>IPF was originally written using a rule processing logic of
- <quote>the last matching rule wins</quote> and used only
+ <para>IPF was originally written using a rule processing logic
+ of <quote>the last matching rule wins</quote> and used only
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 only the legacy
- rule coding parameters and rule file processing
+ 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
+ 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 and more secure firewall.</para>
+ options, completely understating their benefits in producing
+ a 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
@@ -542,9 +559,9 @@
<para>The IPF FAQ is at <ulink
url="http://www.phildev.net/ipf/index.html"></ulink>.</para>;
- <para>A searchable archive of the open-source IPFilter mailing list is
- available at <ulink
- url="http://marc.theaimsgroup.com/?l=ipfilter"></ulink>.</para>;
+ <para>A searchable archive of the open-source IPFilter mailing
+ list is available at <ulink
+ url="http://marc.theaimsgroup.com/?l=ipfilter"></ulink>.</para>;
<sect2>
<title>Enabling IPF</title>
@@ -555,15 +572,17 @@
<secondary>enabling</secondary>
</indexterm>
- <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 <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. There is no need
- to compile IPF into the &os; kernel just to change the default
- to <literal>block all</literal>. This can be done just by adding
- a <literal>block all</literal> rule at the end of your ruleset.</para>
+ <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
+ <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. There is no
+ need to compile IPF into the &os; kernel just to change the
+ default to <literal>block all</literal>. This can be done
+ just by adding a <literal>block all</literal> rule at the
+ end of your ruleset.</para>
</sect2>
<sect2>
@@ -607,28 +626,28 @@
options IPFILTER_LOG
options IPFILTER_DEFAULT_BLOCK</programlisting>
- <para><literal>options IPFILTER</literal> enables support for the
- <quote>IPFILTER</quote> firewall.</para>
+ <para><literal>options IPFILTER</literal> enables support for
+ the <quote>IPFILTER</quote> firewall.</para>
<para><literal>options IPFILTER_LOG</literal> enables the option
to have IPF log traffic by writing to the
- <devicename>ipl</devicename> packet logging pseudo—device
- for every rule that has the <literal>log</literal>
- keyword.</para>
+ <devicename>ipl</devicename> packet logging
+ pseudo—device for every rule that has the
+ <literal>log</literal> keyword.</para>
<para><literal>options IPFILTER_DEFAULT_BLOCK</literal> changes
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 installing a kernel
- that has been built with the above options 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 <filename>rc.conf</filename> Options</title>
- <para>To activate IPF at boot time, the following statements need to
- be added to <filename>/etc/rc.conf</filename>:</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
@@ -639,8 +658,8 @@
# n = map IP & port to names</programlisting>
<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>
+ 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
@@ -663,8 +682,8 @@
<para><option>-Fa</option> means flush all internal rules
tables.</para>
- <para><option>-f</option> means this is the file to read for the
- rules to load.</para>
+ <para><option>-f</option> means this is the file to read for
+ the rules to load.</para>
<para>This gives you the ability to make changes to your custom
rules file, run the above IPF command, and thus update the
@@ -677,8 +696,8 @@
flags available with this command.</para>
<para>The &man.ipf.8; command expects the rules file to be a
- standard text file. It will not accept a rules file written as
- a script with symbolic substitution.</para>
+ standard text file. It will not accept a rules file written
+ as a script with symbolic substitution.</para>
<para>There is a way to build IPF rules that utilizes the power
of script symbolic substitution. For more information, see
@@ -696,12 +715,12 @@
<secondary>statistics</secondary>
</indexterm>
- <para>The default behavior of &man.ipfstat.8; is to retrieve and
- display the totals of the accumulated statistics gathered as a
- result of applying the user coded rules against packets going
- in and out of the firewall since it was last started, or since
- the last time the accumulators were reset to zero by the
- <command>ipf -Z</command> command.</para>
+ <para>The default behavior of &man.ipfstat.8; is to retrieve
+ and display the totals of the accumulated statistics gathered
+ as a result of applying the user coded rules against packets
+ going in and out of the firewall since it was last started,
+ or since the last time the accumulators were reset to zero
+ by the <command>ipf -Z</command> command.</para>
<para>See the &man.ipfstat.8; manual page for details.</para>
@@ -727,8 +746,8 @@
Packet log flags set: (0)</screen>
<para>When supplied with either <option>-i</option> for inbound
- or <option>-o</option> for outbound, the command will retrieve and
- display the appropriate list of filter rules currently
+ 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>
<para><command>ipfstat -in</command> displays the inbound
@@ -759,14 +778,14 @@
<para>One of the most important functions of the
<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
- 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
- real time. See the &man.ipfstat.8; manual page for
- details.</para>
+ 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 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 real time. See the &man.ipfstat.8; manual page
+ for details.</para>
</sect2>
<sect2>
@@ -780,21 +799,23 @@
<secondary>logging</secondary>
</indexterm>
- <para>In order for <command>ipmon</command> to work properly, the
- 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 the command is typed on the command line
- without the <option>-D</option> flag.</para>
+ <para>In order for <command>ipmon</command> to work properly,
+ the 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 the command
+ is typed on the command line without the <option>-D</option>
+ flag.</para>
<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 &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>
+ 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 &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
# s = log to syslog
@@ -804,8 +825,8 @@
<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 can all provide a significant edge
- in tracking down attackers.</para>
+ where they were going. These can all provide a significant
+ edge in tracking down attackers.</para>
<para>Even with the logging facility enabled, IPF will not
generate any rule logging on its own. The firewall
@@ -815,8 +836,8 @@
<para>It is very customary to include a default deny everything
rule with the log keyword included as your last rule in the
- ruleset. This makes it possible to see all the packets that did not
- match any of the rules in the ruleset.</para>
+ ruleset. This makes it possible to see all the packets that
+ did not match any of the rules in the ruleset.</para>
</sect2>
<sect2>
@@ -824,12 +845,11 @@
<para><application>Syslogd</application> uses its own special
method for segregation of log data. It uses special groupings
- called <quote>facility</quote> and <quote>level</quote>. IPMON
- in <option>-Ds</option> mode uses <literal>local0</literal>
- as the <quote>facility</quote>
- name by default.
- The following levels can be
- used to further segregate the logged data if desired:</para>
+ called <quote>facility</quote> and <quote>level</quote>.
+ IPMON in <option>-Ds</option> mode uses
+ <literal>local0</literal> as the <quote>facility</quote>
+ name by default. The following levels can be used to further
+ segregate the logged data if desired:</para>
<screen>LOG_INFO - packets logged using the "log" keyword as the action rather than pass or block.
LOG_NOTICE - packets logged which are also passed
@@ -839,16 +859,18 @@
<!-- XXX: "can be considered short" == "with incomplete header" -->
<para>To setup IPFILTER to log all data to
- <filename>/var/log/ipfilter.log</filename>, the file will need to be
- created beforehand. 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 &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 <application>syslog</application> will deal with system messages issued
- by software applications like IPF.</para>
+ <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 <application>syslog</application> will
+ deal with system messages issued by software applications
+ like IPF.</para>
<para>Add the following statement to
<filename>/etc/syslog.conf</filename>:</para>
@@ -860,21 +882,21 @@
file location.</para>
<para>To activate the changes to <filename>/etc/syslog.conf
- </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>
+ </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
- created above.</para>
+ <filename>/etc/newsyslog.conf</filename> to rotate the new
+ log created above.</para>
</sect2>
<sect2>
<title>The Format of Logged Messages</title>
- <para>Messages generated by <command>ipmon</command> consist of
- data fields separated by white space. Fields common to all
- messages are:</para>
+ <para>Messages generated by <command>ipmon</command> consist
+ of data fields separated by white space. Fields common to
+ all messages are:</para>
<orderedlist>
<listitem>
@@ -883,13 +905,13 @@
<listitem>
<para>The time of packet receipt. This is in the form
- HH:MM:SS.F, for hours, minutes, seconds, and fractions of a
- second (which can be several digits long).</para>
+ HH:MM:SS.F, for hours, minutes, seconds, and fractions
+ of a second (which can be several digits long).</para>
</listitem>
<listitem>
- <para>The name of the interface the packet was processed on,
- e.g., <devicename>dc0</devicename>.</para>
+ <para>The name of the interface the packet was processed
+ on, e.g., <devicename>dc0</devicename>.</para>
</listitem>
<listitem>
@@ -898,33 +920,36 @@
</listitem>
</orderedlist>
- <para>These can be viewed with <command>ipfstat
- -in</command>.</para>
+ <para>These can be viewed with
+ <command>ipfstat -in</command>.</para>
<orderedlist>
<listitem>
<para>The action: p for passed, b for blocked, S for a short
- packet, n did not match any rules, L for a log rule. The
- order of precedence in showing flags is: S, p, b, n, L. A
- capital P or B means that the packet has been logged due to
- a global logging setting, not a particular rule.</para>
+ packet, n did not match any rules, L for a log rule.
+ The order of precedence in showing flags is: S, p, b, n,
+ L. A capital P or B means that the packet has been logged
+ due to a global logging setting, not a particular
+ rule.</para>
</listitem>
<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, e.g.:
- <literal>209.53.17.22,80 -> 198.73.220.17,1722</literal>.</para>
+ <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.: <literal>PR tcp</literal>.</para>
+ <para><literal>PR</literal> followed by the protocol name
+ or number, e.g.: <literal>PR tcp</literal>.</para>
</listitem>
<listitem>
<para><literal>len</literal> followed by the header length
- and total length of the packet, e.g.: <literal>len 20 40</literal>.</para>
+ and total length of the packet, e.g.:
+ <literal>len 20 40</literal>.</para>
</listitem>
</orderedlist>
@@ -935,9 +960,10 @@
flags.</para>
<para>If the packet is an ICMP packet, there will be two fields
- at the end, the first always being <quote>ICMP</quote>, and the
- next being the ICMP message and sub-message type, separated by
- a slash, e.g., ICMP 3/3 for a port unreachable message.</para>
+ at the end, the first always being <quote>ICMP</quote>, and
+ the next being the ICMP message and sub-message type,
+ separated by a slash, e.g., ICMP 3/3 for a port unreachable
+ message.</para>
</sect2>
<sect2 id="firewalls-ipf-rules-script">
@@ -945,17 +971,18 @@
Substitution</title>
<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 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, symbolic substitution can be used
- to code frequently used values and substitute them in multiple
- rules. This can be seen in the following example.</para>
+ 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 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, symbolic
+ substitution can be used to code frequently used values and
+ substitute them in multiple rules. This can be seen in the
+ following example.</para>
- <para>The script syntax used here is compatible with the &man.sh.1;, &man.csh.1;,
- and &man.tcsh.1; 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>
@@ -998,11 +1025,11 @@
EOF
################## End of IPF rules script ########################</programlisting>
- <para>That is all there is to it. The rules are not important in
- this example; how the symbolic substitution fields are
+ <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>, these rules could be
- reloaded 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>
@@ -1029,9 +1056,10 @@
value) into <filename>/etc/rc.conf</filename> file.</para>
<para>Add a script like the following to your
- <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
+ 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>
<programlisting>#!/bin/sh
@@ -1053,30 +1081,31 @@
<para>A ruleset 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 ruleset processes both the
- packets arriving from the public Internet, as well as the packets
- produced by the system as a response to them.
+ bi-directional exchange of packets between hosts comprises
+ a session conversation. The firewall ruleset processes both
+ the 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,
- 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>
+ 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>IPFILTER</primary>
<secondary>rule processing order</secondary>
- </indexterm>
+ </indexterm>
- <para>IPF was originally written using a rules processing logic
- of <quote>the last matching rule wins</quote> and used only
- stateless 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 rule
- processing logic.</para>
+ <para>IPF was originally written using a rules processing
+ logic of <quote>the last matching rule wins</quote> and used
+ only stateless 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 rule processing logic.</para>
<para>The instructions contained in this section are based on
using rules that contain the <quote>quick</quote> option and
@@ -1104,27 +1133,28 @@
<secondary>rule syntax</secondary>
</indexterm>
- <para>The rule syntax presented here has been simplified to only
- address the modern stateful rule context and <quote>first
- matching rule wins</quote> logic. For the complete legacy rule
- syntax description see the &man.ipf.8; manual page.</para>
+ <para>The rule syntax presented here has been simplified to
+ only address the modern stateful rule context and <quote>first
+ matching rule wins</quote> logic. For the complete legacy
+ rule syntax description see the &man.ipf.8; manual
+ page.</para>
- <para>A <literal>#</literal> character is used to mark the start
- of a comment and may appear at the end of a rule line or on its
- own line. Blank lines are ignored.</para>
+ <para>A <literal>#</literal> character is used to mark the
+ start of a comment and may appear at the end of a rule line
+ or on its own line. Blank lines are ignored.</para>
- <para>Rules contain keywords. These keywords have to be coded in
- a specific order from left to right on the line. Keywords are
- identified in bold type. Some keywords have sub-options which
- may be keywords themselves and also include more sub-options.
- Each of the headings in the below syntax has a bold section
- header which expands on the content.</para>
+ <para>Rules contain keywords. These keywords have to be coded
+ in a specific order from left to right on the line. Keywords
+ are identified in bold type. Some keywords have sub-options
+ which may be keywords themselves and also include more
+ sub-options. Each of the headings in the below syntax has
+ a bold section header which expands on the content.</para>
<!-- This section is probably wrong. See the OpenBSD flag -->
<!-- What is the "OpenBSD flag"? Reference please -->
- <para><replaceable>ACTION IN-OUT OPTIONS SELECTION STATEFUL PROTO
- SRC_ADDR,DST_ADDR OBJECT PORT_NUM TCP_FLAG
+ <para><replaceable>ACTION IN-OUT OPTIONS SELECTION STATEFUL
+ PROTO SRC_ADDR,DST_ADDR OBJECT PORT_NUM TCP_FLAG
STATEFUL</replaceable></para>
<para><replaceable>ACTION</replaceable> = block | pass</para>
@@ -1132,19 +1162,20 @@
<para><replaceable>IN-OUT</replaceable> = in | out</para>
<para><replaceable>OPTIONS</replaceable> = log | quick | on
- interface-name</para>
+ interface-name</para>
<para><replaceable>SELECTION</replaceable> = proto value |
- source/destination IP | port = number | flags
- flag-value</para>
+ source/destination IP | port = number | flags
+ flag-value</para>
<para><replaceable>PROTO</replaceable> = tcp/udp | udp | tcp |
- icmp</para>
+ icmp</para>
<para><replaceable>SRC_ADD,DST_ADDR</replaceable> = all | from
- object to object</para>
+ object to object</para>
- <para><replaceable>OBJECT</replaceable> = IP address | any</para>
+ <para><replaceable>OBJECT</replaceable> = IP address |
+ any</para>
<para><replaceable>PORT_NUM</replaceable> = port number</para>
@@ -1160,8 +1191,8 @@
<emphasis>must</emphasis> have an action. The following
actions are recognized:</para>
- <para><literal>block</literal> indicates that the packet should
- be dropped if the selection parameters match the
+ <para><literal>block</literal> indicates that the packet
+ should be dropped if the selection parameters match the
packet.</para>
<para><literal>pass</literal> indicates that the packet should
@@ -1173,14 +1204,14 @@
<title>IN-OUT</title>
<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 <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>
+ explicitly state which side of the I/O it is to be used
+ on. 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>
<para><literal>in</literal> means this rule is being applied
- against an inbound packet which has just been received on the
- interface facing the public Internet.</para>
+ against an inbound packet which has just been received on
+ the interface facing the public Internet.</para>
<para><literal>out</literal> means this rule is being applied
against an outbound packet destined for the interface facing
@@ -1192,7 +1223,7 @@
<note>
<para>These options must be used in the order shown
- here.</para>
+ here.</para>
</note>
<para><literal>log</literal> indicates that the packet header
@@ -1205,24 +1236,25 @@
packet.</para>
<para><literal>quick</literal> indicates that if the selection
- parameters match the packet, this rule will be the last rule
- checked, allowing a <quote>short-circuit</quote> path to avoid processing
- any following rules for this packet. This option is a
- mandatory requirement for the modernized rules processing
- logic.</para>
+ parameters match the packet, this rule will be the last
+ rule checked, allowing a <quote>short-circuit</quote> path
+ to avoid processing any following rules for this packet.
+ This option is a mandatory requirement for the modernized
+ rules processing logic.</para>
- <para><literal>on</literal> indicates the interface name to be
- incorporated into the selection parameters. Interface names
- are as displayed by &man.ifconfig.8;. Using this option, the
- rule will only match if the packet is going through that
- interface in the specified direction (in/out). This option
- is a mandatory requirement for the modernized rules
- processing logic.</para>
+ <para><literal>on</literal> indicates the interface name to
+ be incorporated into the selection parameters. Interface
+ names are as displayed by &man.ifconfig.8;. Using this
+ option, the rule will only match if the packet is going
+ through that interface in the specified direction (in/out).
+ This option is a mandatory requirement for the modernized
+ rules processing logic.</para>
<para>When a packet is logged, the headers of the packet are
- 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>
+ 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
bytes of the packet contents will be logged after the
@@ -1230,10 +1262,10 @@
<para><literal>first</literal> If the <literal>log</literal>
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>
+ 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>
</sect3>
<sect3>
@@ -1251,19 +1283,20 @@
<sect3>
<title>PROTO</title>
- <para><literal>proto</literal> is the subject keyword and must
- be coded along with one of its corresponding keyword
- sub-option values. The value allows a specific protocol to
- be matched against. This option is a mandatory requirement
- for the modernized rules processing logic.</para>
+ <para><literal>proto</literal> is the subject keyword and
+ must be coded along with one of its corresponding keyword
+ sub-option values. The value allows a specific protocol
+ to be matched against. This option is a mandatory
+ requirement for the modernized rules processing
+ logic.</para>
<para><literal>tcp/udp | udp | tcp | icmp</literal> or any
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 <acronym>UDP</acronym> packet, and has been added as
- a convenience to save duplication of otherwise identical
- rules.</para>
+ 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 <acronym>UDP</acronym>
+ packet, and has been added as a convenience to save
+ duplication of otherwise identical rules.</para>
</sect3>
<sect3>
@@ -1273,46 +1306,49 @@
synonym for <quote>from any to any</quote> with no other
match parameters.</para>
- <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 <emphasis>both</emphasis> source and destination parameters.
- <literal>any</literal> is a special keyword that matches any
- 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
+ <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 <emphasis>both</emphasis> source and
+ destination parameters. <literal>any</literal> is a special
+ keyword that matches any 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>
-
<para>There is no way to match ranges of IP addresses which
do not express themselves easily using the dotted numeric
form / mask-length notation. The <filename
- role="package">net-mgmt/ipcalc</filename> port may be used to
- ease up the calculations. Additional information is available in
- the utility's web page: <ulink
+ role="package">net-mgmt/ipcalc</filename> port may be
+ used to ease up the calculations. Additional information
+ is available in the utility's web page: <ulink
url="http://jodies.de/ipcalc"></ulink>.</para>;
</sect3>
<sect3>
<title>PORT</title>
- <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 <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 <literal>from</literal>
- object, it matches the source port number; when it appears
- 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:
- <literal>from any to any port = 80</literal></para>
+ <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 <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
+ <literal>from</literal> object, it matches the source port
+ number; when it appears 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: <literal>from any to any port =
+ 80</literal></para>
<!-- XXX: Rewritten, but probably needs more changes -->
- <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>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 "=" | "!=" | "<" | ">" | "<=" | ">=" |
"eq" | "ne" | "lt" | "gt" | "le" | "ge".</para>
@@ -1333,8 +1369,8 @@
<para>Flags are only effective for <acronym>TCP</acronym>
filtering. The letters represent one of the possible flags
- that can be matched against the <acronym>TCP</acronym> packet
- header.</para>
+ that can be matched against the <acronym>TCP</acronym>
+ packet header.</para>
<para>The modernized rules processing logic uses the
<literal>flags S</literal> parameter to identify the tcp
@@ -1368,18 +1404,20 @@
<para>Stateful filtering treats traffic as a bi-directional
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 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>
+ activated, keep-state dynamically generates internal rules
+ for each anticipated packet being exchanged during 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 <acronym>ICMP</acronym> packets related to a
- <acronym>TCP</acronym> or <acronym>UDP</acronym> session through. So if you get
- <acronym>ICMP</acronym> type 3 code 4 in response to some web surfing allowed out
+ <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 <acronym>ICMP</acronym> type
+ 3 code 4 in response to some web surfing allowed out
by a keep state rule, they will be automatically allowed in.
Any packet that IPF can be certain is part of an active
session, even if it is a different protocol, will be let
@@ -1387,34 +1425,35 @@
<para>What happens is:</para>
- <para>Packets destined to go out through 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 an active session conversation, then it exits the
+ firewall and the state of the session conversation flow is
+ updated in the dynamic state table. Packets that do not
+ belong to an already active session, are simply checked
+ against the outbound ruleset.</para>
+
+ <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. Packets that do not belong to
- an already active session, are simply checked against the outbound
- ruleset.</para>
+ updated in the dynamic state table. Packets that do not
+ belong to an already active session, are simply checked
+ against the inbound ruleset.</para>
- <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. Packets that do not belong to an already active
- session, are simply checked against the inbound ruleset.</para>
-
<para>When the conversation completes it is removed from the
dynamic state table.</para>
<para>Stateful filtering allows you to focus on blocking/passing
- new sessions. If the new session is passed, all its subsequent
- 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 matching abilities
- capable of defending against the flood of different attack
- methods currently employed by attackers.</para>
+ new sessions. If the new session is passed, all its
+ subsequent 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 matching
+ abilities capable of defending against the flood of different
+ attack methods currently employed by attackers.</para>
</sect2>
<sect2>
@@ -1422,17 +1461,18 @@
<title>Inclusive Ruleset Example</title>
- <para>The following ruleset is an example of how to code a very
- secure inclusive type of firewall. An inclusive firewall only
- allows services matching <literal>pass</literal> rules through, and blocks all
- others by default. Firewalls intended to protect other machines,
- also called <quote>network firewalls</quote>, should have at least
- two interfaces, which are generally configured to trust one side
- (the <acronym>LAN</acronym>) and not the other (the public Internet). Alternatively,
- a firewall might be configured to protect only the system it is
- running on—this is called a
- <quote>host based firewall</quote>, and is particularly appropriate
- for servers on an untrusted network.</para>
+ <para>The following ruleset is an example of how to code a
+ very secure inclusive type of firewall. An inclusive firewall
+ only allows services matching <literal>pass</literal> rules
+ through, and blocks all others by default. Firewalls intended
+ to protect other machines, also called <quote>network
+ firewalls</quote>, should have at least two interfaces, which
+ are generally configured to trust one side (the
+ <acronym>LAN</acronym>) and not the other (the public
+ Internet). Alternatively, a firewall might be configured to
+ protect only the system it is running on—this is called
+ a <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
@@ -1442,19 +1482,20 @@
special internally used packets.</para>
<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 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 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>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 organized into three major
sections: first trusted interfaces, then the public
- interface outbound, and last the public untrusted interface inbound.</para>
+ 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
@@ -1463,67 +1504,75 @@
direction.</para>
<para>The Outbound section in the following ruleset only
- 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 <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>
+ 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
+ <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
- 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
+ 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 that should be taken care of, is to ensure 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.
- 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>
+ <para>Another thing that should be taken care of, is to ensure
+ 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. 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>
<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>
+ 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>
<para>The <filename>/etc/services</filename> file may be used to
lookup unknown port numbers. Alternatively,
visit <ulink
url="http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers"></ulink>;
- and do a port number lookup to find the purpose of a particular
- port number.</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
+ <para>Check out this link for port numbers used by Trojans
+ <ulink
url="http://www.sans.org/security-resources/idfaq/oddports.php"></ulink>.</para>;
<para>The following ruleset creates a complete and very secure
- <literal>inclusive</literal> type of firewall ruleset 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>
+ <literal>inclusive</literal> type of firewall ruleset 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>To avoid logging unwanted messages,
- just add a <literal>block</literal> rule in the inbound section.</para>
+ just add a <literal>block</literal> rule in the inbound
+ section.</para>
- <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>
+ <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>
<para>Add the following statements to
<filename>/etc/ipf.rules</filename>:</para>
@@ -1706,40 +1755,42 @@
<see>NAT</see>
</indexterm>
- <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
- have a private Local Area Network (LAN) behind the firewall
- sharing a single ISP assigned IP address on the public
- Internet.</para>
+ <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 have a private Local Area Network
+ (LAN) behind the firewall sharing a single ISP assigned IP
+ address on the public Internet.</para>
<para>You may ask why would someone want to do this. ISPs
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 the modem is power cycled. This dynamic IP
- address is used to identify your system to the public Internet.</para>
+ 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 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> 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
- separate PC on the LAN to the single public IP address as it
- exits the firewall bound for the public Internet. It also does
- the reverse translation for returning packets.</para>
+ <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 separate PC on the LAN to
+ the single public IP address as it exits the firewall bound
+ for the public Internet. It also does the reverse translation
+ for returning packets.</para>
<para>There is a special range of IP addresses reserved for
<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
+ RFC 1918, the following IP ranges may be used for private
+ nets which will never be routed directly to the public
Internet:</para>
<informaltable frame="none" pgwide="1">
@@ -1752,27 +1803,33 @@
<tbody>
<row>
- <entry>Start IP <hostid role="ipaddr">10.0.0.0</hostid></entry>
+ <entry>Start IP <hostid
+ role="ipaddr">10.0.0.0</hostid></entry>
<entry>-</entry>
- <entry>Ending IP <hostid role="ipaddr">10.255.255.255</hostid></entry>
+ <entry>Ending IP <hostid
+ role="ipaddr">10.255.255.255</hostid></entry>
</row>
<row>
- <entry>Start IP <hostid role="ipaddr">172.16.0.0</hostid></entry>
+ <entry>Start IP <hostid
+ role="ipaddr">172.16.0.0</hostid></entry>
<entry>-</entry>
- <entry>Ending IP <hostid role="ipaddr">172.31.255.255</hostid></entry>
+ <entry>Ending IP <hostid
+ role="ipaddr">172.31.255.255</hostid></entry>
</row>
<row>
- <entry>Start IP <hostid role="ipaddr">192.168.0.0</hostid></entry>
+ <entry>Start IP <hostid
+ role="ipaddr">192.168.0.0</hostid></entry>
<entry>-</entry>
- <entry>Ending IP <hostid role="ipaddr">192.168.255.255</hostid></entry>
+ <entry>Ending IP <hostid
+ role="ipaddr">192.168.255.255</hostid></entry>
</row>
</tbody>
</tgroup>
@@ -1798,15 +1855,17 @@
<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 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>
+ 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>
<para>To reload the <acronym>NAT</acronym> rules issue a command
like this:</para>
- <screen>&prompt.root; <userinput>ipnat -CF -f /etc/ipnat.rules</userinput></screen>
+ <screen>&prompt.root; <userinput>ipnat -CF -f
+ /etc/ipnat.rules</userinput></screen>
<para>To display some statistics about your
<acronym>NAT</acronym>, use this command:</para>
@@ -1828,13 +1887,13 @@
<title>IP<acronym>NAT</acronym> Rules</title>
<para><acronym>NAT</acronym> rules are very flexible and can
- accomplish many different things to fit the needs of commercial
- and home users.</para>
+ accomplish many different things to fit the needs of
+ commercial and home users.</para>
- <para>The rule syntax presented here has been simplified to what
- is most commonly used in a non-commercial environment. For a
- complete rule syntax description see the &man.ipnat.5; manual
- page.</para>
+ <para>The rule syntax presented here has been simplified to
+ what is most commonly used in a non-commercial environment.
+ For a complete rule syntax description see the &man.ipnat.5;
+ manual page.</para>
<para>The syntax for a <acronym>NAT</acronym> rule looks
something like this:</para>
@@ -1860,16 +1919,16 @@
<sect2>
<title>How <acronym>NAT</acronym> Works</title>
- <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 its turn at the packet and applies
- its rules top down, first matching rule wins.
+ <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 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
- 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
- is checked to see if it falls within the IP address range
- specified to the left of the arrow symbol on the
+ 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 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.
@@ -1896,8 +1955,8 @@
<programlisting>ipnat_enable="YES"</programlisting>
- <para>To specify where to load the IP<acronym>NAT</acronym> rules
- from:</para>
+ <para>To specify where to load the IP<acronym>NAT</acronym>
+ rules from:</para>
<programlisting>ipnat_rules="/etc/ipnat.rules"</programlisting>
</sect2>
@@ -1905,11 +1964,11 @@
<sect2>
<title><acronym>NAT</acronym> for a Large LAN</title>
- <para>For networks that have large numbers of PC's on the LAN or
- networks with more than a single LAN, the process of funneling
- all those private IP addresses into a single public IP address
- becomes a resource problem that may cause problems with the
- same port numbers being used many times across many
+ <para>For networks that have large numbers of PC's on the LAN
+ or networks with more than a single LAN, the process of
+ funneling all those private IP addresses into a single public
+ IP address becomes a resource problem that may cause problems
+ with the same port numbers being used many times across many
<acronym>NAT</acronym>ed LAN PC's, causing collisions. There
are two ways to relieve this resource problem.</para>
@@ -1927,10 +1986,10 @@
<para>In the above rule the packet's source port is unchanged
as the packet passes through IP<acronym>NAT</acronym>. By
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 the range shown:</para>
+ 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 the range shown:</para>
<programlisting>map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:60000</programlisting>
@@ -1945,20 +2004,21 @@
<sect3>
<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, 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
+ <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,
+ 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>
- <para>For example, instead of mapping all packets through a single
- public IP address, as in:</para>
+ <para>For example, instead of mapping all packets through a
+ single public IP address, as in:</para>
<programlisting>map dc0 192.168.1.0/24 -> 204.134.75.1</programlisting>
- <para>A range of public IP addresses can be specified either with a
- netmask:</para>
+ <para>A range of public IP addresses can be specified either
+ with a netmask:</para>
<programlisting>map dc0 192.168.1.0/24 -> 204.134.75.0/255.255.255.0</programlisting>
@@ -1978,10 +2038,11 @@
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.
- 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>
+ 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>
@@ -2006,25 +2067,26 @@
not a consideration. Over the years the FTP protocol became
buried into the backbone of the emerging Internet and its
username and password being sent in clear text was never
- 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 by the ordinal ftp
- session requester. For a real good explanation of FTP and the
- different modes see <ulink
+ 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 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>;
<sect3>
<title>IP<acronym>NAT</acronym> Rules</title>
- <para>IP<acronym>NAT</acronym> has a special built in FTP proxy
- option which can be specified on the <acronym>NAT</acronym>
- map rule. It can monitor all outbound packet traffic for FTP
- active or passive start session requests and dynamically
- create temporary filter rules containing only the port number
- really in use for the data channel. This eliminates the
- security risk FTP normally exposes the firewall to from
- having large ranges of high order port numbers open.</para>
+ <para>IP<acronym>NAT</acronym> has a special built in FTP
+ proxy option which can be specified on the
+ <acronym>NAT</acronym> map rule. It can monitor all
+ outbound packet traffic for FTP active or passive start
+ session requests and dynamically create temporary filter
+ rules containing only the port number really in use for
+ the data channel. This eliminates the security risk FTP
+ normally exposes the firewall to from having large ranges
+ of high order port numbers open.</para>
<para>This rule will handle all the traffic for the internal
LAN:</para>
@@ -2085,11 +2147,11 @@
<secondary>IPFW</secondary>
</indexterm>
- <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
- Stateful logic.</para>
+ <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 Stateful logic.</para>
<para>The IPFW sample ruleset (found in
<filename>/etc/rc.firewall</filename> and
@@ -2112,10 +2174,11 @@
<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 <literal>divert</literal>
- rule which triggers the <acronym>NAT</acronym> facility, and the
- advanced special purpose facilities, the dummynet traffic shaper
- facilities, the <literal>fwd rule</literal> forward facility, the bridge
+ 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 <literal>fwd rule</literal> forward facility, the bridge
facility, and the ipstealth facility. IPFW supports both IPv4
and IPv6.</para>
@@ -2129,10 +2192,10 @@
</indexterm>
<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. There is no
- need to compile IPFW into the &os; kernel.</para>
+ 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.
+ There is no need to compile IPFW into the &os; kernel.</para>
<para>After rebooting your system with
<literal>firewall_enable="YES"</literal> in
@@ -2190,15 +2253,16 @@
<programlisting>options IPFIREWALL_VERBOSE</programlisting>
<para>Enables logging of packets that pass through IPFW and have
- the <literal>log</literal> keyword specified in the ruleset.</para>
+ the <literal>log</literal> keyword specified in the
+ ruleset.</para>
<programlisting>options IPFIREWALL_VERBOSE_LIMIT=5</programlisting>
- <para>Limits the number of packets logged through &man.syslogd.8;
- 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>
+ <para>Limits the number of packets logged through
+ &man.syslogd.8; 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>
<indexterm>
<primary>kernel options</primary>
@@ -2209,8 +2273,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 the firewall is being
- set up for the first time.</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>
@@ -2224,8 +2288,9 @@
functionality.</para>
<note>
- <para>The firewall will block all incoming and outgoing packets if
- either the <literal>IPFIREWALL_DEFAULT_TO_ACCEPT</literal> kernel
+ <para>The firewall will block all incoming and outgoing
+ packets if either the
+ <literal>IPFIREWALL_DEFAULT_TO_ACCEPT</literal> kernel
option or a rule to explicitly allow these connections are
missing.</para>
</note>
@@ -2249,49 +2314,53 @@
<itemizedlist>
<listitem>
- <para><literal>open</literal> — pass all traffic.</para>
+ <para><literal>open</literal> — pass all
+ traffic.</para>
</listitem>
<listitem>
- <para><literal>client</literal> — will protect only this
- machine.</para>
+ <para><literal>client</literal> — will protect only
+ this machine.</para>
</listitem>
<listitem>
<para><literal>simple</literal> — protect the whole
network.</para>
</listitem>
<listitem>
- <para><literal>closed</literal> — entirely disables IP
- traffic except for the loopback interface.</para>
+ <para><literal>closed</literal> — entirely disables
+ IP traffic except for the loopback interface.</para>
</listitem>
<listitem>
- <para><literal>UNKNOWN</literal> — disables the loading
- of firewall rules.</para>
+ <para><literal>UNKNOWN</literal> — disables the
+ loading of firewall rules.</para>
</listitem>
<listitem>
- <para><filename><replaceable>filename</replaceable></filename> — absolute path of
- file containing firewall rules.</para>
+
+ <para><filename><replaceable>filename</replaceable></filename>
+ — absolute path of file containing firewall
+ rules.</para>
</listitem>
</itemizedlist>
<para>It is possible to use two different ways to load custom
rules for <application>ipfw</application> firewall. One is
- by setting <literal>firewall_type</literal> variable to absolute
- path of file, which contains <emphasis>firewall rules</emphasis>
- without any command-line options for &man.ipfw.8; itself.
- The following is a simple example of a ruleset file that blocks
- all incoming and outgoing traffic:</para>
+ by setting <literal>firewall_type</literal> variable to
+ absolute path of file, which contains <emphasis>firewall
+ rules</emphasis> without any command-line options for
+ &man.ipfw.8; itself. The following is a simple example of
+ a ruleset file that blocksall incoming and outgoing
+ traffic:</para>
- <programlisting>add deny in
-add deny out</programlisting>
+ <programlisting>add deny in add deny out</programlisting>
<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 the following:</para>
+ <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 the
+ following:</para>
- <programlisting>#!/bin/sh
+ <programlisting>#!/bin/sh
ipfw -q flush
@@ -2318,9 +2387,10 @@
setting the <varname>net.inet.ip.fw.verbose</varname> sysctl
variable to the value of <literal>1</literal> (see <xref
linkend="firewalls-ipfw-enable"/>). There is no
- <filename>rc.conf</filename> variable to set log limitations,
- but it can be set via sysctl variable, manually or from the
- <filename>/etc/sysctl.conf</filename> file:</para>
+ <filename>rc.conf</filename> variable to set log
+ limitations, but it can be set via sysctl variable, manually
+ or from the <filename>/etc/sysctl.conf</filename>
+ file:</para>
<programlisting>net.inet.ip.fw.verbose_limit=5</programlisting>
</warning>
@@ -2337,23 +2407,24 @@
<indexterm><primary><command>ipfw</command></primary></indexterm>
- <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 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
- recommended method used here.</para>
+ <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 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 recommended method used
+ here.</para>
- <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 one of the ways of determining if the rule is
- functioning.</para>
+ <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 one of the ways of
+ determining if the rule is functioning.</para>
<para>To list all the rules in sequence:</para>
@@ -2364,11 +2435,11 @@
<screen>&prompt.root; <userinput>ipfw -t list</userinput></screen>
- <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
- packets, and then the rule itself.</para>
+ <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 packets, and then the rule itself.</para>
<screen>&prompt.root; <userinput>ipfw -a list</userinput></screen>
@@ -2398,17 +2469,18 @@
<para>A ruleset 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 ruleset processes both the
- packets arriving from the public Internet, as well as the packets
- originating from the system as a response to them.
+ bi-directional exchange of packets between hosts comprises
+ a session conversation. The firewall ruleset 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,
- 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>
+ 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>
@@ -2419,16 +2491,16 @@
<!-- Needs rewording to include note below -->
<para>When a packet enters the firewall it is compared against
- the first rule in the ruleset 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 the selection parameters
- of a rule, the rules' action field value is executed and the
- search of the ruleset 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
- denies all packets and discards them without any reply back to
- the originating destination.</para>
+ the first rule in the ruleset 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 the selection
+ parameters of a rule, the rules' action field value is
+ executed and the search of the ruleset 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 denies all packets and discards them
+ without any reply back to the originating destination.</para>
<note>
<para>The search continues after <literal>count</literal>,
@@ -2437,13 +2509,15 @@
</note>
<para>The instructions contained here are based on using rules
- 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 ruleset.</para>
+ 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 ruleset.</para>
<warning>
- <para>Be careful when working with firewall rules, as it is easy to
- end up locking yourself 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">
@@ -2461,10 +2535,10 @@
see the &man.ipfw.8; manual page.</para>
<para>Rules contain keywords: these keywords have to be coded
- in a specific order from left to right on the line. Keywords
- are identified in bold type. Some keywords have sub-options
- which may be keywords them selves and also include more
- sub-options.</para>
+ in a specific order from left to right on the line.
+ Keywords are identified in bold type. Some keywords have
+ sub-options which may be keywords them selves and also
+ include more sub-options.</para>
<para><literal>#</literal> is used to mark the start of a
comment and may appear at the end of a rule line or on its
@@ -2484,8 +2558,8 @@
<sect4>
<title>RULE_NUMBER</title>
- <para>Each rule is associated with a rule_number in the range
- 1..65535.</para>
+ <para>Each rule is associated with a rule_number in the
+ range 1..65535.</para>
</sect4>
<sect4>
@@ -2498,19 +2572,19 @@
<para><parameter>allow | accept | pass |
permit</parameter></para>
- <para>These all mean the same thing which is to allow packets
- that match the rule to exit the firewall rule processing.
- The search terminates at this rule.</para>
+ <para>These all mean the same thing which is to allow
+ packets that match the rule to exit the firewall rule
+ processing. The search terminates at this rule.</para>
<para><parameter>check-state</parameter></para>
- <para>Checks the packet against the dynamic rules table. If
- a match is found, execute the action associated with the
- rule which generated this dynamic rule, otherwise move to
- the next rule. The check-state rule does not have
- selection criterion. If no check-state rule is present in
- the ruleset, the dynamic rules table is checked at the
- first keep-state or limit rule.</para>
+ <para>Checks the packet against the dynamic rules table.
+ If a match is found, execute the action associated with
+ the rule which generated this dynamic rule, otherwise
+ move to the next rule. The check-state rule does not
+ have selection criterion. If no check-state rule is
+ present in the ruleset, the dynamic rules table is checked
+ at the first keep-state or limit rule.</para>
<para><parameter>deny | drop</parameter></para>
@@ -2525,25 +2599,29 @@
<para><parameter>log</parameter> or
<parameter>logamount</parameter></para>
- <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 <literal>logamount</literal> parameter. If no <literal>logamount</literal> is
- specified, the limit is taken from the sysctl variable
- <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 <command>ipfw reset log</command> command.</para>
+ <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
+ <literal>logamount</literal> parameter. If no
+ <literal>logamount</literal> is specified, the limit is
+ taken from the sysctl variable
+ <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 <command>ipfw reset log</command>
+ command.</para>
<note>
<para>Logging is done after
all other packet matching conditions have been
successfully verified, and before performing the final
- action (accept, deny) on the packet. It is up to you to
- decide which rules you want to enable logging on.</para>
- </note>
+ action (accept, deny) on the packet. It is up to you
+ to decide which rules you want to enable logging
+ on.</para>
+ </note>
</sect4>
<sect4>
@@ -2558,43 +2636,50 @@
<para><parameter>udp | tcp | icmp</parameter></para>
<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>
+ <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 <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 <literal>from me to
- 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. The <filename
- role="package">net-mgmt/ipcalc</filename> port may be used to
- ease up the calculations. Additional
+ <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 <literal>from me to
+ 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. The <filename
+ role="package">net-mgmt/ipcalc</filename> port may be
+ used to ease up the calculations. Additional
information is available in the utility's web page: <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 <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>
+ <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 <literal>in</literal> and <literal>out</literal> are keywords and it is mandatory that
+ 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>
@@ -2607,26 +2692,30 @@
<para><parameter>setup</parameter></para>
- <para>This is a mandatory keyword that identifies the session
- start request for <acronym>TCP</acronym> packets.</para>
+ <para>This is a mandatory keyword that identifies the
+ session start request for <acronym>TCP</acronym>
+ packets.</para>
<para><parameter>keep-state</parameter></para>
<para>This is a mandatory keyword. Upon a match, the
- firewall will create a dynamic rule, whose default behavior
- is to match bidirectional traffic between source and
- destination IP/port using the same protocol.</para>
+ firewall will create a dynamic rule, whose default
+ behavior is to match bidirectional traffic between source
+ and destination IP/port using the same protocol.</para>
<para><parameter>limit {src-addr | src-port | dst-addr |
dst-port}</parameter></para>
<para>The firewall will only allow
- <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 <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>
+ <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 <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>
@@ -2650,26 +2739,27 @@
properly fit the session conversation template are
automatically rejected as impostors.</para>
- <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 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 ruleset for
- testing.</para>
+ <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 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 ruleset for testing.</para>
<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 <literal>limit</literal>. This
- option is used to limit the number of simultaneous session
- 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 <literal>limit</literal> option, the
+ added another new option named <literal>limit</literal>.
+ This option is used to limit the number of simultaneous
+ session 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 <literal>limit</literal> option, the
packet is discarded.</para>
</sect3>
@@ -2684,69 +2774,74 @@
<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 and where they were
- going, giving you a significant edge in tracking down
- attackers.</para>
+ logging on which provides information like, what packets
+ had been dropped, what addresses they came from and where
+ they were going, giving you a significant edge in tracking
+ down 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 ruleset 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 <quote>ipfw default deny everything</quote> rule with the
- <literal>log</literal> verb included as your last rule in the ruleset. This
- way it is possible to see all the packets that did not match any
- of the rules in the ruleset.</para>
+ 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 <quote>ipfw default deny
+ everything</quote> rule with the <literal>log</literal>
+ verb included as your last rule in the ruleset. This
+ way it is possible to see all the packets that did not
+ match any of the rules in the ruleset.</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 messages are not only written to <application>syslogd</application>, but also are
+ <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 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 &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
- <application>syslogd</application>, the remainder identical consecutive messages would
- be counted and posted to <application>syslogd</application> with a phrase like
- the following:</para>
+ 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 <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>
<para>All logged packets messages are written by default to
- <filename>/var/log/security</filename> file, which is defined
- in the <filename>/etc/syslog.conf</filename> file.</para>
+ <filename>/var/log/security</filename> file, which is
+ defined in the <filename>/etc/syslog.conf</filename>
+ file.</para>
</sect3>
<sect3 id="firewalls-ipfw-rules-script">
<title>Building a Rule Script</title>
- <para>Most experienced IPFW users create a file containing the
- 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 them. This method is very
- convenient in testing new rules as the procedure can be
- 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>Most experienced IPFW users create a file containing
+ the 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 them. This method is
+ very convenient in testing new rules as the procedure can
+ be 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 &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 in "double quotes".</para>
+ <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
+ in "double quotes".</para>
<para>Start your rules file like this:</para>
@@ -2771,8 +2866,9 @@
populated and used are.</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>
+ <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>
@@ -2798,26 +2894,28 @@
<para>The following non-<acronym>NAT</acronym>ed ruleset 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.
- Firewalls designed to protect entire network segments, have at minimum two interfaces which must
+ matching pass rules through and blocks all other by
+ default. 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
- address <hostid role="ipaddr">127.0.0.1</hostid> for internal
- communication with in the operating system. The firewall
- rules must contain rules to allow free unmolested movement of
- these special internally used packets.</para>
+ <para>All &unix; flavored operating systems, &os; included,
+ are designed to use interface <devicename>lo0</devicename>
+ and IP address <hostid role="ipaddr">127.0.0.1</hostid>
+ for internal communication with in the operating system.
+ The firewall rules must contain rules to allow free
+ unmolested movement of these special internally used
+ packets.</para>
- <para>The interface which faces the public Internet is the one
- 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>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 NICs are connected to
- a private LAN 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>
@@ -2828,55 +2926,62 @@
<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 blocking and logging all packets on that interface
- and direction.</para>
+ the section blocking and logging all packets on that
+ interface and direction.</para>
<para>The Outbound section in the following ruleset only
- 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 <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>
+ 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 <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. 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>
+ 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 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. Packets with unrecognized port numbers may be looked
- up in <filename>/etc/services/</filename> or go to <ulink
+ <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. Packets
+ with unrecognized port numbers may be looked up in
+ <filename>/etc/services/</filename> or go to <ulink
url="http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers"></ulink>;
- 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
+ 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.sans.org/security-resources/idfaq/oddports.php"></ulink>.</para>;
</sect3>
<sect3>
<title>An Example Inclusive Ruleset</title>
- <para>The following non-<acronym>NAT</acronym>ed ruleset is a
- complete inclusive type ruleset. It is safe to use this ruleset
- 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
- 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
+ <para>The following non-<acronym>NAT</acronym>ed ruleset is
+ a complete inclusive type ruleset. It is safe to use this
+ ruleset 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 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>There is a noticeable pattern in the usage of these
@@ -2885,22 +2990,25 @@
<itemizedlist>
<listitem>
<para>All statements that are a request to start a session
- to the public Internet use <literal>keep-state</literal>.</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 <literal>limit</literal> option to stop
- flooding.</para>
+ <para>All the authorized services that originate from
+ the public Internet have the <literal>limit</literal>
+ option to stop flooding.</para>
</listitem>
<listitem>
- <para>All rules use <literal>in</literal> or <literal>out</literal> 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 <literal>via</literal> <replaceable>interface-name</replaceable> to specify the
- interface the packet is traveling over.</para>
+ <para>All rules use <literal>via</literal>
+ <replaceable>interface-name</replaceable> to specify
+ the interface the packet is traveling over.</para>
</listitem>
</itemizedlist>
@@ -3069,9 +3177,10 @@
<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 <literal>option IPDIVERT</literal>
- statement added to the other IPFIREWALL statements compiled
- into a custom kernel.</para>
+ function of IPFW. The kernel source needs
+ <literal>option IPDIVERT</literal> statement added to the
+ other IPFIREWALL statements compiled into a custom
+ kernel.</para>
<para>In addition to the normal IPFW options in
<filename>/etc/rc.conf</filename>, the following are
@@ -3081,15 +3190,19 @@
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 <literal>divert natd</literal> rule (Network
- Address Translation) greatly complicates the ruleset coding
- logic. The positioning of the <literal>check-state</literal>, and <literal>divert natd</literal>
- rules in the ruleset becomes very critical. This is no
- longer a simple fall-through logic flow. A new action type
- 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>Utilizing stateful rules with
+ <literal>divert natd</literal> rule (Network Address
+ Translation) greatly complicates the ruleset coding
+ logic. The positioning of the
+ <literal>check-state</literal>, and
+ <literal>divert natd</literal> rules in the ruleset becomes
+ very critical. This is no longer a simple fall-through
+ logic flow. A new action type 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
method, selected here to explain the sequence of the packet
@@ -3099,68 +3212,74 @@
top of the rule file and progress one rule at a time deeper
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 specify the
- direction the packet is going (i.e.: outbound or inbound) and
- the interface. Also notice that the start outbound
- session requests, all <literal>skipto rule 500</literal> for the network address
+ 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
+ specify the direction the packet is going (i.e.: outbound
+ or inbound) and 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 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 <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 <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, where a response
+ 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
+ <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
+ <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, where a response
packet is generated and sent back. This new packet
- enters the top of the ruleset. 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
- <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 <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>
+ enters the top of the ruleset. 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 <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
+ <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 <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 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 then matched against
- all the nasty things that need to be checked for and finally matches
+ 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 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 then matched against 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
- <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>
+ 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 <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 anexisting 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>
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1358551408.34925.YahooMailClassic>