os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Initial prep work on NAT gateway section. Still a WIP.

Browse source 
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne 2014-02-14 21:04:15 +00:00
parent 68e4a86d99
commit d01a8ba4c4
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=43929
1 changed files with 22 additions and 88 deletions

110
en_US.ISO8859-1/books/handbook/firewalls/chapter.xml
View file

@ -628,25 +628,14 @@ pass proto udp to any port $udp_services keep state</programlisting>
<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 keep state</programlisting>
<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 keep state</programlisting>
<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 state</programlisting>
<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 state</programlisting>
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 state</programlisting>
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 keep state</programlisting>
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>