From owner-svn-doc-all@FreeBSD.ORG Sun Feb 23 20:18:56 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CBF4E188; Sun, 23 Feb 2014 20:18:56 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9C30A11A4; Sun, 23 Feb 2014 20:18:56 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1NKIuOW010270; Sun, 23 Feb 2014 20:18:56 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1NKIuLj010269; Sun, 23 Feb 2014 20:18:56 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402232018.s1NKIuLj010269@svn.freebsd.org> From: Dru Lavigne Date: Sun, 23 Feb 2014 20:18:56 +0000 (UTC) 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 X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 20:18:57 -0000 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 @@ Check out this link for port numbers used by Trojans http://www.sans.org/security-resources/idfaq/oddports.php. + 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 http://www.slacksite.com/other/ftp.html. + A firewall ruleset can be either exclusive or inclusive. An exclusive firewall allows all traffic through except for the @@ -2220,167 +2227,143 @@ ipnat_enable="YES" ipnat_rules="/etc/ipnat.rules" NAT 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;. - The syntax for a NAT rule looks like - this, where map starts the rule and + The basic syntax for a NAT rule is as + follows, where map starts the rule and IF should be replaced with the name of the external interface: map IF LAN_IP_RANGE -> PUBLIC_ADDRESS - The LAN_IP_RANGE is used by the - internal clients use for IP Addressing. Usually, this is - something like The LAN_IP_RANGE is the range + of IP addresses used by + internal clients. Usually, it is a private address range + such as 192.168.1.0/24. The PUBLIC_ADDRESS can either - be the static external IP address or the special keyword - 0/32 which uses the IP address assigned to + be the static external IP address or the keyword + 0/32 which represents the IP address assigned to IF. - In IPF, when a packet arrives at the firewall from the LAN - with a public destination, it passes through the outbound - filter rules. NAT gets its turn at the - packet and applies its rules top down, where the first - matching rule wins. NAT tests each of its - rules against the packet's interface name and source IP + In IPF, when a packet arrives + at the firewall from the LAN + with a public destination, it first passes through the outbound + rules of the firewall ruleset. Then, the packet is passed to the NAT ruleset + which is read from the top down, where the first + matching rule wins. IPF tests each + NAT rule against the packet's interface name and source IP address. When a packet's interface name matches a - NAT 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 - NAT rule. On a match, the packet has its - source IP address rewritten with the public IP address - obtained by the 0/32 keyword. - NAT posts an entry in its internal - NAT 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. - - 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. + NAT rule, the packet's source IP address in + the private LAN is checked to see if it falls within the IP + address range specified in LAN_IP_RANGE. + On a match, the packet has its + source IP address rewritten with the public IP address + specified by PUBLIC_ADDRESS. + IPF posts an entry in its internal + NAT table so that when the packet returns from + the Internet, it can be mapped back to its original + private IP address before being passed to the firewall rules for + further processing. + + For networks that have large numbers of internal systems + or multiple subnets, the process of + funneling every private IP address into a single + public IP address becomes a resource problem. Two methods + are available to relieve this issue. - The first method is to assign ports to use. A normal - NAT rule would look like: - - map dc0 192.168.1.0/24 -> 0/32 - - In the above rule, the packet's source port is unchanged - as the packet passes through IPNAT. By + The first method is to assign a range of ports to use + as source ports. By adding the portmap keyword, - IPNAT can be directed to only use - source ports in the specified range. For example, the - following rule will tell IPNAT to modify - the source port to be within the range shown: + NAT can be directed to only use + source ports in the specified range: map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:60000 - Additionally, the auto keyword tells - IPNAT to determine which ports are + Alternately, use the auto keyword which tells + NAT to determine the ports that are available for use: map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp auto 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 pool, and - IPNAT may pick one of the public IP - addresses as packet addresses are mapped on their way + This is useful when there are + too many LAN addresses to fit into a single public + address and a block of public IP addresses is available. + These public addresses can be used as a pool from which + NAT selects an IP address + as a packet's address is mapped on its way out. - For example, instead of mapping all packets through a - single public IP address: - - map dc0 192.168.1.0/24 -> 204.134.75.1 - - A range of public IP addresses can be specified either - with a netmask: - - map dc0 192.168.1.0/24 -> 204.134.75.0/255.255.255.0 - - or using CIDR notation: - - map dc0 192.168.1.0/24 -> 204.134.75.0/24 - - 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 + The range of public IP addresses can + be specified + using a netmask or CIDR notation. These + two rules are equivalent: + + 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 + + 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 NAT, - but port redirection is also needed to direct the inbound traffic - to the correct server. For example, a web server operating - on LAN address 10.0.10.25 and using a - single public IP address of 20.20.20.5, 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 10.0.10.25 to its + public IP address of 20.20.20.5, use this rule: rdr dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80 - or: + If it is the only web server, this rule would also work + as it redirects all external HTTP + requests to 10.0.10.25: rdr dc0 0.0.0.0/0 port 80 -> 10.0.10.25 port 80 - For a LAN DNS server on a private address of - 10.0.10.33 that - needs to receive public DNS requests: - - rdr dc0 20.20.20.5/32 port 53 -> 10.0.10.33 port 53 udp - - 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 http://www.slacksite.com/other/ftp.html. - - IPNAT has a built in FTP proxy option - which can be specified on the NAT 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. + IPF has a built in + FTP proxy + which can be used with NAT. + It monitors all outbound traffic for active or passive FTP + connection requests and dynamically + creates temporary filter rules containing the port number + used by the FTP data channel. This eliminates the + need to open large ranges of high order ports for + FTP connections. This rule will handle all the traffic for the internal LAN: map dc0 10.0.10.0/29 -> 0/32 proxy port 21 ftp/tcp - This rule handles the FTP traffic from the + This rule handles the FTP traffic from the gateway: map dc0 0.0.0.0/0 -> 0/32 proxy port 21 ftp/tcp - This rule handles all non-FTP traffic from the internal + This rule handles all non-FTP traffic from the internal LAN: map dc0 10.0.10.0/29 -> 0/32 - The FTP map rules go before the + The FTP map rules go before the NAT 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 - NAT. All LAN packets that are not FTP - will not match the FTP rules but will undergo + FTP rule, the FTP proxy creates temporary filter rules to + let the FTP session packets pass and undergo + NAT. All LAN packets that are not FTP + will not match the FTP rules but will undergo NAT if they match the third rule. - Only one filter rule is needed for FTP if the - NAT FTP proxy is used. + Only one filter rule is needed for FTP if the + NAT FTP proxy is used. - Without the FTP proxy, the following three rules will be + Without the FTP proxy, the following three rules will be needed: # Allow out LAN PC client FTP to public Internet