svn commit: r44057 - head/en_US.ISO8859-1/books/handbook/firewalls
Dru Lavigne
dru at FreeBSD.org
Tue Feb 25 19:40:14 UTC 2014
Author: dru
Date: Tue Feb 25 19:40:13 2014
New Revision: 44057
URL: http://svnweb.freebsd.org/changeset/doc/44057
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 Tue Feb 25 19:00:35 2014 (r44056)
+++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 25 19:40:13 2014 (r44057)
@@ -78,12 +78,11 @@
</itemizedlist>
<para>&os; has three firewalls built into the base system:
- <application>PF</application>,
- <application>IPFW</application>, and <application>IPFILTER</application>, also known as
- <application>IPF</application>.
- &os; also provides two traffic shapers for controlling bandwidth
- usage: &man.altq.4; and &man.dummynet.4;.
- <application>ALTQ</application> has
+ <application>PF</application>, <application>IPFW</application>,
+ and <application>IPFILTER</application>, also known as
+ <application>IPF</application>. &os; also provides two traffic
+ shapers for controlling bandwidth usage: &man.altq.4; and
+ &man.dummynet.4;. <application>ALTQ</application> has
traditionally been closely tied with
<application>PF</application> and
<application>dummynet</application> with
@@ -1593,23 +1592,23 @@ block drop out quick on $ext_if from any
<secondary>IPFW</secondary>
</indexterm>
- <para><application>IPFW</application> is a stateful firewall written for
- &os; which supports both <acronym>IPv4</acronym>
- and <acronym>IPv6</acronym>. It is comprised of several components: the kernel firewall
- filter rule processor and its integrated packet accounting
- facility, the logging facility,
- <acronym>NAT</acronym>, the &man.dummynet.4; traffic shaper,
- a forward facility, a bridge
- facility, and an ipstealth facility.</para>
+ <para><application>IPFW</application> is a stateful firewall
+ written for &os; which supports both <acronym>IPv4</acronym> and
+ <acronym>IPv6</acronym>. It is comprised of several components:
+ the kernel firewall filter rule processor and its integrated
+ packet accounting facility, the logging facility,
+ <acronym>NAT</acronym>, the &man.dummynet.4; traffic shaper, a
+ forward facility, a bridge facility, and an ipstealth
+ facility.</para>
<para>&os; provides a sample ruleset in
- <filename>/etc/rc.firewall</filename> which
- defines several firewall types for common scenarios to assist
- novice users in generating an appropriate ruleset.
- <application>IPFW</application> provides a powerful syntax which advanced users can
- use to craft customized rulesets that meet the security
- requirements of a given environment.</para>
-
+ <filename>/etc/rc.firewall</filename> which defines several
+ firewall types for common scenarios to assist novice users in
+ generating an appropriate ruleset.
+ <application>IPFW</application> provides a powerful syntax which
+ advanced users can use to craft customized rulesets that meet
+ the security requirements of a given environment.</para>
+
<para>This section describes how to enable
<application>IPFW</application>, provides an overview of its
rule syntax, and demonstrates several rulesets for common
@@ -1624,8 +1623,10 @@ block drop out quick on $ext_if from any
<secondary>enabling</secondary>
</indexterm>
- <para><application>IPFW</application> is included in the basic &os; install as a kernel
- loadable module, meaning that a custom kernel is not needed in order to enable <application>IPFW</application>.</para>
+ <para><application>IPFW</application> is included in the basic
+ &os; install as a kernel loadable module, meaning that a
+ custom kernel is not needed in order to enable
+ <application>IPFW</application>.</para>
<indexterm>
<primary>kernel options</primary>
@@ -1669,8 +1670,8 @@ options IPDIVERT # enables NAT</pro
<programlisting>firewall_enable="YES"</programlisting>
- <para>To use one of the default firewall types provided by
- &os;, add another line which specifies the type:</para>
+ <para>To use one of the default firewall types provided by &os;,
+ add another line which specifies the type:</para>
<programlisting>firewall_type="open"</programlisting>
@@ -1701,19 +1702,18 @@ options IPDIVERT # enables NAT</pro
firewall rules.</para>
</listitem>
<listitem>
- <para><filename>filename</filename>:
- full path of the file containing the firewall
- rules.</para>
+ <para><filename>filename</filename>: full path of the file
+ containing the firewall rules.</para>
</listitem>
</itemizedlist>
- <para>To instead load a custom ruleset, either
- set the <filename>filename</filename> value of
+ <para>To instead load a custom ruleset, either set the
+ <filename>filename</filename> value of
<literal>firewall_type</literal> or set the
<literal>firewall_script</literal> variable to the absolute
path of an executable script that includes
- <command>IPFW</command> commands. This example script
- blocks all incoming and outgoing traffic:</para>
+ <command>IPFW</command> commands. This example script blocks
+ all incoming and outgoing traffic:</para>
<programlisting>#!/bin/sh
@@ -1750,10 +1750,9 @@ ipfw add deny out</programlisting>
</warning>
<para>If the machine is acting as a gateway providing
- <acronym>NAT</acronym> using &man.natd.8;,
- refer to <xref linkend="network-natd"/> for information
- regarding the required <filename>/etc/rc.conf</filename>
- options.</para>
+ <acronym>NAT</acronym> using &man.natd.8;, refer to <xref
+ linkend="network-natd"/> for information regarding the
+ required <filename>/etc/rc.conf</filename> options.</para>
</sect2>
<sect2 xml:id="firewalls-ipfw-cmd">
@@ -1771,12 +1770,12 @@ ipfw add deny out</programlisting>
changes.</para>
<para><command>ipfw</command> is a useful way to display the
- running firewall rules to the console screen. The <application>IPFW</application>
- 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>
+ running firewall rules to the console screen. The
+ <application>IPFW</application> 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 running rules in sequence:</para>
@@ -1830,13 +1829,14 @@ ipfw add deny out</programlisting>
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 <application>IPFW</application> default
- 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>
+ any of the rules, it gets caught by the mandatory
+ <application>IPFW</application> default 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>
<para>The examples in this section create an inclusive type
firewall ruleset containing the stateful <literal>keep
@@ -1845,212 +1845,219 @@ ipfw add deny out</programlisting>
<literal>via</literal> options. For a complete rule syntax
description, refer to &man.ipfw.8;.</para>
- <indexterm>
- <primary><application>IPFW</application></primary>
+ <indexterm>
+ <primary><application>IPFW</application></primary>
- <secondary>rule syntax</secondary>
- </indexterm>
+ <secondary>rule syntax</secondary>
+ </indexterm>
- <para>This section describes the keywords which comprise an
- <application>IPFW</application> 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>This section describes the keywords which comprise an
+ <application>IPFW</application> 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>
+ <para><replaceable>CMD RULE_NUMBER ACTION LOGGING SELECTION
+ STATEFUL</replaceable></para>
- <variablelist>
- <varlistentry>
+ <variablelist>
+ <varlistentry>
<term>CMD</term>
<listitem>
- <para>Each new rule has to be prefixed with
- <parameter>add</parameter> to add the rule to the internal
- table.</para>
- </listitem>
- </varlistentry>
+ <para>Each new rule has to be prefixed with
+ <parameter>add</parameter> to add the rule to the
+ internal table.</para>
+ </listitem>
+ </varlistentry>
<varlistentry>
<term>RULE_NUMBER</term>
<listitem>
- <para>Each rule is associated with a rule_number in the
- range of <literal>1</literal> to
- <literal>65535</literal>.</para>
- </listitem>
- </varlistentry>
+ <para>Each rule is associated with a rule_number in the
+ range of <literal>1</literal> to
+ <literal>65535</literal>.</para>
+ </listitem>
+ </varlistentry>
<varlistentry>
<term>ACTION</term>
<listitem>
- <para>A rule can be associated with one of the following
- 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 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. 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
- packets that match this rule. The search
- terminates.</para>
- </listitem>
- </varlistentry>
+ <para>A rule can be associated with one of the following
+ 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 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. 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
+ packets that match this rule. The search
+ terminates.</para>
+ </listitem>
+ </varlistentry>
<varlistentry>
<term>Logging</term>
<listitem>
- <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
- <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 <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, using <command>ipfw reset log</command>.</para>
-
- <note>
- <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>
- </listitem>
- </varlistentry>
+ <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
+ <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 <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, using <command>ipfw reset
+ log</command>.</para>
+
+ <note>
+ <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>
+ </listitem>
+ </varlistentry>
<varlistentry>
<term>Selection</term>
<listitem>
- <para>The keywords described in this section are used to
- describe attributes of the packet to be checked when
- determining whether rules match the packet or not.
- The following general-purpose attributes are provided for
- matching, and must be used in this order:</para>
-
- <para><parameter>udp | tcp | icmp</parameter></para>
-
- <para>Any other protocol names found in
- <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>
-
- <para>The <literal>from</literal> and <literal>to</literal>
- keywords are used to match against IP addresses. Rules
- must specify <emphasis>both</emphasis> source and
- destination parameters. <literal>any</literal> is a
- special keyword that matches any IP address.
- <literal>me</literal> is a special keyword that matches
- any IP address configured on an interface in 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 <package>net-mgmt/ipcalc</package> 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 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. 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 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 mandatory keyword identifies the session start
- request for <acronym>TCP</acronym> packets.</para>
-
- <para><parameter>keep-state</parameter></para>
-
- <para>This is a mandatory keyword. Upon a match, the
- firewall will create a dynamic rule, whose default
- behavior is to match bidirectional traffic between source
- and destination IP/port using the same protocol.</para>
-
- <para><parameter>limit {src-addr | src-port | dst-addr |
- dst-port}</parameter></para>
-
- <para>The firewall will only allow
- <replaceable>N</replaceable> connections with the same
- set of parameters as specified in the rule. One or more
- of source and destination addresses and ports can be
- specified. <literal>limit</literal> and
- <literal>keep-state</literal> can not be used on the same
- rule as they provide the same stateful function.</para>
- </listitem>
- </varlistentry>
+ <para>The keywords described in this section are used to
+ describe attributes of the packet to be checked when
+ determining whether rules match the packet or not. The
+ following general-purpose attributes are provided for
+ matching, and must be used in this order:</para>
+
+ <para><parameter>udp | tcp | icmp</parameter></para>
+
+ <para>Any other protocol names found in
+ <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>
+
+ <para>The <literal>from</literal> and
+ <literal>to</literal> keywords are used to match against
+ IP addresses. Rules must specify
+ <emphasis>both</emphasis> source and destination
+ parameters. <literal>any</literal> is a special keyword
+ that matches any IP address. <literal>me</literal> is a
+ special keyword that matches any IP address configured
+ on an interface in 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 <package>net-mgmt/ipcalc</package>
+ 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 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. 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 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 mandatory keyword identifies the session start
+ request for <acronym>TCP</acronym> packets.</para>
+
+ <para><parameter>keep-state</parameter></para>
+
+ <para>This is a mandatory keyword. Upon a match, the
+ firewall will create a dynamic rule, whose default
+ behavior is to match bidirectional traffic between
+ source and destination IP/port using the same
+ protocol.</para>
+
+ <para><parameter>limit {src-addr | src-port | dst-addr |
+ dst-port}</parameter></para>
+
+ <para>The firewall will only allow
+ <replaceable>N</replaceable> connections with the same
+ set of parameters as specified in the rule. One or more
+ of source and destination addresses and ports can be
+ specified. <literal>limit</literal> and
+ <literal>keep-state</literal> can not be used on the
+ same rule as they provide the same stateful
+ function.</para>
+ </listitem>
+ </varlistentry>
- <varlistentry>
- <term>Stateful Rule Option</term>
- <listitem>
- <para>The <literal>check-state</literal> option is used to
- identify where in the <application>IPFW</application> 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 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 type of attack
- with <application>IPFW</application>, 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>
- </listitem>
- </varlistentry>
- </variablelist>
+ <varlistentry>
+ <term>Stateful Rule Option</term>
+ <listitem>
+ <para>The <literal>check-state</literal> option is used to
+ identify where in the <application>IPFW</application>
+ 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 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 type of
+ attack with <application>IPFW</application>, 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>
+ </listitem>
+ </varlistentry>
+ </variablelist>
<sect3>
<title>Logging Firewall Messages</title>
@@ -2061,16 +2068,17 @@ ipfw add deny out</programlisting>
<secondary>logging</secondary>
</indexterm>
- <para>Even with the logging facility enabled, <application>IPFW</application> will not
- generate any rule logging on its own. The firewall
- 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>Even with the logging facility enabled,
+ <application>IPFW</application> will not generate any rule
+ logging on its own. The firewall 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 one is not careful,
an over abundance of log data or a DoS attack can fill the
@@ -2102,15 +2110,15 @@ ipfw add deny out</programlisting>
<sect3 xml:id="firewalls-ipfw-rules-script">
<title>Building a Rule Script</title>
- <para>Most experienced <application>IPFW</application> users create a file containing
- the rules and code them in a manner compatible with running
- them as a script. The major benefit of doing this is the
- firewall rules can be refreshed in mass without the need
- of rebooting the system to activate them. This method is
- convenient in testing new rules as the procedure can
- be executed as many times as needed. Being a script,
- symbolic substitution can be used for frequently used
- values to be substituted into multiple rules.</para>
+ <para>Most experienced <application>IPFW</application> users
+ create a file containing the rules and code them in a manner
+ compatible with running them as a script. The major benefit
+ of doing this is the firewall rules can be refreshed in mass
+ without the need of rebooting the system to activate them.
+ This method is convenient in testing new rules as the
+ procedure can be executed as many times as needed. Being a
+ script, symbolic substitution can be used for frequently
+ used values to be substituted into multiple rules.</para>
<para>This example script is compatible with the syntax used
by the &man.sh.1;, &man.csh.1;, and &man.tcsh.1; shells.
@@ -2367,12 +2375,13 @@ pif="dc0" # public interface name of
<para>There are some additional configuration statements that
need to be enabled to activate the <acronym>NAT</acronym>
- function of <application>IPFW</application>. For a customized kernel, the kernel
- configuration file needs
+ function of <application>IPFW</application>. 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 <application>IPFW</application> options in
+ <para>In addition to the normal
+ <application>IPFW</application> options in
<filename>/etc/rc.conf</filename>, the following are
needed:</para>
@@ -2380,10 +2389,9 @@ pif="dc0" # public interface name of
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 a
- <literal>divert natd</literal> rule complicates the ruleset
- logic. The positioning of the
- <literal>check-state</literal>, and
+ <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
@@ -3442,8 +3450,9 @@ map dc0 10.0.10.0/29 -> 0/32</program
<acronym>NAT</acronym> if they match the third rule.</para>
<para>Without the <acronym>FTP</acronym> proxy, the following
- firewall rules would instead be needed. Note that without the proxy,
- all ports above <literal>1024</literal> need to be allowed:</para>
+ firewall rules would instead be needed. Note that without the
+ proxy, all ports above <literal>1024</literal> need to be
+ allowed:</para>
<programlisting># Allow out LAN PC client FTP to public Internet
# Active and passive modes
@@ -3455,13 +3464,13 @@ pass out quick on rl0 proto tcp from any
# Active mode let data channel in from FTP server
pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state</programlisting>
- <para>Whenever the file containing the <acronym>NAT</acronym> rules
- is edited, run
- <command>ipnat</command> with <option>-CF</option> to delete
- the current <acronym>NAT</acronym> rules and flush the
- contents of the dynamic translation table. Include
- <option>-f</option> and specify the name
- of the <acronym>NAT</acronym> ruleset to load:</para>
+ <para>Whenever the file containing the <acronym>NAT</acronym>
+ rules is edited, run <command>ipnat</command> with
+ <option>-CF</option> to delete the current
+ <acronym>NAT</acronym> rules and flush the contents of the
+ dynamic translation table. Include <option>-f</option> and
+ specify the name of the <acronym>NAT</acronym> ruleset to
+ load:</para>
<screen>&prompt.root; <userinput>ipnat -CF -f /etc/ipnat.rules</userinput></screen>
@@ -3633,35 +3642,35 @@ sh /etc/ipf.rules.script</programlisting
TCP cksum fails(in): 0 (out): 0
Packet log flags set: (0)</screen>
- <para>Several options are available. When supplied with either <option>-i</option> for inbound
- or <option>-o</option> for outbound, the command will retrieve
- and display the appropriate list of filter rules currently
- installed and in use by the kernel. To also see the rule
- numbers, include <option>-n</option>. For example,
- <command>ipfstat -on</command> displays the outbound
- rules table with rule numbers:</para>
+ <para>Several options are available. When supplied with either
+ <option>-i</option> for inbound or <option>-o</option> for
+ outbound, the command will retrieve and display the
+ appropriate list of filter rules currently installed and in
+ use by the kernel. To also see the rule numbers, include
+ <option>-n</option>. For example, <command>ipfstat
+ -on</command> displays the outbound rules table with rule
+ numbers:</para>
<screen>@1 pass out on xl0 from any to any
@2 block out on dc0 from any to any
@3 pass out quick on dc0 proto tcp/udp from any to any keep state</screen>
- <para>Include <option>-h</option> to
- prefix each rule with a count of how
- many times the rule was matched. For example,
- <command>ipfstat -oh</command> displays the outbound
- internal rules table, prefixing each rule with its usage count:</para>
+ <para>Include <option>-h</option> to prefix each rule with a
+ count of how many times the rule was matched. For example,
+ <command>ipfstat -oh</command> displays the outbound internal
+ rules table, prefixing each rule with its usage count:</para>
<screen>2451423 pass out on xl0 from any to any
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>To display the state table in a format similar to &man.top.1;, use
- <command>ipfstat -t</command>. When the firewall is
- under attack, this option provides the ability to identify
- and see the attacking packets. The optional sub-flags give
- the ability to select the destination or source <acronym>IP</acronym>, port, or
- protocol to be monitored in real time. Refer to
- &man.ipfstat.8; for details.</para>
+ <para>To display the state table in a format similar to
+ &man.top.1;, use <command>ipfstat -t</command>. When the
+ firewall is under attack, this option provides the ability to
+ identify and see the attacking packets. The optional
+ sub-flags give the ability to select the destination or source
+ <acronym>IP</acronym>, port, or protocol to be monitored in
+ real time. Refer to &man.ipfstat.8; for details.</para>
</sect2>
<sect2>
@@ -3676,16 +3685,17 @@ sh /etc/ipf.rules.script</programlisting
</indexterm>
<para><application>IPF</application> provides
- <command>ipmon</command>, which can be used to write the firewall's logging
- information in a human readable format. It requires that
- <literal>options IPFILTER_LOG</literal> be first added
- to a custom kernel using the instructions in <xref linkend="kernelconfig"/>.</para>
-
- <para>This command is typically run in
- daemon mode in order to provide a continuous system log file so that
- logging of past events may be reviewed. Since &os; has a built in
- &man.syslogd.8; facility to automatically rotate system logs, the default
- <filename>rc.conf</filename>
+ <command>ipmon</command>, which can be used to write the
+ firewall's logging information in a human readable format. It
+ requires that <literal>options IPFILTER_LOG</literal> be first
+ added to a custom kernel using the instructions in <xref
+ linkend="kernelconfig"/>.</para>
+
+ <para>This command is typically run in daemon mode in order to
+ provide a continuous system log file so that logging of past
+ events may be reviewed. Since &os; has a built in
+ &man.syslogd.8; facility to automatically rotate system logs,
+ the default <filename>rc.conf</filename>
<literal>ipmon_flags</literal> statement uses
<option>-Ds</option>:</para>
@@ -3701,20 +3711,19 @@ sh /etc/ipf.rules.script</programlisting
<para>Once the logging facility is enabled in
<filename>rc.conf</filename> and started with <command>service
- ipmon start</command>, <application>IPF</application> will only
- log the rules which contain the <literal>log</literal> keyword. The firewall
- administrator decides which rules in the ruleset should be
- logged and normally
- only deny rules are logged. It is customary to include the
- <literal>log</literal> keyword in 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>
+ ipmon start</command>, <application>IPF</application> will
+ only log the rules which contain the <literal>log</literal>
+ keyword. The firewall administrator decides which rules in
+ the ruleset should be logged and normally only deny rules are
+ logged. It is customary to include the
+ <literal>log</literal> keyword in 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>
<para>By default, <command>ipmon -Ds</command> mode uses
- <literal>local0</literal> as
- the logging facility. The following logging levels can be
- used to further segregate the logged data:</para>
+ <literal>local0</literal> as the logging facility. The
+ following logging 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
@@ -3798,11 +3807,13 @@ LOG_ERR - packets which have been logged
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 <acronym>ICMP</acronym> packet, there will be two fields
- at the end: the first always being <quote>icmp</quote> and
- the next being the <acronym>ICMP</acronym> message and sub-message type,
- separated by a slash. For example: <literal>icmp 3/3</literal> for a port
- unreachable message.</para>
+ <para>If the packet is an <acronym>ICMP</acronym> packet, there
+ will be two fields at the end: the first always being
+ <quote>icmp</quote> and the next being the
+ <acronym>ICMP</acronym> message and sub-message type,
+ separated by a slash. For example:
+ <literal>icmp 3/3</literal> for a port unreachable
+ message.</para>
</sect2>
</sect1>
- </chapter>
+</chapter>
More information about the svn-doc-all
mailing list