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

White space fix only. Translators can ignore.

Browse source 
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne 2014-02-22 03:13:44 +00:00
parent be4fc36d5e
commit 984d8c3dbb
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=44025
1 changed files with 228 additions and 218 deletions

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

@ -156,28 +156,27 @@
<secondary>rulesets</secondary>
</indexterm>
<para>A ruleset contains a group of rules which pass or
block packets based on the values contained in the packet.
The bi-directional exchange of packets between hosts comprises
a session conversation. The firewall ruleset processes both
the packets arriving from the public Internet, as well as the
packets produced by the system as a response to them. Each
<acronym>TCP/IP</acronym> service is predefined by its
protocol and listening port. Packets destined for a specific
service originate from the source address using an
unprivileged port and target the specific service port on the
destination address. All the above parameters can be used as
selection criteria to create rules which will pass or block
services.</para>
<para>A ruleset contains a group of rules which pass or block
packets based on the values contained in the packet. The
bi-directional exchange of packets between hosts comprises a
session conversation. The firewall ruleset processes both the
packets arriving from the public Internet, as well as the
packets produced by the system as a response to them. Each
<acronym>TCP/IP</acronym> service is predefined by its protocol
and listening port. Packets destined for a specific service
originate from the source address using an unprivileged port and
target the specific service port on the destination address.
All the above parameters can be used as selection criteria to
create rules which will pass or block services.</para>
<para>To lookup unknown port numbers, refer to
<filename>/etc/services</filename>. Alternatively, visit <uri
xlink:href="http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers">http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers</uri>
and do a port number lookup to find the purpose of a
particular port number.</para>
<para>To lookup unknown port numbers, refer to
<filename>/etc/services</filename>. Alternatively, visit <uri
xlink:href="http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers">http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers</uri>
and do a port number lookup to find the purpose of a particular
port number.</para>
<para>Check out this link for port numbers used by Trojans <uri
xlink:href="http://www.sans.org/security-resources/idfaq/oddports.php">http://www.sans.org/security-resources/idfaq/oddports.php</uri>.</para>
<para>Check out this link for port numbers used by Trojans <uri
xlink:href="http://www.sans.org/security-resources/idfaq/oddports.php">http://www.sans.org/security-resources/idfaq/oddports.php</uri>.</para>
<para>A firewall ruleset can be either
<quote>exclusive</quote> or <quote>inclusive</quote>. An
@ -207,35 +206,34 @@
connections and only allows traffic which either matches an
existing connection or opens a new, allowed connection.</para>
<para>Stateful filtering treats traffic as a bi-directional
exchange of packets comprising a session. When state is specified on a matching rule
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>Stateful filtering treats traffic as a bi-directional
exchange of packets comprising a session. When state is
specified on a matching rule 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>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>
<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>
<para>When working with the firewall rules, be <emphasis>very
careful</emphasis>. Some configurations <emphasis>can
<warning>
<para>When working with the firewall rules, be <emphasis>very
careful</emphasis>. Some configurations <emphasis>can
lock the administrator out</emphasis> of the server. To be
on the safe side, consider performing the initial firewall
configuration from the local console rather than doing it
remotely over <application>ssh</application>.</para>
</warning>
on the safe side, consider performing the initial firewall
configuration from the local console rather than doing it
remotely over <application>ssh</application>.</para>
</warning>
</sect1>
<sect1 xml:id="firewalls-pf">
@ -1685,23 +1683,22 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<programlisting>&prompt.root; <userinput>service ipfilter start</userinput></programlisting>
<para>To load the firewall rules, specify the name of the ruleset file using <command>ipf</command>.
The following command can
be used to replace the currently running firewall
<para>To load the firewall rules, specify the name of the
ruleset file using <command>ipf</command>. The following
command can be used to replace the currently running firewall
rules:</para>
<screen>&prompt.root; <userinput>ipf -Fa -f /etc/ipf.rules</userinput></screen>
<para>where <option>-Fa</option> flushes all the internal rules
tables and <option>-f</option> specifies the file containing the
rules to load.</para>
tables and <option>-f</option> specifies the file containing
the rules to load.</para>
<para>This provides the ability to make changes to a custom
ruleset and update the
running firewall with a fresh copy of the rules without having
to reboot the system. This method is convenient for testing
new rules as the procedure can be executed as many times as
needed.</para>
ruleset and update the running firewall with a fresh copy of
the rules without having to reboot the system. This method is
convenient for testing new rules as the procedure can be
executed as many times as needed.</para>
<para>Refer to &man.ipf.8; for details on the other flags
available with this command.</para>
@ -1716,37 +1713,40 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<secondary>rule syntax</secondary>
</indexterm>
<para>This section describes the <application>IPF</application> rule syntax
used to create stateful rules. When creating rules, keep in
mind that unless the <literal>quick</literal> keyword appears
in a rule, every rule is read
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
that is a <literal>block</literal>, the packet will be dropped.
Sample rulesets can be found in
<filename class="directory">/usr/share/examples/ipfilter</filename>.</para>
<para>This section describes the <application>IPF</application>
rule syntax used to create stateful rules. When creating
rules, keep in mind that unless the <literal>quick</literal>
keyword appears in a rule, every rule is read 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 that is a <literal>block</literal>, the
packet will be dropped. 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
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>
<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 that rule's function, 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
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
keyword order is as follows, where the words shown in uppercase
represent a variable and the words shown in lowercase must
precede the variable that follows it:</para>
<para>The keywords which are used in rules must be written in a
specific 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 keyword order is as follows, where the
words shown in uppercase represent a variable and the words
shown in lowercase must precede the variable that follows
it:</para>
<para><replaceable>ACTION DIRECTION OPTIONS proto PROTO_TYPE
from SRC_ADDR SRC_PORT to DST_ADDR DST_PORT TCP_FLAG|ICMP_TYPE
keep state STATE</replaceable></para>
from SRC_ADDR SRC_PORT to DST_ADDR DST_PORT
TCP_FLAG|ICMP_TYPE keep state STATE</replaceable></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
<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>
@ -1755,15 +1755,16 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<term>ACTION</term>
<listitem>
<para>The action keyword indicates what to do with the
packet if it matches that rule. Every
rule <emphasis>must</emphasis> have an action. The
packet if it matches that rule. Every rule
<emphasis>must</emphasis> have an action. The
following actions are recognized:</para>
<para><literal>block</literal>: drops the packet.</para>
<para><literal>pass</literal>: allows the packet.</para>
<para><literal>log</literal>: generates a log record.</para>
<para><literal>log</literal>: generates a log
record.</para>
<para><literal>count</literal>: counts the number of
packets and bytes which can provide an indication of
@ -1777,62 +1778,60 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
allow more complex actions.</para>
<para><literal>decapsulate</literal>: removes any headers
in order to process the contents of the packet.</para>
in order to process the contents of the packet.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>DIRECTION</term>
<listitem>
<para>Next, each rule must
explicitly state the direction of traffic using one of
these keywords:</para>
<para>Next, each rule must explicitly state the direction
of traffic using one of these keywords:</para>
<para><literal>in</literal>: the rule is
applied against an inbound packet.</para>
<para><literal>in</literal>: the rule is applied against
an inbound packet.</para>
<para><literal>out</literal>: the rule is
applied against an outbound packet.</para>
<para><literal>out</literal>: the rule is applied against
an outbound packet.</para>
<para><literal>all</literal>: the rule applies to either
direction.</para>
<para>If the system has multiple interfaces, the interface
can be specified along with the direction. An example would
be <literal>in on fxp0</literal>.</para>
can be specified along with the direction. An example
would be <literal>in on fxp0</literal>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>OPTIONS</term>
<listitem>
<para>Options are optional. However, if multiple options
are specified, they must be used in the order shown
here.</para>
<para>Options are optional. However, if multiple options
are specified, they must be used in the order shown
here.</para>
<para><literal>log</literal>: when performing the
specified ACTION, the contents of the packet's
headers will be written to the &man.ipl.4; packet log
specified ACTION, the contents of the packet's headers
will be written to the &man.ipl.4; packet log
pseudo-device.</para>
<para><literal>quick</literal>: if
a packet matches this rule, the ACTION specified by the
rule occurs and no further processing of any
following rules will occur for this packet.</para>
<para><literal>quick</literal>: if a packet matches this
rule, the ACTION specified by the rule occurs and no
further processing of any following rules will occur for
this packet.</para>
<para><literal>on</literal>: must be followed by the interface name
as displayed by &man.ifconfig.8;.
The rule will only match if the
packet is going through the specified interface in the specified
direction.</para>
<para><literal>on</literal>: must be followed by the
interface name as displayed by &man.ifconfig.8;. The
rule will only match if the packet is going through the
specified interface in the specified direction.</para>
<para>When using the
<literal>log</literal> keyword, the following qualifiers
may be used in this order:</para>
<para><literal>body</literal>: indicates that the first 128
bytes of the packet contents will be logged after the
headers.</para>
<para><literal>body</literal>: indicates that the first
128 bytes of the packet contents will be logged after
the headers.</para>
<para><literal>first</literal>: if the
<literal>log</literal> keyword is being used in
@ -1841,8 +1840,9 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
packet is logged and not every packet which matches the
stateful connection.</para>
<para>Additional options are available to specify
error return messages. Refer to &man.ipf.5; for more details.</para>
<para>Additional options are available to specify error
return messages. Refer to &man.ipf.5; for more
details.</para>
</listitem>
</varlistentry>
@ -1850,7 +1850,7 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<varlistentry>
<term>PROTO_TYPE</term>
<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_PORT or
a DST_PORT as it defines the type of protocol. When
specifying the type of protocol, use the
@ -1858,10 +1858,10 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
protocol number or name from
<filename>/etc/protocols</filename>.
Example protocol names include <literal>tcp</literal>,
<literal>udp</literal>, or
<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>
<literal>udp</literal>, or <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>
</varlistentry>
@ -1870,17 +1870,19 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<listitem>
<para>The <literal>from</literal> keyword is mandatory and
is followed by a keyword which represents the source of
the packet. The source can be a hostname, an
the packet. The source can be a hostname, an
<acronym>IP</acronym> address followed by the
<acronym>CIDR</acronym> mask, an address pool, or the
keyword <literal>all</literal>. Refer to &man.ipf.5;
for examples.</para>
<para>There is no way to match ranges of <acronym>IP</acronym> addresses
which do not express themselves easily using the dotted
numeric form / mask-length notation. The
<package>net-mgmt/ipcalc</package> package or port may be used to
ease the calculation of the <acronym>CIDR</acronym> mask. Additional information is
<para>There is no way to match ranges of
<acronym>IP</acronym> addresses which do not express
themselves easily using the dotted numeric form /
mask-length notation. The
<package>net-mgmt/ipcalc</package> package or port may
be used to ease the calculation of the
<acronym>CIDR</acronym> mask. Additional information is
available at the utility's web page: <uri
xlink:href="http://jodies.de/ipcalc">http://jodies.de/ipcalc</uri>.</para>
</listitem>
@ -1890,24 +1892,24 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<term>SRC_PORT</term>
<listitem>
<para>The port number of the source is optional. However,
if it is used, it requires PROTO_TYPE to be first defined in
the rule. The port number must also be preceded by the
<literal>proto</literal> keyword.</para>
if it is used, it requires PROTO_TYPE to be first
defined in the rule. The port number must also be
preceded by the <literal>proto</literal> keyword.</para>
<para>A number of different comparison operators are supported:
<literal>=</literal> (equal to),
<literal>!=</literal> (not equal to),
<para>A number of different comparison operators are
supported: <literal>=</literal> (equal to),
<literal>!=</literal> (not equal to),
<literal>&lt;</literal> (less than),
<literal>&gt;</literal> (greater than),
<literal>&gt;</literal> (greater than),
<literal>&lt;=</literal> (less than or equal to), and
<literal>&gt;=</literal> (greater than or equal to).
</para>
<literal>&gt;=</literal> (greater than or equal
to).</para>
<para>To specify port ranges, place the two port numbers
between <literal>&lt;&gt;</literal> (less than and greater than ),
<literal>&gt;&lt;</literal> (greater than and less than ), or
<literal>:</literal> (greater than or equal to and
less than or equal to).</para>
between <literal>&lt;&gt;</literal> (less than and
greater than ), <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>
</varlistentry>
@ -1915,20 +1917,21 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<term>DST_ADDR</term>
<listitem>
<para>The <literal>to</literal> keyword is mandatory and
is followed by a keyword which represents the destination of
the packet. Similar to SRC_ADDR, it can be a hostname, an
<acronym>IP</acronym> address followed by the
<acronym>CIDR</acronym> mask, an address pool, or the
keyword <literal>all</literal>.</para>
is followed by a keyword which represents the
destination of the packet. Similar to SRC_ADDR, it can
be a hostname, an <acronym>IP</acronym> address
followed by the <acronym>CIDR</acronym> mask, an address
pool, or the keyword <literal>all</literal>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>DST_PORT</term>
<listitem>
<para>Similar to SRC_PORT, the port number of the destination is optional. However,
if it is used, it requires PROTO_TYPE to be first defined in
the rule. The port number must also be preceded by the
<para>Similar to SRC_PORT, the port number of the
destination is optional. However, if it is used, it
requires PROTO_TYPE to be first defined in the rule.
The port number must also be preceded by the
<literal>proto</literal> keyword.</para>
</listitem>
</varlistentry>
@ -1936,11 +1939,12 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<varlistentry>
<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),
<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),
@ -1949,9 +1953,10 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<literal>C</literal> (CWN), and
<literal>E</literal> (ECN).</para>
<para>If <literal>icmp</literal> is specifed as the PROTO_TYPE,
the <acronym>ICMP</acronym> type to match can be
specified. Refer to &man.ipf.5; for the allowable types.</para>
<para>If <literal>icmp</literal> is specifed as the
PROTO_TYPE, the <acronym>ICMP</acronym> type to match
can be specified. Refer to &man.ipf.5; for the
allowable types.</para>
</listitem>
</varlistentry>
@ -1959,39 +1964,42 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
<term>STATE</term>
<listitem>
<para>If a <literal>pass</literal> rule contains
<literal>keep state</literal>,
<application>IPF</application> will add an entry to its
dynamic state table and allow subsequent packets that
match the connection.
<application>IPF</application> can track state for
<acronym>TCP</acronym>, <acronym>UDP</acronym>, and
<acronym>ICMP</acronym> sessions. Any packet that <application>IPF</application> can be certain
is part of an active session, even if it is a different
protocol, will be allowed.</para>
<literal>keep state</literal>,
<application>IPF</application> will add an entry to its
dynamic state table and allow subsequent packets that
match the connection.
<application>IPF</application> can track state for
<acronym>TCP</acronym>, <acronym>UDP</acronym>, and
<acronym>ICMP</acronym> sessions. Any packet that
<application>IPF</application> can be certain is part of
an active session, even if it is a different protocol,
will be allowed.</para>
<para>In <application>IPF</application>, packets destined to go out through the interface connected
to the public Internet are first checked against the dynamic
state table. If the packet matches the next expected packet
comprising an active session conversation, it exits the
firewall and the state of the session conversation flow is
updated in the dynamic state table. Packets that do not
belong to an already active session are checked against the
outbound ruleset. Packets coming in from the interface connected to the
public Internet are first checked against the dynamic state
table. If the packet matches the next expected packet
comprising an active session, it exits the firewall and the
state of the session conversation flow is updated in the
dynamic state table. Packets that do not belong to an already
active session are checked against the inbound
ruleset.</para>
<para>In <application>IPF</application>, packets destined
to go out through the interface connected to the public
Internet are first checked against the dynamic state
table. If the packet matches the next expected packet
comprising an active session conversation, it exits the
firewall and the state of the session conversation flow
is updated in the dynamic state table. Packets that do
not belong to an already active session are checked
against the outbound ruleset. Packets coming in from
the interface connected to the public Internet are first
checked against the dynamic state table. If the packet
matches the next expected packet comprising an active
session, it exits the firewall and the state of the
session conversation flow is updated in the dynamic
state table. Packets that do not belong to an already
active session are checked against the inbound
ruleset.</para>
<para>Several keywords can be added after
<literal>keep state</literal>. If used, these keywords set
various options that control stateful filtering, such as
setting connection limits or connection age. Refer to
&man.ipf.5; for the list of available options and their
descriptions.</para>
</listitem>
<para>Several keywords can be added after
<literal>keep state</literal>. If used, these keywords
set various options that control stateful filtering,
such as setting connection limits or connection age.
Refer to &man.ipf.5; for the list of available options
and their descriptions.</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
@ -2003,47 +2011,51 @@ ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlist
which only allows services matching
<literal>pass</literal> rules and blocks all others.</para>
<para>&os; uses the loopback interface (<filename>lo0</filename>) and the <acronym>IP</acronym>
<para>&os; uses the loopback interface
(<filename>lo0</filename>) and the <acronym>IP</acronym>
address <systemitem class="ipaddress">127.0.0.1</systemitem>
for internal communication. The
firewall ruleset must contain rules to allow free movement of
these internally used packets:</para>
for internal communication. The firewall ruleset must contain
rules to allow free movement of these internally used
packets:</para>
<programlisting># no restrictions on loopback interface
pass in quick on lo0 all
pass out quick on lo0 all</programlisting>
<para>The public interface connected to the Internet is used to
authorize and control access of
all outbound and inbound connections. If one or more interfaces are cabled to private
authorize and control access of all outbound and inbound
connections. If one or more interfaces are cabled to private
networks, those internal interfaces may require rules to allow
packets originating from the <acronym>LAN</acronym> to flow between the internal networks
or to the interface attached to the Internet. The ruleset should be organized into three major
sections: any trusted internal interfaces, outbound connections through the public
interface, and inbound connections through the public interface.</para>
packets originating from the <acronym>LAN</acronym> to flow
between the internal networks or to the interface attached to
the Internet. The ruleset should be organized into three
major sections: any trusted internal interfaces, outbound
connections through the public interface, and inbound
connections through the public interface.</para>
<para>These two rules allow all traffic to pass through a trusted
<acronym>LAN</acronym> interface named <filename>xl0</filename>:</para>
<para>These two rules allow all traffic to pass through a
trusted <acronym>LAN</acronym> interface named
<filename>xl0</filename>:</para>
<programlisting># no restrictions on inside LAN interface for private network
pass out quick on xl0 all
pass in quick on xl0 all</programlisting>
<para>The rules for the public interface's outbound and inbound sections should
have the most frequently matched rules placed before less
commonly matched rules, with the last rule in the section
blocking and logging all packets for that interface and
direction.</para>
<para>The rules for the public interface's outbound and inbound
sections should have the most frequently matched rules placed
before less commonly matched rules, with the last rule in the
section blocking and logging all packets for that interface
and direction.</para>
<para>This set of rules defines the outbound section of the
public interface named <filename>dc0</filename>.
These rules keep state and identify
the specific services that internal systems are authorized for public Internet access.
All the rules use <literal>quick</literal> and specify the
public interface named <filename>dc0</filename>. These rules
keep state and identify the specific services that internal
systems are authorized for public Internet access. All the
rules use <literal>quick</literal> and specify the
appropriate port numbers and, where applicable, destination
addresses.</para>
<programlisting># interface facing Internet (outbound)
<programlisting># interface facing Internet (outbound)
# Matches session start requests originating from or behind the
# firewall, destined for the Internet.
@ -2082,11 +2094,11 @@ pass out quick on dc0 proto icmp from any to any icmp-type 8 keep state
# Block and log everything else
block out log first quick on dc0 all</programlisting>
<para>This example of the rules in the inbound section of the
public interface blocks all undesirable packets first.
This reduces the number of packets that are
logged by the last rule.</para>
public interface blocks all undesirable packets first. This
reduces the number of packets that are logged by the last
rule.</para>
<programlisting># interface facing Internet (inbound)
# Block all inbound traffic from non-routable or reserved address spaces
@ -2126,18 +2138,16 @@ block in log first quick on dc0 proto tcp/udp from any to any port = 81</program
<para>Any time there are logged messages on a rule with
the <literal>log first</literal> option, run
<command>ipfstat -hio</command>
to evaluate how many times the rule has been matched. A
large number of matches may indicate that the system is
under attack.</para>
<command>ipfstat -hio</command> to evaluate how many times the
rule has been matched. A large number of matches may indicate
that the system is under attack.</para>
<para>The rest of the rules in the inbound section define which
connections are allowed to be initiated from the Internet.
The last rule denies all connections which were not explicitly
allowed by previous rules in this section.</para>
<programlisting>
# Allow traffic in from ISP's DHCP server. Replace z.z.z.z with
<programlisting># Allow traffic in from ISP's DHCP server. Replace z.z.z.z with
# the same IP address used in the outbound section.
pass in quick on dc0 proto udp from z.z.z.z to any port = 68 keep state