Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 Feb 2014 22:23:52 +0000 (UTC)
From:      Dru Lavigne <dru@FreeBSD.org>
To:        doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org
Subject:   svn commit: r43988 - head/en_US.ISO8859-1/books/handbook/firewalls
Message-ID:  <201402182223.s1IMNqRG080747@svn.freebsd.org>

next in thread | raw e-mail | index | archive | help
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 -&gt; 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 &gt;&lt; 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>&lt; &gt;</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>&lt; &gt;</literal>, like this:</para>
 
 	<programlisting>table &lt;clients&gt; { 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 &lt;clients&gt; 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
 	    &gt;/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 &lt;bruteforce&gt; 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 &lt;bruteforce&gt;
 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 &lt;bruteforce&gt;</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>&lt;bruteforce&gt;</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>&lt;bruteforce&gt;</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>&lt;bruteforce&gt;</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>&lt;bruteforce&gt;</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&amp;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&amp;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 &lt;spamd&gt; persist
+	    <programlisting>table &lt;spamd&gt; persist
 table &lt;spamd-white&gt; persist
 rdr pass on $ext_if inet proto tcp from &lt;spamd&gt; to \
     { $ext_if, $localnet } port smtp -&gt; 127.0.0.1 port 8025
 rdr pass on $ext_if inet proto tcp from !&lt;spamd-white&gt; to \
     { $ext_if, $localnet } port smtp -&gt; 127.0.0.1 port 8025</programlisting>
 
-		<para>The two tables &lt;spamd&gt; and
-		  &lt;spamd-white&gt; 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 &lt;spamd&gt; and
+	      &lt;spamd-white&gt; 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 ***



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201402182223.s1IMNqRG080747>