svn commit: r43993 - head/en_US.ISO8859-1/books/handbook/firewalls

Dru Lavigne dru at FreeBSD.org
Wed Feb 19 18:32:16 UTC 2014


Author: dru
Date: Wed Feb 19 18:32:15 2014
New Revision: 43993
URL: http://svnweb.freebsd.org/changeset/doc/43993

Log:
  Finish editorial pass through PF chapter.
  
  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	Wed Feb 19 17:51:00 2014	(r43992)
+++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml	Wed Feb 19 18:32:15 2014	(r43993)
@@ -433,6 +433,13 @@ device pfsync</programlisting>
 	  privileges.  It can be installed from the Ports
 	  Collection.</para>
       </tip>
+
+      <para>To keep an eye on the traffic that passes through the
+	  <application>PF</application> firewall, consider installing the
+	  <package>sysutils/pftop</package> package or port.  Once installed,
+	  <application>pftop</application> can be run to view
+	  a running snapshot of traffic in a format which is
+	  similar to &man.top.1;.</para>
     </sect2>
 
     <sect2>
@@ -1400,94 +1407,80 @@ rdr pass on $ext_if inet proto tcp from 
 	  and <literal>antispoof</literal> can be used to make the
 	  ruleset behave sanely.</para>
 
-	  <para><literal>block-policy</literal> is an option which
+	  <para>The <literal>block-policy</literal> is an option which
 	    can be set in the <literal>options</literal> part of the
 	    ruleset, which precedes the redirection and filtering
 	    rules.  This option determines which feedback, if any,
-	    <application>PF</application> will give to hosts which
-	    try to create connections which are subsequently
-	    blocked.  The option has two possible values,
-	    <literal>drop</literal>, which drops blocked packets
-	    with no feedback, and <literal>return</literal>, which
-	    returns with status codes such as
-	    <computeroutput>Connection refused</computeroutput> or
-	    similar.</para>
-
-	  <para>The correct strategy for block policies has been the
-	    subject of rather a lot of discussion.  We choose to
-	    play nicely and instruct our firewall to issue
-	    returns:</para>
+	    <application>PF</application> sends to hosts that are
+	    blocked by a rule.  The option has two possible values:
+	    <literal>drop</literal> drops blocked packets
+	    with no feedback, and <literal>return</literal>
+	    returns a status code such as
+	    <computeroutput>Connection refused</computeroutput>.</para>
+
+	  <para>If not set, the default policy is <literal>drop</literal>.  To change the <literal>block-policy</literal>, specify
+	    the desired value:</para>
 
 	  <programlisting>set block-policy return</programlisting>
 
-	  <para>In <application>PF</application> versions up to
-	    OpenBSD 4.5 inclusive, <literal>scrub</literal> is a
-	    keyword which enables network packet normalization,
-	    causing fragmented packets to be assembled and removing
-	    ambiguity.  Enabling <literal>scrub</literal> provides a
+	  <para>In <application>PF</application>, <literal>scrub</literal> is a
+	    keyword which enables network packet normalization.  This
+	    process reassembles
+	    fragmented packets and drops TCP packets that have invalid
+	    flag combinations.  Enabling <literal>scrub</literal> provides a
 	    measure of protection against certain kinds of attacks
 	    based on incorrect handling of packet fragments.  A
-	    number of supplementing options are available, but we
-	    choose the simplest form which is suitable for most
-	    configurations.</para>
+	    number of options are available, but the
+	    simplest form is suitable for most
+	    configurations:</para>
 
 	  <programlisting>scrub in all</programlisting>
 
-	  <para>Some services, such as NFS, require some specific
-	    fragment handling options.  This is extensively
-	    documented in the <application>PF</application> user
-	    guide and man pages provide all the information you
-	    could need.</para>
-
-	  <para>One fairly common example is this,</para>
+	  <para>Some services, such as <acronym>NFS</acronym>, require specific
+	    fragment handling options.  Refer to
+	    <link
+	      xlink:href="http://www.openbsd.gr/faq/pf/scrub.html">http://www.openbsd.gr/faq/pf/scrub.html</link>
+	    for more information.</para>
+
+	  <para>This example reassembles fragments, clears the
+	    <quote>do not fragment</quote> bit, and sets the maximum
+	    segment size to 1440 bytes:</para>
 
 	  <programlisting>scrub in all fragment reassemble no-df max-mss 1440</programlisting>
 
-	  <para>meaning, we reassemble fragments, clear the
-	    <quote>do not fragment</quote> bit and set the maximum
-	    segment size to 1440 bytes.  Other variations are
-	    possible, and you should be able to cater to various
-	    specific needs by consulting the man pages and some
-	    experimentation.</para>
-
-	  <para><literal>antispoof</literal> is a common special
-	    case of filtering and blocking.  This mechanism protects
-	    against activity from spoofed or forged IP addresses,
+	  <para>The <literal>antispoof</literal> mechanism protects
+	    against activity from spoofed or forged <acronym>IP</acronym> addresses,
 	    mainly by blocking packets appearing on interfaces and
 	    in directions which are logically not possible.</para>
 
-	  <para>We specify that we want to weed out spoofed traffic
-	    coming in from the rest of the world and any spoofed
-	    packets which, however unlikely, were to originate in
-	    our own network:</para>
+	  <para>These rules weed out spoofed traffic
+	    coming in from the rest of the world as well as any spoofed
+	    packets which originate in the local
+	    network:</para>
 
 	  <programlisting>antispoof for $ext_if
 antispoof for $int_if</programlisting>
       </sect3>
 
       <sect3 xml:id="pftut-unrouteables">
-	<title>Handling Non-Routable Addresses from
-	  Elsewhere</title>
+	<title>Handling Non-Routable Addresses</title>
 
 	<para>Even with a properly configured gateway to handle
-	  network address translation for your own network, you
-	  may find yourself in the unenviable position of having
+	  network address translation, one may have
 	  to compensate for other people's
-	  misconfigurations.</para>
+	  misconfigurations.  A common misconfiguration is to
+	  let traffic with non-routable
+	  addresses out to the Internet.  Since traffic from
+	  non-routeable addresses can play a part in
+	  several <acronym>DoS</acronym> attack techniques,
+	  consider explicitly blocking traffic from
+	  non-routeable addresses from entering the
+	  network through the external interface.</para>
 
-	<para>One depressingly common class of misconfigurations
-	  is the kind which lets traffic with non-routable
-	  addresses out to the Internet.  Traffic from
-	  non-routeable addresses have also played a part in
-	  several DOS attack techniques, so it may be worth
-	  considering explicitly blocking traffic from
-	  non-routeable addresses from entering your
-	  network.</para>
-
-	<para>One possible solution is the one outlined below,
-	  which for good measure also blocks any attempt to
-	  initiate contact to non-routable addresses through the
-	  gateway's external interface:</para>
+	<para>In this example, a macro containing non-routable
+	  addresses is defined, then used in blocking rules.  Traffic to and from these addresses is
+	  quietly dropped on the gateway's external
+	  interface.</para>
 
 	<programlisting>martians = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, \
 	      10.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, \
@@ -1495,43 +1488,6 @@ antispoof for $int_if</programlisting>
 
 block drop in quick on $ext_if from $martians to any
 block drop out quick on $ext_if from any to $martians</programlisting>
-
-	<para>Here, the <literal>martians</literal> macro denotes
-	  the RFC 1918 addresses and a few other ranges which are
-	  mandated by various RFCs not to be in circulation on the
-	  open Internet.  Traffic to and from such addresses is
-	  quietly dropped on the gateway's external
-	  interface.</para>
-
-	<para>The specific details of how to implement this kind
-	  of protection will vary, among other things according to
-	  your specific network configuration.  Your network
-	  design could for example dictate that you include or
-	  exclude other address ranges than these.</para>
-
-	<para>This completes our simple NATing firewall for a
-	  small local network.  A more thorough tutorial is
-	  available at <link
-	    xlink:href="http://home.nuug.no/~peter/pf/">http://home.nuug.no/~peter/pf/</link>,
-	  where you will also find slides from related
-	  presentations.</para>
-      </sect3>
-
-      <sect3 xml:id="pftut-pftop">
-	<title>Viewing Traffic</title>
-
-	<para>Over time, a number of tools have been developed which
-	  interact with <application>PF</application> in various
-	  ways.</para>
-
-	<para>Can Erkin Acar's <application>pftop</application>
-	  makes it possible to keep an eye on what passes into and
-	  out of the network.  <application>pftop</application> is
-	  available through the ports system as
-	  <package>sysutils/pftop</package>.  The name is a strong
-	  hint at what it does - <application>pftop</application>
-	  shows a running snapshot of traffic in a format which is
-	  strongly inspired by &man.top.1;.</para>
       </sect3>
     </sect2>
   </sect1>


More information about the svn-doc-all mailing list