Date: Sun, 23 Feb 2014 20:18:56 +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: r44038 - head/en_US.ISO8859-1/books/handbook/firewalls Message-ID: <201402232018.s1NKIuLj010269@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201402232018.s1NKIuLj010269>