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

Editorial pass through first 1/2 of IPF NAT section.

Browse source 
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne 2014-02-23 20:18:56 +00:00
parent 0fc636eba0
commit 07e37e24de
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=44038
1 changed files with 88 additions and 105 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -178,6 +178,13 @@
<para>Check out this link for port numbers used by Trojans <uri
xlink:href="http://www.sans.org/security-resources/idfaq/oddports.php">http://www.sans.org/security-resources/idfaq/oddports.php</uri>.</para>
<para>FTP has two modes: active mode and passive mode. The
difference is in how the data channel is acquired. Passive
mode is more secure as the data channel is acquired by the
ordinal ftp session requester. For a good explanation of
FTP and the different modes, see <uri
xlink:href="http://www.slacksite.com/other/ftp.html">http://www.slacksite.com/other/ftp.html</uri>.</para>
<para>A firewall ruleset can be either
<quote>exclusive</quote> or <quote>inclusive</quote>. An
exclusive firewall allows all traffic through except for the
@ -2220,167 +2227,143 @@ ipnat_enable="YES"
ipnat_rules="/etc/ipnat.rules"</programlisting>
<para><acronym>NAT</acronym> rules are flexible and can
accomplish many different things to fit the needs of
accomplish many different things to fit the needs of both
commercial and home users. The rule syntax presented here has been simplified to
demonstrate common usage.
For a complete rule syntax description, refer to
&man.ipnat.5;.</para>
<para>The syntax for a <acronym>NAT</acronym> rule looks like
this, where <literal>map</literal> starts the rule and
<para>The basic syntax for a <acronym>NAT</acronym> rule is as
follows, where <literal>map</literal> starts the rule and
<replaceable>IF</replaceable> should be replaced with the
name of the external
interface:</para>
<programlisting>map <replaceable>IF</replaceable> <replaceable>LAN_IP_RANGE</replaceable> -&gt; <replaceable>PUBLIC_ADDRESS</replaceable></programlisting>
<para>The <replaceable>LAN_IP_RANGE</replaceable> is used by the
internal clients use for IP Addressing. Usually, this is
something like <systemitem
<para>The <replaceable>LAN_IP_RANGE</replaceable> is the range
of <acronym>IP</acronym> addresses used by
internal clients. Usually, it is a private address range
such as <systemitem
class="ipaddress">192.168.1.0/24</systemitem>. The <replaceable>PUBLIC_ADDRESS</replaceable> can either
be the static external IP address or the special keyword
<literal>0/32</literal> which uses the IP address assigned to
be the static external <acronym>IP</acronym> address or the keyword
<literal>0/32</literal> which represents the <acronym>IP</acronym> address assigned to
<replaceable>IF</replaceable>.</para>
<para>In IPF, when a packet arrives at the firewall from the LAN
with a public destination, it passes through the outbound
filter rules. <acronym>NAT</acronym> gets its turn at the
packet and applies its rules top down, where the first
matching rule wins. <acronym>NAT</acronym> tests each of its
rules against the packet's interface name and source IP
<para>In <application>IPF</application>, when a packet arrives
at the firewall from the <acronym>LAN</acronym>
with a public destination, it first passes through the outbound
rules of the firewall ruleset. Then, the packet is passed to the <acronym>NAT</acronym> ruleset
which is read from the top down, where the first
matching rule wins. <application>IPF</application> tests each
<acronym>NAT</acronym> rule against the packet's interface name and source <acronym>IP</acronym>
address. When a packet's interface name matches a
<acronym>NAT</acronym> rule, the packet's source IP address in
the private LAN is checked to see if it falls within the IP
address range specified to the left of the arrow symbol on the
<acronym>NAT</acronym> rule. On a match, the packet has its
source IP address rewritten with the public IP address
obtained by the <literal>0/32</literal> keyword.
<acronym>NAT</acronym> posts an entry in its internal
<acronym>NAT</acronym> table so when the packet returns from
the public Internet it can be mapped back to its original
private IP address and then passed to the filter rules for
processing.</para>
<acronym>NAT</acronym> rule, the packet's source <acronym>IP</acronym> address in
the private <acronym>LAN</acronym> is checked to see if it falls within the <acronym>IP</acronym>
address range specified in <replaceable>LAN_IP_RANGE</replaceable>.
On a match, the packet has its
source <acronym>IP</acronym> address rewritten with the public <acronym>IP</acronym> address
specified by <replaceable>PUBLIC_ADDRESS</replaceable>.
<application>IPF</application> posts an entry in its internal
<acronym>NAT</acronym> table so that when the packet returns from
the Internet, it can be mapped back to its original
private <acronym>IP</acronym> address before being passed to the firewall rules for
further processing.</para>
<para>For networks that have large numbers of systems on the
LAN or networks with more than a single LAN, the process of
funneling all those private IP addresses into a single
public IP address becomes a resource problem that may cause
problems with the same port numbers being used many times
across many connections, causing collisions. This section
describes two ways to relieve this resource problem.</para>
<para>For networks that have large numbers of internal systems
or multiple subnets, the process of
funneling every private <acronym>IP</acronym> address into a single
public <acronym>IP</acronym> address becomes a resource problem. Two methods
are available to relieve this issue.</para>
<para>The first method is to assign ports to use. A normal
NAT rule would look like:</para>
<programlisting>map dc0 192.168.1.0/24 -&gt; 0/32</programlisting>
<para>In the above rule, the packet's source port is unchanged
as the packet passes through IP<acronym>NAT</acronym>. By
<para>The first method is to assign a range of ports to use
as source ports. By
adding the <literal>portmap</literal> keyword,
IP<acronym>NAT</acronym> can be directed to only use
source ports in the specified range. For example, the
following rule will tell IP<acronym>NAT</acronym> to modify
the source port to be within the range shown:</para>
<acronym>NAT</acronym> can be directed to only use
source ports in the specified range:</para>
<programlisting>map dc0 192.168.1.0/24 -&gt; 0/32 portmap tcp/udp 20000:60000</programlisting>
<para>Additionally, the <literal>auto</literal> keyword tells
IP<acronym>NAT</acronym> to determine which ports are
<para>Alternately, use the <literal>auto</literal> keyword which tells
<acronym>NAT</acronym> to determine the ports that are
available for use:</para>
<programlisting>map dc0 192.168.1.0/24 -&gt; 0/32 portmap tcp/udp auto</programlisting>
<para>The second method is to use a pool of public addresses.
In very large LANs there comes a point where there are
just too many LAN addresses to fit into a single public
address. If a block of public IP addresses is available,
these addresses can be used as a <quote>pool</quote>, and
IP<acronym>NAT</acronym> may pick one of the public IP
addresses as packet addresses are mapped on their way
This is useful when there are
too many <acronym>LAN</acronym> addresses to fit into a single public
address and a block of public <acronym>IP</acronym> addresses is available.
These public addresses can be used as a pool from which
<acronym>NAT</acronym> selects an <acronym>IP</acronym> address
as a packet's address is mapped on its way
out.</para>
<para>For example, instead of mapping all packets through a
single public IP address:</para>
<para>The range of public <acronym>IP</acronym> addresses can
be specified
using a netmask or <acronym>CIDR</acronym> notation. These
two rules are equivalent:</para>
<programlisting>map dc0 192.168.1.0/24 -&gt; 204.134.75.1</programlisting>
<programlisting>map dc0 192.168.1.0/24 -&gt; 204.134.75.0/255.255.255.0
map dc0 192.168.1.0/24 -&gt; 204.134.75.0/24</programlisting>
<para>A range of public IP addresses can be specified either
with a netmask:</para>
<programlisting>map dc0 192.168.1.0/24 -&gt; 204.134.75.0/255.255.255.0</programlisting>
<para>or using CIDR notation:</para>
<programlisting>map dc0 192.168.1.0/24 -&gt; 204.134.75.0/24</programlisting>
<para>A common practice is to have a web server, email server,
database server, and DNS server each segregated to a
different system on the LAN. In this case, the traffic from
<para>A common practice is to have a publically accessible web server or mail server
segregated to an internal
network segment. The traffic from
these servers still has to undergo <acronym>NAT</acronym>,
but port redirection is also needed to direct the inbound traffic
to the correct server. For example, a web server operating
on LAN address <systemitem
class="ipaddress">10.0.10.25</systemitem> and using a
single public IP address of <systemitem
class="ipaddress">20.20.20.5</systemitem>, would use this
but port redirection is needed to direct inbound traffic
to the correct server. For example, to map a web server using
the internal address <systemitem
class="ipaddress">10.0.10.25</systemitem> to its
public <acronym>IP</acronym> address of <systemitem
class="ipaddress">20.20.20.5</systemitem>, use this
rule:</para>
<programlisting>rdr dc0 20.20.20.5/32 port 80 -&gt; 10.0.10.25 port 80</programlisting>
<para>or:</para>
<para>If it is the only web server, this rule would also work
as it redirects all external <acronym>HTTP</acronym>
requests to <literal>10.0.10.25</literal>:</para>
<programlisting>rdr dc0 0.0.0.0/0 port 80 -&gt; 10.0.10.25 port 80</programlisting>
<para>For a LAN DNS server on a private address of
<systemitem class="ipaddress">10.0.10.33</systemitem> that
needs to receive public DNS requests:</para>
<programlisting>rdr dc0 20.20.20.5/32 port 53 -&gt; 10.0.10.33 port 53 udp</programlisting>
<para>FTP has two modes: active mode and passive mode. The
difference is in how the data channel is acquired. Passive
mode is more secure as the data channel is acquired by the
ordinal ftp session requester. For a good explanation of
FTP and the different modes, see <uri
xlink:href="http://www.slacksite.com/other/ftp.html">http://www.slacksite.com/other/ftp.html</uri>.</para>
<para>IP<acronym>NAT</acronym> has a built in FTP proxy option
which can be specified on the <acronym>NAT</acronym> map
rule. It can monitor all outbound packet traffic for FTP
active or passive start session requests and dynamically
create temporary filter rules containing the port number
being used by the data channel. This eliminates the
security risk FTP normally exposes the firewall to as it no
longer needs to open large ranges of high order ports for
FTP connections.</para>
<para><application>IPF</application> has a built in
<acronym>FTP</acronym> proxy
which can be used with <acronym>NAT</acronym>.
It monitors all outbound traffic for active or passive <acronym>FTP</acronym>
connection requests and dynamically
creates temporary filter rules containing the port number
used by the <acronym>FTP</acronym> data channel. This eliminates the
need to open large ranges of high order ports for
<acronym>FTP</acronym> connections.</para>
<para>This rule will handle all the traffic for the internal
LAN:</para>
<programlisting>map dc0 10.0.10.0/29 -&gt; 0/32 proxy port 21 ftp/tcp</programlisting>
<para>This rule handles the FTP traffic from the
<para>This rule handles the <acronym>FTP</acronym> traffic from the
gateway:</para>
<programlisting>map dc0 0.0.0.0/0 -&gt; 0/32 proxy port 21 ftp/tcp</programlisting>
<para>This rule handles all non-FTP traffic from the internal
<para>This rule handles all non-<acronym>FTP</acronym> traffic from the internal
LAN:</para>
<programlisting>map dc0 10.0.10.0/29 -&gt; 0/32</programlisting>
<para>The FTP <literal>map</literal> rules go before the
<para>The <acronym>FTP</acronym> <literal>map</literal> rules go before the
<acronym>NAT</acronym> rule so that when a packet matches an
FTP rule, the FTP proxy creates temporary filter rules to
let the FTP session packets pass and undergo
<acronym>NAT</acronym>. All LAN packets that are not FTP
will not match the FTP rules but will undergo
<acronym>FTP</acronym> rule, the <acronym>FTP</acronym> proxy creates temporary filter rules to
let the <acronym>FTP</acronym> session packets pass and undergo
<acronym>NAT</acronym>. All LAN packets that are not <acronym>FTP</acronym>
will not match the <acronym>FTP</acronym> rules but will undergo
<acronym>NAT</acronym> if they match the third rule.</para>
<para>Only one filter rule is needed for FTP if the
<acronym>NAT</acronym> FTP proxy is used.</para>
<para>Only one filter rule is needed for <acronym>FTP</acronym> if the
<acronym>NAT</acronym> <acronym>FTP</acronym> proxy is used.</para>
<para>Without the FTP proxy, the following three rules will be
<para>Without the <acronym>FTP</acronym> proxy, the following three rules will be
needed:</para>
<programlisting># Allow out LAN PC client FTP to public Internet