White space fix only. Translators can ignore.
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne
parent
373746f7f6
commit
a702301297
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=44057
1 changed files with 300 additions and 289 deletions
|
|
@ -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 to $martians</programlisting>
|
|||
<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 to $martians</programlisting>
|
|||
<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</programlisting>
|
|||
|
||||
<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</programlisting>
|
|||
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>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><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>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><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>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><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>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>
|
||||
<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>
|
||||
<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>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><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>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><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>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><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>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><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>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><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>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><parameter>setup</parameter></para>
|
||||
|
||||
<para>This mandatory keyword 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>
|
||||
<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>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><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 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>
|
||||
<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>
|
||||
<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 NIC
|
|||
|
||||
<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 NIC
|
|||
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</programlisting>
|
|||
<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 to any port > 1024 flags S keep stat
|
|||
# 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>
|
||||
<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>
|
||||
<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 and which can be considered short due t
|
|||
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>
|
||||
|
|
|
|||
Loading…
Reference in a new issue