From 4aef5b60d44eb1a1884bf08d23e655c8a341dbf7 Mon Sep 17 00:00:00 2001
From: Dru Lavigne <dru@FreeBSD.org>
Date: Mon, 11 Feb 2013 15:01:37 +0000
Subject: [PATCH] This patch addresses the following:
- rewording to remove you, etc., i.e., and references to PPP
- fixes xref
- general tightening, removal of redundant paragraphs, and many fixes to grammos/typos
- a reference to a non-existing logging section was removed
- several comments were addressed and removed
Approved by gjb (mentor)
---
.../books/handbook/firewalls/chapter.xml | 2243 +++++++----------
1 file changed, 937 insertions(+), 1306 deletions(-)
diff --git a/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml b/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
index 72913cb2df..d465ae3de3 100644
--- a/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
+++ b/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
@@ -36,39 +36,37 @@
<sect1 id="firewalls-intro">
<title>Introduction</title>
- <para>Firewalls make it possible to filter incoming and outgoing
- traffic that flows through your system. A firewall can use one
- or more sets of <quote>rules</quote> to inspect the network
- packets as they come in or go out of your network connections
- and either allows the traffic through or blocks it. The rules
- of a firewall can inspect one or more characteristics of the
- packets, including but not limited to the protocol type, the
- source or destination host address, and the source or
- destination port.</para>
+ <para>Firewalls make it possible to filter the incoming and
+ outgoing traffic that flows through a system. A firewall can
+ use one or more sets of <quote>rules</quote> to inspect network
+ packets as they come in or go out of network connections and
+ either allows the traffic through or blocks it. The rules of
+ a firewall can inspect one or more characteristics of the
+ packets such as the protocol type, source or destination host
+ address, and source or destination port.</para>
- <para>Firewalls can greatly enhance the security of a host or a
- network. They can be used to do one or more of
- the following things:</para>
+ <para>Firewalls can enhance the security of a host or a network.
+ They can be used to do one or more of the following:</para>
<itemizedlist>
<listitem>
- <para>To protect and insulate the applications, services and
- machines of your internal network from unwanted traffic
- coming in from the public Internet.</para>
+ <para>Protect and insulate the applications, services, and
+ machines of an internal network from unwanted traffic from
+ the public Internet.</para>
</listitem>
<listitem>
- <para>To limit or disable access from hosts of the internal
+ <para>Limit or disable access from hosts of the internal
network to services of the public Internet.</para>
</listitem>
<listitem>
- <para>To support network address translation
- (<acronym>NAT</acronym>), which allows your internal network
+ <para>Support network address translation
+ (<acronym>NAT</acronym>), which allows an internal network
to use private <acronym>IP</acronym> addresses and share a
- single connection to the public Internet (either with a
- single <acronym>IP</acronym> address or by a shared pool of
- automatically assigned public addresses).</para>
+ single connection to the public Internet using either a
+ single <acronym>IP</acronym> address or a shared pool of
+ automatically assigned public addresses.</para>
</listitem>
</itemizedlist>
@@ -76,27 +74,27 @@
<itemizedlist>
<listitem>
- <para>How to properly define packet filtering rules.</para>
+ <para>How to define packet filtering rules.</para>
</listitem>
<listitem>
- <para>The differences between the firewalls
- built into &os;.</para>
+ <para>The differences between the firewalls built into
+ &os;.</para>
</listitem>
<listitem>
- <para>How to use and configure the OpenBSD
+ <para>How to use and configure the
<application>PF</application> firewall.</para>
</listitem>
<listitem>
- <para>How to use and configure
- <application>IPFILTER</application>.</para>
+ <para>How to use and configure the
+ <application>IPFILTER</application> firewall.</para>
</listitem>
<listitem>
- <para>How to use and configure
- <application>IPFW</application>.</para>
+ <para>How to use and configure the
+ <application>IPFW</application> firewall.</para>
</listitem>
</itemizedlist>
@@ -118,81 +116,68 @@
<secondary>rulesets</secondary>
</indexterm>
- <para>There are two basic ways to create firewall rulesets:
- <quote>inclusive</quote> or <quote>exclusive</quote>. An
+ <para>A firewall ruleset can be either
+ <quote>exclusive</quote> or <quote>inclusive</quote>. An
exclusive firewall allows all traffic through except for the
traffic matching the ruleset. An inclusive firewall does the
- reverse. It only allows traffic matching the rules through and
+ reverse as 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 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 a private network. All traffic that does not match
+ the rules is blocked and logged. Inclusive firewalls are
+ generally safer than exclusive firewalls because they
+ significantly reduce the risk of allowing unwanted
+ traffic.</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 firewall
+ rulesets.</para>
</note>
<para>Security can be tightened further using a <quote>stateful
- firewall</quote>. This type of firewall keeps
- track of which connections are opened through the firewall and
- will only allow traffic through which either matches an existing
- connection or opens a new one. The disadvantage of a stateful
- firewall is that it can be vulnerable to Denial of Service
- (<acronym>DoS</acronym>) attacks if a lot of new connections are
- opened very fast. With most firewalls it is possible to use a
- combination of stateful and non-stateful behavior to make an
- optimal firewall for the site.</para>
+ firewall</quote>. This type of firewall keeps track of open
+ connections and only allows traffic which either matches an
+ existing connection or opens a new, allowed connection. The
+ disadvantage of a stateful firewall is that it can be vulnerable
+ to Denial of Service (<acronym>DoS</acronym>) attacks if a lot
+ of new connections are opened very fast. Most firewalls use a
+ combination of stateful and non-stateful behavior.</para>
</sect1>
<sect1 id="firewalls-apps">
<title>Firewall Packages</title>
- <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
- <acronym>ALTQ</acronym> with
- <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>
+ <para>&os; has three firewalls built into the base system:
+ <emphasis>IPFILTER</emphasis>, also known as
+ <acronym>IPF</acronym>, <emphasis>IPFIREWALL</emphasis>, also
+ known as <acronym>IPFW</acronym>, and <acronym>PF</acronym>).
+ &os; also provides two traffic shapers for 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>. Each
+ firewall uses rules to control the access of packets to and from
+ a &os; system, although they go about it in different ways and
+ each has a different rule syntax.</para>
- <para>The reason that &os; has multiple built in firewall packages
- is that different people have different requirements and
- preferences. No single firewall package is the best.</para>
-
- <para>The author prefers IPFILTER because its stateful rules are
- much less complicated to use in a <acronym>NAT</acronym>
- environment and it has a built in ftp proxy that simplifies the
- rules to allow secure outbound FTP usage.</para>
+ <para>&os; provides multiple firewalls in order to meet the
+ different requirements and preferences for a wide variety of
+ users. Each user should evaluate which firewall best meets
+ their needs.</para>
<para>Since all firewalls are based on inspecting the values of
selected packet control fields, the creator of the firewall
- rulesets must have an understanding of how
+ ruleset must have an understanding of how
<acronym>TCP/IP</acronym> works, what the different values in
- the packet control fields are and how these values are used in a
- normal session conversation. For a good explanation go to:
- <ulink
- url="http://www.ipprimer.com/overview.cfm"></ulink>.</para>
+ the packet control fields are, and how these values are used in
+ a normal session conversation. For a good introduction, refer
+ to <ulink
+ url="http://www.ipprimer.com/overview.cfm">Daryl's TCP/IP
+ Primer</ulink>.</para>
</sect1>
<sect1 id="firewalls-pf">
@@ -207,8 +192,7 @@
</authorgroup>
</sect1info>
- <title>The OpenBSD Packet Filter (PF) and
- <acronym>ALTQ</acronym></title>
+ <title>PF and <acronym>ALTQ</acronym></title>
<indexterm>
<primary>firewall</primary>
@@ -216,72 +200,65 @@
<secondary>PF</secondary>
</indexterm>
- <para>As of July 2003 the OpenBSD firewall software application
- known as <acronym>PF</acronym> was ported to &os; and
- made available in the &os; Ports Collection. Released in 2004,
- &os; 5.3 was the first release that contained
- <acronym>PF</acronym> as an integrated part of the base system.
- <acronym>PF</acronym> is a complete, full-featured firewall
- that has optional support for <acronym>ALTQ</acronym> (Alternate
- Queuing). <acronym>ALTQ</acronym> provides Quality of Service
- (<acronym>QoS</acronym>) functionality.</para>
+ <para>Since &os; 5.3, a ported version of OpenBSD's
+ <acronym>PF</acronym> firewall has been included as an
+ integrated part of the base system. <acronym>PF</acronym> is a
+ complete, full-featured firewall that has optional support for
+ <acronym>ALTQ</acronym> (Alternate Queuing), which provides
+ Quality of Service (<acronym>QoS</acronym>).</para>
- <para>The OpenBSD Project does an outstanding job of
- maintaining the <ulink
- url="http://www.openbsd.org/faq/pf/">PF FAQ</ulink>.
- As such, this section of the Handbook will focus on
- <acronym>PF</acronym> as it pertains to &os; while providing
- some general information regarding usage. For detailed usage
- information please refer to the <ulink
- url="http://www.openbsd.org/faq/pf/">PF FAQ</ulink>.</para>
+ <para>Since the OpenBSD Project maintains the definitive
+ reference for <acronym>PF</acronym> in the<ulink
+ url="http://www.openbsd.org/faq/pf/">PF FAQ</ulink>, this
+ section of the Handbook focuses on <acronym>PF</acronym> as it
+ pertains to &os;, while providing some general usage
+ information.</para>
- <para>More information about <acronym>PF</acronym> for &os;
+ <para>More information about porting <acronym>PF</acronym> to &os;
can be found at <ulink
url="http://pf4freebsd.love2party.net/"></ulink>.</para>
<sect2>
<title>Using the PF Loadable Kernel Modules</title>
- <para>To load the PF Kernel Module add the following line to
+ <para>In order to use PF, the PF kernel module must be first
+ loaded. 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>service 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
+ <para>The PF module will not load if it cannot find the
+ ruleset configuration 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
- <filename>/etc/rc.conf</filename>:</para>
+ located somewhere else, add a line to
+ <filename>/etc/rc.conf</filename> which specifies the full
+ path to the file:</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>
<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
+ <para>Logging support for PF is provided by
+ <varname>pflog.ko</varname> which can be loaded by adding the
following line to <filename>/etc/rc.conf</filename>:</para>
<programlisting>pflog_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>service 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>
</sect2>
<sect2>
@@ -305,37 +282,32 @@
<secondary>device pfsync</secondary>
</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>CARP</acronym> can be found in
- <xref linkend="carp"/> of the Handbook.</para>
+ <para>While it is not necessary to compile
+ <acronym>PF</acronym> support into the &os; kernel, some of
+ PF's advanced features are 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 <link
+ linkend="carp">of the Handbook</link>.</para>
- <para>The <acronym>PF</acronym> kernel options can be found in
- <filename>/usr/src/sys/conf/NOTES</filename> and are
- reproduced below:</para>
+ <para>The following <acronym>PF</acronym> kernel options can be
+ found in <filename>/usr/src/sys/conf/NOTES</filename>:</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><literal>device pf</literal> enables PF support.</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><literal>device pflog</literal> 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 then be used to store the logging information to
+ disk.</para>
- <para>The <literal>device pfsync</literal> option enables the
- optional
+ <para><literal>device pfsync</literal> enables the optional
&man.pfsync.4; pseudo-network device that is used to monitor
<quote>state changes</quote>.</para>
</sect2>
@@ -343,8 +315,9 @@ device pfsync</programlisting>
<sect2>
<title>Available <filename>rc.conf</filename> Options</title>
- <para>The following &man.rc.conf.5; statements configure
- <acronym>PF</acronym> and &man.pflog.4; at boot:</para>
+ <para>The following &man.rc.conf.5; statements can be used to
+ configure <acronym>PF</acronym> and &man.pflog.4; at
+ boot:</para>
<programlisting>pf_enable="YES" # Enable PF (load module if required)
pf_rules="/etc/pf.conf" # rules definition file for pf
@@ -353,9 +326,9 @@ pflog_enable="YES" # start pflogd(8)
pflog_logfile="/var/log/pflog" # where pflogd should store the logfile
pflog_flags="" # additional flags for pflogd startup</programlisting>
- <para>If you have a LAN behind this firewall and have to forward
- packets for the computers on the LAN or want to do NAT, you
- will need the following option as well:</para>
+ <para>If there is a LAN behind the firewall and packets need to
+ be forwarded for the computers on the LAN, or NAT is required,
+ add the following option:</para>
<programlisting>gateway_enable="YES" # Enable as LAN gateway</programlisting>
</sect2>
@@ -363,40 +336,40 @@ pflog_flags="" # additional flags for pflogd startup</programli
<sect2>
<title>Creating Filtering Rules</title>
- <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;
- 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>
+ <para>By default, <acronym>PF</acronym> reads its configuration
+ rules from <filename>/etc/pf.conf</filename> and modifies,
+ drops, or passes packets according to the rules or definitions
+ specified in this file. The &os; installation includes
+ several sample files located in
+ <filename>/usr/share/examples/pf/</filename>. 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>,
- 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
+ <para>When reading the <ulink
+ url="http://www.openbsd.org/faq/pf/">PF FAQ</ulink>,
+ keep in mind that different versions of &os; 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>
</warning>
<para>The &a.pf; is a good place to ask questions about
- configuring and running the <acronym>PF</acronym>
- firewall. Do not forget to check the mailing list archives
- before asking questions!</para>
+ configuring and running the <acronym>PF</acronym> firewall.
+ Do not forget to check the mailing list archives before asking
+ questions.</para>
</sect2>
<sect2>
<title>Working with PF</title>
- <para>Use &man.pfctl.8; to control <acronym>PF</acronym>. Below
- are some useful commands (be sure to review the &man.pfctl.8;
- man page for all available options):</para>
+ <para>To control <acronym>PF</acronym>, use &man.pfctl.8;.
+ Below are some useful options to this command. Review
+ &man.pfctl.8; for a description of all available
+ options:</para>
<informaltable frame="none" pgwide="1">
<tgroup cols="2">
@@ -411,35 +384,35 @@ pflog_flags="" # additional flags for pflogd startup</programli
<row>
<entry><command>pfctl
<option>-e</option></command></entry>
- <entry>Enable PF</entry>
+ <entry>Enable PF.</entry>
</row>
<row>
<entry><command>pfctl
<option>-d</option></command></entry>
- <entry>Disable PF</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>Flush all NAT, filter, state, and table
+ rules and reload
+ <filename>/etc/pf.conf</filename>.</entry>
</row>
<row>
<entry><command>pfctl <option>-s</option> [ rules | nat
state ]</command></entry>
- <entry>Report on the filter rules, nat rules, or state
- table</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>
+ errors, but do not load ruleset.</entry>
</row>
</tbody>
</tgroup>
@@ -449,11 +422,11 @@ pflog_flags="" # additional flags for pflogd startup</programli
<sect2>
<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.
- Please see the &man.altq.4; manual page for a list of drivers
- that are supported in your release of &os;.</para>
+ <para><acronym>ALTQ</acronym> is only available by compiling its
+ support into the &os; kernel. <acronym>ALTQ</acronym> is not
+ supported by all network card drivers. Refer to &man.altq.4;
+ for a list of drivers that are supported by the release of
+ &os;.</para>
<para>The following kernel options will enable
<acronym>ALTQ</acronym> and add additional
@@ -473,28 +446,27 @@ options ALTQ_NOPCC # Required for SMP build</programlisting>
<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
+ can be used 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.
- True to its name, <acronym>RED</acronym> drops packets from
- different connections randomly.</para>
+ used to avoid network congestion 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. <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_HFSC</literal> enables the
<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>
+ Scheduler</emphasis> <acronym>HFSC</acronym>. For more
+ information, refer to <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>
@@ -517,51 +489,46 @@ options ALTQ_NOPCC # Required for SMP build</programlisting>
<secondary>IPFILTER</secondary>
</indexterm>
- <para>The author of IPFILTER is Darren Reed. IPFILTER is not
- operating system dependent: it is an open source application and
+ <para>IPFILTER is a cross-platform, open source firewall which
has been ported to &os;, NetBSD, OpenBSD, &sunos;, HP/UX, and
- &solaris; operating systems. IPFILTER is actively being
- supported and maintained, with updated versions being released
- regularly.</para>
+ &solaris; operating systems.</para>
<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
- <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>
+ can be set or deleted using &man.ipf.8;. The
+ <acronym>NAT</acronym> rules can be set or deleted using
+ &man.ipnat.8;. Run-time statistics for the kernel parts of
+ IPFILTER can be printed using &man.ipfstat.8;. To log IPFILTER
+ actions to the system log files, use &man.ipmon.8;.</para>
<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
- logic. The modernized functions are only included as additional
- options, completely understating their benefits in producing
- a far superior and more secure firewall.</para>
+ of <quote>the last matching rule wins</quote> and only used
+ stateless rules. Over time, IPF has been enhanced to include a
+ <quote>quick</quote> option and a stateful
+ <quote>keep state</quote> option which modernized the rules
+ processing logic. IPF's official documentation covers only the
+ legacy rule coding parameters and rule file processing logic and
+ the modernized functions are only included as additional
+ options.</para>
<para>The instructions contained in this section are based on
- using rules that contain the <quote>quick</quote> option and the
- stateful <quote>keep state</quote> option. This is the basic
- framework for coding an inclusive firewall ruleset.</para>
+ using rules that contain <quote>quick</quote> and
+ <quote>keep state</quote> as these provide the basic framework
+ for configuring an inclusive firewall ruleset.</para>
- <para>For detailed explanation of the legacy rules processing
- method see: <ulink
- url="http://www.munk.me.uk/ipf/ipf-howto.html"></ulink>
+ <para>For a detailed explanation of the legacy rules processing
+ method, refer to <ulink
+ url="http://www.munk.me.uk/ipf/ipf-howto.html"></ulink>
and <ulink
- url="http://coombs.anu.edu.au/~avalon/ip-filter.html"></ulink>.</para>
+ url="http://coombs.anu.edu.au/~avalon/ip-filter.html"></ulink>.</para>
<para>The IPF FAQ is at <ulink
- url="http://www.phildev.net/ipf/index.html"></ulink>.</para>
+ 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 IPFilter mailing list is
+ available at <ulink
+ url="http://marc.theaimsgroup.com/?l=ipfilter"></ulink>.</para>
<sect2>
<title>Enabling IPF</title>
@@ -572,17 +539,15 @@ options ALTQ_NOPCC # Required for SMP build</programlisting>
<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 kernel
+ loadable module. The system will dynamically load
+ this module at boot time when
+ <varname>ipfilter_enable="YES"</varname> is added to
+ <filename>rc.conf</filename>. The module enables logging and
+ <literal>default pass all</literal>. To change the
+ default to <literal>block all</literal>, add a
+ <literal>block all</literal> rule at the end of the
+ ruleset.</para>
</sect2>
<sect2>
@@ -612,15 +577,10 @@ options ALTQ_NOPCC # Required for SMP build</programlisting>
<secondary>kernel options</secondary>
</indexterm>
- <para>It is not a mandatory requirement to enable IPF by
- compiling the following options into the &os; kernel. It is
- only presented here as background information. Compiling IPF
- into the kernel causes the loadable module to never be
- used.</para>
-
- <para>Sample kernel config IPF option statements are in the
- <filename>/usr/src/sys/conf/NOTES</filename> kernel source
- and are reproduced here:</para>
+ <para>For users who prefer to statically compile IPF support
+ into a custom kernel, the following IPF option statements,
+ listed in <filename>/usr/src/sys/conf/NOTES</filename>, are
+ available:</para>
<programlisting>options IPFILTER
options IPFILTER_LOG
@@ -629,15 +589,14 @@ options IPFILTER_DEFAULT_BLOCK</programlisting>
<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
+ <para><literal>options IPFILTER_LOG</literal> enables IPF
+ logging using the <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>
+ the default behavior so that 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>
@@ -657,9 +616,9 @@ ipmon_flags="-Ds" # D = start as daemon
# v = log tcp window, ack, seq
# 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>
+ <para>If there is a LAN behind the firewall that uses the
+ reserved private IP address ranges, the following lines have
+ to be added to enable <acronym>NAT</acronym>
functionality:</para>
<programlisting>gateway_enable="YES" # Enable as LAN gateway
@@ -672,36 +631,36 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<indexterm><primary><command>ipf</command></primary></indexterm>
- <para>The &man.ipf.8; command is used to load your ruleset file.
- Your custom rules would normally be placed in a file, and the
- following command could then be used to replace in mass the
- currently running firewall rules:</para>
+ <para>To load the ruleset file, use &man.ipf.8;. Custom rules
+ are normally placed in a file, and the following command can
+ be used to replace the currently running firewall
+ rules:</para>
<screen>&prompt.root; <userinput>ipf -Fa -f /etc/ipf.rules</userinput></screen>
- <para><option>-Fa</option> means flush all internal rules
+ <para><option>-Fa</option> flushes all the 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> specifies the file containing the
+ rules to load.</para>
- <para>This gives you the ability to make changes to your custom
+ <para>This provides the ability to make changes to a custom
rules file, run the above IPF command, and thus update the
- running firewall with a fresh copy of all the rules without
- having to reboot the system. This method is very convenient
- for testing new rules as the procedure can be executed as many
- times as needed.</para>
+ running firewall with a fresh copy of the rules without having
+ to reboot the system. This method is convenient for testing
+ new rules as the procedure can be executed as many times as
+ needed.</para>
- <para>See the &man.ipf.8; manual page for details on the other
- flags available with this command.</para>
+ <para>Refer to &man.ipf.8; for details on the other 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>
+ <para>&man.ipf.8; 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>
- <para>There is a way to build IPF rules that utilizes the power
+ <para>There is a way to build IPF rules that utilize the power
of script symbolic substitution. For more information, see
- <xref linkend="firewalls-ipf-rules-script"/>.</para>
+ <link linkend="firewalls-ipf-rules-script"></link>.</para>
</sect2>
<sect2>
@@ -717,15 +676,15 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<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
- using <command>ipf -Z</command>.</para>
+ by applying the 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 using <command>ipf
+ -Z</command>.</para>
- <para>See the &man.ipfstat.8; manual page for details.</para>
+ <para>Refer to &man.ipfstat.8; for details.</para>
- <para>The default &man.ipfstat.8; command output will look
- something like this:</para>
+ <para>The default &man.ipfstat.8; output will look something
+ like this:</para>
<screen>input packets: blocked 99286 passed 1255609 nomatch 14686 counted 0
output packets: blocked 4200 passed 1284345 nomatch 14687 counted 0
@@ -751,10 +710,10 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
installed and in use by the kernel.</para>
<para><command>ipfstat -in</command> displays the inbound
- internal rules table with rule number.</para>
+ internal rules table with rule numbers.</para>
<para><command>ipfstat -on</command> displays the outbound
- internal rules table with the rule number.</para>
+ internal rules table with rule numbers.</para>
<para>The output will look something like this:</para>
@@ -776,16 +735,15 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
354727 block out on dc0 from any to any
430918 pass out quick on dc0 proto tcp/udp from any to any keep state</screen>
- <para>One of the most important functions of
- <command>ipfstat</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>
+ <para>One of the most important options of
+ <command>ipfstat</command> is <option>-t</option> which
+ displays the state table in a way similar to how &man.top.1;
+ shows the &os; running process table. When a firewall is
+ under attack, this function provides the ability to identify
+ and see the attacking packets. The optional sub-flags give
+ the ability to select the destination or source IP, port, or
+ protocol to be monitored in real time. Refer to
+ &man.ipfstat.8; for details.</para>
</sect2>
<sect2>
@@ -801,55 +759,51 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<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>
+ turned on. This command has two different modes. Native mode
+ is the default mode when the command is used without
+ <option>-D</option>.</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>, the
- <literal>ipmon_flags</literal> statement uses the
- <option>-Ds</option> flags:</para>
+ <para>Daemon mode provides a continuous system log file so that
+ logging of past events may be reviewed. &os; has a built in
+ facility to automatically rotate system logs. This is why
+ outputting the log information to &man.syslogd.8; is better
+ than the default of outputting to a regular file. The default
+ <filename>rc.conf</filename>
+ <literal>ipmon_flags</literal> statement uses
+ <option>-Ds</option>:</para>
<programlisting>ipmon_flags="-Ds" # D = start as daemon
# s = log to syslog
# v = log tcp window, ack, seq
# n = map IP & port to names</programlisting>
- <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>
+ <para>Logging provides the ability to review, after the fact,
+ information such as which packets were dropped, what addresses
+ they came from and 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
- administrator decides what rules in the ruleset he wants to
- log and adds the log keyword to those rules. Normally only
- deny rules are logged.</para>
+ generate any rule logging by default. The firewall
+ administrator decides which rules in the ruleset should be
+ logged and adds the log keyword to those rules. Normally,
+ only deny rules are logged.</para>
- <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>
+ <para>It is customary to include a <quote>default deny
+ everything</quote> rule with the log keyword included as the
+ 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>
</sect2>
<sect2>
<title>IPMON Logging</title>
- <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>
+ <para>&man.syslogd.8; uses its own method for segregation of log
+ data. It uses groupings called <quote>facility</quote> and
+ <quote>level</quote>. By default, IPMON in
+ <option>-Ds</option> mode uses <literal>local0</literal> as
+ the <quote>facility</quote> name. The following levels can be
+ used to further segregate the logged data:</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
@@ -858,37 +812,31 @@ LOG_ERR - packets which have been logged and which can be considered short</scre
<!-- 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>
+ <para>In order to setup IPFILTER to log all data to
+ <filename>/var/log/ipfilter.log</filename>, first
+ create the empty file:</para>
<screen>&prompt.root; <userinput>touch /var/log/ipfilter.log</userinput></screen>
- <para>The &man.syslogd.8; function is controlled by definition
- statements in <filename>/etc/syslog.conf</filename>.
- This file offers considerable
- flexibility in how <application>syslog</application> will
- deal with system messages issued by software applications
- like IPF.</para>
+ <para>&man.syslogd.8; is controlled by definition statements in
+ <filename>/etc/syslog.conf</filename>. This 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
+ <para>To write all logged messages to the specified file,
+ add the following statement to
<filename>/etc/syslog.conf</filename>:</para>
<programlisting>local0.* /var/log/ipfilter.log</programlisting>
- <para>The <literal>local0.*</literal>
- means to write all the logged messages to the coded
- file location.</para>
-
- <para>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>service syslogd reload</command></para>
+ <para>To activate the changes and instruct &man.syslogd.8;
+ to read the modified <filename>/etc/syslog.conf</filename>,
+ run <command>service syslogd reload</command>.</para>
<para>Do not forget to change
<filename>/etc/newsyslog.conf</filename> to rotate the new
- log created above.</para>
+ log file.</para>
</sect2>
<sect2>
@@ -906,16 +854,16 @@ LOG_ERR - packets which have been logged and which can be considered short</scre
<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>
+ of a second.</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 that processed the
+ packet.</para>
</listitem>
<listitem>
- <para>The group and rule number of the rule, e.g.,
+ <para>The group and rule number of the rule in the format
<literal>@0:17</literal>.</para>
</listitem>
</orderedlist>
@@ -925,45 +873,48 @@ LOG_ERR - packets which have been logged and which can be considered short</scre
<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>
+ <para>The action: <literal>p</literal> for passed,
+ <literal>b</literal> for blocked, <literal>S</literal> for
+ a short packet, <literal>n</literal> did not match any
+ rules, and <literal>L</literal> for a log rule. The order
+ of precedence in showing flags is: <literal>S</literal>,
+ <literal>p</literal>, <literal>b</literal>,
+ <literal>n</literal>, <literal>L</literal>. A capital
+ <literal>P</literal> or <literal>B</literal> 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.:
+ <para>The addresses written as three fields: the source
+ address and port separated by a comma, the -> symbol,
+ and the destination address and port. For example:
<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>
+ or number: for example, <literal>PR tcp</literal>.</para>
</listitem>
<listitem>
<para><literal>len</literal> followed by the header length
- and total length of the packet, e.g.:
+ and total length of the packet: for example,
<literal>len 20 40</literal>.</para>
</listitem>
</orderedlist>
<para>If the packet is a <acronym>TCP</acronym> packet, there
will be an additional field starting with a hyphen followed by
- letters corresponding to any flags that were set. See the
- &man.ipf.5; manual page for a list of letters and their
- flags.</para>
+ letters corresponding to any flags that were set. Refer to
+ &man.ipf.5; for a list of letters and their 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
+ 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>
+ separated by a slash. For example: ICMP 3/3 for a port
+ unreachable message.</para>
</sect2>
<sect2 id="firewalls-ipf-rules-script">
@@ -984,15 +935,15 @@ LOG_ERR - packets which have been logged and which can be considered short</scre
<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>
+ <para>Symbolic substitution fields are prefixed with a
+ <literal>$</literal>.</para>
<para>Symbolic fields do not have the $ prefix.</para>
<para>The value to populate the symbolic field must be enclosed
- with double quotes (<literal>"</literal>).</para>
+ between double quotes (<literal>"</literal>).</para>
- <para>Start your rule file with something like this:</para>
+ <para>Start the rule file with something like this:</para>
<programlisting>############# Start of IPF rules script ########################
@@ -1025,11 +976,11 @@ pass out quick on $oif proto tcp from $myip to any port = 443 &dol
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
- 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>
+ <para>The rules are not important in this example as it instead
+ focuses on how the symbolic substitution fields are populated.
+ If this example was in a file named
+ <filename>/etc/ipf.rules.script</filename>, these rules could
+ be reloaded by running:</para>
<screen>&prompt.root; <userinput>sh /etc/ipf.rules.script</userinput></screen>
@@ -1045,54 +996,52 @@ EOF
<literal>cat</literal>, and comment out the line that
begins with <literal>/sbin/ipf</literal>. Place
<literal>ipfilter_enable="YES"</literal> into
- <filename>/etc/rc.conf</filename> as usual, and run script
+ <filename>/etc/rc.conf</filename>, and run the script
once after each modification to create or update
<filename>/etc/ipf.rules</filename>.</para>
</listitem>
<listitem>
- <para>Disable IPFILTER in system startup scripts by adding
- <literal>ipfilter_enable="NO"</literal> (this is default
- value) to <filename>/etc/rc.conf</filename>.</para>
+ <para>Disable IPFILTER in the system startup scripts by
+ adding <literal>ipfilter_enable="NO"</literal>to
+ <filename>/etc/rc.conf</filename>.</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
+ <para>Then, add a script like the following to <filename
+ class="directory">/usr/local/etc/rc.d/</filename>.
+ The script should have an obvious name like
+ <filename>ipf.loadrules.sh</filename>, where the
<filename>.sh</filename> extension is mandatory.</para>
<programlisting>#!/bin/sh
sh /etc/ipf.rules.script</programlisting>
<para>The permissions on this script file must be read,
- write, execute for owner <username>root</username>.</para>
+ write, execute for owner <username>root</username>:</para>
<screen>&prompt.root; <userinput>chmod 700 /usr/local/etc/rc.d/ipf.loadrules.sh</userinput></screen>
</listitem>
</itemizedlist>
- <para>Now, when your system boots, your IPF rules will be
+ <para>Now, when the system boots, the IPF rules will be
loaded.</para>
</sect2>
<sect2>
<title>IPF Rulesets</title>
- <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
+ <para>A ruleset contains a group of IPF rules which 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.
- 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>
+ Each <acronym>TCP/IP</acronym> service is predefined by its
+ protocol and listening port. Packets destined for a specific
+ service originate from the source address using an
+ unprivileged port and target the specific service port on the
+ destination address. All the above parameters can be used as
+ selection criteria to create rules which will pass or block
+ services.</para>
<indexterm>
<primary>IPFILTER</primary>
@@ -1100,27 +1049,13 @@ sh /etc/ipf.rules.script</programlisting>
<secondary>rule processing order</secondary>
</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>The instructions contained in this section are based on
- using rules that contain the <quote>quick</quote> option and
- the stateful <quote>keep state</quote> option. This is the
- basic framework for coding an inclusive firewall rule
- set.</para>
-
<warning>
<para>When working with the firewall rules, be <emphasis>very
- careful</emphasis>. Some configurations <emphasis>will
- lock you out</emphasis> of the server. To be on the safe
- side, you may wish to consider performing the initial
- firewall configuration from the local console rather than
- doing it remotely e.g., via
- <application>ssh</application>.</para>
+ careful</emphasis>. Some configurations <emphasis>can
+ lock the administrator out</emphasis> of the server. To be
+ on the safe side, consider performing the initial firewall
+ configuration from the local console rather than doing it
+ remotely over <application>ssh</application>.</para>
</warning>
</sect2>
@@ -1136,19 +1071,18 @@ sh /etc/ipf.rules.script</programlisting>
<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>
+ rule syntax, refer to &man.ipf.8;.</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 which must be written 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 -->
@@ -1186,8 +1120,8 @@ sh /etc/ipf.rules.script</programlisting>
<sect3>
<title>ACTION</title>
- <para>The action indicates what to do with the packet if it
- matches the rest of the filter rule. Each rule
+ <para>The action keyword indicates what to do with the packet
+ if it matches the rest of the filter rule. Each rule
<emphasis>must</emphasis> have an action. The following
actions are recognized:</para>
@@ -1207,7 +1141,7 @@ sh /etc/ipf.rules.script</programlisting>
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>
+ included 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
@@ -1227,45 +1161,34 @@ sh /etc/ipf.rules.script</programlisting>
</note>
<para><literal>log</literal> indicates that the packet header
- will be written to
-
- <!-- XXX - xref here -->
-
- the <devicename>ipl</devicename> log (as described in the
- LOGGING section below) if the selection parameters match the
- packet.</para>
+ will be written to the &man.ipl.4; packet log pseudo-device
+ if the selection parameters match the 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>
+ rule checked, and no further processing of any following
+ rules will occur for this packet.</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>
+ through that interface in the specified direction.</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 &man.ipl.4; 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
headers.</para>
- <para><literal>first</literal> If the <literal>log</literal>
+ <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, this option is recommended so that
+ only the triggering packet is logged and not every packet
+ which matches the stateful connection.</para>
</sect3>
<sect3>
@@ -1273,7 +1196,7 @@ sh /etc/ipf.rules.script</programlisting>
<para>The keywords described in this section are used to
describe attributes of the packet to be checked when
- determining whether rules match or not. There is a
+ determining whether or not rules match. There is a
keyword subject, and it has sub-option keywords, one of
which has to be selected. The following general-purpose
attributes are provided for matching, and must be used in
@@ -1283,12 +1206,10 @@ sh /etc/ipf.rules.script</programlisting>
<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 which
+ must include one of its corresponding keyword sub-option
+ values. The sub-option indicates a specific protocol to be
+ matched against.</para>
<para><literal>tcp/udp | udp | tcp | icmp</literal> or any
protocol names found in <filename>/etc/protocols</filename>
@@ -1302,66 +1223,59 @@ sh /etc/ipf.rules.script</programlisting>
<sect3>
<title>SRC_ADDR/DST_ADDR</title>
- <para>The <literal>all</literal> keyword is essentially a
- synonym for <quote>from any to any</quote> with no other
- match parameters.</para>
+ <para>The <literal>all</literal> keyword is equivalent to
+ <quote>from any to any</quote> with no other match
+ parameters.</para>
- <para><literal>from src to dst</literal>: the
+ <para><literal>from | to 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
+ must specify <emphasis>both</emphasis> the 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>
+ keyword that matches any IP address. Examples include:
+ <literal>from any to any</literal>, <literal>from 0.0.0.0/0
+ to any</literal>, <literal>from any to
+ 0.0.0.0/0</literal>, <literal>from 0.0.0.0 to
+ any</literal>, and <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
- url="http://jodies.de/ipcalc"></ulink>.</para>
+ role="package">net-mgmt/ipcalc</filename> port may be
+ used to ease the calculation. Additional information
+ is available at 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
+ source and destination, 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 -->
+ number. When it appears as part of the
+ <literal>to</literal> object, it matches the destination
+ port number. An example usage is <literal>from any to any
+ port = 80</literal></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>
+ using a number of different comparison operators. Instead
+ of the <literal>=</literal> shown in the example above,
+ the following operators may be used: <literal>!=</literal>,
+ <literal><</literal>, <literal>></literal>,
+ <literal><=</literal>, <literal>>=</literal>,
+ <literal>eq</literal>, <literal>ne</literal>,
+ <literal>lt</literal>, <literal>gt</literal>,
+ <literal>le</literal>, and <literal>ge</literal>.</para>
- <para>port "=" | "!=" | "<" | ">" | "<=" | ">=" |
- "eq" | "ne" | "lt" | "gt" | "le" | "ge".</para>
-
- <para>To specify port ranges, port "<>" |
- "><"</para>
-
- <warning>
- <para>Following the source and destination matching
- parameters, the following two parameters are mandatory
- requirements for the modernized rules processing
- logic.</para>
- </warning>
+ <para>To specify port ranges, place the two port numbers
+ between <literal><></literal> or
+ <literal>><</literal></para>
</sect3>
<sect3>
@@ -1373,7 +1287,7 @@ sh /etc/ipf.rules.script</programlisting>
packet header.</para>
<para>The modernized rules processing logic uses the
- <literal>flags S</literal> parameter to identify the tcp
+ <literal>flags S</literal> parameter to identify the TCP
session start request.</para>
</sect3>
@@ -1383,11 +1297,6 @@ sh /etc/ipf.rules.script</programlisting>
<para><literal>keep state</literal> indicates that on a pass
rule, any packets that match the rules selection parameters
should activate the stateful filtering facility.</para>
-
- <note>
- <para>This option is a mandatory requirement for the
- modernized rules processing logic.</para>
- </note>
</sect3>
</sect2>
@@ -1403,57 +1312,52 @@ sh /etc/ipf.rules.script</programlisting>
<!-- XXX: duplicated -->
<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>
+ exchange of packets comprising a session. When activated,
+ <literal>keep-state</literal> dynamically generates
+ internal rules for each anticipated packet being exchanged
+ during the session. It has sufficient matching capabilities
+ to determine if a packet is valid for a session. Any packets
+ that do not properly fit the session template are
+ automatically rejected.</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
- 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
- in.</para>
-
- <para>What happens is:</para>
+ <para>IPF stateful filtering will also allow
+ <acronym>ICMP</acronym> packets related to an existing
+ <acronym>TCP</acronym> or <acronym>UDP</acronym> session. So,
+ if an <acronym>ICMP</acronym> type 3 code 4 packet is a
+ response in a session started by a keep state rule, it will
+ automatically be allowed. Any packet that IPF can be certain
+ is part of an active session, even if it is a different
+ protocol, will be allowed.</para>
<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
+ comprising an active session conversation, 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>
+ belong to an already active session, are 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 inbound ruleset.</para>
+ comprising an active session, 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 checked against the inbound
+ ruleset.</para>
- <para>When the conversation completes it is removed from the
+ <para>When the session completes, it is removed from the
dynamic state table.</para>
- <para>Stateful filtering allows you to focus on blocking/passing
+ <para>Stateful filtering allows one 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>
+ subsequent packets are allowed automatically and any impostor
+ packets are automatically rejected. If a new session is
+ blocked, none of its subsequent packets are allowed. Stateful
+ filtering provides advanced matching abilities capable of
+ defending against the flood of different attack methods
+ employed by attackers.</para>
</sect2>
<sect2>
@@ -1461,40 +1365,36 @@ sh /etc/ipf.rules.script</programlisting>
<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 an inclusive type
+ of firewall which only allows services matching
+ <literal>pass</literal> rules and blocks all others by
+ default. Network firewalls intended to protect other machines
+ should have at least two interfaces, and are generally
+ configured to trust the <acronym>LAN</acronym> and to not
+ trust the public Internet. Alternatively, a host based
+ firewall might be configured to protect only the system it is
+ running on, and is appropriate for servers on an untrusted
+ network or a desktop system not protected by firewall on the
+ network.</para>
- <para>All &unix; flavored systems including &os; are designed to
- use interface <devicename>lo0</devicename> and IP address
- <hostid role="ipaddr">127.0.0.1</hostid> for internal
+ <para>&os; uses interface <devicename>lo0</devicename> and IP
+ address <hostid role="ipaddr">127.0.0.1</hostid> for internal
communication within the operating system. The firewall rules
- must contain rules to allow free unmolested movement of these
- special internally used packets.</para>
+ must contain rules to allow free movement of these 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
- <devicename>tun0</devicename> interface or your NIC that is
- connected to your DSL or cable modem.</para>
+ specified in the rules that authorize and control access of
+ the outbound and inbound connections.</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>
+ other or to the 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
+ sections: the trusted interfaces, then the public
+ interface outbound, and lastly, the public untrusted interface
inbound.</para>
<para>The rules in each of the public interface sections should
@@ -1503,78 +1403,69 @@ sh /etc/ipf.rules.script</programlisting>
blocking and logging all packets on that interface and
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>
+ <para>The outbound section in the following ruleset only
+ contains <literal>pass</literal> rules which uniquely identify
+ the services that are authorized for public Internet access.
+ All the rules use <literal>quick</literal>,
+ <literal>on</literal>, <literal>proto</literal>,
+ <literal>port</literal>, and <literal>keep state</literal>.
+ The <literal>proto tcp</literal> rules include
+ <literal>flag</literal> 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
- to prosecute the people who are attacking your system.</para>
+ <para>The inbound section blocks 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, based on their
+ partial matches against the <literal>allow</literal> rules.
+ The second reason is that known and uninteresting rejects may
+ be blocked silently, rather than being logged by the last rule
+ in the section.</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
+ <para>The ruleset should ensure that there is no response
+ returned for any undesirable traffic. Invalid packets should
+ be silently dropped so that the attacker has no knowledge if
+ the packets reached the system. 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>
+ operating system of the server.</para>
<para>Any time there are logged messages on a rule with
the <literal>log first</literal> option,
<command>ipfstat -hio</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>
+ to evaluate how many times the rule has been matched. A
+ large number of matches usually indicates that the system is
+ being flooded or is 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>
+ <para>To lookup unknown port numbers, refer to
+ <filename>/etc/services</filename>. 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>
<para>Check out this link for port numbers used by Trojans
<ulink
- url="http://www.sans.org/security-resources/idfaq/oddports.php"></ulink>.</para>
+ 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
+ <para>The following ruleset creates an
+ <literal>inclusive</literal> firewall ruleset which can be
+ easily customized by commenting out
<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>
+ <para>To avoid logging unwanted messages, 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>Change the <devicename>dc0</devicename> interface name in
+ every rule to the interface name that connects the system to
+ the public Internet.</para>
- <para>Add the following statements to
+ <para>The following statements were added to
<filename>/etc/ipf.rules</filename>:</para>
<programlisting>#################################################################
@@ -1756,84 +1647,40 @@ block in log first quick on dc0 all
</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>
+ Address Translation</emphasis>. In &linux;, NAT is called
+ <quote>IP Masquerading</quote>. The IPF
+ <acronym>NAT</acronym> function enables the private LAN behind
+ the firewall to share a single ISP-assigned IP address, even
+ if that address is dynamically assigned. NAT allows each
+ computer in the LAN to have Internet access, without
+ having to pay the ISP for multiple Internet accounts or IP
+ addresses.</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>
+ <para><acronym>NAT</acronym> will automatically translate the
+ private LAN IP address for each system on the LAN to the
+ single public IP address as packets exit the firewall bound
+ for the public Internet. It also performs the reverse
+ translation for returning packets.</para>
- <para>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>According to RFC 1918, the following IP address ranges are
+ reserved for private networks which will never be routed
+ directly to the public Internet, and therefore are available
+ for use with NAT:</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>
+ <itemizedlist>
+ <listitem>
+ <para><literal>10.0.0.0/8</literal>.</para>
+ </listitem>
- <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
- Internet:</para>
+ <listitem>
+ <para><literal>172.16.0.0/12</literal>.</para>
+ </listitem>
- <informaltable frame="none" pgwide="1">
- <tgroup cols="2">
- <colspec colwidth="1*"/>
+ <listitem>
+ <para><literal>192.168.0.0/16</literal>.</para>
+ </listitem>
+ </itemizedlist>
- <colspec colwidth="1*"/>
-
- <colspec colwidth="1*"/>
-
- <tbody>
- <row>
- <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>
- </row>
-
- <row>
- <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>
- </row>
-
- <row>
- <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>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
</sect2>
<sect2>
@@ -1847,28 +1694,27 @@ block in log first quick on dc0 all
<indexterm><primary><command>ipnat</command></primary></indexterm>
- <para><acronym>NAT</acronym> rules are loaded by using
- <command>ipnat</command>. Typically the
+ <para><acronym>NAT</acronym> rules are loaded using
+ <command>ipnat</command>. Typically, the
<acronym>NAT</acronym> rules are stored in
<filename>/etc/ipnat.rules</filename>. See &man.ipnat.8; for
details.</para>
- <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
- <command>ipnat</command> with the <option>-CF</option>
- flags to delete the internal in use <acronym>NAT</acronym>
- rules and flush the contents of the translation table of all
- active entries.</para>
+ <para>When the file containing the <acronym>NAT</acronym> rules
+ is edited after <acronym>NAT</acronym> has been started, run
+ <command>ipnat</command> with <option>-CF</option> 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>
+ <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>
- <para>To display some statistics about your
- <acronym>NAT</acronym>, use this command:</para>
+ <para>To display some <acronym>NAT</acronym> statistics, use
+ this command:</para>
<screen>&prompt.root; <userinput>ipnat -s</userinput></screen>
@@ -1877,7 +1723,7 @@ block in log first quick on dc0 all
<screen>&prompt.root; <userinput>ipnat -l</userinput></screen>
- <para>To turn verbose mode on, and display information relating
+ <para>To turn verbose mode on and display information relating
to rule processing and active rules/table entries:</para>
<screen>&prompt.root; <userinput>ipnat -v</userinput></screen>
@@ -1886,17 +1732,17 @@ block in log first quick on dc0 all
<sect2>
<title>IP<acronym>NAT</acronym> Rules</title>
- <para><acronym>NAT</acronym> rules are very flexible and can
+ <para><acronym>NAT</acronym> rules are flexible and can
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>
+ For a complete rule syntax description, refer to
+ &man.ipnat.5;.</para>
- <para>The syntax for a <acronym>NAT</acronym> rule looks
- something like this:</para>
+ <para>The syntax for a <acronym>NAT</acronym> rule looks like
+ this:</para>
<programlisting>map <replaceable>IF</replaceable> <replaceable>LAN_IP_RANGE</replaceable> -> <replaceable>PUBLIC_ADDRESS</replaceable></programlisting>
@@ -1905,31 +1751,31 @@ block in log first quick on dc0 all
<para>Replace <replaceable>IF</replaceable> with the external
interface.</para>
- <para>The <replaceable>LAN_IP_RANGE</replaceable> is what your
- internal clients use for IP Addressing, usually this is
+ <para>The <replaceable>LAN_IP_RANGE</replaceable> is used by the
+ internal clients use for IP Addressing. Usually, this is
something like <hostid
role="ipaddr">192.168.1.0/24</hostid>.</para>
<para>The <replaceable>PUBLIC_ADDRESS</replaceable> can either
- be the external IP address or the special keyword
- <literal>0/32</literal>, which means to use the IP address
- assigned to <replaceable>IF</replaceable>.</para>
+ be the static external IP address or the special keyword
+ <literal>0/32</literal> which uses the IP address assigned to
+ <replaceable>IF</replaceable>.</para>
</sect2>
<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.
- <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
- <acronym>NAT</acronym> rule. On a match the packet has its
+ <para>In IPF, when 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, where the 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, the packet's source IP address in
+ the private LAN is checked to see if it falls within the IP
+ address range specified to the left of the arrow symbol on the
+ <acronym>NAT</acronym> rule. On a match, the packet has its
source IP address rewritten with the public IP address
obtained by the <literal>0/32</literal> keyword.
<acronym>NAT</acronym> posts an entry in its internal
@@ -1942,10 +1788,10 @@ block in log first quick on dc0 all
<sect2>
<title>Enabling IP<acronym>NAT</acronym></title>
- <para>To enable IP<acronym>NAT</acronym> add these statements to
- <filename>/etc/rc.conf</filename>.</para>
+ <para>To enable IP<acronym>NAT</acronym>, add these statements
+ to <filename>/etc/rc.conf</filename>.</para>
- <para>To enable your machine to route traffic between
+ <para>To enable the machine to route traffic between
interfaces:</para>
<programlisting>gateway_enable="YES"</programlisting>
@@ -1964,39 +1810,34 @@ block in log first quick on dc0 all
<sect2>
<title><acronym>NAT</acronym> for a Large LAN</title>
- <para>For networks that have large numbers of PC's on the LAN
+ <para>For networks that have large numbers of systems 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>
+ connections, causing collisions. There are two ways to
+ relieve this resource problem.</para>
<sect3>
<title>Assigning Ports to Use</title>
- <!-- What does it mean ? Is there something missing ?-->
- <!-- XXXBLAH <- Apparently you can't start a sect
- with a <programlisting> tag ?-->
-
<para>A normal NAT rule would look like:</para>
<programlisting>map dc0 192.168.1.0/24 -> 0/32</programlisting>
- <para>In the above rule the packet's source port is unchanged
+ <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
+ 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>
- <para>Additionally we can make things even easier by using the
- <literal>auto</literal> keyword to tell
- IP<acronym>NAT</acronym> to determine by itself which ports
- are available to use:</para>
+ <para>Additionally, the <literal>auto</literal> keyword tells
+ IP<acronym>NAT</acronym> to determine which ports are
+ available for use:</para>
<programlisting>map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp auto</programlisting>
</sect3>
@@ -2009,11 +1850,11 @@ block in log first quick on dc0 all
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
+ 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>
+ single public IP address:</para>
<programlisting>map dc0 192.168.1.0/24 -> 204.134.75.1</programlisting>
@@ -2031,18 +1872,16 @@ block in log first quick on dc0 all
<sect2>
<title>Port Redirection</title>
- <para>A very common practice is to have a web server, email
- server, database server and DNS server each segregated to a
- different PC on the LAN. In this case the traffic from these
- servers still have to be <acronym>NAT</acronym>ed, but there
+ <para>A common practice is to have a web server, email server,
+ database server, and DNS server each segregated to a different
+ system on the LAN. In this case, the traffic from these
+ servers still has to undergo <acronym>NAT</acronym>, but there
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
+ correct server. For example, 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>
+ IP address of <hostid role="ipaddr">20.20.20.5</hostid>, would
+ use this rule:</para>
<programlisting>rdr dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80</programlisting>
@@ -2050,7 +1889,7 @@ block in log first quick on dc0 all
<programlisting>rdr dc0 0.0.0.0/0 port 80 -> 10.0.10.25 port 80</programlisting>
- <para>or for a LAN DNS Server on LAN address of <hostid
+ <para>For a LAN DNS server on a private address of <hostid
role="ipaddr">10.0.10.33</hostid> that needs to receive
public DNS requests:</para>
@@ -2060,33 +1899,25 @@ block in log first quick on dc0 all
<sect2>
<title>FTP and <acronym>NAT</acronym></title>
- <para>FTP is a dinosaur left over from the time before the
- Internet as it is known today, when research universities were
- leased lined together and FTP was used to share files among
- research Scientists. This was a time when data security was
- 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
+ <para>FTP has two modes: active mode and 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>
+ ordinal ftp session requester. For a 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 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 the port number
+ being used by the data channel. This eliminates the
+ security risk FTP normally exposes the firewall to as it no
+ longer needs to open large ranges of high order ports for
+ FTP connections.</para>
<para>This rule will handle all the traffic for the internal
LAN:</para>
@@ -2103,17 +1934,13 @@ block in log first quick on dc0 all
<programlisting>map dc0 10.0.10.0/29 -> 0/32</programlisting>
- <para>The FTP map rule goes before our regular map rule. All
- packets are tested against the first rule from the top.
- Matches on interface name, then private LAN source IP
- address, and then is it a FTP packet. If all that matches
- then the special FTP proxy creates temp filter rules to let
- the FTP session packets pass in and out, in addition to also
- <acronym>NAT</acronym>ing the FTP packets. All LAN packets
- that are not FTP do not match the first rule and fall
- through to the third rule and are tested, matching on
- interface and source IP, then are
- <acronym>NAT</acronym>ed.</para>
+ <para>The FTP <literal>map</literal> rules go before the
+ <acronym>NAT</acronym> rule so that when a packet matches an
+ FTP rule, the FTP proxy creates temporary filter rules to
+ let the FTP session packets pass and undergo
+ <acronym>NAT</acronym>. All LAN packets that are not FTP
+ will not match the FTP rules but will undergo
+ <acronym>NAT</acronym> if they match the third rule.</para>
</sect3>
<sect3>
@@ -2122,7 +1949,7 @@ block in log first quick on dc0 all
<para>Only one filter rule is needed for FTP if the
<acronym>NAT</acronym> FTP proxy is used.</para>
- <para>Without the FTP Proxy, the following three rules will be
+ <para>Without the FTP proxy, the following three rules will be
needed:</para>
<programlisting># Allow out LAN PC client FTP to public Internet
@@ -2147,37 +1974,23 @@ pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state</pro
<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><acronym>IPFW</acronym>) is a stateful firewall written for
+ &os; which also provides a traffic shaper, packet scheduler,
+ and in-kernel NAT.</para>
- <para>The IPFW sample ruleset (found in
- <filename>/etc/rc.firewall</filename> and
- <filename>/etc/rc.firewall6</filename>) in the standard &os;
- install is rather simple and it is not expected to be used
- directly without modifications. The example does not use
- stateful filtering, which is beneficial in most setups, so it
- will not be used as base for this section.</para>
+ <para>&os; provides a sample ruleset in
+ <filename>/etc/rc.firewall</filename>. The sample ruleset
+ define several firewall types for common scenarios to assist
+ novice users in generating an appropriate ruleset.
+ &man.ipfw.8; provides a powerful syntax which advanced users can
+ use to craft customized rulesets that meet the security
+ requirements of a given environment.</para>
- <para>The IPFW stateless rule syntax is empowered with technically
- sophisticated selection capabilities which far surpasses the
- knowledge level of the customary firewall installer. IPFW is
- targeted at the professional user or the advanced technical
- computer hobbyist who have advanced packet selection
- requirements. A high degree of detailed knowledge into how
- different protocols use and create their unique packet header
- information is necessary before the power of the IPFW rules can
- be unleashed. Providing that level of explanation is out of the
- scope of this section of the Handbook.</para>
-
- <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,
+ <para>IPFW is composed of several components: the kernel firewall
+ filter rule processor and its integrated packet accounting
+ facility, the logging facility, the
+ <literal>divert</literal> rule which triggers
+ <acronym>NAT</acronym>, 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>
@@ -2191,25 +2004,19 @@ pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state</pro
<secondary>enabling</secondary>
</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>
-
- <para>After rebooting your system with
- <literal>firewall_enable="YES"</literal> in
- <filename>rc.conf</filename> the following white highlighted
- message is displayed on the screen as part of the boot
- process:</para>
+ <para>IPFW is included in the basic &os; install as a run time
+ loadable module. The system will dynamically load the kernel
+ module when <filename>rc.conf</filename> contains the
+ statement <literal>firewall_enable="YES"</literal>. After
+ rebooting the system, the following white highlighted message
+ is displayed on the screen as part of the boot process:</para>
<screen>ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to deny, logging disabled</screen>
- <para>The loadable module does have logging ability
- compiled in. To enable logging and set the verbose logging
- limit, there is a knob that can be set in
- <filename>/etc/sysctl.conf</filename>. By adding these
- statements, logging will be enabled on future reboots:</para>
+ <para>The loadable module includes logging ability. To enable
+ logging and set the verbose logging limit, add these
+ statements to
+ <filename>/etc/sysctl.conf</filename> before rebooting:</para>
<programlisting>net.inet.ip.fw.verbose=1
net.inet.ip.fw.verbose_limit=5</programlisting>
@@ -2242,24 +2049,24 @@ net.inet.ip.fw.verbose_limit=5</programlisting>
<secondary>kernel options</secondary>
</indexterm>
- <para>It is not a mandatory requirement to enable IPFW by
- compiling the following options into the &os; kernel. It is
- presented here as background information only.</para>
+ <para>For those users who wish to statically compile kernel
+ IPFW support, the following options are available for the
+ custom kernel configuration file:</para>
<programlisting>options IPFIREWALL</programlisting>
- <para>This option enables IPFW as part of the kernel</para>
+ <para>This option enables IPFW as part of the kernel.</para>
<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>
+ <para>This option enables logging of packets that pass through
+ IPFW and have 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
+ <para>This option 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>
@@ -2272,9 +2079,9 @@ net.inet.ip.fw.verbose_limit=5</programlisting>
<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>
+ <para>This option allows 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>
<indexterm>
<primary>kernel options</primary>
@@ -2284,14 +2091,14 @@ net.inet.ip.fw.verbose_limit=5</programlisting>
<programlisting>options IPDIVERT</programlisting>
- <para>This enables the use of <acronym>NAT</acronym>
+ <para>This option enables the use of <acronym>NAT</acronym>
functionality.</para>
<note>
<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
+ option or a rule to explicitly allow these connections is
missing.</para>
</note>
</sect2>
@@ -2299,13 +2106,13 @@ net.inet.ip.fw.verbose_limit=5</programlisting>
<sect2 id="firewalls-ipfw-rc">
<title><filename>/etc/rc.conf</filename> Options</title>
- <para>Enable the firewall:</para>
+ <para>Enables the firewall:</para>
<programlisting>firewall_enable="YES"</programlisting>
<para>To select one of the default firewall types provided by
&os;, select one by reading
- <filename>/etc/rc.firewall</filename> and place it in
+ <filename>/etc/rc.firewall</filename> and specify it in
the following:</para>
<programlisting>firewall_type="open"</programlisting>
@@ -2314,52 +2121,44 @@ net.inet.ip.fw.verbose_limit=5</programlisting>
<itemizedlist>
<listitem>
- <para><literal>open</literal> — pass all
- traffic.</para>
+ <para><literal>open</literal>: passes all traffic.</para>
</listitem>
<listitem>
- <para><literal>client</literal> — will protect only
- this machine.</para>
+ <para><literal>client</literal>: protects only this
+ machine.</para>
</listitem>
<listitem>
- <para><literal>simple</literal> — protect the whole
+ <para><literal>simple</literal>: protects 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
+ <para><filename><replaceable>filename</replaceable></filename>:
+ absolute path of the file containing the 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 blocksall incoming and outgoing
- traffic:</para>
+ <para>Two methods are available for loading custom
+ <application>ipfw</application> rules. One is to set the
+ <literal>firewall_type</literal> variable to the absolute
+ path of the file which contains the firewall rules.</para>
- <programlisting>add deny in add deny out</programlisting>
+ <para>The other method is to set the
+ <literal>firewall_script</literal> variable to the absolute
+ path of an executable script that includes
+ <command>ipfw</command> commands. A ruleset script that
+ blocks all incoming and outgoing traffic would look like
+ this:</para>
- <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>
-
- <programlisting>#!/bin/sh
+ <programlisting>#!/bin/sh
ipfw -q flush
@@ -2368,12 +2167,12 @@ ipfw add deny out</programlisting>
<note>
<para>If <literal>firewall_type</literal> is set to either
- <literal>client</literal> or <literal>simple</literal>, the
- default rules found in <filename>/etc/rc.firewall</filename>
- should be reviewed to fit to the configuration of the given
- machine. Also note that the examples used in this chapter
- expect that the <literal>firewall_script</literal> is set to
- <filename>/etc/ipfw.rules</filename>.</para>
+ <literal>client</literal> or <literal>simple</literal>,
+ modify the default rules found in
+ <filename>/etc/rc.firewall</filename> to fit the
+ configuration of the system. The examples used in this
+ section assume that the <literal>firewall_script</literal>
+ is set to <filename>/etc/ipfw.rules</filename>.</para>
</note>
<para>Enable logging:</para>
@@ -2381,21 +2180,21 @@ ipfw add deny out</programlisting>
<programlisting>firewall_logging="YES"</programlisting>
<warning>
- <para>The only thing that the
- <varname>firewall_logging</varname> variable will do is
- 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
+ <para><varname>firewall_logging</varname> sets the
+ <varname>net.inet.ip.fw.verbose</varname> sysctl
+ variable to the value of <literal>1</literal>. There is no
<filename>rc.conf</filename> variable to set log
- limitations, but it can be set via sysctl variable, manually
- or from <filename>/etc/sysctl.conf</filename>:</para>
+ limitations, but the desired value can be set using
+ <command>sysctl</command> or by adding the following
+ variable and desired value to
+ <filename>/etc/sysctl.conf</filename>:</para>
<programlisting>net.inet.ip.fw.verbose_limit=5</programlisting>
</warning>
- <para>If your machine is acting as a gateway, i.e., providing
- Network Address Translation (NAT) via &man.natd.8;, please
- refer to <xref linkend="network-natd"/> for information
+ <para>If the machine is acting as a gateway providing
+ <acronym>NAT</acronym> using &man.natd.8;,
+ refer to <link linkend="network-natd"></link> for information
regarding the required <filename>/etc/rc.conf</filename>
options.</para>
</sect2>
@@ -2405,56 +2204,54 @@ ipfw add deny out</programlisting>
<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><command>ipfw</command> can be used to make manual,
+ single rule additions or deletions to the active firewall
+ while it is running. The problem with using this method is
+ that all the changes are lost when the system reboots. It is
+ recommended to instead write all the rules in a file and to
+ use that file to load the rules at boot time and to replace
+ the currently running firewall rules whenever that file
+ changes.</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><command>ipfw</command> is a 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 way to determine if the rule is
+ functioning as expected.</para>
- <para>To list all the rules in sequence:</para>
+ <para>To list all the running rules in sequence:</para>
<screen>&prompt.root; <userinput>ipfw list</userinput></screen>
- <para>To list all the rules with a time stamp of when the last
- time the rule was matched:</para>
+ <para>To list all the running rules with a time stamp of when
+ the last time the rule was matched:</para>
<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 and 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, followed by the rule
+ itself.</para>
<screen>&prompt.root; <userinput>ipfw -a list</userinput></screen>
- <para>List the dynamic rules in addition to the static
- rules:</para>
+ <para>To list dynamic rules in addition to static rules:</para>
<screen>&prompt.root; <userinput>ipfw -d list</userinput></screen>
- <para>Also show the expired dynamic rules:</para>
+ <para>To also show the expired dynamic rules:</para>
<screen>&prompt.root; <userinput>ipfw -d -e list</userinput></screen>
- <para>Zero the counters:</para>
+ <para>To zero the counters:</para>
<screen>&prompt.root; <userinput>ipfw zero</userinput></screen>
- <para>Zero the counters for just the rule with number
+ <para>To zero the counters for just the rule with number
<replaceable>NUM</replaceable>:</para>
<screen>&prompt.root; <userinput>ipfw zero <replaceable>NUM</replaceable></userinput></screen>
@@ -2463,59 +2260,38 @@ ipfw add deny out</programlisting>
<sect2 id="firewalls-ipfw-rules">
<title>IPFW Rulesets</title>
- <!-- This has already appeared once -->
-
- <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.
- 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>
-
<indexterm>
<primary>IPFW</primary>
<secondary>rule processing order</secondary>
</indexterm>
- <!-- 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
+ <para>When a packet enters the <acronym>IPFW</acronym> 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 rule's
+ action field value is executed and the search of the ruleset
+ terminates for that packet. This is referred to as
+ <quote>first match wins</quote>. 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>
+ rule, number 65535, which denies all packets and silently
+ discards them. However, if the packet matches a rule that
+ contains the <literal>count</literal>,
+ <literal>skipto</literal>, or <literal>tee</literal> keywords,
+ the search continues. Refer to &man.ipfw.8; for details on
+ how these keywords affect rule processing.</para>
- <note>
- <para>The search continues after <literal>count</literal>,
- <literal>skipto</literal> and <literal>tee</literal>
- rules.</para>
- </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>
+ <para>The examples in this section create an inclusive type
+ firewall ruleset containing the stateful <literal>keep
+ state</literal>, <literal>limit</literal>,
+ <literal>in</literal>, <literal>out</literal> and
+ <literal>via</literal> options. For a complete rule syntax
+ description, refer to &man.ipfw.8;.</para>
<warning>
<para>Be careful when working with firewall rules, as it is
- easy to end up locking yourself out.</para>
+ easy to lock out even the administrator.</para>
</warning>
<sect3 id="firewalls-ipfw-rules-syntax">
@@ -2527,20 +2303,11 @@ ipfw add deny out</programlisting>
<secondary>rule syntax</secondary>
</indexterm>
- <para>The rule syntax presented here has been simplified to
- what is necessary to create a standard inclusive type
- firewall ruleset. For a complete rule syntax description
- 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>
-
- <para><literal>#</literal> is used to mark the start of a
- comment and may appear at the end of a rule line or on its
- own lines. Blank lines are ignored.</para>
+ <para>This section describes the keywords which comprise an
+ <acronym>IPFW</acronym> rule. Keywords must be written in
+ the following order. <literal>#</literal> is used to mark
+ the start of a comment and may appear at the end of a rule
+ line or on its own line. Blank lines are ignored.</para>
<para><replaceable>CMD RULE_NUMBER ACTION LOGGING SELECTION
STATEFUL</replaceable></para>
@@ -2549,44 +2316,47 @@ ipfw add deny out</programlisting>
<title>CMD</title>
<para>Each new rule has to be prefixed with
- <parameter>add</parameter> to add the
- rule to the internal table.</para>
+ <parameter>add</parameter> to add the rule to the internal
+ table.</para>
</sect4>
<sect4>
<title>RULE_NUMBER</title>
<para>Each rule is associated with a rule_number in the
- range 1..65535.</para>
+ range of <literal>1</literal> to
+ <literal>65535</literal>.</para>
</sect4>
<sect4>
<title>ACTION</title>
<para>A rule can be associated with one of the following
- actions, which will be executed when the packet matches
- the selection criterion of the rule.</para>
+ actions. The specified action will be executed when the
+ packet matches the selection criterion of the rule.</para>
<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 keywords are equivalent as they 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>
+ move to the next rule. A <literal>check-state</literal>
+ rule does not have selection criterion. If no
+ <literal>check-state</literal> rule is present in the
+ ruleset, the dynamic rules table is checked at the first
+ <literal>keep-state</literal> or <literal>limit</literal>
+ rule.</para>
<para><parameter>deny | drop</parameter></para>
- <para>Both words mean the same thing which is to discard
+ <para>Both words mean the same thing, which is to discard
packets that match this rule. The search
terminates.</para>
</sect4>
@@ -2594,30 +2364,25 @@ ipfw add deny out</programlisting>
<sect4>
<title>Logging</title>
- <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
+ to &man.syslogd.8; with a facility name of
+ <literal>SECURITY</literal>. Logging only occurs if the
+ number of packets logged 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
+ taken from the <command>sysctl</command> value of
+ <varname>net.inet.ip.fw.verbose_limit</varname>. 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, use <command>ipfw reset log</command>.</para>
+ that rule, using <command>ipfw reset log</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>
+ <para>Logging is done after all other packet matching
+ conditions have been met, and before performing the
+ final action on the packet. The administrator decides
+ which rules to enable logging on.</para>
</note>
</sect4>
@@ -2633,10 +2398,9 @@ ipfw add deny out</programlisting>
<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> can be used. The
+ value specified is the protocol to be matched against.
+ This is a mandatory keyword.</para>
<para><parameter>from src to dst</parameter></para>
@@ -2646,52 +2410,46 @@ ipfw add deny out</programlisting>
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>
+ any IP address configured on an interface in the &os;
+ system to represent the PC the firewall is running on.
+ Example usage includes <literal>from me to any</literal>,
+ <literal>from any to me</literal>, <literal>from 0.0.0.0/0
+ to any</literal>, <literal>from any to
+ 0.0.0.0/0</literal>, <literal>from 0.0.0.0 to
+ any</literal>. <literal>from any to 0.0.0.0</literal>,
+ and <literal>from me to 0.0.0.0</literal>. IP addresses
+ are specified in dotted IP address format followed by the
+ mask in CIDR notation, or as a single host in dotted IP
+ address format. This keyword is a mandatory requirement.
+ The <filename role="package">net-mgmt/ipcalc</filename>
+ port may be used to assist the mask calculation.</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
+ <para>For protocols which support port numbers, such as
+ <acronym>TCP</acronym> and <acronym>UDP</acronym>, it
+ is mandatory to include 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
- one or the other is coded as part of your rule matching
- criterion.</para>
+ <para>Matches incoming or outgoing packets. It is mandatory
+ that one or the other is included as part of the rule
+ matching criterion.</para>
<para><parameter>via IF</parameter></para>
<para>Matches packets going through the interface specified
- by exact name. The <literal>via</literal> keyword causes
+ by device name. The <literal>via</literal> keyword causes
the interface to always be checked as part of the match
process.</para>
<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 mandatory keyword identifies the session start
+ request for <acronym>TCP</acronym> packets.</para>
<para><parameter>keep-state</parameter></para>
@@ -2707,12 +2465,9 @@ ipfw add deny out</programlisting>
<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>
+ specified. <literal>limit</literal> and
+ <literal>keep-state</literal> can not be used on the same
+ rule as they provide the same stateful function.</para>
</sect4>
</sect3>
@@ -2725,39 +2480,26 @@ ipfw add deny out</programlisting>
<secondary>stateful filtering</secondary>
</indexterm>
- <!-- XXX: duplicated -->
-
- <para>Stateful filtering treats traffic as a bi-directional
- exchange of packets comprising a session conversation. It
- has the matching capabilities to determine if the session
- conversation between the originating sender and the
- destination are following the valid procedure of
- bi-directional packet exchange. Any packets that do not
- properly fit the session conversation template are
- automatically rejected as impostors.</para>
-
<para>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
+ identify where in the IPFW ruleset 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>
+ being exchanged during this session. 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
- packet is discarded.</para>
+ number of dynamic rules. To counter this type of attack
+ with <acronym>IPFW</acronym>, use <literal>limit</literal>.
+ This keyword limits the number of simultaneous sessions by
+ checking that rule's source or destinations fields and using
+ the packet's IP address 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 than the
+ value specified by <literal>limit</literal>, the packet is
+ discarded.</para>
</sect3>
<sect3>
@@ -2769,47 +2511,36 @@ ipfw add deny out</programlisting>
<secondary>logging</secondary>
</indexterm>
- <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>
-
<para>Even with the logging facility enabled, IPFW will not
generate any rule logging on its 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
+ administrator decides which rules in the ruleset will be
+ logged, and adds the <literal>log</literal> keyword to those
+ rules. Normally only deny rules are logged. It is
+ customary to duplicate the <quote>ipfw default deny
+ everything</quote> rule with the <literal>log</literal>
+ keyword included as the 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
- displayed on the root console screen and soon become very
- annoying.</para>
+ <para>Logging is a two edged sword. If one is not careful,
+ an over abundance of log data or a DoS attack can fill the
+ disk with log files. Log messages are not only written to
+ <application>syslogd</application>, but also are displayed
+ on the root console screen and soon become 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,
+ sent to &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 identical log messages. With this option
+ set to five,
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>
+ would be logged to <application>syslogd</application> and
+ 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>
@@ -2826,20 +2557,19 @@ ipfw add deny out</programlisting>
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
+ 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>
+ symbolic substitution can be used for frequently used
+ values to be substituted into multiple rules.</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>This example script is compatible with the syntax used
+ by the &man.sh.1;, &man.csh.1;, and &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>
+ <para>Start the rules file like this:</para>
<programlisting>############### start of example ipfw rules script #############
#
@@ -2857,23 +2587,21 @@ ks="keep-state" # just too lazy to key this each time
$cmd 00611 allow udp from any to $odns 53 out via $oif $ks
################### End of example ipfw rules script ############</programlisting>
- <para>That is all there is to it. The rules are not important
- in this example, how the symbolic substitution field are
- populated and used are.</para>
+ <para>The rules are not important as the focus of this example
+ is how the symbolic substitution fields are
+ populated.</para>
<para>If the above example was in
- <filename>/etc/ipfw.rules</filename>, the rules could
- be reloaded by entering the following on the command
- line.</para>
+ <filename>/etc/ipfw.rules</filename>, the rules could be
+ reloaded by the following command:</para>
<screen>&prompt.root; <userinput>sh /etc/ipfw.rules</userinput></screen>
- <para>The <filename>/etc/ipfw.rules</filename> file could be
- located anywhere you want and the file could be named any
- thing you would like.</para>
+ <para><filename>/etc/ipfw.rules</filename> can be located
+ anywhere and the file can have any name.</para>
- <para>The same thing could also be accomplished by running
- these commands by hand:</para>
+ <para>The same thing could be accomplished by running these
+ commands by hand:</para>
<screen>&prompt.root; <userinput>ipfw -q -f flush</userinput>
&prompt.root; <userinput>ipfw -q add check-state</userinput>
@@ -2885,100 +2613,16 @@ ks="keep-state" # just too lazy to key this each time
</sect3>
<sect3>
- <title>Stateful Ruleset</title>
+ <title>An Example Stateful Ruleset</title>
- <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
- 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>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
- have rules coded to allow free unmolested movement of
- packets originating from those LAN interfaces.</para>
-
- <para>The rules should be first organized into three major
- sections, all the free unmolested interfaces, public
- interface outbound, and the public interface inbound.</para>
-
- <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>
-
- <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>
-
- <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>
-
- <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
- 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
+ <para>The following sample ruleset is a complete inclusive
+ type ruleset. 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>
+ <literal>deny</literal> rule in the inbound section.
+ Change the <devicename>dc0</devicename> in every rule to the
+ device name of the interface that connects the system to the
+ Internet.</para>
<para>There is a noticeable pattern in the usage of these
rules.</para>
@@ -2986,14 +2630,14 @@ ks="keep-state" # just too lazy to key this each time
<itemizedlist>
<listitem>
<para>All statements that are a request to start a session
- to the public Internet use
+ to the 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>
+ the Internet use <literal>limit</literal> to prevent
+ flooding.</para>
</listitem>
<listitem>
@@ -3009,7 +2653,7 @@ ks="keep-state" # just too lazy to key this each time
</itemizedlist>
<para>The following rules go into
- <filename>/etc/ipfw.rules</filename>.</para>
+ <filename>/etc/ipfw.rules</filename>:</para>
<programlisting>################ Start of IPFW rules file ###############################
# Flush out the list before we begin.
@@ -3173,109 +2817,97 @@ pif="dc0" # public interface name of NIC
<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. For a customized kernel, the kernel
+ configuration file needs
+ <literal>option IPDIVERT</literal> added to the other
+ <literal>IPFIREWALL</literal> options.</para>
<para>In addition to the normal IPFW options in
<filename>/etc/rc.conf</filename>, the following are
- needed.</para>
+ needed:</para>
<programlisting>natd_enable="YES" # Enable <acronym>NAT</acronym>D function
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
+ <para>Utilizing stateful rules with a
+ <literal>divert natd</literal> rule complicates the ruleset
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>
+ <literal>divert natd</literal> rules in the ruleset is
+ critical and a new action type is used, called
+ <literal>skipto</literal>. When using
+ <literal>skipto</literal>, it is mandatory that each rule is
+ numbered, so that the <literal>skipto</literal> rule knows
+ which rule to jump to.</para>
- <para>The following is an uncommented example of one coding
- method, selected here to explain the sequence of the packet
- flow through the rulesets.</para>
+ <para>The following is an uncommented example of a ruleset
+ which explains the sequence of the packet flow.</para>
<para>The processing flow starts with the first rule from the
- top of the rule file and progress one rule at a time deeper
- into the file until the end is 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
- translation.</para>
+ top of the ruleset and progresses one rule at a time until
+ the end is reached or the packet matches and the packet is
+ released out of the firewall. Take note of the location of
+ rule numbers 100 101, 450, 500, and 510. These rules
+ control the translation of the outbound and inbound packets
+ so that their entries in the dynamic keep-state table always
+ register the private LAN IP address. All the allow and deny
+ rules specify the direction of the packet and the interface.
+ All start outbound session requests will
+ <literal>skipto rule 500</literal> to undergo NAT.</para>
- <para>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
- its 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,
+ <para>Consider a web browser which initializes a new HTTP
+ session over port 80. When the first outbound 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, and it has not been posted to the
+ dynamic keep-state table yet. The packet finally matches
+ rule 125 as it is outbound through the NIC facing the
+ Internet and has a source IP address as a private LAN IP
+ address. On matching this rule, two actions take place.
+ <literal>keep-state</literal> adds this rule to the dynamic
+ keep-state rules table and the specified action is executed
+ and posted as part of the info in the dynamic table. In
+ this case, the action is <literal>skipto rule 500</literal>.
+ Rule 500 <acronym>NAT</acronym>s the packet IP address and
+ sends it out to the Internet. This packet makes its way to
+ the destination web server, where a response packet is
+ generated and sent back. This new packet enters the top of
+ the ruleset. It matches rule 100 and has it destination IP
+ address mapped back to the corresponding LAN IP address. It
+ then is processed by the <literal>check-state</literal>
+ rule, is found in the table as an existing session, and is
+ released to the LAN. It goes to the LAN system that sent it
+ and a new packet is sent requesting another segment of the
+ data from the remote server. This time it matches the
+ <literal>check-state</literal> rule, its outbound entry is
+ found, and the associated action,
<literal>skipto 500</literal>, is executed. The packet
- jumps to rule 500 gets <acronym>NAT</acronym>ed and released
- on its way out.</para>
+ jumps to rule 500, gets <acronym>NAT</acronym>ed, and is
+ released to the Internet.</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. 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 anexisting session conversation. It is then
- sent to rule 500 for <acronym>NAT</acronym>ing and released
- to the outbound interface.</para>
+ of an existing session is automatically handled by the
+ <literal>check-state</literal> rule and the properly placed
+ <literal>divert natd</literal> rules. The ruleset only has
+ to deny bad packets and allow only authorized services.
+ Consider a web server running on the firewall where web
+ requests from the Internet should have access to the local
+ web site. An inbound start request packet will match rule
+ 100 and its IP address will be mapped to the LAN IP address
+ of the firewall. The packet is then matched against all the
+ nasty things that need to be checked and finally matches
+ rule 425 where two actions occur. The packet rule is posted
+ to the dynamic keep-state table but this time, any new
+ session requests originating from that source IP address are
+ limited to 2. This defends against DoS attacks against the
+ 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. It is then sent to rule 500 for
+ <acronym>NAT</acronym>ing and released to the outbound
+ interface.</para>
<para>Example Ruleset #1:</para>
@@ -3326,10 +2958,9 @@ ipfw -q -f flush
######################## end of rules ##################</programlisting>
- <para>The following is pretty much the same as above, but uses
- a self documenting coding style full of description comments
- to help the inexperienced IPFW rule writer to better
- understand what the rules are doing.</para>
+ <para>The next example is functionally equivalent, but uses
+ descriptive comments to help the inexperienced IPFW rule
+ writer to better understand what the rules are doing.</para>
<para>Example Ruleset #2:</para>