svn commit: r44038 - head/en_US.ISO8859-1/books/handbook/firewalls
Dru Lavigne
dru at FreeBSD.org
Sun Feb 23 20:18:57 UTC 2014
Author: dru
Date: Sun Feb 23 20:18:56 2014
New Revision: 44038
URL: http://svnweb.freebsd.org/changeset/doc/44038
Log:
Editorial pass through first 1/2 of IPF NAT section.
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 Sun Feb 23 16:11:36 2014 (r44037)
+++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Sun Feb 23 20:18:56 2014 (r44038)
@@ -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> -> <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>
-
- <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>
+ <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 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 -> 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 -> 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 -> 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>
-
- <programlisting>map dc0 192.168.1.0/24 -> 204.134.75.1</programlisting>
-
- <para>A range of public IP addresses can be specified either
- with a netmask:</para>
-
- <programlisting>map dc0 192.168.1.0/24 -> 204.134.75.0/255.255.255.0</programlisting>
-
- <para>or using CIDR notation:</para>
-
- <programlisting>map dc0 192.168.1.0/24 -> 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>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 -> 204.134.75.0/255.255.255.0
+map dc0 192.168.1.0/24 -> 204.134.75.0/24</programlisting>
+
+ <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 -> 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 -> 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 -> 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 -> 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 -> 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 -> 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
More information about the svn-doc-all
mailing list