From owner-svn-doc-head@FreeBSD.ORG Mon Feb 24 04:16:59 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93E3240B; Mon, 24 Feb 2014 04:16:59 +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 7CB9B1C88; Mon, 24 Feb 2014 04:16:59 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1O4GxGM005802; Mon, 24 Feb 2014 04:16:59 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1O4Gx6k005801; Mon, 24 Feb 2014 04:16:59 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402240416.s1O4Gx6k005801@svn.freebsd.org> From: Dru Lavigne Date: Mon, 24 Feb 2014 04:16:59 +0000 (UTC) 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 X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 04:16:59 -0000 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. 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. + 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 @@ -234,38 +234,37 @@ flood of different attack methods employed by attackers. NAT stands for Network - Address Translation. - NAT 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. - - NAT 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. - - 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: - - - - 10.0.0.0/8. - - - - 172.16.0.0/12. - - - - 192.168.0.0/16. - - + Address Translation. NAT + 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. + + NAT 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. + + 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: + + + + 10.0.0.0/8. + + + + 172.16.0.0/12. + + + + 192.168.0.0/16. + + When working with the firewall rules, be very @@ -2228,145 +2227,146 @@ ipnat_rules="/etc/ipnat.rules"NAT 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;. + 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 basic syntax for a NAT rule is as - follows, where map starts the rule and + follows, where map starts the rule and IF should be replaced with the - name of the external - interface: + name of the external interface: map IF LAN_IP_RANGE -> PUBLIC_ADDRESS 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 keyword - 0/32 which represents the IP address assigned to + 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 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 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 in LAN_IP_RANGE. - On a match, the packet has its - source IP address rewritten with the public IP address - specified by PUBLIC_ADDRESS. + 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 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 a range of ports to use - as source ports. By - adding the portmap keyword, - 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 - - 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. - 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. - - The range of public IP addresses can - be specified - using a netmask or CIDR notation. These - two rules are equivalent: + 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 a range of ports to use as + source ports. By adding the portmap + keyword, 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 + + 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. + 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. + + 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/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 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: + 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 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 + + 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 + + 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 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 LAN: + + map dc0 10.0.10.0/29 -> 0/32 + + 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 + NAT if they match the third rule. + + Only one filter rule is needed for FTP + if the NAT FTP proxy is + used. - rdr dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80 - - 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 - - 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 - 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 - LAN: - - map dc0 10.0.10.0/29 -> 0/32 - - 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 - NAT if they match the third rule. - - 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 - needed: + Without the FTP proxy, the following + three rules will be needed: - # Allow out LAN PC client FTP to public Internet + # 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