svn commit: r44025 - head/en_US.ISO8859-1/books/handbook/firewalls
Dru Lavigne
dru at FreeBSD.org
Sat Feb 22 03:13:44 UTC 2014
Author: dru
Date: Sat Feb 22 03:13:44 2014
New Revision: 44025
URL: http://svnweb.freebsd.org/changeset/doc/44025
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 Sat Feb 22 02:43:03 2014 (r44024)
+++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Sat Feb 22 03:13:44 2014 (r44025)
@@ -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>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>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>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>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 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>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" # rule
<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" # rule
<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>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>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>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" # rule
<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" # rule
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>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>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>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" # rule
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" # rule
<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" # rule
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" # rule
<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" # rule
<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>
-
- <para>A number of different comparison operators are supported:
- <literal>=</literal> (equal to),
- <literal>!=</literal> (not equal to),
+ 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),
<literal><</literal> (less than),
- <literal>></literal> (greater than),
+ <literal>></literal> (greater than),
<literal><=</literal> (less than or equal to), and
- <literal>>=</literal> (greater than or equal to).
- </para>
+ <literal>>=</literal> (greater than or equal
+ to).</para>
<para>To specify port ranges, place the two port numbers
- between <literal><></literal> (less than and greater than ),
- <literal>><</literal> (greater than and less than ), or
- <literal>:</literal> (greater than or equal to and
- less than or equal to).</para>
+ between <literal><></literal> (less than and
+ greater than ), <literal>><</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" # rule
<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" # rule
<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" # rule
<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" # rule
<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>
-
- <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>
+ <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>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" # rule
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>
-
- <para>These two rules allow all traffic to pass through a trusted
- <acronym>LAN</acronym> interface named <filename>xl0</filename>:</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>
<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 an
# 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 tc
<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
More information about the svn-doc-all
mailing list