svn commit: r43929 - head/en_US.ISO8859-1/books/handbook/firewalls
Dru Lavigne
dru at FreeBSD.org
Fri Feb 14 21:04:16 UTC 2014
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>
More information about the svn-doc-head
mailing list