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