From owner-svn-doc-all@FreeBSD.ORG Wed Feb 26 22:19:05 2014 Return-Path: Delivered-To: svn-doc-all@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 955D670C; Wed, 26 Feb 2014 22:19:05 +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 709C912DA; Wed, 26 Feb 2014 22:19:05 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1QMJ5Qa033820; Wed, 26 Feb 2014 22:19:05 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1QMJ53n033818; Wed, 26 Feb 2014 22:19:05 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402262219.s1QMJ53n033818@svn.freebsd.org> From: Dru Lavigne Date: Wed, 26 Feb 2014 22:19:05 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44080 - in head/en_US.ISO8859-1/books/handbook: advanced-networking 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: Wed, 26 Feb 2014 22:19:05 -0000 Author: dru Date: Wed Feb 26 22:19:04 2014 New Revision: 44080 URL: http://svnweb.freebsd.org/changeset/doc/44080 Log: Prep work for merging Advanced Networking NAT section into IPFW Configuring NAT section. Move Configuring NAT to after Example Ruleset. Next commit will start to merge the deleted content into the NAT section. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Wed Feb 26 21:53:13 2014 (r44079) +++ head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Wed Feb 26 22:19:04 2014 (r44080) @@ -48,10 +48,6 @@ - How to set up network address translation. - - - How to set up IPv6 on a &os; machine. @@ -4740,386 +4736,6 @@ Received 264951 bytes in 0.1 seconds - - - Network Address Translation - - - - - Chern - Lee - - Contributed by - - - - - - Overview - - - &man.natd.8; - - - &os;'s Network Address Translation - (NAT) daemon, &man.natd.8;, accepts - incoming raw IP packets, changes the - source to the local machine, and injects these packets back - into the outgoing IP packet stream. The - source IP address and port are changed - such that when data is received back, it is able to determine - the original location of the data and forward it back to its - original requester. - - - Internet connection sharing - - - NAT - - - The most common use of NAT is to - perform what is commonly known as Internet Connection - Sharing. - - - - Setup - - Due to the diminishing IP address - space in IPv4 and the increased number of - users on high-speed consumer lines such as cable or - DSL, people are increasingly in need of - an Internet Connection Sharing solution. The ability to - connect several computers online through one connection and - IP address makes &man.natd.8; a reasonable - choice. - - Most commonly, a user has a machine connected to a cable - or DSL line with one IP - address and wishes to use this one connected computer to - provide Internet access to several more over a - LAN. - - To do this, the &os; machine connected to the Internet - must act as a gateway. This gateway machine must have two - NICs: one connects to the Internet router - and the other connects to a LAN. All the - machines on the LAN are connected through - a hub or switch. - - - There are many ways to get a LAN - connected to the Internet through a &os; gateway. This - example will only cover a gateway with at least two - NICs. - - - - - - - - - _______ __________ ________ - | | | | | | - | Hub |-----| Client B |-----| Router |----- Internet - |_______| |__________| |________| - | - ____|_____ -| | -| Client A | -|__________| - - - - Network Layout - - - - A setup like this is commonly used to share an Internet - connection. One of the LAN machines is - connected to the Internet and the rest of the machines access - the Internet through that gateway - machine. - - - - Boot Loader Configuration - - - boot loader - configuration - - - The kernel features for &man.natd.8; are not enabled in - the GENERIC kernel, but they can be - loaded at boot time by adding a couple of options to - /boot/loader.conf: - - ipfw_load="YES" -ipdivert_load="YES" - - Additionally, the - net.inet.ip.fw.default_to_accept tunable - option should be set to 1: - - net.inet.ip.fw.default_to_accept="1" - - - It is a good idea to set this option during the first - attempts to setup a firewall and NAT - gateway. This sets the default policy of &man.ipfw.8; to - be more permissive than the default deny ip from - any to any, making it slightly more difficult - to get locked out of the system right after a reboot. - - - - - Kernel Configuration - - - kernel - configuration - - - When modules are not an option or if it is preferable to - build all the required features into a custom kernel, the - following options must be in the custom kernel configuration - file: - - options IPFIREWALL -options IPDIVERT - - Additionally, the following may also be suitable: - - options IPFIREWALL_DEFAULT_TO_ACCEPT -options IPFIREWALL_VERBOSE - - - - System Startup Configuration - - To enable firewall and NAT support at - boot time, the following must be in - /etc/rc.conf: - - gateway_enable="YES" -firewall_enable="YES" -firewall_type="OPEN" -natd_enable="YES" -natd_interface="fxp0" -natd_flags="" - - - - Sets up the machine to act as a gateway. Running - sysctl net.inet.ip.forwarding=1 would - have the same effect. - - - - Enables the firewall rules in - /etc/rc.firewall at boot. - - - - This specifies a predefined firewall ruleset that - allows anything in. See - /etc/rc.firewall for additional - types. - - - - Indicates which interface to forward packets through. - This is the interface that is connected to the - Internet. - - - - Any additional configuration options passed to - &man.natd.8; on boot. - - - - These - /etc/rc.conf options will run - natd -interface fxp0 at boot. This can - also be run manually after boot. - - - It is also possible to use a configuration file for - &man.natd.8; when there are too many options to pass. In - this case, the configuration file must be defined by adding - the following line to - /etc/rc.conf: - - natd_flags="-f /etc/natd.conf" - - A list of configuration options, one per line, can be - added to /etc/natd.conf. For - example: - - redirect_port tcp 192.168.0.2:6667 6667 -redirect_port tcp 192.168.0.3:80 80 - - For more information about this configuration file, - consult &man.natd.8;. - - - Each machine and interface behind the - LAN should be assigned - IP addresses in the private network space, - as defined by RFC - 1918, and have a default gateway of the - &man.natd.8; machine's internal IP - address. - - For example, client A and - B behind the LAN - have IP addresses of 192.168.0.2 and 192.168.0.3, while the - &man.natd.8; machine's LAN interface has an - IP address of 192.168.0.1. The default - gateway of clients A and - B must be set to that of the - &man.natd.8; machine, 192.168.0.1. The - &man.natd.8; machine's external Internet interface does not - require any special modification for &man.natd.8; to - work. - - - - Port Redirection - - The drawback with &man.natd.8; is that the - LAN clients are not accessible from the - Internet. Clients on the LAN can make - outgoing connections to the world but cannot receive incoming - ones. This presents a problem if trying to run Internet - services on one of the LAN client machines. - A simple way around this is to redirect selected Internet - ports on the &man.natd.8; machine to a LAN - client. - - For example, an IRC server runs on - client A and a web server runs on - client B. For this to work properly, - connections received on ports 6667 (IRC) - and 80 (HTTP) must be redirected to the - respective machines. - - The syntax for is as - follows: - - -redirect_port proto targetIP:targetPORT[-targetPORT] - [aliasIP:]aliasPORT[-aliasPORT] - [remoteIP[:remotePORT[-remotePORT]]] - - In the above example, the argument should be: - - -redirect_port tcp 192.168.0.2:6667 6667 - -redirect_port tcp 192.168.0.3:80 80 - - This redirects the proper TCP ports - to the LAN client machines. - - Port ranges over individual ports can be indicated with - . For example, - tcp 192.168.0.2:2000-3000 2000-3000 - would redirect all connections received on ports 2000 to 3000 - to ports 2000 to 3000 on client - A. - - These options can be used when directly running - &man.natd.8;, placed within the - natd_flags="" option in - /etc/rc.conf, or passed via a - configuration file. - - For further configuration options, consult - &man.natd.8; - - - - Address Redirection - - - address redirection - - - Address redirection is useful if more than one - IP address is available. Each - LAN client can be assigned its own - external IP address by &man.natd.8;, - which will then rewrite outgoing packets from the - LAN clients with the proper external - IP address and redirects all traffic - incoming on that particular IP address - back to the specific LAN client. This is - also known as static NAT. For example, - if IP addresses 128.1.1.1, 128.1.1.2, and 128.1.1.3 are available, - 128.1.1.1 can be - used as the &man.natd.8; machine's external - IP address, while 128.1.1.2 and 128.1.1.3 are forwarded back - to LAN clients A - and B. - - The syntax is as - follows: - - -redirect_address localIP publicIP - - - - - - - localIP - The internal IP address of - the LAN client. - - - - publicIP - The external IP address - corresponding to the LAN - client. - - - - - - In the example, this argument would read: - - -redirect_address 192.168.0.2 128.1.1.2 --redirect_address 192.168.0.3 128.1.1.3 - - Like , these arguments are - placed within the natd_flags="" option - of /etc/rc.conf, or passed via a - configuration file. With address redirection, there is no - need for port redirection since all data received on a - particular IP address is redirected. - - The external IP addresses on the - &man.natd.8; machine must be active and aliased to the - external interface. Refer to &man.rc.conf.5; for - details. - - - <acronym>IPv6</acronym> Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 26 21:53:13 2014 (r44079) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 26 22:19:04 2014 (r44080) @@ -2120,177 +2120,9 @@ pif="dc0" # interface name of NIC at # Everything else is denied and logged $cmd 00999 deny log all from any to any - - - The <application>IPFW</application> Command - - ipfw - - ipfw can be used to make manual, - single rule additions or deletions to the active firewall - while it is running. The problem with using this method is - that all the changes are lost when the system reboots. It is - recommended to instead write all the rules in a file and to - use that file to load the rules at boot time and to replace - the currently running firewall rules whenever that file - changes. - - ipfw is a useful way to display the - running firewall rules to the console screen. The - IPFW accounting facility - dynamically creates a counter for each rule that counts each - packet that matches the rule. During the process of testing a - rule, listing the rule with its counter is one way to - determine if the rule is functioning as expected. - - To list all the running rules in sequence: - - &prompt.root; ipfw list - - To list all the running rules with a time stamp of when - the last time the rule was matched: - - &prompt.root; ipfw -t list - - The next example lists accounting information and the - packet count for matched rules along with the rules - themselves. The first column is the rule number, followed by - the number of matched packets and bytes, followed by the rule - itself. - - &prompt.root; ipfw -a list - - To list dynamic rules in addition to static rules: - - &prompt.root; ipfw -d list - To also show the expired dynamic rules: - - &prompt.root; ipfw -d -e list - - To zero the counters: - - &prompt.root; ipfw zero - - To zero the counters for just the rule with number - NUM: - - &prompt.root; ipfw zero NUM - - - Logging Firewall Messages - - - IPFW - - logging - - - Even with the logging facility enabled, - IPFW will not generate any rule - logging on its own. The firewall administrator decides - which rules in the ruleset will be logged, and adds the - log keyword to those rules. Normally - only deny rules are logged. It is customary to duplicate - the ipfw default deny everything rule with - the log keyword included as the last rule - in the ruleset. This way, it is possible to see all the - packets that did not match any of the rules in the - ruleset. - - Logging is a two edged sword. If one is not careful, - an over abundance of log data or a DoS attack can fill the - disk with log files. Log messages are not only written to - syslogd, but also are displayed - on the root console screen and soon become annoying. - - The IPFIREWALL_VERBOSE_LIMIT=5 - kernel option limits the number of consecutive messages - sent to &man.syslogd.8;, concerning the packet matching of a - given rule. When this option is enabled in the kernel, the - number of consecutive messages concerning a particular rule - is capped at the number specified. There is nothing to be - gained from 200 identical log messages. With this option - set to five, - five consecutive messages concerning a particular rule - would be logged to syslogd and - the remainder identical consecutive messages would be - counted and posted to syslogd - with a phrase like the following: - - last message repeated 45 times - - All logged packets messages are written by default to - /var/log/security, which is - defined in /etc/syslog.conf. - - - - Building a Rule Script - - Most experienced IPFW users - create a file containing the rules and code them in a manner - compatible with running them as a script. The major benefit - of doing this is the firewall rules can be refreshed in mass - without the need of rebooting the system to activate them. - This method is convenient in testing new rules as the - procedure can be executed as many times as needed. Being a - script, symbolic substitution can be used for frequently - used values to be substituted into multiple rules. - - This example script is compatible with the syntax used - by the &man.sh.1;, &man.csh.1;, and &man.tcsh.1; shells. - Symbolic substitution fields are prefixed with a dollar sign - ($). Symbolic fields do not have the $ - prefix. The value to populate the symbolic field must be - enclosed in double quotes (""). - - Start the rules file like this: - - ############### start of example ipfw rules script ############# -# -ipfw -q -f flush # Delete all rules -# Set defaults -oif="tun0" # out interface -odns="192.0.2.11" # ISP's DNS server IP address -cmd="ipfw -q add " # build rule prefix -ks="keep-state" # just too lazy to key this each time -$cmd 00500 check-state -$cmd 00502 deny all from any to any frag -$cmd 00501 deny tcp from any to any established -$cmd 00600 allow tcp from any to any 80 out via $oif setup $ks -$cmd 00610 allow tcp from any to $odns 53 out via $oif setup $ks -$cmd 00611 allow udp from any to $odns 53 out via $oif $ks -################### End of example ipfw rules script ############ - - The rules are not important as the focus of this example - is how the symbolic substitution fields are - populated. - - If the above example was in - /etc/ipfw.rules, the rules could be - reloaded by the following command: - - &prompt.root; sh /etc/ipfw.rules - - /etc/ipfw.rules can be located - anywhere and the file can have any name. - - The same thing could be accomplished by running these - commands by hand: - - &prompt.root; ipfw -q -f flush -&prompt.root; ipfw -q add check-state -&prompt.root; ipfw -q add deny all from any to any frag -&prompt.root; ipfw -q add deny tcp from any to any established -&prompt.root; ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state -&prompt.root; ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state -&prompt.root; ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state - - - - An Example <acronym>NAT</acronym> and Stateful - Ruleset + + Configuring <acronym>NAT</acronym> NAT @@ -2599,6 +2431,173 @@ pif="rl0" # public interface name of # deny and log all packets that fell through to see what they are $cmd 999 deny log all from any to any ################ End of IPFW rules file ############################### + + + + The <application>IPFW</application> Command + + ipfw + + ipfw can be used to make manual, + single rule additions or deletions to the active firewall + while it is running. The problem with using this method is + that all the changes are lost when the system reboots. It is + recommended to instead write all the rules in a file and to + use that file to load the rules at boot time and to replace + the currently running firewall rules whenever that file + changes. + + ipfw is a useful way to display the + running firewall rules to the console screen. The + IPFW accounting facility + dynamically creates a counter for each rule that counts each + packet that matches the rule. During the process of testing a + rule, listing the rule with its counter is one way to + determine if the rule is functioning as expected. + + To list all the running rules in sequence: + + &prompt.root; ipfw list + + To list all the running rules with a time stamp of when + the last time the rule was matched: + + &prompt.root; ipfw -t list + + The next example lists accounting information and the + packet count for matched rules along with the rules + themselves. The first column is the rule number, followed by + the number of matched packets and bytes, followed by the rule + itself. + + &prompt.root; ipfw -a list + + To list dynamic rules in addition to static rules: + + &prompt.root; ipfw -d list + + To also show the expired dynamic rules: + + &prompt.root; ipfw -d -e list + + To zero the counters: + + &prompt.root; ipfw zero + + To zero the counters for just the rule with number + NUM: + + &prompt.root; ipfw zero NUM + + + Logging Firewall Messages + + + IPFW + + logging + + + Even with the logging facility enabled, + IPFW will not generate any rule + logging on its own. The firewall administrator decides + which rules in the ruleset will be logged, and adds the + log keyword to those rules. Normally + only deny rules are logged. It is customary to duplicate + the ipfw default deny everything rule with + the log keyword included as the last rule + in the ruleset. This way, it is possible to see all the + packets that did not match any of the rules in the + ruleset. + + Logging is a two edged sword. If one is not careful, + an over abundance of log data or a DoS attack can fill the + disk with log files. Log messages are not only written to + syslogd, but also are displayed + on the root console screen and soon become annoying. + + The IPFIREWALL_VERBOSE_LIMIT=5 + kernel option limits the number of consecutive messages + sent to &man.syslogd.8;, concerning the packet matching of a + given rule. When this option is enabled in the kernel, the + number of consecutive messages concerning a particular rule + is capped at the number specified. There is nothing to be + gained from 200 identical log messages. With this option + set to five, + five consecutive messages concerning a particular rule + would be logged to syslogd and + the remainder identical consecutive messages would be + counted and posted to syslogd + with a phrase like the following: + + last message repeated 45 times + + All logged packets messages are written by default to + /var/log/security, which is + defined in /etc/syslog.conf. + + + + Building a Rule Script + + Most experienced IPFW users + create a file containing the rules and code them in a manner + compatible with running them as a script. The major benefit + of doing this is the firewall rules can be refreshed in mass + without the need of rebooting the system to activate them. + This method is convenient in testing new rules as the + procedure can be executed as many times as needed. Being a + script, symbolic substitution can be used for frequently + used values to be substituted into multiple rules. + + This example script is compatible with the syntax used + by the &man.sh.1;, &man.csh.1;, and &man.tcsh.1; shells. + Symbolic substitution fields are prefixed with a dollar sign + ($). Symbolic fields do not have the $ + prefix. The value to populate the symbolic field must be + enclosed in double quotes (""). + + Start the rules file like this: + + ############### start of example ipfw rules script ############# +# +ipfw -q -f flush # Delete all rules +# Set defaults +oif="tun0" # out interface +odns="192.0.2.11" # ISP's DNS server IP address +cmd="ipfw -q add " # build rule prefix +ks="keep-state" # just too lazy to key this each time +$cmd 00500 check-state +$cmd 00502 deny all from any to any frag +$cmd 00501 deny tcp from any to any established +$cmd 00600 allow tcp from any to any 80 out via $oif setup $ks +$cmd 00610 allow tcp from any to $odns 53 out via $oif setup $ks +$cmd 00611 allow udp from any to $odns 53 out via $oif $ks +################### End of example ipfw rules script ############ + + The rules are not important as the focus of this example + is how the symbolic substitution fields are + populated. + + If the above example was in + /etc/ipfw.rules, the rules could be + reloaded by the following command: + + &prompt.root; sh /etc/ipfw.rules + + /etc/ipfw.rules can be located + anywhere and the file can have any name. + + The same thing could be accomplished by running these + commands by hand: + + &prompt.root; ipfw -q -f flush +&prompt.root; ipfw -q add check-state +&prompt.root; ipfw -q add deny all from any to any frag +&prompt.root; ipfw -q add deny tcp from any to any established +&prompt.root; ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state +&prompt.root; ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state +&prompt.root; ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state