Date: Wed, 26 Feb 2014 23:44:34 +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: r44083 - head/en_US.ISO8859-1/books/handbook/firewalls Message-ID: <201402262344.s1QNiYqI071931@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: dru Date: Wed Feb 26 23:44:33 2014 New Revision: 44083 URL: http://svnweb.freebsd.org/changeset/doc/44083 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 Wed Feb 26 23:14:36 2014 (r44082) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 26 23:44:33 2014 (r44083) @@ -1708,40 +1708,39 @@ options IPDIVERT # enables NAT</pro </itemizedlist> <para>If <literal>firewall_type</literal> is set to either - <literal>client</literal> or <literal>simple</literal>, - modify the default rules found in - <filename>/etc/rc.firewall</filename> to fit the - configuration of the system.</para> + <literal>client</literal> or <literal>simple</literal>, + modify the default rules found in + <filename>/etc/rc.firewall</filename> to fit the + configuration of the system.</para> - <para>Note that the - <literal>filename</literal> type is used to load a custom ruleset.</para> + <para>Note that the <literal>filename</literal> type is used to + load a custom ruleset.</para> <para>An alternate way to load a custom ruleset is to set the <literal>firewall_script</literal> variable to the absolute - path of an <emphasis>executable script</emphasis> that includes - <application>IPFW</application> commands. The examples used in this - section assume that the <literal>firewall_script</literal> - is set to <filename>/etc/ipfw.rules</filename>:</para> + path of an <emphasis>executable script</emphasis> that + includes <application>IPFW</application> commands. The + examples used in this section assume that the + <literal>firewall_script</literal> is set to + <filename>/etc/ipfw.rules</filename>:</para> - <programlisting>firewall_script="/etc/ipfw.rules"</programlisting> + <programlisting>firewall_script="/etc/ipfw.rules"</programlisting> <para>To enable logging, include this line:</para> <programlisting>firewall_logging="YES"</programlisting> - <para>There is no - <filename>/etc/rc.conf</filename> variable to set logging - limits. To limit the number of times a rule is logged - per connection attempt, specify the number using this line - in - <filename>/etc/sysctl.conf</filename>:</para> + <para>There is no <filename>/etc/rc.conf</filename> variable to + set logging limits. To limit the number of times a rule is + logged per connection attempt, specify the number using this + line in <filename>/etc/sysctl.conf</filename>:</para> <programlisting>net.inet.ip.fw.verbose_limit=<replaceable>5</replaceable></programlisting> - + <para>After saving the needed edits, start the firewall. To enable logging limits now, also set the <command>sysctl</command> value specified above:</para> - + <screen>&prompt.root; <userinput>service ipfw start</userinput> &prompt.root; <userinput>sysctl net.inet.ip.fw.verbose_limit=<replaceable>5</replaceable></userinput></screen> </sect2> @@ -1755,13 +1754,12 @@ options IPDIVERT # enables NAT</pro <secondary>rule processing order</secondary> </indexterm> - <para>When a packet enters the <application>IPFW</application> firewall, - it is compared against the first rule in the ruleset and - progresses one rule at a time, moving from top to bottom in - sequence. When the - packet matches the selection parameters of a rule, the rule's - action is executed and the search of the ruleset - terminates for that packet. This is referred to as + <para>When a packet enters the <application>IPFW</application> + firewall, it is compared against the first rule in the ruleset + and progresses one rule at a time, moving from top to bottom + in sequence. When the packet matches the selection parameters + of a rule, the rule's action is executed and the search of the + ruleset terminates for that packet. This is referred to as <quote>first match wins</quote>. If the packet does not match any of the rules, it gets caught by the mandatory <application>IPFW</application> default rule number 65535, @@ -1781,19 +1779,20 @@ options IPDIVERT # enables NAT</pro <para>When creating an <application>IPFW</application> rule, keywords must be written in the following order. Some keywords are mandatory - while other keywords are optional. The words shown in uppercase - represent a variable and the words shown in lowercase must - precede the variable that follows it. The <literal>#</literal> symbol is used - to mark the start of a comment and may appear at the end of a - rule or on its own line. Blank lines are ignored.</para> + while other keywords are optional. The words shown in + uppercase represent a variable and the words shown in + lowercase must precede the variable that follows it. The + <literal>#</literal> symbol is used to mark the start of a + comment and may appear at the end of a rule or on its own + line. Blank lines are ignored.</para> <para><replaceable>CMD RULE_NUMBER set SET_NUMBER ACTION log - LOG_AMOUNT PROTO from SRC SRC_PORT to DST DST_PORT + LOG_AMOUNT PROTO from SRC SRC_PORT to DST DST_PORT OPTIONS</replaceable></para> <para>This section provides an overview of these keywords and - their options. It is not an exhaustive list of every possible - option. Refer to &man.ipfw.8; for a complete description of + their options. It is not an exhaustive list of every possible + option. Refer to &man.ipfw.8; for a complete description of the rule syntax that can be used when creating <application>IPFW</application> rules.</para> @@ -1812,9 +1811,10 @@ options IPDIVERT # enables NAT</pro <para>Each rule is associated with a number in the range of <literal>1</literal> to <literal>65534</literal>. The number is used to - indicate the order of rule processing. Multiple rules can have the same - number, in which case they are checked according to - the order in which they have been added.</para> + indicate the order of rule processing. Multiple rules + can have the same number, in which case they are checked + according to the order in which they have been + added.</para> </listitem> </varlistentry> @@ -1822,13 +1822,12 @@ options IPDIVERT # enables NAT</pro <term>SET_NUMBER</term> <listitem> <para>Each rule is associated with a set number in the - range of <literal>0</literal> to - <literal>31</literal>. Sets can be individually - disabled or enabled, making it possible to quickly add - or delete a set of rules. If a SET_NUMBER is not - specified, the rule will be added to set <literal>0</literal>.</para> - - </listitem> + range of <literal>0</literal> to <literal>31</literal>. + Sets can be individually disabled or enabled, making it + possible to quickly add or delete a set of rules. If a + SET_NUMBER is not specified, the rule will be added to + set <literal>0</literal>.</para> + </listitem> </varlistentry> <varlistentry> @@ -1840,14 +1839,15 @@ options IPDIVERT # enables NAT</pro rule.</para> <para><parameter>allow | accept | pass | - permit</parameter>: these keywords are equivalent and allow packets - that match the rule.</para> + permit</parameter>: these keywords are equivalent and + allow packets that match the rule.</para> - <para><parameter>check-state</parameter>: checks the packet against the dynamic state table. - If a match is found, execute the action associated with - the rule which generated this dynamic rule, otherwise - move to the next rule. A <literal>check-state</literal> - rule does not have selection criterion. If no + <para><parameter>check-state</parameter>: checks the + packet against the dynamic state table. If a match is + found, execute the action associated with the rule which + generated this dynamic rule, otherwise move to the next + rule. A <literal>check-state</literal> rule does not + have selection criterion. If no <literal>check-state</literal> rule is present in the ruleset, the dynamic rules table is checked at the first <literal>keep-state</literal> or @@ -1857,9 +1857,9 @@ options IPDIVERT # enables NAT</pro all packets that match rule. The search continues with the next rule.</para> - <para><parameter>deny | drop</parameter>: either word discards - packets that match this rule.</para> - + <para><parameter>deny | drop</parameter>: either word + discards packets that match this rule.</para> + <para>Additional actions are available. Refer to &man.ipfw.8; for details.</para> </listitem> @@ -1873,15 +1873,14 @@ options IPDIVERT # enables NAT</pro to &man.syslogd.8; with a facility name of <literal>SECURITY</literal>. Logging only occurs if the number of packets logged for that particular rule does - not exceed the optional specified LOG_AMOUNT. - If no LOG_AMOUNT is specified, the - limit is taken from the value - of <varname>net.inet.ip.fw.verbose_limit</varname>. A - value of zero removes the logging limit. - Once the limit is reached, logging can be re-enabled by - clearing the logging counter or the packet counter for - that rule, using <command>ipfw reset - log</command>.</para> + not exceed the optional specified LOG_AMOUNT. If no + LOG_AMOUNT is specified, the limit is taken from the + value of + <varname>net.inet.ip.fw.verbose_limit</varname>. A + value of zero removes the logging limit. Once the limit + is reached, logging can be re-enabled by clearing the + logging counter or the packet counter for that rule, + using <command>ipfw reset log</command>.</para> <note> <para>Logging is done after all other packet matching @@ -1898,25 +1897,25 @@ options IPDIVERT # enables NAT</pro <para>This optional value can be used to specify any protocol name or number found in <filename>/etc/protocols</filename>.</para> - </listitem> - </varlistentry> + </listitem> + </varlistentry> <varlistentry> <term>SRC</term> <listitem> - <para>The <literal>from</literal> - keyword must be followed by the source address or a - keyword that represents the source address. An address - can be represented by the <literal>any</literal>, - <literal>me</literal> (any address configured on an - interface on this system), + <para>The <literal>from</literal> keyword must be followed + by the source address or a keyword that represents the + source address. An address can be represented by the + <literal>any</literal>, <literal>me</literal> (any + address configured on an interface on this system), <literal>me6</literal>, (any <acronym>IPv6</acronym> address configured on an interface on this system), or <literal>table</literal> followed by the number of a lookup table which contains a list of addresses. When specifying an <acronym>IP</acronym> address, it can be optionally followed by its <acronym>CIDR</acronym> mask - or subnet mask. For example, <literal>1.2.3.4/25</literal> or + or subnet mask. For example, + <literal>1.2.3.4/25</literal> or <literal>1.2.3.4:255.255.255.128</literal>.</para> </listitem> </varlistentry> @@ -1934,10 +1933,10 @@ options IPDIVERT # enables NAT</pro <term>DST</term> <listitem> <para>The <literal>to</literal> keyword must be followed - by the destination address or a - keyword that represents the destination address. The - same keywords and addresses described in the SRC section - can be used to describe the destination.</para> + by the destination address or a keyword that represents + the destination address. The same keywords and + addresses described in the SRC section can be used to + describe the destination.</para> </listitem> </varlistentry> @@ -1956,28 +1955,29 @@ options IPDIVERT # enables NAT</pro <para>Several keywords can follow the source and destination. As the name suggests, OPTIONS are optional. Commonly used options include - <literal>in</literal> or - <literal>out</literal>, which specify the direction of - packet flow, <literal>icmptypes</literal> followed by - the type of <acronym>ICMP</acronym> message, and + <literal>in</literal> or <literal>out</literal>, which + specify the direction of packet flow, + <literal>icmptypes</literal> followed by the type of + <acronym>ICMP</acronym> message, and <literal>keep-state</literal>.</para> - <para>When a <parameter>keep-state</parameter> rule is matched, the - firewall will create a dynamic rule which - matches bidirectional traffic between the - source and destination addresses and ports using the same + <para>When a <parameter>keep-state</parameter> rule is + matched, the firewall will create a dynamic rule which + matches bidirectional traffic between the source and + destination addresses and ports using the same protocol.</para> <para>The dynamic rules facility is vulnerable to resource depletion from a SYN-flood attack which would open a huge number of dynamic rules. To counter this type of attack with <application>IPFW</application>, use - <literal>limit</literal>. This option limits the - number of simultaneous sessions by checking the open dynamic rules, counting - the number of times this rule and <acronym>IP</acronym> address - combination occurred. If this count is greater than the - value specified by <literal>limit</literal>, the packet - is discarded.</para> + <literal>limit</literal>. This option limits the number + of simultaneous sessions by checking the open dynamic + rules, counting the number of times this rule and + <acronym>IP</acronym> address combination occurred. If + this count is greater than the value specified by + <literal>limit</literal>, the packet is + discarded.</para> <para>Dozens of OPTIONS are available. Refer to &man.ipfw.8; for a description of each available @@ -1988,38 +1988,38 @@ options IPDIVERT # enables NAT</pro </sect2> <sect2> - <title>Example Ruleset</title> + <title>Example Ruleset</title> - <para>This section demonstrates how to create an example - stateful firewall ruleset script named - <filename>/etc/ipfw.rules</filename>. In this example, all - connection rules use <literal>in</literal> or - <literal>out</literal> to clarify the direction. They also - use <literal>via</literal> - <replaceable>interface-name</replaceable> to specify - the interface the packet is traveling over.</para> - - <note> - <para>When first creating or testing a firewall ruleset, - consider temporarily setting this tunable:</para> - - <programlisting>net.inet.ip.fw.default_to_accept="1"</programlisting> - - <para>This sets the default policy of &man.ipfw.8; to - be more permissive than the default <literal>deny ip from - any to any</literal>, making it slightly more difficult - to get locked out of the system right after a reboot.</para> + <para>This section demonstrates how to create an example + stateful firewall ruleset script named + <filename>/etc/ipfw.rules</filename>. In this example, all + connection rules use <literal>in</literal> or + <literal>out</literal> to clarify the direction. They also + use <literal>via</literal> + <replaceable>interface-name</replaceable> to specify + the interface the packet is traveling over.</para> + + <note> + <para>When first creating or testing a firewall ruleset, + consider temporarily setting this tunable:</para> + + <programlisting>net.inet.ip.fw.default_to_accept="1"</programlisting> + + <para>This sets the default policy of &man.ipfw.8; to be more + permissive than the default <literal>deny ip from any to + any</literal>, making it slightly more difficult to get + locked out of the system right after a reboot.</para> </note> - <para>The firewall script begins by indicating that it is a - Bourne shell script and flushes any existing rules. It then - creates the <literal>cmd</literal> variable so that - <literal>ipfw add</literal> does not have to be typed at the - beginning of every rule. It also defines the - <literal>pif</literal> variable which represents the name of - the interface that is attached to the Internet.</para> + <para>The firewall script begins by indicating that it is a + Bourne shell script and flushes any existing rules. It then + creates the <literal>cmd</literal> variable so that + <literal>ipfw add</literal> does not have to be typed at the + beginning of every rule. It also defines the + <literal>pif</literal> variable which represents the name of + the interface that is attached to the Internet.</para> - <programlisting>#!/bin/sh + <programlisting>#!/bin/sh # Flush out the list before we begin. ipfw -q -f flush @@ -2027,24 +2027,24 @@ ipfw -q -f flush cmd="ipfw -q add" pif="dc0" # interface name of NIC attached to Internet</programlisting> - <para>The first two rules allow all traffic on the trusted - internal interface and on the loopback interface:</para> + <para>The first two rules allow all traffic on the trusted + internal interface and on the loopback interface:</para> - <programlisting># Change xl0 to LAN NIC interface name + <programlisting># Change xl0 to LAN NIC interface name $cmd 00005 allow all from any to any via xl0 # No restrictions on Loopback Interface $cmd 00010 allow all from any to any via lo0</programlisting> - <para>The next rule allows the packet through if it matches - an existing entry in the dynamic rules table:</para> + <para>The next rule allows the packet through if it matches an + existing entry in the dynamic rules table:</para> - <programlisting>$cmd 00015 check-state</programlisting> + <programlisting>$cmd 00015 check-state</programlisting> - <para>The next set of rules defines which stateful connections - internal systems can create to hosts on the Internet:</para> + <para>The next set of rules defines which stateful connections + internal systems can create to hosts on the Internet:</para> - <programlisting># Allow access to public DNS + <programlisting># Allow access to public DNS # Replace x.x.x.x with the IP address of a public DNS server # and repeat for each DNS server in /etc/resolv.conf $cmd 00110 allow tcp from any to x.x.x.x 53 out via $pif setup keep-state @@ -2076,14 +2076,14 @@ pif="dc0" # interface name of NIC at # deny and log all other outbound connections $cmd 00299 deny log all from any to any out via $pif</programlisting> - <para>The next set of rules controls connections from - Internet hosts to the internal network. It starts by - denying packets typically associated with attacks and then - explicitly allows specific types of connections. All the - authorized services that originate from the Internet use - <literal>limit</literal> to prevent flooding.</para> + <para>The next set of rules controls connections from Internet + hosts to the internal network. It starts by denying packets + typically associated with attacks and then explicitly allows + specific types of connections. All the authorized services + that originate from the Internet use <literal>limit</literal> + to prevent flooding.</para> - <programlisting># Deny all inbound traffic from non-routable reserved address spaces + <programlisting># Deny all inbound traffic from non-routable reserved address spaces $cmd 00300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP $cmd 00301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918 private IP $cmd 00302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918 private IP @@ -2125,50 +2125,49 @@ pif="dc0" # interface name of NIC at # Reject and log all other incoming connections $cmd 00499 deny log all from any to any in via $pif</programlisting> - <para>The last rule logs all packets that do not match any of - the rules in the - ruleset:</para> + <para>The last rule logs all packets that do not match any of + the rules in the ruleset:</para> - <programlisting># Everything else is denied and logged + <programlisting># Everything else is denied and logged $cmd 00999 deny log all from any to any</programlisting> - </sect2> + </sect2> - <sect2 xml:id="network-natd"> - <info> + <sect2 xml:id="network-natd"> + <info> <title>Configuring <acronym>NAT</acronym></title> <authorgroup> - <author> - <personname> - <firstname>Chern</firstname> - <surname>Lee</surname> - </personname> - <contrib>Contributed by </contrib> - </author> - </authorgroup> - </info> - <indexterm> - <primary>NAT</primary> + <author> + <personname> + <firstname>Chern</firstname> + <surname>Lee</surname> + </personname> + <contrib>Contributed by </contrib> + </author> + </authorgroup> + </info> + <indexterm> + <primary>NAT</primary> - <secondary>and <application>IPFW</application></secondary> - </indexterm> + <secondary>and <application>IPFW</application></secondary> + </indexterm> - <para>&os;'s built-in - <acronym>NAT</acronym> daemon, &man.natd.8;, works in - conjunction with <application>IPFW</application> to provide - network address translation. This can be used to provide an - Internet Connection Sharing solution so that - several internal computers can connect to the Internet using - <acronym>IP</acronym> address.</para> + <para>&os;'s built-in <acronym>NAT</acronym> daemon, + &man.natd.8;, works in conjunction with + <application>IPFW</application> to provide network address + translation. This can be used to provide an Internet + Connection Sharing solution so that several internal computers + can connect to the Internet using <acronym>IP</acronym> + address.</para> - <para>To do this, the &os; machine connected to the Internet + <para>To do this, the &os; machine connected to the Internet must act as a gateway. This gateway machine must have two <acronym>NIC</acronym>s: one connects to the Internet router and the other connects to a <acronym>LAN</acronym>. All the machines on the <acronym>LAN</acronym> are connected through a hub or switch.</para> - <para>Each machine and interface behind the + <para>Each machine and interface behind the <acronym>LAN</acronym> should be assigned <acronym>IP</acronym> addresses in the private network space, as defined by <link @@ -2177,18 +2176,18 @@ pif="dc0" # interface name of NIC at &man.natd.8; machine's internal <acronym>IP</acronym> address.</para> - <para>Some additional configuration is - needed in order to activate the <acronym>NAT</acronym> - function of <application>IPFW</application>. If the system - has a custom kernel, the kernel configuration file needs to - include <literal>option IPDIVERT</literal> with the other - <literal>IPFIREWALL</literal> options.</para> - - <para>To enable firewall and <acronym>NAT</acronym> support at - boot time, the following must be in - <filename>/etc/rc.conf</filename>:</para> + <para>Some additional configuration is needed in order to + activate the <acronym>NAT</acronym> function of + <application>IPFW</application>. If the system has a custom + kernel, the kernel configuration file needs to include + <literal>option IPDIVERT</literal> with the other + <literal>IPFIREWALL</literal> options.</para> + + <para>To enable firewall and <acronym>NAT</acronym> support at + boot time, the following must be in + <filename>/etc/rc.conf</filename>:</para> - <programlisting>gateway_enable="YES" # enables the gateway function + <programlisting>gateway_enable="YES" # enables the gateway function natd_enable="YES" # enables the <acronym>NAT</acronym> function natd_interface="rl0" # specify interface name of NIC attached to Internet natd_flags="-dynamic -m" # -m = preserve port numbers if possible</programlisting> @@ -2213,87 +2212,87 @@ redirect_port tcp 192.168.0.3:80 80</pro consult &man.natd.8;.</para> </note> - <para>Utilizing stateful rules with a <literal>divert - natd</literal> rule complicates the ruleset logic. The - positioning of the <literal>check-state</literal>, and - <literal>divert natd</literal> rules in the ruleset is - critical and a new action type is used, called - <literal>skipto</literal>. When using - <literal>skipto</literal>, it is mandatory that each rule is - numbered, so that the <literal>skipto</literal> rule knows - which rule to jump to.</para> - - <para>The following is an uncommented example of a ruleset - which explains the sequence of the packet flow.</para> - - <para>The processing flow starts with the first rule from the - top of the ruleset and progresses one rule at a time until - the end is reached or the packet matches and the packet is - released out of the firewall. Take note of the location of - rule numbers 100 101, 450, 500, and 510. These rules - control the translation of the outbound and inbound packets - so that their entries in the dynamic keep-state table always - register the private LAN IP address. All the allow and deny - rules specify the direction of the packet and the interface. - All start outbound session requests will - <literal>skipto rule 500</literal> to undergo NAT.</para> - - <para>Consider a web browser which initializes a new HTTP - session over port 80. When the first outbound packet enters - the firewall, it does not match rule 100 because it is - headed out rather than in. It passes rule 101 because this - is the first packet, and it has not been posted to the - dynamic keep-state table yet. The packet finally matches - rule 125 as it is outbound through the NIC facing the - Internet and has a source IP address as a private LAN IP - address. On matching this rule, two actions take place. - <literal>keep-state</literal> adds this rule to the dynamic - keep-state rules table and the specified action is executed - and posted as part of the info in the dynamic table. In - this case, the action is <literal>skipto rule 500</literal>. - Rule 500 <acronym>NAT</acronym>s the packet IP address and - sends it out to the Internet. This packet makes its way to - the destination web server, where a response packet is - generated and sent back. This new packet enters the top of - the ruleset. It matches rule 100 and has it destination IP - address mapped back to the corresponding LAN IP address. It - then is processed by the <literal>check-state</literal> - rule, is found in the table as an existing session, and is - released to the LAN. It goes to the LAN system that sent it - and a new packet is sent requesting another segment of the - data from the remote server. This time it matches the - <literal>check-state</literal> rule, its outbound entry is - found, and the associated action, - <literal>skipto 500</literal>, is executed. The packet - jumps to rule 500, gets <acronym>NAT</acronym>ed, and is - released to the Internet.</para> - - <para>On the inbound side, everything coming in that is part - of an existing session is automatically handled by the - <literal>check-state</literal> rule and the properly placed - <literal>divert natd</literal> rules. The ruleset only has - to deny bad packets and allow only authorized services. - Consider a web server running on the firewall where web - requests from the Internet should have access to the local - web site. An inbound start request packet will match rule - 100 and its IP address will be mapped to the LAN IP address - of the firewall. The packet is then matched against all the - nasty things that need to be checked and finally matches - rule 425 where two actions occur. The packet rule is posted - to the dynamic keep-state table but this time, any new - session requests originating from that source IP address are - limited to 2. This defends against DoS attacks against the - service running on the specified port number. The action is - <literal>allow</literal>, so the packet is released to the - LAN. The packet generated as a response is recognized by the - <literal>check-state</literal> as belonging to an existing - session. It is then sent to rule 500 for - <acronym>NAT</acronym>ing and released to the outbound - interface.</para> + <para>Utilizing stateful rules with a <literal>divert + natd</literal> rule complicates the ruleset logic. The + positioning of the <literal>check-state</literal>, and + <literal>divert natd</literal> rules in the ruleset is + critical and a new action type is used, called + <literal>skipto</literal>. When using + <literal>skipto</literal>, it is mandatory that each rule is + numbered, so that the <literal>skipto</literal> rule knows + which rule to jump to.</para> + + <para>The following is an uncommented example of a ruleset + which explains the sequence of the packet flow.</para> + + <para>The processing flow starts with the first rule from the + top of the ruleset and progresses one rule at a time until + the end is reached or the packet matches and the packet is + released out of the firewall. Take note of the location of + rule numbers 100 101, 450, 500, and 510. These rules + control the translation of the outbound and inbound packets + so that their entries in the dynamic keep-state table always + register the private LAN IP address. All the allow and deny + rules specify the direction of the packet and the interface. + All start outbound session requests will + <literal>skipto rule 500</literal> to undergo NAT.</para> + + <para>Consider a web browser which initializes a new HTTP + session over port 80. When the first outbound packet enters + the firewall, it does not match rule 100 because it is + headed out rather than in. It passes rule 101 because this + is the first packet, and it has not been posted to the + dynamic keep-state table yet. The packet finally matches + rule 125 as it is outbound through the NIC facing the + Internet and has a source IP address as a private LAN IP + address. On matching this rule, two actions take place. + <literal>keep-state</literal> adds this rule to the dynamic + keep-state rules table and the specified action is executed + and posted as part of the info in the dynamic table. In + this case, the action is <literal>skipto rule 500</literal>. + Rule 500 <acronym>NAT</acronym>s the packet IP address and + sends it out to the Internet. This packet makes its way to + the destination web server, where a response packet is + generated and sent back. This new packet enters the top of + the ruleset. It matches rule 100 and has it destination IP + address mapped back to the corresponding LAN IP address. It + then is processed by the <literal>check-state</literal> + rule, is found in the table as an existing session, and is + released to the LAN. It goes to the LAN system that sent it + and a new packet is sent requesting another segment of the + data from the remote server. This time it matches the + <literal>check-state</literal> rule, its outbound entry is + found, and the associated action, + <literal>skipto 500</literal>, is executed. The packet + jumps to rule 500, gets <acronym>NAT</acronym>ed, and is + released to the Internet.</para> + + <para>On the inbound side, everything coming in that is part of + an existing session is automatically handled by the + <literal>check-state</literal> rule and the properly placed + <literal>divert natd</literal> rules. The ruleset only has + to deny bad packets and allow only authorized services. + Consider a web server running on the firewall where web + requests from the Internet should have access to the local + web site. An inbound start request packet will match rule + 100 and its IP address will be mapped to the LAN IP address + of the firewall. The packet is then matched against all the + nasty things that need to be checked and finally matches + rule 425 where two actions occur. The packet rule is posted + to the dynamic keep-state table but this time, any new + session requests originating from that source IP address are + limited to 2. This defends against DoS attacks against the + service running on the specified port number. The action is + <literal>allow</literal>, so the packet is released to the + LAN. The packet generated as a response is recognized by the + <literal>check-state</literal> as belonging to an existing + session. It is then sent to rule 500 for + <acronym>NAT</acronym>ing and released to the outbound + interface.</para> - <para>Example Ruleset #1:</para> + <para>Example Ruleset #1:</para> - <programlisting>#!/bin/sh + <programlisting>#!/bin/sh cmd="ipfw -q add" skip="skipto 500" pif=rl0 @@ -2340,13 +2339,13 @@ ipfw -q -f flush ######################## end of rules ##################</programlisting> - <para>The next example is functionally equivalent, but uses - descriptive comments to help the inexperienced IPFW rule - writer to better understand what the rules are doing.</para> + <para>The next example is functionally equivalent, but uses + descriptive comments to help the inexperienced IPFW rule + writer to better understand what the rules are doing.</para> - <para>Example Ruleset #2:</para> + <para>Example Ruleset #2:</para> - <programlisting>#!/bin/sh + <programlisting>#!/bin/sh ################ Start of IPFW rules file ############################### # Flush out the list before we begin. ipfw -q -f flush @@ -2499,130 +2498,132 @@ pif="rl0" # public interface name of $cmd 999 deny log all from any to any ################ End of IPFW rules file ###############################</programlisting> - <sect3> - <title>Port Redirection</title> + <sect3> + <title>Port Redirection</title> - <para>The drawback with &man.natd.8; is that the - <acronym>LAN</acronym> clients are not accessible from the - Internet. Clients on the <acronym>LAN</acronym> 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 <acronym>LAN</acronym> client machines. - A simple way around this is to redirect selected Internet - ports on the &man.natd.8; machine to a <acronym>LAN</acronym> - client.</para> - - <para>For example, an <acronym>IRC</acronym> server runs on - client <systemitem>A</systemitem> and a web server runs on - client <systemitem>B</systemitem>. For this to work properly, - connections received on ports 6667 (<acronym>IRC</acronym>) - and 80 (<acronym>HTTP</acronym>) must be redirected to the - respective machines.</para> + <para>The drawback with &man.natd.8; is that the + <acronym>LAN</acronym> clients are not accessible from the + Internet. Clients on the <acronym>LAN</acronym> 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 <acronym>LAN</acronym> + client machines. A simple way around this is to redirect + selected Internet ports on the &man.natd.8; machine to a + <acronym>LAN</acronym> client.</para> + + <para>For example, an <acronym>IRC</acronym> server runs on + client <systemitem>A</systemitem> and a web server runs on + client <systemitem>B</systemitem>. For this to work + properly, connections received on ports 6667 + (<acronym>IRC</acronym>) and 80 (<acronym>HTTP</acronym>) + must be redirected to the respective machines.</para> - <para>The syntax for <option>-redirect_port</option> is as - follows:</para> + <para>The syntax for <option>-redirect_port</option> is as + follows:</para> - <programlisting> -redirect_port proto targetIP:targetPORT[-targetPORT] + <programlisting> -redirect_port proto targetIP:targetPORT[-targetPORT] [aliasIP:]aliasPORT[-aliasPORT] [remoteIP[:remotePORT[-remotePORT]]]</programlisting> - <para>In the above example, the argument should be:</para> + <para>In the above example, the argument should be:</para> - <programlisting> -redirect_port tcp 192.168.0.2:6667 6667 + <programlisting> -redirect_port tcp 192.168.0.2:6667 6667 -redirect_port tcp 192.168.0.3:80 80</programlisting> - <para>This redirects the proper <acronym>TCP</acronym> ports - to the <acronym>LAN</acronym> client machines.</para> + <para>This redirects the proper <acronym>TCP</acronym> ports + to the <acronym>LAN</acronym> client machines.</para> - <para>Port ranges over individual ports can be indicated with - <option>-redirect_port</option>. For example, - <replaceable>tcp 192.168.0.2:2000-3000 2000-3000</replaceable> - would redirect all connections received on ports 2000 to 3000 - to ports 2000 to 3000 on client - <systemitem>A</systemitem>.</para> - - <para>These options can be used when directly running - &man.natd.8;, placed within the - <literal>natd_flags=""</literal> option in - <filename>/etc/rc.conf</filename>, or passed via a - configuration file.</para> - - <para>For further configuration options, consult - &man.natd.8;</para> - </sect3> + <para>Port ranges over individual ports can be indicated with + <option>-redirect_port</option>. For example, + <replaceable>tcp 192.168.0.2:2000-3000 + 2000-3000</replaceable> would redirect all connections + received on ports 2000 to 3000 to ports 2000 to 3000 on + client <systemitem>A</systemitem>.</para> + + <para>These options can be used when directly running + &man.natd.8;, placed within the + <literal>natd_flags=""</literal> option in + <filename>/etc/rc.conf</filename>, or passed via a + configuration file.</para> - <sect3> - <title>Address Redirection</title> + <para>For further configuration options, consult + &man.natd.8;</para> + </sect3> - <indexterm> - <primary>address redirection</primary> - </indexterm> + <sect3> + <title>Address Redirection</title> - <para>Address redirection is useful if more than one - <acronym>IP</acronym> address is available. Each - <acronym>LAN</acronym> client can be assigned its own - external <acronym>IP</acronym> address by &man.natd.8;, - which will then rewrite outgoing packets from the - <acronym>LAN</acronym> clients with the proper external - <acronym>IP</acronym> address and redirects all traffic - incoming on that particular <acronym>IP</acronym> address - back to the specific <acronym>LAN</acronym> client. This is - also known as static <acronym>NAT</acronym>. For example, - if <acronym>IP</acronym> addresses <systemitem - class="ipaddress">128.1.1.1</systemitem>, <systemitem - class="ipaddress">128.1.1.2</systemitem>, and <systemitem - class="ipaddress">128.1.1.3</systemitem> are available, - <systemitem class="ipaddress">128.1.1.1</systemitem> can be - used as the &man.natd.8; machine's external - <acronym>IP</acronym> address, while <systemitem - class="ipaddress">128.1.1.2</systemitem> and <systemitem - class="ipaddress">128.1.1.3</systemitem> are forwarded back - to <acronym>LAN</acronym> clients <systemitem>A</systemitem> - and <systemitem>B</systemitem>.</para> - - <para>The <option>-redirect_address</option> syntax is as - follows:</para> - - <programlisting>-redirect_address localIP publicIP</programlisting> - - - <informaltable frame="none" pgwide="1"> - <tgroup cols="2"> - <tbody> - <row> - <entry>localIP</entry> - <entry>The internal <acronym>IP</acronym> address of - the <acronym>LAN</acronym> client.</entry> - </row> - - <row> - <entry>publicIP</entry> - <entry>The external <acronym>IP</acronym> address - corresponding to the <acronym>LAN</acronym> - client.</entry> - </row> - </tbody> - </tgroup> - </informaltable> + <indexterm> + <primary>address redirection</primary> + </indexterm> - <para>In the example, this argument would read:</para> + <para>Address redirection is useful if more than one + <acronym>IP</acronym> address is available. Each + <acronym>LAN</acronym> client can be assigned its own + external <acronym>IP</acronym> address by &man.natd.8;, + which will then rewrite outgoing packets from the + <acronym>LAN</acronym> clients with the proper external + <acronym>IP</acronym> address and redirects all traffic + incoming on that particular <acronym>IP</acronym> address + back to the specific <acronym>LAN</acronym> client. This is + also known as static <acronym>NAT</acronym>. For example, + if <acronym>IP</acronym> addresses <systemitem + class="ipaddress">128.1.1.1</systemitem>, <systemitem + class="ipaddress">128.1.1.2</systemitem>, and <systemitem + class="ipaddress">128.1.1.3</systemitem> are available, + <systemitem class="ipaddress">128.1.1.1</systemitem> can be + used as the &man.natd.8; machine's external + <acronym>IP</acronym> address, while <systemitem + class="ipaddress">128.1.1.2</systemitem> and <systemitem + class="ipaddress">128.1.1.3</systemitem> are forwarded + back to <acronym>LAN</acronym> clients + <systemitem>A</systemitem> and + <systemitem>B</systemitem>.</para> + + <para>The <option>-redirect_address</option> syntax is as + follows:</para> + + <programlisting>-redirect_address localIP publicIP</programlisting> + + + <informaltable frame="none" pgwide="1"> + <tgroup cols="2"> + <tbody> + <row> + <entry>localIP</entry> + <entry>The internal <acronym>IP</acronym> address of + the <acronym>LAN</acronym> client.</entry> + </row> + + <row> + <entry>publicIP</entry> + <entry>The external <acronym>IP</acronym> address + corresponding to the <acronym>LAN</acronym> + client.</entry> + </row> + </tbody> + </tgroup> + </informaltable> - <programlisting>-redirect_address 192.168.0.2 128.1.1.2 + <para>In the example, this argument would read:</para> + + <programlisting>-redirect_address 192.168.0.2 128.1.1.2 -redirect_address 192.168.0.3 128.1.1.3</programlisting> - <para>Like <option>-redirect_port</option>, these arguments are - placed within the <literal>natd_flags=""</literal> option - of <filename>/etc/rc.conf</filename>, or passed via a - configuration file. With address redirection, there is no - need for port redirection since all data received on a - particular <acronym>IP</acronym> address is redirected.</para> - - <para>The external <acronym>IP</acronym> addresses on the - &man.natd.8; machine must be active and aliased to the - external interface. Refer to &man.rc.conf.5; for - details.</para> - </sect3> -</sect2> + <para>Like <option>-redirect_port</option>, these arguments + are placed within the <literal>natd_flags=""</literal> + option of <filename>/etc/rc.conf</filename>, or passed via a + configuration file. With address redirection, there is no + need for port redirection since all data received on a + particular <acronym>IP</acronym> address is + redirected.</para> + + <para>The external <acronym>IP</acronym> addresses on the + &man.natd.8; machine must be active and aliased to the + external interface. Refer to &man.rc.conf.5; for + details.</para> + </sect3> + </sect2> <sect2 xml:id="firewalls-ipfw-cmd"> <title>The <application>IPFW</application> Command</title>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201402262344.s1QNiYqI071931>