Date: Fri, 14 Feb 2014 21:04:16 +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: r43929 - head/en_US.ISO8859-1/books/handbook/firewalls Message-ID: <201402142104.s1EL4GL6034348@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: dru Date: Fri Feb 14 21:04:15 2014 New Revision: 43929 URL: http://svnweb.freebsd.org/changeset/doc/43929 Log: Initial prep work on NAT gateway section. Still a WIP. 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 Fri Feb 14 20:37:25 2014 (r43928) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Fri Feb 14 21:04:15 2014 (r43929) @@ -628,25 +628,14 @@ pass proto udp to any port $udp_services <sect3 xml:id="pftut-gateway"> <title>A Simple Gateway with NAT</title> - <para>To most users, a single machine setup will be of limited - interest, and at this point we move on to more realistic or - at least more common setups, concentrating on a machine + <para>This section demonstrates how to configure a &os; system which is running <application>PF</application> and also acts - as a gateway for at least one other machine.</para> + as a gateway for at least one other machine. The gateway + has at least two network interfaces, each connected to a + separate network. For example, one connection is to the + Internet and the other is to the internal network.</para> - <para>In the single machine setup, life is relatively - simple. Traffic created on it should either pass out to - the rest of the world or not, and the administrator - decides what to let in from elsewhere.</para> - - <para>On a gateway, the perspective changes from - <quote>me versus the network out there</quote> to - <quote>I am the one who decides what to pass to or from - all the networks I am connected to</quote>. The machine - has at least two network interfaces, each connected to a - separate net.</para> - - <para>It is very reasonable to think that for traffic to + <para>It is reasonable to think that for stateful traffic to pass from the network connected to <filename>xl1</filename> to hosts on the network connected to <filename>xl0</filename>, a rule like @@ -654,46 +643,32 @@ pass proto udp to any port $udp_services <programlisting>pass in on xl1 from xl1:network to xl0:network port $ports keep state</programlisting> - <para>This rule keeps track of states as well.</para> - - <para>However, one of the most common and most - complained-about mistakes in firewall configuration is not - realizing that the <quote>to</quote> keyword does not in - itself guarantee passage all the way there. The rule we - just wrote only lets the traffic pass in to the gateway on - the internal interface. To let the packets get a bit - further, a matching rule is needed which says</para> + <para>However, the <quote>to</quote> keyword does + guarantee passage all the way from source to destination. This 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>These rules will work, but they will not necessarily achieve the desired effect.</para> - <para>Rules this specific are rarely needed. For the basic - gateway configurations we will be dealing with here, a - better rule says</para> + <para>Rules this specific are rarely needed. A + better rule says:</para> <programlisting>pass from xl1:network to any port $ports keep state</programlisting> - <para>This provides local net access to the Internet and + <para>This provides local network access to the Internet and leaves the detective work to the <firstterm>antispoof</firstterm> and - <firstterm>scrub</firstterm> code. They are both pretty - good these days, and we will get back to them later. For - now we just accept the fact that for simple setups, - interface-bound rules with in/out rules tend to add more - clutter than they are worth to rulesets.</para> + <firstterm>scrub</firstterm> code.</para> <para>For a busy network admin, a readable ruleset is a - safer ruleset.</para> - - <para>For the remainder of this section, with some + safer ruleset. For the remainder of this section, with some exceptions, we will keep the rules as simple as possible for readability.</para> - <sect4 xml:id="pftut-whatsthelocalnet"> - <title>What is the Local Network, Anyway?</title> - <para>Above, we introduced the <literal>interface:network</literal> notation. That is a nice piece of shorthand, but the ruleset can be made even @@ -720,21 +695,6 @@ pass proto udp to any port $udp_services <para>could end up saving you a few headaches. We will stick to that convention from here on.</para> - </sect4> - - <sect4 xml:id="pftut-gwsimplesetup"> - <title>Setting Up</title> - - <para>We assume that the machine has acquired another - network card or at any rate there is a network - connection from the local network, via PPP or other - means. We will not consider the specific interface - configurations.</para> - - <para>For the discussion and examples below, only the - interface names will differ between a PPP setup and an - Ethernet one, and we will do our best to get rid of the - actual interface names as quickly as possible.</para> <para>First, we need to turn on gatewaying in order to let the machine forward the network traffic it receives on one @@ -820,25 +780,13 @@ pass from { lo0, $localnet } to any keep <programlisting>pass inet proto tcp from $localnet to any port $client_out \ flags S/SA keep state</programlisting> - <para>This may be a somewhat peculiar selection of ports, - but it is based on a real life example. Individual needs - probably differ at least in some specifics, but this - should cover at least some of the more useful - services.</para> - - <para>In addition, we have a few other pass rules. We will - be returning to some of the more interesting ones rather - soon. One pass rule which is useful to those of us who - want the ability to administer our machines from elsewhere - is</para> - - <programlisting>pass in inet proto tcp to port ssh</programlisting> - - <para>or for that matter</para> + <para>In addition, we have a few other pass rules. One pass rule which is useful for + administering machines remotely + is:</para> <programlisting>pass in inet proto tcp to $ext_if port ssh</programlisting> - <para>whichever is preferred. Lastly we need to make the + <para>Lastly we need to make the name service work for our clients:</para> <programlisting>udp_services = "{ domain, ntp }"</programlisting> @@ -870,11 +818,10 @@ pass from { lo0, $localnet } to any keep to both protocols is that they may under certain circumstances communicate alternately over TCP and UDP.</para> - </sect4> </sect3> <sect3 xml:id="pftut-ftp"> - <title>That Sad Old <acronym>FTP</acronym> Thing</title> + <title>Creating an <acronym>FTP</acronym> Proxy</title> <para>The short list of real life <acronym>TCP</acronym> ports above contained, among other things, <acronym>FTP</acronym>. @@ -923,10 +870,6 @@ pass from { lo0, $localnet } to any keep program which is written specifically for this purpose.</para> - <sect4 xml:id="pftut-ftp-proxy"> - <title><acronym>FTP</acronym> Via Redirect: - <application>ftp-proxy</application></title> - <para>Enabling <acronym>FTP</acronym> transfers through your gateway is amazingly simple, thanks to the <acronym>FTP</acronym> proxy program (called @@ -1015,11 +958,10 @@ rdr-anchor "ftp-proxy/*"</programlisting <command>ftp-proxy</command> in reverse mode (using <option>-R</option>), on a separate port with its own redirecting pass rule.</para> - </sect4> </sect3> <sect3 xml:id="pftut-icmp"> - <title>Easing Troubleshooting</title> + <title>Managing <acronym>ICMP</acronym></title> <para>Making network troubleshooting friendly is a potentially large subject. At most times, the debugging or @@ -1069,9 +1011,6 @@ rdr-anchor "ftp-proxy/*"</programlisting these rulesets have been around for roughly fifteen years, and the people who put them there are still scared.</para> - <sect4 xml:id="pftut-dowepass"> - <title>Then, Do We Let it All Through?</title> - <para>The obvious question then becomes, if <acronym>ICMP</acronym> is such a good and useful thing, should we not let it all through, all the time? The @@ -1090,10 +1029,6 @@ rdr-anchor "ftp-proxy/*"</programlisting <acronym>ICMP</acronym> traffic might be found quite harmlessly riding piggyback on <literal>keep state</literal> rules.</para> - </sect4> - - <sect4 xml:id="pftut-icmpstopatgw"> - <title>The Easy Way Out: the Buck Stops Here</title> <para>The easiest solution could very well be to let all <acronym>ICMP</acronym> traffic from the local net through @@ -1106,7 +1041,6 @@ pass inet proto icmp from any to $ext_if option anyway, but let us have a look at a few other options which will show some of <application>PF</application>'s flexibility.</para> - </sect4> <sect4 xml:id="pftut-letpingthru"> <title>Letting <command>ping</command> Through</title>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201402142104.s1EL4GL6034348>