Date: Mon, 24 Feb 2014 04:16:59 +0000 (UTC) From: Dru Lavigne <dru@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44039 - head/en_US.ISO8859-1/books/handbook/firewalls Message-ID: <201402240416.s1O4Gx6k005801@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201402240416.s1O4Gx6k005801>