svn commit: r44083 - head/en_US.ISO8859-1/books/handbook/firewalls
Dru Lavigne
dru at FreeBSD.org
Wed Feb 26 23:44:34 UTC 2014
Author: dru
Date: Wed Feb 26 23:44:33 2014
New Revision: 44083
URL: http://svnweb.freebsd.org/changeset/doc/44083
Log:
White space fix only. Translators can ignore.
Sponsored by: iXsystems
Modified:
head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 26 23:14:36 2014 (r44082)
+++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 26 23:44:33 2014 (r44083)
@@ -1708,40 +1708,39 @@ options IPDIVERT # enables NAT</pro
</itemizedlist>
<para>If <literal>firewall_type</literal> is set to either
- <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.</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.</para>
- <para>Note that the
- <literal>filename</literal> type is used to load a custom ruleset.</para>
+ <para>Note that the <literal>filename</literal> type is used to
+ load a custom ruleset.</para>
<para>An alternate way to load a custom ruleset is to set the
<literal>firewall_script</literal> variable to the absolute
- path of an <emphasis>executable script</emphasis> that includes
- <application>IPFW</application> commands. The examples used in this
- section assume that the <literal>firewall_script</literal>
- is set to <filename>/etc/ipfw.rules</filename>:</para>
+ path of an <emphasis>executable script</emphasis> that
+ includes <application>IPFW</application> commands. The
+ examples used in this section assume that the
+ <literal>firewall_script</literal> is set to
+ <filename>/etc/ipfw.rules</filename>:</para>
- <programlisting>firewall_script="/etc/ipfw.rules"</programlisting>
+ <programlisting>firewall_script="/etc/ipfw.rules"</programlisting>
<para>To enable logging, include this line:</para>
<programlisting>firewall_logging="YES"</programlisting>
- <para>There is no
- <filename>/etc/rc.conf</filename> variable to set logging
- limits. To limit the number of times a rule is logged
- per connection attempt, specify the number using this line
- in
- <filename>/etc/sysctl.conf</filename>:</para>
+ <para>There is no <filename>/etc/rc.conf</filename> variable to
+ set logging limits. To limit the number of times a rule is
+ logged per connection attempt, specify the number using this
+ line in <filename>/etc/sysctl.conf</filename>:</para>
<programlisting>net.inet.ip.fw.verbose_limit=<replaceable>5</replaceable></programlisting>
-
+
<para>After saving the needed edits, start the firewall. To
enable logging limits now, also set the
<command>sysctl</command> value specified above:</para>
-
+
<screen>&prompt.root; <userinput>service ipfw start</userinput>
&prompt.root; <userinput>sysctl net.inet.ip.fw.verbose_limit=<replaceable>5</replaceable></userinput></screen>
</sect2>
@@ -1755,13 +1754,12 @@ options IPDIVERT # enables NAT</pro
<secondary>rule processing order</secondary>
</indexterm>
- <para>When a packet enters the <application>IPFW</application> firewall,
- it is compared against the first rule in the ruleset and
- progresses one rule at a time, moving from top to bottom in
- sequence. When the
- packet matches the selection parameters of a rule, the rule's
- action is executed and the search of the ruleset
- terminates for that packet. This is referred to as
+ <para>When a packet enters the <application>IPFW</application>
+ firewall, it is compared against the first rule in the ruleset
+ and progresses one rule at a time, moving from top to bottom
+ in sequence. When the packet matches the selection parameters
+ of a rule, the rule's action 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
<application>IPFW</application> default rule number 65535,
@@ -1781,19 +1779,20 @@ options IPDIVERT # enables NAT</pro
<para>When creating an
<application>IPFW</application> rule, keywords must be
written in the following order. Some keywords are mandatory
- while other keywords are optional. The words shown in uppercase
- represent a variable and the words shown in lowercase must
- precede the variable that follows it. The <literal>#</literal> symbol is used
- to mark the start of a comment and may appear at the end of a
- rule or on its own line. Blank lines are ignored.</para>
+ while other keywords are optional. The words shown in
+ uppercase represent a variable and the words shown in
+ lowercase must precede the variable that follows it. The
+ <literal>#</literal> symbol is used to mark the start of a
+ comment and may appear at the end of a rule or on its own
+ line. Blank lines are ignored.</para>
<para><replaceable>CMD RULE_NUMBER set SET_NUMBER ACTION log
- LOG_AMOUNT PROTO from SRC SRC_PORT to DST DST_PORT
+ LOG_AMOUNT PROTO from SRC SRC_PORT to DST DST_PORT
OPTIONS</replaceable></para>
<para>This section provides an overview of these keywords and
- their options. It is not an exhaustive list of every possible
- option. Refer to &man.ipfw.8; for a complete description of
+ their options. It is not an exhaustive list of every possible
+ option. Refer to &man.ipfw.8; for a complete description of
the rule syntax that can be used when creating
<application>IPFW</application> rules.</para>
@@ -1812,9 +1811,10 @@ options IPDIVERT # enables NAT</pro
<para>Each rule is associated with a number in the
range of <literal>1</literal> to
<literal>65534</literal>. The number is used to
- indicate the order of rule processing. Multiple rules can have the same
- number, in which case they are checked according to
- the order in which they have been added.</para>
+ indicate the order of rule processing. Multiple rules
+ can have the same number, in which case they are checked
+ according to the order in which they have been
+ added.</para>
</listitem>
</varlistentry>
@@ -1822,13 +1822,12 @@ options IPDIVERT # enables NAT</pro
<term>SET_NUMBER</term>
<listitem>
<para>Each rule is associated with a set number in the
- range of <literal>0</literal> to
- <literal>31</literal>. Sets can be individually
- disabled or enabled, making it possible to quickly add
- or delete a set of rules. If a SET_NUMBER is not
- specified, the rule will be added to set <literal>0</literal>.</para>
-
- </listitem>
+ range of <literal>0</literal> to <literal>31</literal>.
+ Sets can be individually disabled or enabled, making it
+ possible to quickly add or delete a set of rules. If a
+ SET_NUMBER is not specified, the rule will be added to
+ set <literal>0</literal>.</para>
+ </listitem>
</varlistentry>
<varlistentry>
@@ -1840,14 +1839,15 @@ options IPDIVERT # enables NAT</pro
rule.</para>
<para><parameter>allow | accept | pass |
- permit</parameter>: these keywords are equivalent and allow packets
- that match the rule.</para>
+ permit</parameter>: these keywords are equivalent and
+ allow packets that match the rule.</para>
- <para><parameter>check-state</parameter>: checks the packet against the dynamic state table.
- If a match is found, execute the action associated with
- the rule which generated this dynamic rule, otherwise
- move to the next rule. A <literal>check-state</literal>
- rule does not have selection criterion. If no
+ <para><parameter>check-state</parameter>: checks the
+ packet against the dynamic state table. If a match is
+ found, execute the action associated with the rule which
+ generated this dynamic rule, otherwise 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
@@ -1857,9 +1857,9 @@ options IPDIVERT # enables NAT</pro
all packets that match rule. The search continues with
the next rule.</para>
- <para><parameter>deny | drop</parameter>: either word discards
- packets that match this rule.</para>
-
+ <para><parameter>deny | drop</parameter>: either word
+ discards packets that match this rule.</para>
+
<para>Additional actions are available. Refer to
&man.ipfw.8; for details.</para>
</listitem>
@@ -1873,15 +1873,14 @@ options IPDIVERT # enables NAT</pro
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 optional specified LOG_AMOUNT.
- If no LOG_AMOUNT is specified, the
- limit is taken from the value
- of <varname>net.inet.ip.fw.verbose_limit</varname>. 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, using <command>ipfw reset
- log</command>.</para>
+ not exceed the optional specified LOG_AMOUNT. If no
+ LOG_AMOUNT is specified, the limit is taken from the
+ value of
+ <varname>net.inet.ip.fw.verbose_limit</varname>. 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,
+ using <command>ipfw reset log</command>.</para>
<note>
<para>Logging is done after all other packet matching
@@ -1898,25 +1897,25 @@ options IPDIVERT # enables NAT</pro
<para>This optional value can be used to specify any
protocol name or number found in
<filename>/etc/protocols</filename>.</para>
- </listitem>
- </varlistentry>
+ </listitem>
+ </varlistentry>
<varlistentry>
<term>SRC</term>
<listitem>
- <para>The <literal>from</literal>
- keyword must be followed by the source address or a
- keyword that represents the source address. An address
- can be represented by the <literal>any</literal>,
- <literal>me</literal> (any address configured on an
- interface on this system),
+ <para>The <literal>from</literal> keyword must be followed
+ by the source address or a keyword that represents the
+ source address. An address can be represented by the
+ <literal>any</literal>, <literal>me</literal> (any
+ address configured on an interface on this system),
<literal>me6</literal>, (any <acronym>IPv6</acronym>
address configured on an interface on this system), or
<literal>table</literal> followed by the number of a
lookup table which contains a list of addresses. When
specifying an <acronym>IP</acronym> address, it can be
optionally followed by its <acronym>CIDR</acronym> mask
- or subnet mask. For example, <literal>1.2.3.4/25</literal> or
+ or subnet mask. For example,
+ <literal>1.2.3.4/25</literal> or
<literal>1.2.3.4:255.255.255.128</literal>.</para>
</listitem>
</varlistentry>
@@ -1934,10 +1933,10 @@ options IPDIVERT # enables NAT</pro
<term>DST</term>
<listitem>
<para>The <literal>to</literal> keyword must be followed
- by the destination address or a
- keyword that represents the destination address. The
- same keywords and addresses described in the SRC section
- can be used to describe the destination.</para>
+ by the destination address or a keyword that represents
+ the destination address. The same keywords and
+ addresses described in the SRC section can be used to
+ describe the destination.</para>
</listitem>
</varlistentry>
@@ -1956,28 +1955,29 @@ options IPDIVERT # enables NAT</pro
<para>Several keywords can follow the source and
destination. As the name suggests, OPTIONS are
optional. Commonly used options include
- <literal>in</literal> or
- <literal>out</literal>, which specify the direction of
- packet flow, <literal>icmptypes</literal> followed by
- the type of <acronym>ICMP</acronym> message, and
+ <literal>in</literal> or <literal>out</literal>, which
+ specify the direction of packet flow,
+ <literal>icmptypes</literal> followed by the type of
+ <acronym>ICMP</acronym> message, and
<literal>keep-state</literal>.</para>
- <para>When a <parameter>keep-state</parameter> rule is matched, the
- firewall will create a dynamic rule which
- matches bidirectional traffic between the
- source and destination addresses and ports using the same
+ <para>When a <parameter>keep-state</parameter> rule is
+ matched, the firewall will create a dynamic rule which
+ matches bidirectional traffic between the source and
+ destination addresses and ports using the same
protocol.</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 type of
attack with <application>IPFW</application>, use
- <literal>limit</literal>. This option limits the
- number of simultaneous sessions by checking the open dynamic rules, counting
- the number of times this rule and <acronym>IP</acronym> address
- combination occurred. If this count is greater than the
- value specified by <literal>limit</literal>, the packet
- is discarded.</para>
+ <literal>limit</literal>. This option limits the number
+ of simultaneous sessions by checking the open dynamic
+ rules, counting the number of times this rule and
+ <acronym>IP</acronym> address combination occurred. If
+ this count is greater than the value specified by
+ <literal>limit</literal>, the packet is
+ discarded.</para>
<para>Dozens of OPTIONS are available. Refer to
&man.ipfw.8; for a description of each available
@@ -1988,38 +1988,38 @@ options IPDIVERT # enables NAT</pro
</sect2>
<sect2>
- <title>Example Ruleset</title>
+ <title>Example Ruleset</title>
- <para>This section demonstrates how to create an example
- stateful firewall ruleset script named
- <filename>/etc/ipfw.rules</filename>. In this example, all
- connection rules use <literal>in</literal> or
- <literal>out</literal> to clarify the direction. They also
- use <literal>via</literal>
- <replaceable>interface-name</replaceable> to specify
- the interface the packet is traveling over.</para>
-
- <note>
- <para>When first creating or testing a firewall ruleset,
- consider temporarily setting this tunable:</para>
-
- <programlisting>net.inet.ip.fw.default_to_accept="1"</programlisting>
-
- <para>This sets the default policy of &man.ipfw.8; to
- be more permissive than the default <literal>deny ip from
- any to any</literal>, making it slightly more difficult
- to get locked out of the system right after a reboot.</para>
+ <para>This section demonstrates how to create an example
+ stateful firewall ruleset script named
+ <filename>/etc/ipfw.rules</filename>. In this example, all
+ connection rules use <literal>in</literal> or
+ <literal>out</literal> to clarify the direction. They also
+ use <literal>via</literal>
+ <replaceable>interface-name</replaceable> to specify
+ the interface the packet is traveling over.</para>
+
+ <note>
+ <para>When first creating or testing a firewall ruleset,
+ consider temporarily setting this tunable:</para>
+
+ <programlisting>net.inet.ip.fw.default_to_accept="1"</programlisting>
+
+ <para>This sets the default policy of &man.ipfw.8; to be more
+ permissive than the default <literal>deny ip from any to
+ any</literal>, making it slightly more difficult to get
+ locked out of the system right after a reboot.</para>
</note>
- <para>The firewall script begins by indicating that it is a
- Bourne shell script and flushes any existing rules. It then
- creates the <literal>cmd</literal> variable so that
- <literal>ipfw add</literal> does not have to be typed at the
- beginning of every rule. It also defines the
- <literal>pif</literal> variable which represents the name of
- the interface that is attached to the Internet.</para>
+ <para>The firewall script begins by indicating that it is a
+ Bourne shell script and flushes any existing rules. It then
+ creates the <literal>cmd</literal> variable so that
+ <literal>ipfw add</literal> does not have to be typed at the
+ beginning of every rule. It also defines the
+ <literal>pif</literal> variable which represents the name of
+ the interface that is attached to the Internet.</para>
- <programlisting>#!/bin/sh
+ <programlisting>#!/bin/sh
# Flush out the list before we begin.
ipfw -q -f flush
@@ -2027,24 +2027,24 @@ ipfw -q -f flush
cmd="ipfw -q add"
pif="dc0" # interface name of NIC attached to Internet</programlisting>
- <para>The first two rules allow all traffic on the trusted
- internal interface and on the loopback interface:</para>
+ <para>The first two rules allow all traffic on the trusted
+ internal interface and on the loopback interface:</para>
- <programlisting># Change xl0 to LAN NIC interface name
+ <programlisting># Change xl0 to LAN NIC interface name
$cmd 00005 allow all from any to any via xl0
# No restrictions on Loopback Interface
$cmd 00010 allow all from any to any via lo0</programlisting>
- <para>The next rule allows the packet through if it matches
- an existing entry in the dynamic rules table:</para>
+ <para>The next rule allows the packet through if it matches an
+ existing entry in the dynamic rules table:</para>
- <programlisting>$cmd 00015 check-state</programlisting>
+ <programlisting>$cmd 00015 check-state</programlisting>
- <para>The next set of rules defines which stateful connections
- internal systems can create to hosts on the Internet:</para>
+ <para>The next set of rules defines which stateful connections
+ internal systems can create to hosts on the Internet:</para>
- <programlisting># Allow access to public DNS
+ <programlisting># Allow access to public DNS
# Replace x.x.x.x with the IP address of a public DNS server
# and repeat for each DNS server in /etc/resolv.conf
$cmd 00110 allow tcp from any to x.x.x.x 53 out via $pif setup keep-state
@@ -2076,14 +2076,14 @@ pif="dc0" # interface name of NIC at
# deny and log all other outbound connections
$cmd 00299 deny log all from any to any out via $pif</programlisting>
- <para>The next set of rules controls connections from
- Internet hosts to the internal network. It starts by
- denying packets typically associated with attacks and then
- explicitly allows specific types of connections. All the
- authorized services that originate from the Internet use
- <literal>limit</literal> to prevent flooding.</para>
+ <para>The next set of rules controls connections from Internet
+ hosts to the internal network. It starts by denying packets
+ typically associated with attacks and then explicitly allows
+ specific types of connections. All the authorized services
+ that originate from the Internet use <literal>limit</literal>
+ to prevent flooding.</para>
- <programlisting># Deny all inbound traffic from non-routable reserved address spaces
+ <programlisting># Deny all inbound traffic from non-routable reserved address spaces
$cmd 00300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP
$cmd 00301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918 private IP
$cmd 00302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918 private IP
@@ -2125,50 +2125,49 @@ pif="dc0" # interface name of NIC at
# Reject and log all other incoming connections
$cmd 00499 deny log all from any to any in via $pif</programlisting>
- <para>The last rule logs all packets that do not match any of
- the rules in the
- ruleset:</para>
+ <para>The last rule logs all packets that do not match any of
+ the rules in the ruleset:</para>
- <programlisting># Everything else is denied and logged
+ <programlisting># Everything else is denied and logged
$cmd 00999 deny log all from any to any</programlisting>
- </sect2>
+ </sect2>
- <sect2 xml:id="network-natd">
- <info>
+ <sect2 xml:id="network-natd">
+ <info>
<title>Configuring <acronym>NAT</acronym></title>
<authorgroup>
- <author>
- <personname>
- <firstname>Chern</firstname>
- <surname>Lee</surname>
- </personname>
- <contrib>Contributed by </contrib>
- </author>
- </authorgroup>
- </info>
- <indexterm>
- <primary>NAT</primary>
+ <author>
+ <personname>
+ <firstname>Chern</firstname>
+ <surname>Lee</surname>
+ </personname>
+ <contrib>Contributed by </contrib>
+ </author>
+ </authorgroup>
+ </info>
+ <indexterm>
+ <primary>NAT</primary>
- <secondary>and <application>IPFW</application></secondary>
- </indexterm>
+ <secondary>and <application>IPFW</application></secondary>
+ </indexterm>
- <para>&os;'s built-in
- <acronym>NAT</acronym> daemon, &man.natd.8;, works in
- conjunction with <application>IPFW</application> to provide
- network address translation. This can be used to provide an
- Internet Connection Sharing solution so that
- several internal computers can connect to the Internet using
- <acronym>IP</acronym> address.</para>
+ <para>&os;'s built-in <acronym>NAT</acronym> daemon,
+ &man.natd.8;, works in conjunction with
+ <application>IPFW</application> to provide network address
+ translation. This can be used to provide an Internet
+ Connection Sharing solution so that several internal computers
+ can connect to the Internet using <acronym>IP</acronym>
+ address.</para>
- <para>To do this, the &os; machine connected to the Internet
+ <para>To do this, the &os; machine connected to the Internet
must act as a gateway. This gateway machine must have two
<acronym>NIC</acronym>s: one connects to the Internet router
and the other connects to a <acronym>LAN</acronym>. All the
machines on the <acronym>LAN</acronym> are connected through
a hub or switch.</para>
- <para>Each machine and interface behind the
+ <para>Each machine and interface behind the
<acronym>LAN</acronym> should be assigned
<acronym>IP</acronym> addresses in the private network space,
as defined by <link
@@ -2177,18 +2176,18 @@ pif="dc0" # interface name of NIC at
&man.natd.8; machine's internal <acronym>IP</acronym>
address.</para>
- <para>Some additional configuration is
- needed in order to activate the <acronym>NAT</acronym>
- function of <application>IPFW</application>. If the system
- has a custom kernel, the kernel configuration file needs to
- include <literal>option IPDIVERT</literal> with the other
- <literal>IPFIREWALL</literal> options.</para>
-
- <para>To enable firewall and <acronym>NAT</acronym> support at
- boot time, the following must be in
- <filename>/etc/rc.conf</filename>:</para>
+ <para>Some additional configuration is needed in order to
+ activate the <acronym>NAT</acronym> function of
+ <application>IPFW</application>. If the system has a custom
+ kernel, the kernel configuration file needs to include
+ <literal>option IPDIVERT</literal> with the other
+ <literal>IPFIREWALL</literal> options.</para>
+
+ <para>To enable firewall and <acronym>NAT</acronym> support at
+ boot time, the following must be in
+ <filename>/etc/rc.conf</filename>:</para>
- <programlisting>gateway_enable="YES" # enables the gateway function
+ <programlisting>gateway_enable="YES" # enables the gateway function
natd_enable="YES" # enables the <acronym>NAT</acronym> function
natd_interface="rl0" # specify interface name of NIC attached to Internet
natd_flags="-dynamic -m" # -m = preserve port numbers if possible</programlisting>
@@ -2213,87 +2212,87 @@ redirect_port tcp 192.168.0.3:80 80</pro
consult &man.natd.8;.</para>
</note>
- <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 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 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 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>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 is
- released to the Internet.</para>
-
- <para>On the inbound side, everything coming in that is part
- 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>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 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 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 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>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 is
+ released to the Internet.</para>
+
+ <para>On the inbound side, everything coming in that is part 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>
+ <para>Example Ruleset #1:</para>
- <programlisting>#!/bin/sh
+ <programlisting>#!/bin/sh
cmd="ipfw -q add"
skip="skipto 500"
pif=rl0
@@ -2340,13 +2339,13 @@ ipfw -q -f flush
######################## end of rules ##################</programlisting>
- <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>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>
+ <para>Example Ruleset #2:</para>
- <programlisting>#!/bin/sh
+ <programlisting>#!/bin/sh
################ Start of IPFW rules file ###############################
# Flush out the list before we begin.
ipfw -q -f flush
@@ -2499,130 +2498,132 @@ pif="rl0" # public interface name of
$cmd 999 deny log all from any to any
################ End of IPFW rules file ###############################</programlisting>
- <sect3>
- <title>Port Redirection</title>
+ <sect3>
+ <title>Port Redirection</title>
- <para>The drawback with &man.natd.8; is that the
- <acronym>LAN</acronym> clients are not accessible from the
- Internet. Clients on the <acronym>LAN</acronym> can make
- outgoing connections to the world but cannot receive incoming
- ones. This presents a problem if trying to run Internet
- services on one of the <acronym>LAN</acronym> client machines.
- A simple way around this is to redirect selected Internet
- ports on the &man.natd.8; machine to a <acronym>LAN</acronym>
- client.</para>
-
- <para>For example, an <acronym>IRC</acronym> server runs on
- client <systemitem>A</systemitem> and a web server runs on
- client <systemitem>B</systemitem>. For this to work properly,
- connections received on ports 6667 (<acronym>IRC</acronym>)
- and 80 (<acronym>HTTP</acronym>) must be redirected to the
- respective machines.</para>
+ <para>The drawback with &man.natd.8; is that the
+ <acronym>LAN</acronym> clients are not accessible from the
+ Internet. Clients on the <acronym>LAN</acronym> can make
+ outgoing connections to the world but cannot receive
+ incoming ones. This presents a problem if trying to run
+ Internet services on one of the <acronym>LAN</acronym>
+ client machines. A simple way around this is to redirect
+ selected Internet ports on the &man.natd.8; machine to a
+ <acronym>LAN</acronym> client.</para>
+
+ <para>For example, an <acronym>IRC</acronym> server runs on
+ client <systemitem>A</systemitem> and a web server runs on
+ client <systemitem>B</systemitem>. For this to work
+ properly, connections received on ports 6667
+ (<acronym>IRC</acronym>) and 80 (<acronym>HTTP</acronym>)
+ must be redirected to the respective machines.</para>
- <para>The syntax for <option>-redirect_port</option> is as
- follows:</para>
+ <para>The syntax for <option>-redirect_port</option> is as
+ follows:</para>
- <programlisting> -redirect_port proto targetIP:targetPORT[-targetPORT]
+ <programlisting> -redirect_port proto targetIP:targetPORT[-targetPORT]
[aliasIP:]aliasPORT[-aliasPORT]
[remoteIP[:remotePORT[-remotePORT]]]</programlisting>
- <para>In the above example, the argument should be:</para>
+ <para>In the above example, the argument should be:</para>
- <programlisting> -redirect_port tcp 192.168.0.2:6667 6667
+ <programlisting> -redirect_port tcp 192.168.0.2:6667 6667
-redirect_port tcp 192.168.0.3:80 80</programlisting>
- <para>This redirects the proper <acronym>TCP</acronym> ports
- to the <acronym>LAN</acronym> client machines.</para>
+ <para>This redirects the proper <acronym>TCP</acronym> ports
+ to the <acronym>LAN</acronym> client machines.</para>
- <para>Port ranges over individual ports can be indicated with
- <option>-redirect_port</option>. For example,
- <replaceable>tcp 192.168.0.2:2000-3000 2000-3000</replaceable>
- would redirect all connections received on ports 2000 to 3000
- to ports 2000 to 3000 on client
- <systemitem>A</systemitem>.</para>
-
- <para>These options can be used when directly running
- &man.natd.8;, placed within the
- <literal>natd_flags=""</literal> option in
- <filename>/etc/rc.conf</filename>, or passed via a
- configuration file.</para>
-
- <para>For further configuration options, consult
- &man.natd.8;</para>
- </sect3>
+ <para>Port ranges over individual ports can be indicated with
+ <option>-redirect_port</option>. For example,
+ <replaceable>tcp 192.168.0.2:2000-3000
+ 2000-3000</replaceable> would redirect all connections
+ received on ports 2000 to 3000 to ports 2000 to 3000 on
+ client <systemitem>A</systemitem>.</para>
+
+ <para>These options can be used when directly running
+ &man.natd.8;, placed within the
+ <literal>natd_flags=""</literal> option in
+ <filename>/etc/rc.conf</filename>, or passed via a
+ configuration file.</para>
- <sect3>
- <title>Address Redirection</title>
+ <para>For further configuration options, consult
+ &man.natd.8;</para>
+ </sect3>
- <indexterm>
- <primary>address redirection</primary>
- </indexterm>
+ <sect3>
+ <title>Address Redirection</title>
- <para>Address redirection is useful if more than one
- <acronym>IP</acronym> address is available. Each
- <acronym>LAN</acronym> client can be assigned its own
- external <acronym>IP</acronym> address by &man.natd.8;,
- which will then rewrite outgoing packets from the
- <acronym>LAN</acronym> clients with the proper external
- <acronym>IP</acronym> address and redirects all traffic
- incoming on that particular <acronym>IP</acronym> address
- back to the specific <acronym>LAN</acronym> client. This is
- also known as static <acronym>NAT</acronym>. For example,
- if <acronym>IP</acronym> addresses <systemitem
- class="ipaddress">128.1.1.1</systemitem>, <systemitem
- class="ipaddress">128.1.1.2</systemitem>, and <systemitem
- class="ipaddress">128.1.1.3</systemitem> are available,
- <systemitem class="ipaddress">128.1.1.1</systemitem> can be
- used as the &man.natd.8; machine's external
- <acronym>IP</acronym> address, while <systemitem
- class="ipaddress">128.1.1.2</systemitem> and <systemitem
- class="ipaddress">128.1.1.3</systemitem> are forwarded back
- to <acronym>LAN</acronym> clients <systemitem>A</systemitem>
- and <systemitem>B</systemitem>.</para>
-
- <para>The <option>-redirect_address</option> syntax is as
- follows:</para>
-
- <programlisting>-redirect_address localIP publicIP</programlisting>
-
-
- <informaltable frame="none" pgwide="1">
- <tgroup cols="2">
- <tbody>
- <row>
- <entry>localIP</entry>
- <entry>The internal <acronym>IP</acronym> address of
- the <acronym>LAN</acronym> client.</entry>
- </row>
-
- <row>
- <entry>publicIP</entry>
- <entry>The external <acronym>IP</acronym> address
- corresponding to the <acronym>LAN</acronym>
- client.</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
+ <indexterm>
+ <primary>address redirection</primary>
+ </indexterm>
- <para>In the example, this argument would read:</para>
+ <para>Address redirection is useful if more than one
+ <acronym>IP</acronym> address is available. Each
+ <acronym>LAN</acronym> client can be assigned its own
+ external <acronym>IP</acronym> address by &man.natd.8;,
+ which will then rewrite outgoing packets from the
+ <acronym>LAN</acronym> clients with the proper external
+ <acronym>IP</acronym> address and redirects all traffic
+ incoming on that particular <acronym>IP</acronym> address
+ back to the specific <acronym>LAN</acronym> client. This is
+ also known as static <acronym>NAT</acronym>. For example,
+ if <acronym>IP</acronym> addresses <systemitem
+ class="ipaddress">128.1.1.1</systemitem>, <systemitem
+ class="ipaddress">128.1.1.2</systemitem>, and <systemitem
+ class="ipaddress">128.1.1.3</systemitem> are available,
+ <systemitem class="ipaddress">128.1.1.1</systemitem> can be
+ used as the &man.natd.8; machine's external
+ <acronym>IP</acronym> address, while <systemitem
+ class="ipaddress">128.1.1.2</systemitem> and <systemitem
+ class="ipaddress">128.1.1.3</systemitem> are forwarded
+ back to <acronym>LAN</acronym> clients
+ <systemitem>A</systemitem> and
+ <systemitem>B</systemitem>.</para>
+
+ <para>The <option>-redirect_address</option> syntax is as
+ follows:</para>
+
+ <programlisting>-redirect_address localIP publicIP</programlisting>
+
+
+ <informaltable frame="none" pgwide="1">
+ <tgroup cols="2">
+ <tbody>
+ <row>
+ <entry>localIP</entry>
+ <entry>The internal <acronym>IP</acronym> address of
+ the <acronym>LAN</acronym> client.</entry>
+ </row>
+
+ <row>
+ <entry>publicIP</entry>
+ <entry>The external <acronym>IP</acronym> address
+ corresponding to the <acronym>LAN</acronym>
+ client.</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
- <programlisting>-redirect_address 192.168.0.2 128.1.1.2
+ <para>In the example, this argument would read:</para>
+
+ <programlisting>-redirect_address 192.168.0.2 128.1.1.2
-redirect_address 192.168.0.3 128.1.1.3</programlisting>
- <para>Like <option>-redirect_port</option>, these arguments are
- placed within the <literal>natd_flags=""</literal> option
- of <filename>/etc/rc.conf</filename>, or passed via a
- configuration file. With address redirection, there is no
- need for port redirection since all data received on a
- particular <acronym>IP</acronym> address is redirected.</para>
-
- <para>The external <acronym>IP</acronym> addresses on the
- &man.natd.8; machine must be active and aliased to the
- external interface. Refer to &man.rc.conf.5; for
- details.</para>
- </sect3>
-</sect2>
+ <para>Like <option>-redirect_port</option>, these arguments
+ are placed within the <literal>natd_flags=""</literal>
+ option of <filename>/etc/rc.conf</filename>, or passed via a
+ configuration file. With address redirection, there is no
+ need for port redirection since all data received on a
+ particular <acronym>IP</acronym> address is
+ redirected.</para>
+
+ <para>The external <acronym>IP</acronym> addresses on the
+ &man.natd.8; machine must be active and aliased to the
+ external interface. Refer to &man.rc.conf.5; for
+ details.</para>
+ </sect3>
+ </sect2>
<sect2 xml:id="firewalls-ipfw-cmd">
<title>The <application>IPFW</application> Command</title>
More information about the svn-doc-all
mailing list