Date: Wed, 19 Feb 2014 18:32:15 +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: r43993 - head/en_US.ISO8859-1/books/handbook/firewalls Message-ID: <201402191832.s1JIWFhX003756@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201402191832.s1JIWFhX003756>