svn commit: r44039 - head/en_US.ISO8859-1/books/handbook/firewalls
Dru Lavigne
dru at FreeBSD.org
Mon Feb 24 04:16:59 UTC 2014
Author: dru
Date: Mon Feb 24 04:16:59 2014
New Revision: 44039
URL: http://svnweb.freebsd.org/changeset/doc/44039
Log:
White space fix only. Translators can ignore.
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 20:18:56 2014 (r44038)
+++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Mon Feb 24 04:16:59 2014 (r44039)
@@ -179,11 +179,11 @@
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>
+ 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
@@ -234,38 +234,37 @@
flood of different attack methods employed by attackers.</para>
<para><acronym>NAT</acronym> stands for <emphasis>Network
- Address Translation</emphasis>.
- <acronym>NAT</acronym> function enables the private LAN behind
- the firewall to share a single ISP-assigned IP address, even
- if that address is dynamically assigned. NAT allows each
- computer in the LAN to have Internet access, without
- having to pay the ISP for multiple Internet accounts or IP
- addresses.</para>
-
- <para><acronym>NAT</acronym> will automatically translate the
- private LAN IP address for each system on the LAN to the
- single public IP address as packets exit the firewall bound
- for the public Internet. It also performs the reverse
- translation for returning packets.</para>
-
- <para>According to RFC 1918, the following IP address ranges are
- reserved for private networks which will never be routed
- directly to the public Internet, and therefore are available
- for use with NAT:</para>
-
- <itemizedlist>
- <listitem>
- <para><literal>10.0.0.0/8</literal>.</para>
- </listitem>
-
- <listitem>
- <para><literal>172.16.0.0/12</literal>.</para>
- </listitem>
-
- <listitem>
- <para><literal>192.168.0.0/16</literal>.</para>
- </listitem>
- </itemizedlist>
+ Address Translation</emphasis>. <acronym>NAT</acronym>
+ function enables the private LAN behind the firewall to share a
+ single ISP-assigned IP address, even if that address is
+ dynamically assigned. NAT allows each computer in the LAN to
+ have Internet access, without having to pay the ISP for multiple
+ Internet accounts or IP addresses.</para>
+
+ <para><acronym>NAT</acronym> will automatically translate the
+ private LAN IP address for each system on the LAN to the
+ single public IP address as packets exit the firewall bound for
+ the public Internet. It also performs the reverse translation
+ for returning packets.</para>
+
+ <para>According to RFC 1918, the following IP address ranges are
+ reserved for private networks which will never be routed
+ directly to the public Internet, and therefore are available
+ for use with NAT:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para><literal>10.0.0.0/8</literal>.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>172.16.0.0/12</literal>.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>192.168.0.0/16</literal>.</para>
+ </listitem>
+ </itemizedlist>
<warning>
<para>When working with the firewall rules, be <emphasis>very
@@ -2228,145 +2227,146 @@ ipnat_rules="/etc/ipnat.rules"</programl
<para><acronym>NAT</acronym> rules are flexible and can
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>
+ 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 basic syntax for a <acronym>NAT</acronym> rule is as
- follows, where <literal>map</literal> starts the rule and
+ follows, where <literal>map</literal> starts the rule and
<replaceable>IF</replaceable> should be replaced with the
- name of the external
- interface:</para>
+ 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 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 <acronym>IP</acronym> address or the keyword
- <literal>0/32</literal> which represents the <acronym>IP</acronym> address assigned to
+ 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 <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 <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 <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>.
+ 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 <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 a range of ports to use
- as source ports. By
- adding the <literal>portmap</literal> keyword,
- <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>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.
- 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>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>
+ <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 a range of ports to use as
+ source ports. By adding the <literal>portmap</literal>
+ keyword, <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>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.
+ 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>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
+ <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 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>
+ <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 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>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><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 <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-<acronym>FTP</acronym> traffic
+ from the internal LAN:</para>
+
+ <programlisting>map dc0 10.0.10.0/29 -> 0/32</programlisting>
+
+ <para>The <acronym>FTP</acronym> <literal>map</literal> rules go
+ before the <acronym>NAT</acronym> rule so that when a packet
+ matches an <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 <acronym>FTP</acronym>
+ if the <acronym>NAT</acronym> <acronym>FTP</acronym> proxy is
+ used.</para>
- <programlisting>rdr dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80</programlisting>
-
- <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><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 <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-<acronym>FTP</acronym> traffic from the internal
- LAN:</para>
-
- <programlisting>map dc0 10.0.10.0/29 -> 0/32</programlisting>
-
- <para>The <acronym>FTP</acronym> <literal>map</literal> rules go before the
- <acronym>NAT</acronym> rule so that when a packet matches an
- <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 <acronym>FTP</acronym> if the
- <acronym>NAT</acronym> <acronym>FTP</acronym> proxy is used.</para>
-
- <para>Without the <acronym>FTP</acronym> proxy, the following three rules will be
- needed:</para>
+ <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
+ <programlisting># Allow out LAN PC client FTP to public Internet
# Active and passive modes
pass out quick on rl0 proto tcp from any to any port = 21 flags S keep state
More information about the svn-doc-all
mailing list