os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Move some stuff that applies to all firewalls to Concepts section.

Browse source 
Finish modernization pass through IPF Rulesets.
Next commit will look at the provided examples.

Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne 2014-02-22 01:04:38 +00:00
parent 49e2f26cd5
commit e77439a35c
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=44022
1 changed files with 129 additions and 147 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

276
en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
View file

@ -196,11 +196,28 @@
<para>Security can be tightened further using a <quote>stateful <para>Security can be tightened further using a <quote>stateful
firewall</quote>. This type of firewall keeps track of open firewall</quote>. This type of firewall keeps track of open
connections and only allows traffic which either matches an connections and only allows traffic which either matches an
existing connection or opens a new, allowed connection. The existing connection or opens a new, allowed connection.</para>
disadvantage of a stateful firewall is that it can be vulnerable
to Denial of Service (<acronym>DoS</acronym>) attacks if a lot <para>Stateful filtering treats traffic as a bi-directional
of new connections are opened very fast. Most firewalls use a exchange of packets comprising a session. When state is specified on a matching rule
combination of stateful and non-stateful behavior.</para> the firewall dynamically generates
internal rules for each anticipated packet being exchanged
during the session. It has sufficient matching capabilities
to determine if a packet is valid for a session. Any packets
that do not properly fit the session template are
automatically rejected.</para>
<para>When the session completes, it is removed from the
dynamic state table.</para>
<para>Stateful filtering allows one to focus on blocking/passing
new sessions. If the new session is passed, all its
subsequent packets are allowed automatically and any impostor
packets are automatically rejected. If a new session is
blocked, none of its subsequent packets are allowed. Stateful
filtering provides advanced matching abilities capable of
defending against the flood of different attack methods
employed by attackers.</para>
<warning> <warning>
<para>When working with the firewall rules, be <emphasis>very <para>When working with the firewall rules, be <emphasis>very
@ -1682,7 +1699,7 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
</sect2> </sect2>
<sect2> <sect2>
<title>IPF Rulesets</title> <title><application>IPF</application> Rulesets</title>
<indexterm> <indexterm>
<primary><application>IPFILTER</application></primary> <primary><application>IPFILTER</application></primary>
@ -1692,30 +1709,37 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<para>This section describes the <application>IPF</application> rule syntax <para>This section describes the <application>IPF</application> rule syntax
used to create stateful rules. When creating rules, keep in used to create stateful rules. When creating rules, keep in
mind that the default way in which filter rules are applied mind that unless the <literal>quick</literal> keyword appears
is for the <emphasis>last matching rule</emphasis> to be in a rule, every rule is read
used. Even if the first rule to match a packet is a in order, with the <emphasis>last matching rule</emphasis>
being the one that is applied. This means that even if the first rule to match a packet is a
<literal>pass</literal>, if there is a later matching rule <literal>pass</literal>, if there is a later matching rule
that is a <literal>block</literal>, the packet will be dropped. that is a <literal>block</literal>, the packet will be dropped.
Refer to &man.ipf.5; for more details about rule syntax.</para> Sample rulesets can be found in
<filename class="directory">/usr/share/examples/ipfilter</filename>.</para>
<para>When creating rules, a <literal>#</literal> character is used to mark the <para>When creating rules, a <literal>#</literal> character is used to mark the
start of a comment and may appear at the end of a rule, to explain its function, start of a comment and may appear at the end of a rule, to explain that rule's function,
or on its own line. Any blank lines are ignored.</para> or on its own line. Any blank lines are ignored.</para>
<para>The keywords which are used in rules must be written in a specific <para>The keywords which are used in rules must be written in a specific
order, from left to right. Some keywords have sub-options which may be order, from left to right. Some keywords are mandatory while
others are optional. Some keywords have sub-options which may be
keywords themselves and also include more sub-options. The keywords themselves and also include more sub-options. The
keyword order is as follows:</para> keyword order is as follows, where the words shown in uppercase
represent a variable and the words shown in lowercase must
<!-- This section is probably wrong. See the OpenBSD flag --> precede the variable that follows it:</para>
<!-- What is the "OpenBSD flag"? Reference please -->
<para><replaceable>ACTION DIRECTION OPTIONS proto PROTO_TYPE <para><replaceable>ACTION DIRECTION OPTIONS proto PROTO_TYPE
from SRC_ADDR SRC_PORT to DST_ADDR DST_PORT OBJECT PORT_NUM TCP_FLAG from SRC_ADDR SRC_PORT to DST_ADDR DST_PORT TCP_FLAG|ICMP_TYPE
STATEFUL</replaceable></para> keep state STATE</replaceable></para>
<para>This section describes each keyword and its options.</para> <para>This section describes each of these keywords and their options. It
is not an exhaustive list of every possible option. Refer to
&man.ipf.5; for a complete description of the rule
syntax that can be used when creating
<application>IPF</application> rules and examples for using
each keyword.</para>
<variablelist> <variablelist>
<varlistentry> <varlistentry>
@ -1807,6 +1831,10 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
this option is recommended so that only the triggering this option is recommended so that only the triggering
packet is logged and not every packet which matches the packet is logged and not every packet which matches the
stateful connection.</para> stateful connection.</para>
<para>Additional options are available to specify
error return messages. Refer to &man.ipf.5; for more details.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -1814,15 +1842,17 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<term>PROTO_TYPE</term> <term>PROTO_TYPE</term>
<listitem> <listitem>
<para>The protocol type is optional. However, it is <para>The protocol type is optional. However, it is
mandatory if the rule needs to specify a a SRC_PROTO or mandatory if the rule needs to specify a a SRC_PORT or
a DST_PROTO as it defines the type of protocol. When a DST_PORT as it defines the type of protocol. When
specifying the type of protocol, use the specifying the type of protocol, use the
<literal>proto</literal> keyword followed by either a <literal>proto</literal> keyword followed by either a
protocol number or name from protocol number or name from
<filename>/etc/protocols</filename>. <filename>/etc/protocols</filename>.
Example keywords include <literal>tcp</literal>, Example protocol names include <literal>tcp</literal>,
<literal>udp</literal>, or <literal>udp</literal>, or
<literal>icmp</literal>.</para> <literal>icmp</literal>. If PROTO_TYPE is specified but
no SRC_PORT or DST_PORT is specified, all port numbers
for that protocol will match that rule.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -1836,173 +1866,125 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<acronym>CIDR</acronym> mask, an address pool, or the <acronym>CIDR</acronym> mask, an address pool, or the
keyword <literal>all</literal>. Refer to &man.ipf.5; keyword <literal>all</literal>. Refer to &man.ipf.5;
for examples.</para> for examples.</para>
</listitem>
</varlistentry>
<varlistentry> <para>There is no way to match ranges of <acronym>IP</acronym> addresses
<term>SRC_PORT</term>
<listitem>
<para><literal>proto</literal> is the subject keyword
which must include one of its corresponding keyword
sub-option values. The sub-option indicates a specific
protocol to be matched against.</para>
<para><literal>tcp/udp | udp | tcp | icmp</literal> or any
protocol names found in
<filename>/etc/protocols</filename> are recognized and
may be used. The special protocol keyword
<literal>tcp/udp</literal> may be used to match either a
<acronym>TCP</acronym> or a <acronym>UDP</acronym>
packet, and has been added as a convenience to save
duplication of otherwise identical rules.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>DST_ADDR</term>
<listitem>
<para>The <literal>all</literal> keyword is equivalent to
<quote>from any to any</quote> with no other match
parameters.</para>
<para><literal>from | to src to dst</literal>: the
<literal>from</literal> and <literal>to</literal>
keywords are used to match against IP addresses. Rules
must specify <emphasis>both</emphasis> the source and
destination parameters. <literal>any</literal> is a
special keyword that matches any IP address. Examples
include: <literal>from any to any</literal>,
<literal>from 0.0.0.0/0 to any</literal>, <literal>from
any to 0.0.0.0/0</literal>, <literal>from 0.0.0.0 to
any</literal>, and <literal>from any to
0.0.0.0</literal>.</para>
<para>There is no way to match ranges of IP addresses
which do not express themselves easily using the dotted which do not express themselves easily using the dotted
numeric form / mask-length notation. The numeric form / mask-length notation. The
<package>net-mgmt/ipcalc</package> port may be used to <package>net-mgmt/ipcalc</package> package or port may be used to
ease the calculation. Additional information is ease the calculation of the <acronym>CIDR</acronym> mask. Additional information is
available at the utility's web page: <uri available at the utility's web page: <uri
xlink:href="http://jodies.de/ipcalc">http://jodies.de/ipcalc</uri>.</para> xlink:href="http://jodies.de/ipcalc">http://jodies.de/ipcalc</uri>.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term>DST_PORT</term> <term>SRC_PORT</term>
<listitem> <listitem>
<para>If a port match is included, for either or both of <para>The port number of the source is optional. However,
source and destination, it is only applied to if it is used, it requires PROTO_TYPE to be first defined in
<acronym>TCP</acronym> and <acronym>UDP</acronym> the rule. The port number must also be preceded by the
packets. When composing port comparisons, either the <literal>proto</literal> keyword.</para>
service name from <filename>/etc/services</filename> or
an integer port number may be used. When the port
appears as part of the <literal>from</literal> object,
it matches the source port number. When it appears as
part of the <literal>to</literal> object, it matches the
destination port number. An example usage is
<literal>from any to any port = 80</literal></para>
<para>Single port comparisons may be done in a number of <para>A number of different comparison operators are supported:
ways, using a number of different comparison operators. <literal>=</literal> (equal to),
Instead of the <literal>=</literal> shown in the example <literal>!=</literal> (not equal to),
above, the following operators may be used: <literal>&lt;</literal> (less than),
<literal>!=</literal>, <literal>&lt;</literal>, <literal>&gt;</literal> (greater than),
<literal>&gt;</literal>, <literal>&lt;=</literal>, <literal>&lt;=</literal> (less than or equal to), and
<literal>&gt;=</literal>, <literal>eq</literal>, <literal>&gt;=</literal> (greater than or equal to).
<literal>ne</literal>, <literal>lt</literal>, </para>
<literal>gt</literal>, <literal>le</literal>, and
<literal>ge</literal>.</para>
<para>To specify port ranges, place the two port numbers <para>To specify port ranges, place the two port numbers
between <literal>&lt;&gt;</literal> or between <literal>&lt;&gt;</literal> (less than and greater than ),
<literal>&gt;&lt;</literal></para> <literal>&gt;&lt;</literal> (greater than and less than ), or
<literal>:</literal> (greater than or equal to and
less than or equal to).</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term><acronym>TCP</acronym>_FLAG</term> <term>DST_ADDR</term>
<listitem> <listitem>
<para>Flags are only effective for <acronym>TCP</acronym> <para>The <literal>to</literal> keyword is mandatory and
filtering. The letters represent one of the possible is followed by a keyword which represents the destination of
flags that can be matched against the the packet. Similar to SRC_ADDR, it can be a hostname, an
<acronym>TCP</acronym> packet header.</para> <acronym>IP</acronym> address followed by the
<acronym>CIDR</acronym> mask, an address pool, or the
<para>The modernized rules processing logic uses the keyword <literal>all</literal>.</para>
<literal>flags S</literal> parameter to identify the TCP
session start request.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term>STATEFUL</term> <term>DST_PORT</term>
<listitem> <listitem>
<para><literal>keep state</literal> indicates that on a <para>Similar to SRC_PORT, the port number of the destination is optional. However,
pass rule, any packets that match the rules selection if it is used, it requires PROTO_TYPE to be first defined in
parameters should activate the stateful filtering the rule. The port number must also be preceded by the
facility.</para> <literal>proto</literal> keyword.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
</variablelist>
</sect2>
<sect2> <varlistentry>
<title>Stateful Filtering</title> <term>TCP_FLAG|ICMP_TYPE</term>
<listitem>
<para>If <literal>tcp</literal> is specifed as the PROTO_TYPE, flags
can be specified as letters, where each letter represents one of the possible
<acronym>TCP</acronym> flags used to determine
the state of a connection. Possible values
are: <literal>S</literal> (SYN),
<literal>A</literal> (ACK),
<literal>P</literal> (PSH),
<literal>F</literal> (FIN),
<literal>U</literal> (URG),
<literal>R</literal> (RST),
<literal>C</literal> (CWN), and
<literal>E</literal> (ECN).</para>
<indexterm> <para>If <literal>icmp</literal> is specifed as the PROTO_TYPE,
<primary><application>IPFILTER</application></primary> the <acronym>ICMP</acronym> type to match can be
specified. Refer to &man.ipf.5; for the allowable types.</para>
</listitem>
</varlistentry>
<secondary>stateful filtering</secondary> <varlistentry>
</indexterm> <term>STATE</term>
<listitem>
<!-- XXX: duplicated --> <para>If a <literal>pass</literal> rule contains
<literal>keep state</literal>,
<para>Stateful filtering treats traffic as a bi-directional <application>IPF</application> will add an entry to its
exchange of packets comprising a session. When activated, dynamic state table and allow subsequent packets that
<literal>keep-state</literal> dynamically generates match the connection.
internal rules for each anticipated packet being exchanged <application>IPF</application> can track state for
during the session. It has sufficient matching capabilities <acronym>TCP</acronym>, <acronym>UDP</acronym>, and
to determine if a packet is valid for a session. Any packets <acronym>ICMP</acronym> sessions. Any packet that <application>IPF</application> can be certain
that do not properly fit the session template are
automatically rejected.</para>
<para>IPF stateful filtering will also allow
<acronym>ICMP</acronym> packets related to an existing
<acronym>TCP</acronym> or <acronym>UDP</acronym> session. So,
if an <acronym>ICMP</acronym> type 3 code 4 packet is a
response in a session started by a keep state rule, it will
automatically be allowed. Any packet that IPF can be certain
is part of an active session, even if it is a different is part of an active session, even if it is a different
protocol, will be allowed.</para> protocol, will be allowed.</para>
<para>Packets destined to go out through the interface connected <para>In <application>IPF</application>, packets destined to go out through the interface connected
to the public Internet are first checked against the dynamic to the public Internet are first checked against the dynamic
state table. If the packet matches the next expected packet state table. If the packet matches the next expected packet
comprising an active session conversation, it exits the comprising an active session conversation, it exits the
firewall and the state of the session conversation flow is firewall and the state of the session conversation flow is
updated in the dynamic state table. Packets that do not updated in the dynamic state table. Packets that do not
belong to an already active session, are checked against the belong to an already active session are checked against the
outbound ruleset.</para> outbound ruleset. Packets coming in from the interface connected to the
<para>Packets coming in from the interface connected to the
public Internet are first checked against the dynamic state public Internet are first checked against the dynamic state
table. If the packet matches the next expected packet table. If the packet matches the next expected packet
comprising an active session, it exits the firewall and the comprising an active session, it exits the firewall and the
state of the session conversation flow is updated in the state of the session conversation flow is updated in the
dynamic state table. Packets that do not belong to an already dynamic state table. Packets that do not belong to an already
active session, are checked against the inbound active session are checked against the inbound
ruleset.</para> ruleset.</para>
<para>When the session completes, it is removed from the <para>Several keywords can be added after
dynamic state table.</para> <literal>keep state</literal>. If used, these keywords set
various options that control stateful filtering, such as
<para>Stateful filtering allows one to focus on blocking/passing setting connection limits or connection age. Refer to
new sessions. If the new session is passed, all its &man.ipf.5; for the list of available options and their
subsequent packets are allowed automatically and any impostor descriptions.</para>
packets are automatically rejected. If a new session is </listitem>
blocked, none of its subsequent packets are allowed. Stateful </varlistentry>
filtering provides advanced matching abilities capable of </variablelist>
defending against the flood of different attack methods
employed by attackers.</para>
</sect2> </sect2>
<sect2> <sect2>