svn commit: r43988 - head/en_US.ISO8859-1/books/handbook/firewalls
Dru Lavigne
dru at FreeBSD.org
Tue Feb 18 22:23:52 UTC 2014
Author: dru
Date: Tue Feb 18 22:23:51 2014
New Revision: 43988
URL: http://svnweb.freebsd.org/changeset/doc/43988
Log:
White space fix only. Translators can ignore.
Sponsored by: iXsystems
Modified:
head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 18 21:30:19 2014 (r43987)
+++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 18 22:23:51 2014 (r43988)
@@ -143,7 +143,7 @@
in a normal session conversation. For a good introduction,
refer to <link
xlink:href="http://www.ipprimer.com/overview.cfm">Daryl's
- TCP/IP Primer</link>.</para>
+ TCP/IP Primer</link>.</para>
</note>
</sect1>
@@ -628,15 +628,16 @@ pass proto udp to any port $udp_services
<title>A Simple Gateway with NAT</title>
<para>This section demonstrates how to configure a &os; system
- running <application>PF</application> to act
- as a gateway for at least one other machine. The gateway
- needs at least two network interfaces, each connected to a
- separate network. In this example, <filename>xl1</filename> is connected to the
- Internet and <filename>xl0</filename> is connected to the internal network.</para>
-
- <para>First, enable the gateway in order to let the
- machine forward the network traffic it receives on one
- interface to another interface. This <application>sysctl</application>
+ running <application>PF</application> to act as a gateway
+ for at least one other machine. The gateway needs at least
+ two network interfaces, each connected to a separate
+ network. In this example, <filename>xl1</filename> is
+ connected to the Internet and <filename>xl0</filename> is
+ connected to the internal network.</para>
+
+ <para>First, enable the gateway in order to let the machine
+ forward the network traffic it receives on one interface to
+ another interface. This <application>sysctl</application>
setting will forward <acronym>IPv4</acronym> packets:</para>
<screen>&prompt.root; <userinput>sysctl net.inet.ip.forwarding=1</userinput></screen>
@@ -645,74 +646,71 @@ pass proto udp to any port $udp_services
<screen>&prompt.root; <userinput>sysctl net.inet6.ip6.forwarding=1</userinput></screen>
- <para>To enable these settings at system boot, add the following
- to
- <filename>/etc/rc.conf</filename>:</para>
+ <para>To enable these settings at system boot, add the
+ following to <filename>/etc/rc.conf</filename>:</para>
<programlisting>gateway_enable="YES" #for ipv4
ipv6_gateway_enable="YES" #for ipv6</programlisting>
- <para>Verify with <command>ifconfig</command> that
- both of the interfaces are up and
- running.</para>
+ <para>Verify with <command>ifconfig</command> that both of the
+ interfaces are up and running.</para>
<para>Next, create the <application>PF</application> rules to
- allow the gateway to pass traffic. While the following rule allows stateful traffic to
- pass from the Internet
- to hosts on the network, the <literal>to</literal> keyword does not
- guarantee passage all the way from source to destination:</para>
+ allow the gateway to pass traffic. While the following rule
+ allows stateful traffic to pass from the Internet to hosts
+ on the network, the <literal>to</literal> keyword does not
+ guarantee passage all the way from source to
+ destination:</para>
<programlisting>pass in on xl1 from xl1:network to xl0:network port $ports keep state</programlisting>
- <para>That rule only lets the traffic pass in to the gateway on
- the internal interface. To let the packets go further, a
+ <para>That rule only lets the traffic pass in to the gateway
+ on the internal interface. To let the packets go further, a
matching rule is needed:</para>
<programlisting>pass out on xl0 from xl1:network to xl0:network port $ports keep state</programlisting>
<para>While these two rules will work, rules this specific are
- rarely needed. For a busy network admin, a readable ruleset is a safer
- ruleset. The remainder of this section demonstrates how to
- keep the rules as simple as possible
- for readability. For example, those two rules could be
+ rarely needed. For a busy network admin, a readable ruleset
+ is a safer ruleset. The remainder of this section
+ demonstrates how to keep the rules as simple as possible for
+ readability. For example, those two rules could be
replaced with one rule:</para>
<programlisting>pass from xl1:network to any port $ports keep state</programlisting>
- <para>The
- <literal>interface:network</literal> notation can be
- replaced with a macro to make the ruleset even
- more readable. For example, a <literal>$localnet</literal> macro could
- be defined as the network directly attached to the
+ <para>The <literal>interface:network</literal> notation can be
+ replaced with a macro to make the ruleset even more
+ readable. For example, a <literal>$localnet</literal> macro
+ could be defined as the network directly attached to the
internal interface (<literal>$xl1:network</literal>).
Alternatively, the definition of
<literal>$localnet</literal> could be changed to an
<emphasis>IP address/netmask</emphasis> notation to denote
- a network, such as <literal>192.168.100.1/24</literal> for
- a subnet of private addresses.</para>
+ a network, such as <literal>192.168.100.1/24</literal> for a
+ subnet of private addresses.</para>
<para>If required, <literal>$localnet</literal> could even be
defined as a list of networks. Whatever the specific needs,
a sensible <literal>$localnet</literal> definition could be
- used in a
- typical pass rule as follows:</para>
+ used in a typical pass rule as follows:</para>
<programlisting>pass from $localnet to any port $ports keep state</programlisting>
- <para>The following sample ruleset allows all traffic initiated by
- machines on the internal network. It first defines two
- macros to represent the external and internal 3COM interfaces of
- the gateway.</para>
-
- <note>
- <para>For dialup users, the external interface will use
- <filename>tun0</filename>. For an
- <acronym>ADSL</acronym> connection, specifically those
- using <acronym>PPP</acronym> over Ethernet (<acronym>PPPoE</acronym>), the correct external
- interface is <filename>tun0</filename>,
- not the physical Ethernet
- interface.</para>
- </note>
+ <para>The following sample ruleset allows all traffic
+ initiated by machines on the internal network. It first
+ defines two macros to represent the external and internal
+ 3COM interfaces of the gateway.</para>
+
+ <note>
+ <para>For dialup users, the external interface will use
+ <filename>tun0</filename>. For an
+ <acronym>ADSL</acronym> connection, specifically those
+ using <acronym>PPP</acronym> over Ethernet
+ (<acronym>PPPoE</acronym>), the correct external
+ interface is <filename>tun0</filename>, not the physical
+ Ethernet interface.</para>
+ </note>
<programlisting>ext_if = "xl0" # macro for external interface - use tun0 for PPPoE
int_if = "xl1" # macro for internal interface
@@ -722,20 +720,20 @@ nat on $ext_if from $localnet to any -&g
block all
pass from { lo0, $localnet } to any keep state</programlisting>
- <para>This ruleset introduces the <literal>nat</literal> rule which is used to
- handle the network address translation from the
- non-routable addresses inside the internal network to the <acronym>IP</acronym> address
- assigned to the external interface. The parentheses surrounding the last part of the nat
- rule <literal>($ext_if)</literal> is included
- when the <acronym>IP</acronym> address of the external
- interface is dynamically assigned. It
- ensures that network traffic runs without serious
- interruptions even if the external <acronym>IP</acronym> address
- changes.</para>
-
- <para>Note that this ruleset probably allows more
- traffic to pass out of the network than is needed.
- One reasonable setup could create this macro:</para>
+ <para>This ruleset introduces the <literal>nat</literal> rule
+ which is used to handle the network address translation from
+ the non-routable addresses inside the internal network to
+ the <acronym>IP</acronym> address assigned to the external
+ interface. The parentheses surrounding the last part of the
+ nat rule <literal>($ext_if)</literal> is included when the
+ <acronym>IP</acronym> address of the external interface is
+ dynamically assigned. It ensures that network traffic runs
+ without serious interruptions even if the external
+ <acronym>IP</acronym> address changes.</para>
+
+ <para>Note that this ruleset probably allows more traffic to
+ pass out of the network than is needed. One reasonable
+ setup could create this macro:</para>
<programlisting>client_out = "{ ftp-data, ftp, ssh, domain, pop3, auth, nntp, http, \
https, cvspserver, 2628, 5999, 8000, 8080 }"</programlisting>
@@ -751,27 +749,24 @@ pass from { lo0, $localnet } to any keep
<programlisting>pass in inet proto tcp to $ext_if port ssh</programlisting>
<para>This macro definition and rule allows
- <acronym>DNS</acronym> and <acronym>NTP</acronym> for internal
- clients:</para>
+ <acronym>DNS</acronym> and <acronym>NTP</acronym> for
+ internal clients:</para>
<programlisting>udp_services = "{ domain, ntp }"
pass quick inet proto { tcp, udp } to any port $udp_services keep state</programlisting>
- <para>Note the <literal>quick</literal> keyword in this
- rule. Since the ruleset consists of
- several rules, it is important to understand the
- relationships between the rules in a ruleset. Rules
- are evaluated from top to bottom, in the sequence they are
- written. For each packet or
- connection evaluated by <application>PF</application>,
+ <para>Note the <literal>quick</literal> keyword in this rule.
+ Since the ruleset consists of several rules, it is important
+ to understand the relationships between the rules in a
+ ruleset. Rules are evaluated from top to bottom, in the
+ sequence they are written. For each packet or connection
+ evaluated by <application>PF</application>,
<emphasis>the last matching rule</emphasis> in the ruleset
- is the one which is applied. However,
- when a packet matches a rule which
- contains the <literal>quick</literal> keyword,
- the rule processing stops and the packet is treated
- according to that rule. This is very
- useful when an exception to the general rules
- is needed.</para>
+ is the one which is applied. However, when a packet matches
+ a rule which contains the <literal>quick</literal> keyword,
+ the rule processing stops and the packet is treated
+ according to that rule. This is very useful when an
+ exception to the general rules is needed.</para>
</sect3>
<sect3 xml:id="pftut-ftp">
@@ -781,7 +776,8 @@ pass quick inet proto { tcp, udp } to an
problematic due to the nature of the <acronym>FTP</acronym>
protocol. <acronym>FTP</acronym> pre-dates firewalls by
several decades and is insecure in its design. The most
- common points against using <acronym>FTP</acronym> include:</para>
+ common points against using <acronym>FTP</acronym>
+ include:</para>
<itemizedlist>
<listitem>
@@ -800,52 +796,49 @@ pass quick inet proto { tcp, udp } to an
</listitem>
</itemizedlist>
- <para>All of these points present security challenges,
- even before considering any potential security weaknesses in client
- or server software. More
- secure alternatives for file transfer exist, such as &man.sftp.1;
- or &man.scp.1;, which both feature authentication and data
- transfer over encrypted connections..</para>
+ <para>All of these points present security challenges, even
+ before considering any potential security weaknesses in
+ client or server software. More secure alternatives for
+ file transfer exist, such as &man.sftp.1; or &man.scp.1;,
+ which both feature authentication and data transfer over
+ encrypted connections..</para>
<para>For those situations when <acronym>FTP</acronym> is
required, <application>PF</application> provides
redirection of <acronym>FTP</acronym> traffic to a small
- proxy program called
- &man.ftp-proxy.8;, which is included in the base system of &os;.
- The role of
- the proxy is to dynamically insert and delete rules in the ruleset, using
- a set of anchors, in order to correctly handle
+ proxy program called &man.ftp-proxy.8;, which is included in
+ the base system of &os;. The role of the proxy is to
+ dynamically insert and delete rules in the ruleset, using a
+ set of anchors, in order to correctly handle
<acronym>FTP</acronym> traffic.</para>
- <para>To enable the <acronym>FTP</acronym> proxy, add this line to
- <filename>/etc/rc.conf</filename>:</para>
+ <para>To enable the <acronym>FTP</acronym> proxy, add this
+ line to <filename>/etc/rc.conf</filename>:</para>
<programlisting>ftpproxy_enable="YES"</programlisting>
- <para>Then start the proxy by running
- <command>service ftp-proxy start</command>.</para>
+ <para>Then start the proxy by running <command>service
+ ftp-proxy start</command>.</para>
- <para>For a basic configuration, three elements need to
- be added to <filename>/etc/pf.conf</filename>. First, the
- anchors which the proxy will use to insert the rules it generates for the
- <acronym>FTP</acronym> sessions:</para>
+ <para>For a basic configuration, three elements need to be
+ added to <filename>/etc/pf.conf</filename>. First, the
+ anchors which the proxy will use to insert the rules it
+ generates for the <acronym>FTP</acronym> sessions:</para>
<programlisting>nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"</programlisting>
- <para>Second, a pass rule is
- needed to allow <acronym>FTP</acronym> traffic in to the
- proxy.</para>
+ <para>Second, a pass rule is needed to allow
+ <acronym>FTP</acronym> traffic in to the proxy.</para>
<para>Third, redirection and <acronym>NAT</acronym> rules need
- to be defined before the
- filtering rules. Insert this <literal>rdr</literal> rule immediately
- after the <literal>nat</literal> rule:</para>
+ to be defined before the filtering rules. Insert this
+ <literal>rdr</literal> rule immediately after the
+ <literal>nat</literal> rule:</para>
<programlisting>rdr pass on $int_if proto tcp from any to any port ftp -> 127.0.0.1 port 8021</programlisting>
- <para>Finally, allow the redirected traffic to
- pass:</para>
+ <para>Finally, allow the redirected traffic to pass:</para>
<programlisting>pass out proto tcp from $proxy to any port ftp</programlisting>
@@ -882,78 +875,74 @@ rdr-anchor "ftp-proxy/*"</programlisting
<sect3 xml:id="pftut-icmp">
<title>Managing <acronym>ICMP</acronym></title>
- <para>Many of the tools used for debugging or
- troubleshooting a <acronym>TCP/IP</acronym> network rely on the
- Internet Control Message Protocol (<acronym>ICMP</acronym>), which
+ <para>Many of the tools used for debugging or troubleshooting
+ a <acronym>TCP/IP</acronym> network rely on the Internet
+ Control Message Protocol (<acronym>ICMP</acronym>), which
was designed specifically with debugging in mind.</para>
- <para>The <acronym>ICMP</acronym> protocol sends and
- receives <emphasis>control messages</emphasis> between
- hosts and gateways, mainly to provide feedback to a sender
- about any unusual or difficult conditions enroute to the
- target host.
+ <para>The <acronym>ICMP</acronym> protocol sends and receives
+ <emphasis>control messages</emphasis> between hosts and
+ gateways, mainly to provide feedback to a sender about any
+ unusual or difficult conditions enroute to the target host.
Routers use <acronym>ICMP</acronym> to negotiate packet
sizes and other transmission parameters in a process often
referred to as <emphasis>path <acronym>MTU</acronym>
discovery</emphasis>.</para>
- <para>From a firewall perspective, some <acronym>ICMP</acronym>
- control messages are vulnerable to known attack vectors.
- Also, letting all diagnostic traffic pass unconditionally
- makes debugging easier, but it also makes it
- easier for others to extract information about
- the network. For these reasons, the following rule may not be
+ <para>From a firewall perspective, some
+ <acronym>ICMP</acronym> control messages are vulnerable to
+ known attack vectors. Also, letting all diagnostic traffic
+ pass unconditionally makes debugging easier, but it also
+ makes it easier for others to extract information about the
+ network. For these reasons, the following rule may not be
optimal:</para>
<programlisting>pass inet proto icmp from any to any</programlisting>
- <para>One solution is to let all
- <acronym>ICMP</acronym> traffic from the local network through
- while stopping all probes from outside the network:</para>
+ <para>One solution is to let all <acronym>ICMP</acronym>
+ traffic from the local network through while stopping all
+ probes from outside the network:</para>
<programlisting>pass inet proto icmp from $localnet to any keep state
pass inet proto icmp from any to $ext_if keep state</programlisting>
- <para>Additional
- options are available which demonstrate some of
- <application>PF</application>'s flexibility. For example,
- rather than allowing all <acronym>ICMP</acronym> messages,
- one can specify the messages used by &man.ping.8; and
- &man.traceroute.8;. Start by defining a macro for
- that type of message:</para>
-
- <programlisting>icmp_types = "echoreq"</programlisting>
-
- <para>and a rule which uses the macro:</para>
-
- <programlisting>pass inet proto icmp all icmp-type $icmp_types keep state</programlisting>
-
- <para>If other types of <acronym>ICMP</acronym> packets
- are needed, expand <literal>icmp_types</literal>
- to a list of those packet types. Type
- <command>more /usr/src/contrib/pf/pfctl/pfctl_parser.c</command>
- to see the list of <acronym>ICMP</acronym> message
- types supported by <application>PF</application>. Refer to
- <link
+ <para>Additional options are available which demonstrate some
+ of <application>PF</application>'s flexibility. For
+ example, rather than allowing all <acronym>ICMP</acronym>
+ messages, one can specify the messages used by &man.ping.8;
+ and &man.traceroute.8;. Start by defining a macro for that
+ type of message:</para>
+
+ <programlisting>icmp_types = "echoreq"</programlisting>
+
+ <para>and a rule which uses the macro:</para>
+
+ <programlisting>pass inet proto icmp all icmp-type $icmp_types keep state</programlisting>
+
+ <para>If other types of <acronym>ICMP</acronym> packets are
+ needed, expand <literal>icmp_types</literal> to a list of
+ those packet types. Type <command>more
+ /usr/src/contrib/pf/pfctl/pfctl_parser.c</command> to see
+ the list of <acronym>ICMP</acronym> message types supported
+ by <application>PF</application>. Refer to <link
xlink:href="http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml">http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml</link>
- for an explanation of each message type.</para>
+ for an explanation of each message type.</para>
- <para>Since Unix <command>traceroute</command> uses <acronym>UDP</acronym>
- by default, another rule is needed to allow Unix
- <command>traceroute</command>:</para>
+ <para>Since Unix <command>traceroute</command> uses
+ <acronym>UDP</acronym> by default, another rule is needed to
+ allow Unix <command>traceroute</command>:</para>
- <programlisting># allow out the default range for traceroute(8):
+ <programlisting># allow out the default range for traceroute(8):
pass out on $ext_if inet proto udp from any to any port 33433 >< 33626 keep state</programlisting>
- <para>Since <command>TRACERT.EXE</command> on Microsoft Windows systems
- uses <acronym>ICMP</acronym> echo request messages,
- only the
- first rule is needed to allow network traces from those systems. Unix <command>traceroute</command>
- can be instructed to use other protocols as well, and will
- use <acronym>ICMP</acronym> echo request messages if
- <option>-I</option> is used. Check the &man.traceroute.8;
- man page for
- details.</para>
+ <para>Since <command>TRACERT.EXE</command> on Microsoft
+ Windows systems uses <acronym>ICMP</acronym> echo request
+ messages, only the first rule is needed to allow network
+ traces from those systems. Unix
+ <command>traceroute</command> can be instructed to use other
+ protocols as well, and will use <acronym>ICMP</acronym> echo
+ request messages if <option>-I</option> is used. Check the
+ &man.traceroute.8; man page for details.</para>
<sect4 xml:id="pftut-pathmtudisc">
<title>Path <acronym>MTU</acronym> Discovery</title>
@@ -962,66 +951,62 @@ pass out on $ext_if inet proto udp from
independent, and one consequence of device independence is
that the optimal packet size for a given connection cannot
always be predicted reliably. The main constraint on
- packet size is the
- <firstterm>Maximum Transmission Unit</firstterm>
- (<acronym>MTU</acronym>) which sets the upper limit on the
- packet size for an interface. Type <command>ifconfig</command> to view the
- <acronym>MTU</acronym>s for a system's network interfaces.</para>
-
- <para><acronym>TCP/IP</acronym> uses a process known as path
- <acronym>MTU</acronym> discovery to
- determine the right packet size for a connection. This
- process sends packets of
- varying sizes with the <quote>Do not fragment</quote> flag
- set, expecting an <acronym>ICMP</acronym> return packet
- of <quote>type 3, code 4</quote> when the upper
+ packet size is the <firstterm>Maximum Transmission
+ Unit</firstterm> (<acronym>MTU</acronym>) which sets the
+ upper limit on the packet size for an interface. Type
+ <command>ifconfig</command> to view the
+ <acronym>MTU</acronym>s for a system's network
+ interfaces.</para>
+
+ <para><acronym>TCP/IP</acronym> uses a process known as path
+ <acronym>MTU</acronym> discovery to determine the right
+ packet size for a connection. This process sends packets
+ of varying sizes with the <quote>Do not fragment</quote>
+ flag set, expecting an <acronym>ICMP</acronym> return
+ packet of <quote>type 3, code 4</quote> when the upper
limit has been reached. Type 3 means <quote>destination
unreachable</quote>, and code 4 is short for
<quote>fragmentation needed, but the do-not-fragment flag
is set</quote>. To allow path MTU discovery in order
- to support connections to other <acronym>MTU</acronym>s, add
- the
- <literal>destination unreachable</literal> type to the
- <literal>icmp_types</literal> macro:</para>
+ to support connections to other <acronym>MTU</acronym>s,
+ add the <literal>destination unreachable</literal> type to
+ the <literal>icmp_types</literal> macro:</para>
<programlisting>icmp_types = "{ echoreq, unreach }"</programlisting>
- <para>Since
- the pass rule already uses that macro, it does not need to
- be modified in order to support the new
+ <para>Since the pass rule already uses that macro, it does
+ not need to be modified in order to support the new
<acronym>ICMP</acronym> type:</para>
<programlisting>pass inet proto icmp all icmp-type $icmp_types keep state</programlisting>
<para><application>PF</application> allows filtering on all
variations of <acronym>ICMP</acronym> types and codes.
- The list of possible
- types and codes are documented in &man.icmp.4; and
- &man.icmp6.4;.</para>
+ The list of possible types and codes are documented in
+ &man.icmp.4; and &man.icmp6.4;.</para>
</sect4>
</sect3>
<sect3 xml:id="pftut-tables">
<title>Using Tables</title>
- <para>Some types of data
- are relevant to filtering and redirection at a given time,
- but their definition is too long to be included in the ruleset file.
+ <para>Some types of data are relevant to filtering and
+ redirection at a given time, but their definition is too
+ long to be included in the ruleset file.
<application>PF</application> supports the use of tables,
- which are defined lists that can be
- manipulated without needing to reload the entire ruleset,
- and which can provide fast lookups. Table names are
- always enclosed within <literal>< ></literal>, like
- this:</para>
+ which are defined lists that can be manipulated without
+ needing to reload the entire ruleset, and which can provide
+ fast lookups. Table names are always enclosed within
+ <literal>< ></literal>, like this:</para>
<programlisting>table <clients> { 192.168.2.0/24, !192.168.2.5 }</programlisting>
- <para>In this example, the <literal>192.168.2.0/24</literal> network
- is part of the table, except for the address
- <literal>192.168.2.5</literal>, which is excluded using
- the <literal>!</literal> operator. It is
- also possible to load tables from files where each item is
- on a separate line, as seen in this example
+ <para>In this example, the <literal>192.168.2.0/24</literal>
+ network is part of the table, except for the address
+ <literal>192.168.2.5</literal>, which is excluded using the
+ <literal>!</literal> operator. It is also possible to load
+ tables from files where each item is on a separate line, as
+ seen in this example
<filename>/etc/clients</filename>:</para>
<programlisting>192.168.2.0/24
@@ -1036,33 +1021,34 @@ pass out on $ext_if inet proto udp from
<programlisting>pass inet proto tcp from <clients> to any port $client_out flags S/SA keep state</programlisting>
- <para>A table's contents can be manipulated live, using <command>pfctl</command>.
- This example adds another network to the table:</para>
+ <para>A table's contents can be manipulated live, using
+ <command>pfctl</command>. This example adds another network
+ to the table:</para>
<screen>&prompt.root; <userinput>pfctl -t clients -T add 192.168.1.0/16</userinput></screen>
- <para>Note that any changes made this way will take affect now,
- making them ideal for testing,
- but will not survive a power
- failure or reboot. To make the changes permanent, modify the
- definition of the table in the ruleset or edit the file that the
- table refers to. One can maintain the on-disk copy of the table
- using a &man.cron.8; job which dumps the table's contents to
- disk at regular intervals, using a command such as
- <command>pfctl -t clients -T show
+ <para>Note that any changes made this way will take affect
+ now, making them ideal for testing, but will not survive a
+ power failure or reboot. To make the changes permanent,
+ modify the definition of the table in the ruleset or edit
+ the file that the table refers to. One can maintain the
+ on-disk copy of the table using a &man.cron.8; job which
+ dumps the table's contents to disk at regular intervals,
+ using a command such as <command>pfctl -t clients -T show
>/etc/clients</command>. Alternatively,
- <filename>/etc/clients</filename> can be updated with
- the in-memory table contents:</para>
+ <filename>/etc/clients</filename> can be updated with the
+ in-memory table contents:</para>
<screen>&prompt.root; <userinput>pfctl -t clients -T replace -f /etc/clients</userinput></screen>
</sect3>
<sect3 xml:id="pftut-overload">
- <title>Using Overload Tables to Protect <acronym>SSH</acronym></title>
+ <title>Using Overload Tables to Protect
+ <acronym>SSH</acronym></title>
- <para>Those who run <acronym>SSH</acronym> on an external interface
- have probably seen something
- like this in the authentication logs:</para>
+ <para>Those who run <acronym>SSH</acronym> on an external
+ interface have probably seen something like this in the
+ authentication logs:</para>
<programlisting>Sep 26 03:12:34 skapet sshd[25771]: Failed password for root from 200.72.41.31 port 40992 ssh2
Sep 26 03:12:34 skapet sshd[5279]: Failed password for root from 200.72.41.31 port 40992 ssh2
@@ -1072,29 +1058,26 @@ Sep 26 03:12:44 skapet sshd[24703]: inpu
Sep 26 03:12:44 skapet sshd[24703]: Failed password for invalid user admin from 200.72.41.31 port 41484 ssh2</programlisting>
<para>This is indicative of a brute force attack where
- somebody or some program
- is trying to discover the
- user name and password which will let them
- into the system.</para>
+ somebody or some program is trying to discover the user name
+ and password which will let them into the system.</para>
<para>If external <acronym>SSH</acronym> access is needed for
legitimate users, changing the default port used by
- <acronym>SSH</acronym> can offer some protection.
- However, <application>PF</application> provides a more
- elegant solution. Pass rules can contain
- limits on what connecting hosts can do and
- violators can be banished to a table of
- addresses which are denied some or all access. It
- is even possible to drop all existing connections from
- machines which overreach the limits.</para>
+ <acronym>SSH</acronym> can offer some protection. However,
+ <application>PF</application> provides a more elegant
+ solution. Pass rules can contain limits on what connecting
+ hosts can do and violators can be banished to a table of
+ addresses which are denied some or all access. It is even
+ possible to drop all existing connections from machines
+ which overreach the limits.</para>
- <para>To configure this, create this table in the tables section
- of the ruleset:</para>
+ <para>To configure this, create this table in the tables
+ section of the ruleset:</para>
<programlisting>table <bruteforce> persist</programlisting>
- <para>Then, somewhere early in the ruleset, add rules
- to block brute access while allowing legitimate access:</para>
+ <para>Then, somewhere early in the ruleset, add rules to block
+ brute access while allowing legitimate access:</para>
<programlisting>block quick from <bruteforce>
pass inet proto tcp from any to $localnet port $tcp_services \
@@ -1110,18 +1093,20 @@ pass inet proto tcp from any to $localne
simultaneous connections allowed from one host.</para>
<para><literal>max-src-conn-rate</literal> is the rate of new
- connections allowed from any single host (<replaceable>15</replaceable>)
- per number of seconds (<replaceable>5</replaceable>).</para>
+ connections allowed from any single host
+ (<replaceable>15</replaceable>) per number of seconds
+ (<replaceable>5</replaceable>).</para>
<para><literal>overload <bruteforce></literal> means
that any host which exceeds these limits gets its address
- added to the <literal>bruteforce</literal> table. The ruleset
- blocks all traffic from addresses in the <literal>bruteforce</literal>
- table.</para>
+ added to the <literal>bruteforce</literal> table. The
+ ruleset blocks all traffic from addresses in the
+ <literal>bruteforce</literal> table.</para>
<para>Finally, <literal>flush global</literal> says that when
- a host reaches the limit, that all (<literal>global</literal>) of that host's connections will be
- terminated (<literal>flush</literal>).</para>
+ a host reaches the limit, that all
+ (<literal>global</literal>) of that host's connections will
+ be terminated (<literal>flush</literal>).</para>
<note>
<para>These rules will <emphasis>not</emphasis> block slow
@@ -1129,10 +1114,10 @@ pass inet proto tcp from any to $localne
xlink:href="http://home.nuug.no/~peter/hailmary2013/">http://home.nuug.no/~peter/hailmary2013/</link>.</para>
</note>
- <para>This example ruleset
- is intended mainly as an illustration. For example, if a generous number of connections in
- general are wanted, but the desire is to be more
- restrictive when it comes to
+ <para>This example ruleset is intended mainly as an
+ illustration. For example, if a generous number of
+ connections in general are wanted, but the desire is to be
+ more restrictive when it comes to
<application>ssh</application>, supplement the rule above
with something like the one below, early on in the rule
set:</para>
@@ -1146,481 +1131,474 @@ pass inet proto tcp from any to $localne
<title>It May Not be Necessary to Block All
Overloaders</title>
- <para>It is worth noting that the
- overload mechanism is a general
- technique which does not apply exclusively to
- <acronym>SSH</acronym>, and it is not always
- optimal to entirely block all traffic from offenders.</para>
+ <para>It is worth noting that the overload mechanism is a
+ general technique which does not apply exclusively to
+ <acronym>SSH</acronym>, and it is not always optimal to
+ entirely block all traffic from offenders.</para>
<para>For example, an overload rule could be used to
protect a mail service or a web service, and the overload
table could be used in a rule to assign offenders to a
- queue with a minimal bandwidth allocation or
- to redirect to a specific web page.</para>
+ queue with a minimal bandwidth allocation or to redirect
+ to a specific web page.</para>
</note>
- <para>Over time, tables will be filled by
- overload rules and their size
- will grow incrementally, taking up more memory.
- Sometimes an <acronym>IP</acronym> address that is blocked
- is a dynamically assigned
- one, which has since been assigned to a host who
- has a legitimate reason to communicate with hosts in
- the local network.</para>
-
- <para>For situations like these,
- <application>pfctl</application> provides the ability to
- expire table entries. For example, this
- command will remove <literal><bruteforce></literal>
- table entries which have not been referenced for <literal>86400</literal>
- seconds:</para>
-
- <screen>&prompt.root; <userinput>pfctl -t bruteforce -T expire 86400</userinput></screen>
-
- <para>Similar functionality is provided by
- <package>security/expiretable</package>, which
- removes table entries which have not been accessed for a
- specified period of time.</para>
-
- <para>Once installed,
- <application>expiretable</application> can be run to remove
- <literal><bruteforce></literal> table entries older
- than a specified age. This example removes all entries
- older than 24 hours:</para>
+ <para>Over time, tables will be filled by overload rules and
+ their size will grow incrementally, taking up more memory.
+ Sometimes an <acronym>IP</acronym> address that is blocked
+ is a dynamically assigned one, which has since been assigned
+ to a host who has a legitimate reason to communicate with
+ hosts in the local network.</para>
+
+ <para>For situations like these,
+ <application>pfctl</application> provides the ability to
+ expire table entries. For example, this command will remove
+ <literal><bruteforce></literal> table entries which
+ have not been referenced for <literal>86400</literal>
+ seconds:</para>
+
+ <screen>&prompt.root; <userinput>pfctl -t bruteforce -T expire 86400</userinput></screen>
+
+ <para>Similar functionality is provided by
+ <package>security/expiretable</package>, which removes table
+ entries which have not been accessed for a specified period
+ of time.</para>
+
+ <para>Once installed, <application>expiretable</application>
+ can be run to remove <literal><bruteforce></literal>
+ table entries older than a specified age. This example
+ removes all entries older than 24 hours:</para>
- <programlisting>/usr/local/sbin/expiretable -v -d -t 24h bruteforce</programlisting>
+ <programlisting>/usr/local/sbin/expiretable -v -d -t 24h bruteforce</programlisting>
</sect3>
- <sect3 xml:id="pftut-spamd">
- <title>Protecting Against <acronym>SPAM</acronym></title>
+ <sect3 xml:id="pftut-spamd">
+ <title>Protecting Against <acronym>SPAM</acronym></title>
- <para>Not to be confused with the
- <application>spamd</application> daemon which comes
- bundled with <application>spamassassin</application>, the
- <application>PF</application> companion
- <application>spamd</application> was designed to run on a
- PF gateway to form part of the outer defense against spam.
- <application>spamd</application> hooks into the
- <application>PF</application> configuration via a set of
- redirections.</para>
-
- <para>The main point underlying the
- <application>spamd</application> design is the fact that
- spammers send a large number of messages, and the
- probability that you are the first person receiving a
- particular message is incredibly small. In addition,
- spam is mainly sent via a few spammer friendly networks
- and a large number of hijacked machines. Both the
- individual messages and the machines will be reported to
- blacklists fairly quickly, and this is the kind of data
- <application>spamd</application> can use to our advantage
- with <firstterm>blacklists</firstterm>.</para>
-
- <para>What <application>spamd</application> does to SMTP
- connections from addresses in the blacklist is to
- present its banner and immediately switch to a mode
- where it answers SMTP traffic one byte at the time. This
- technique, which is intended to waste as much time as
- possible on the sending end while costing the receiver
- pretty much nothing, is called
- <firstterm>tarpitting</firstterm>. The specific
- implementation with one byte SMTP replies is often
- referred to as <firstterm>stuttering</firstterm>.</para>
-
- <para>This example demonstrates the basic procedure for setting up
- <application>spamd</application> with automatically
- updated blacklists:</para>
-
- <procedure>
- <step>
- <para>Install the <package>mail/spamd/</package> port.
- In particular, be sure to read the package message
- and act upon what it says. Specifically, to use
- <application>spamd</application>'s greylisting
- features, a file descriptor file system (see <link
- xlink:href="http://www.freebsd.org/cgi/man.cgi?query=fdescfs&sektion=5">fdescfs(5)</link>)
- must be mounted at <filename>/dev/fd/</filename>.
- Do this by adding the following line to
- <filename>/etc/fstab</filename>:</para>
-
- <programlisting> fdescfs /dev/fd fdescfs rw 0 0</programlisting>
-
- <para>Make sure the <filename>fdescfs</filename> code
- is in the kernel, either compiled in or by loading
- the module with &man.kldload.8;.</para>
- </step>
+ <para>Not to be confused with the
+ <application>spamd</application> daemon which comes
+ bundled with <application>spamassassin</application>, the
+ <application>PF</application> companion
+ <application>spamd</application> was designed to run on a
+ PF gateway to form part of the outer defense against spam.
+ <application>spamd</application> hooks into the
+ <application>PF</application> configuration via a set of
+ redirections.</para>
+
+ <para>The main point underlying the
+ <application>spamd</application> design is the fact that
+ spammers send a large number of messages, and the
+ probability that you are the first person receiving a
+ particular message is incredibly small. In addition,
+ spam is mainly sent via a few spammer friendly networks
+ and a large number of hijacked machines. Both the
+ individual messages and the machines will be reported to
+ blacklists fairly quickly, and this is the kind of data
+ <application>spamd</application> can use to our advantage
+ with <firstterm>blacklists</firstterm>.</para>
+
+ <para>What <application>spamd</application> does to SMTP
+ connections from addresses in the blacklist is to
+ present its banner and immediately switch to a mode
+ where it answers SMTP traffic one byte at the time. This
+ technique, which is intended to waste as much time as
+ possible on the sending end while costing the receiver
+ pretty much nothing, is called
+ <firstterm>tarpitting</firstterm>. The specific
+ implementation with one byte SMTP replies is often
+ referred to as <firstterm>stuttering</firstterm>.</para>
+
+ <para>This example demonstrates the basic procedure for
+ setting up <application>spamd</application> with
+ automatically updated blacklists:</para>
+
+ <procedure>
+ <step>
+ <para>Install the <package>mail/spamd/</package> port.
+ In particular, be sure to read the package message
+ and act upon what it says. Specifically, to use
+ <application>spamd</application>'s greylisting
+ features, a file descriptor file system (see <link
+ xlink:href="http://www.freebsd.org/cgi/man.cgi?query=fdescfs&sektion=5">fdescfs(5)</link>)
+ must be mounted at <filename>/dev/fd/</filename>.
+ Do this by adding the following line to
+ <filename>/etc/fstab</filename>:</para>
+
+ <programlisting> fdescfs /dev/fd fdescfs rw 0 0</programlisting>
+
+ <para>Make sure the <filename>fdescfs</filename> code
+ is in the kernel, either compiled in or by loading
+ the module with &man.kldload.8;.</para>
+ </step>
- <step>
- <para>Next, edit the ruleset to include</para>
+ <step>
+ <para>Next, edit the ruleset to include</para>
- <programlisting>table <spamd> persist
+ <programlisting>table <spamd> persist
table <spamd-white> persist
rdr pass on $ext_if inet proto tcp from <spamd> to \
{ $ext_if, $localnet } port smtp -> 127.0.0.1 port 8025
rdr pass on $ext_if inet proto tcp from !<spamd-white> to \
{ $ext_if, $localnet } port smtp -> 127.0.0.1 port 8025</programlisting>
- <para>The two tables <spamd> and
- <spamd-white> are essential. SMTP traffic
- from the addresses in the first table plus the ones
- which are not in the other table are redirected to a
- daemon listening at port 8025.</para>
- </step>
-
- <step>
- <para>The next step is to set up
- <application>spamd</application>'s own configuration
- in <filename>/usr/local/etc/spamd.conf</filename>
- supplemented by <filename>rc.conf</filename>
- parameters.</para>
-
- <para>The supplied sample file offers quite a bit of
- explanation, and the man page offers additional
- information, but we will recap the essentials
- here.</para>
-
- <para>One of the first lines without a
- <literal>#</literal> comment sign at the start
- contains the block which defines the
- <literal>all</literal> list, which specifies the
- lists actually used:</para>
+ <para>The two tables <spamd> and
+ <spamd-white> are essential. SMTP traffic
+ from the addresses in the first table plus the ones
+ which are not in the other table are redirected to a
+ daemon listening at port 8025.</para>
+ </step>
+
+ <step>
+ <para>The next step is to set up
+ <application>spamd</application>'s own configuration
+ in <filename>/usr/local/etc/spamd.conf</filename>
+ supplemented by <filename>rc.conf</filename>
+ parameters.</para>
+
+ <para>The supplied sample file offers quite a bit of
+ explanation, and the man page offers additional
+ information, but we will recap the essentials
+ here.</para>
+
+ <para>One of the first lines without a
+ <literal>#</literal> comment sign at the start
+ contains the block which defines the
+ <literal>all</literal> list, which specifies the
+ lists actually used:</para>
- <programlisting>all:\
+ <programlisting>all:\
:traplist:whitelist:</programlisting>
- <para>Here, all the desired black lists are added,
- separated by colons (<literal>:</literal>). To use
- whitelists to subtract addresses from the blacklist,
- add the name of the whitelist immediately after the
- name of each blacklist, i.e.,
- <literal>:blacklist:whitelist:</literal>.</para>
+ <para>Here, all the desired black lists are added,
+ separated by colons (<literal>:</literal>). To use
+ whitelists to subtract addresses from the blacklist,
+ add the name of the whitelist immediately after the
+ name of each blacklist, i.e.,
+ <literal>:blacklist:whitelist:</literal>.</para>
- <para>Next up is a blacklist definition:</para>
+ <para>Next up is a blacklist definition:</para>
- <programlisting>traplist:\
+ <programlisting>traplist:\
:black:\
:msg="SPAM. Your address %A has sent spam within the last 24 hours":\
:method=http:\
:file=www.openbsd.org/spamd/traplist.gz</programlisting>
- <para>Following the name, the first data field
- specifies the list type, in this case
- <literal>black</literal>. The
- <literal>msg</literal> field contains the message to
- display to blacklisted senders during the SMTP
- dialogue. The <literal>method</literal> field
- specifies how spamd-setup fetches the list data,
- here <literal>http</literal>. The other options are
- fetching via <literal>ftp</literal>, from a
- <literal>file</literal> in a mounted file system or
- via <literal>exec</literal> of an external program.
- Finally the <literal>file</literal> field specifies
- the name of the file spamd expects to
- receive.</para>
+ <para>Following the name, the first data field
+ specifies the list type, in this case
+ <literal>black</literal>. The
+ <literal>msg</literal> field contains the message to
+ display to blacklisted senders during the SMTP
+ dialogue. The <literal>method</literal> field
+ specifies how spamd-setup fetches the list data,
+ here <literal>http</literal>. The other options are
+ fetching via <literal>ftp</literal>, from a
+ <literal>file</literal> in a mounted file system or
+ via <literal>exec</literal> of an external program.
+ Finally the <literal>file</literal> field specifies
+ the name of the file spamd expects to receive.</para>
- <para>The definition of a whitelist follows much the
- same pattern:</para>
+ <para>The definition of a whitelist follows much the
+ same pattern:</para>
- <programlisting>whitelist:\
+ <programlisting>whitelist:\
:white:\
:method=file:\
:file=/var/mail/whitelist.txt</programlisting>
*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
More information about the svn-doc-all
mailing list