Date: Tue, 25 Feb 2014 19:40:14 +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: r44057 - head/en_US.ISO8859-1/books/handbook/firewalls Message-ID: <201402251940.s1PJeE0u078960@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: dru Date: Tue Feb 25 19:40:13 2014 New Revision: 44057 URL: http://svnweb.freebsd.org/changeset/doc/44057 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 Tue Feb 25 19:00:35 2014 (r44056) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 25 19:40:13 2014 (r44057) @@ -78,12 +78,11 @@ </itemizedlist> <para>&os; has three firewalls built into the base system: - <application>PF</application>, - <application>IPFW</application>, and <application>IPFILTER</application>, also known as - <application>IPF</application>. - &os; also provides two traffic shapers for controlling bandwidth - usage: &man.altq.4; and &man.dummynet.4;. - <application>ALTQ</application> has + <application>PF</application>, <application>IPFW</application>, + and <application>IPFILTER</application>, also known as + <application>IPF</application>. &os; also provides two traffic + shapers for controlling bandwidth usage: &man.altq.4; and + &man.dummynet.4;. <application>ALTQ</application> has traditionally been closely tied with <application>PF</application> and <application>dummynet</application> with @@ -1593,23 +1592,23 @@ block drop out quick on $ext_if from any <secondary>IPFW</secondary> </indexterm> - <para><application>IPFW</application> is a stateful firewall written for - &os; which supports both <acronym>IPv4</acronym> - and <acronym>IPv6</acronym>. It is comprised of several components: the kernel firewall - filter rule processor and its integrated packet accounting - facility, the logging facility, - <acronym>NAT</acronym>, the &man.dummynet.4; traffic shaper, - a forward facility, a bridge - facility, and an ipstealth facility.</para> + <para><application>IPFW</application> is a stateful firewall + written for &os; which supports both <acronym>IPv4</acronym> and + <acronym>IPv6</acronym>. It is comprised of several components: + the kernel firewall filter rule processor and its integrated + packet accounting facility, the logging facility, + <acronym>NAT</acronym>, the &man.dummynet.4; traffic shaper, a + forward facility, a bridge facility, and an ipstealth + facility.</para> <para>&os; provides a sample ruleset in - <filename>/etc/rc.firewall</filename> which - defines several firewall types for common scenarios to assist - novice users in generating an appropriate ruleset. - <application>IPFW</application> provides a powerful syntax which advanced users can - use to craft customized rulesets that meet the security - requirements of a given environment.</para> - + <filename>/etc/rc.firewall</filename> which defines several + firewall types for common scenarios to assist novice users in + generating an appropriate ruleset. + <application>IPFW</application> provides a powerful syntax which + advanced users can use to craft customized rulesets that meet + the security requirements of a given environment.</para> + <para>This section describes how to enable <application>IPFW</application>, provides an overview of its rule syntax, and demonstrates several rulesets for common @@ -1624,8 +1623,10 @@ block drop out quick on $ext_if from any <secondary>enabling</secondary> </indexterm> - <para><application>IPFW</application> is included in the basic &os; install as a kernel - loadable module, meaning that a custom kernel is not needed in order to enable <application>IPFW</application>.</para> + <para><application>IPFW</application> is included in the basic + &os; install as a kernel loadable module, meaning that a + custom kernel is not needed in order to enable + <application>IPFW</application>.</para> <indexterm> <primary>kernel options</primary> @@ -1669,8 +1670,8 @@ options IPDIVERT # enables NAT</pro <programlisting>firewall_enable="YES"</programlisting> - <para>To use one of the default firewall types provided by - &os;, add another line which specifies the type:</para> + <para>To use one of the default firewall types provided by &os;, + add another line which specifies the type:</para> <programlisting>firewall_type="open"</programlisting> @@ -1701,19 +1702,18 @@ options IPDIVERT # enables NAT</pro firewall rules.</para> </listitem> <listitem> - <para><filename>filename</filename>: - full path of the file containing the firewall - rules.</para> + <para><filename>filename</filename>: full path of the file + containing the firewall rules.</para> </listitem> </itemizedlist> - <para>To instead load a custom ruleset, either - set the <filename>filename</filename> value of + <para>To instead load a custom ruleset, either set the + <filename>filename</filename> value of <literal>firewall_type</literal> or set the <literal>firewall_script</literal> variable to the absolute path of an executable script that includes - <command>IPFW</command> commands. This example script - blocks all incoming and outgoing traffic:</para> + <command>IPFW</command> commands. This example script blocks + all incoming and outgoing traffic:</para> <programlisting>#!/bin/sh @@ -1750,10 +1750,9 @@ ipfw add deny out</programlisting> </warning> <para>If the machine is acting as a gateway providing - <acronym>NAT</acronym> using &man.natd.8;, - refer to <xref linkend="network-natd"/> for information - regarding the required <filename>/etc/rc.conf</filename> - options.</para> + <acronym>NAT</acronym> using &man.natd.8;, refer to <xref + linkend="network-natd"/> for information regarding the + required <filename>/etc/rc.conf</filename> options.</para> </sect2> <sect2 xml:id="firewalls-ipfw-cmd"> @@ -1771,12 +1770,12 @@ ipfw add deny out</programlisting> changes.</para> <para><command>ipfw</command> is a useful way to display the - running firewall rules to the console screen. The <application>IPFW</application> - 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.</para> + running firewall rules to the console screen. The + <application>IPFW</application> 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.</para> <para>To list all the running rules in sequence:</para> @@ -1830,13 +1829,14 @@ ipfw add deny out</programlisting> action field value 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, which denies all packets and silently - discards them. However, if the packet matches a rule that - contains the <literal>count</literal>, - <literal>skipto</literal>, or <literal>tee</literal> keywords, - the search continues. Refer to &man.ipfw.8; for details on - how these keywords affect rule processing.</para> + any of the rules, it gets caught by the mandatory + <application>IPFW</application> default rule, number 65535, + which denies all packets and silently discards them. However, + if the packet matches a rule that contains the + <literal>count</literal>, <literal>skipto</literal>, or + <literal>tee</literal> keywords, the search continues. Refer + to &man.ipfw.8; for details on how these keywords affect rule + processing.</para> <para>The examples in this section create an inclusive type firewall ruleset containing the stateful <literal>keep @@ -1845,212 +1845,219 @@ ipfw add deny out</programlisting> <literal>via</literal> options. For a complete rule syntax description, refer to &man.ipfw.8;.</para> - <indexterm> - <primary><application>IPFW</application></primary> + <indexterm> + <primary><application>IPFW</application></primary> - <secondary>rule syntax</secondary> - </indexterm> + <secondary>rule syntax</secondary> + </indexterm> - <para>This section describes the keywords which comprise an - <application>IPFW</application> rule. Keywords must be written in - the following order. <literal>#</literal> is used to mark - the start of a comment and may appear at the end of a rule - line or on its own line. Blank lines are ignored.</para> + <para>This section describes the keywords which comprise an + <application>IPFW</application> rule. Keywords must be + written in the following order. <literal>#</literal> is used + to mark the start of a comment and may appear at the end of a + rule line or on its own line. Blank lines are ignored.</para> - <para><replaceable>CMD RULE_NUMBER ACTION LOGGING SELECTION - STATEFUL</replaceable></para> + <para><replaceable>CMD RULE_NUMBER ACTION LOGGING SELECTION + STATEFUL</replaceable></para> - <variablelist> - <varlistentry> + <variablelist> + <varlistentry> <term>CMD</term> <listitem> - <para>Each new rule has to be prefixed with - <parameter>add</parameter> to add the rule to the internal - table.</para> - </listitem> - </varlistentry> + <para>Each new rule has to be prefixed with + <parameter>add</parameter> to add the rule to the + internal table.</para> + </listitem> + </varlistentry> <varlistentry> <term>RULE_NUMBER</term> <listitem> - <para>Each rule is associated with a rule_number in the - range of <literal>1</literal> to - <literal>65535</literal>.</para> - </listitem> - </varlistentry> + <para>Each rule is associated with a rule_number in the + range of <literal>1</literal> to + <literal>65535</literal>.</para> + </listitem> + </varlistentry> <varlistentry> <term>ACTION</term> <listitem> - <para>A rule can be associated with one of the following - actions. The specified action will be executed when the - packet matches the selection criterion of the rule.</para> - - <para><parameter>allow | accept | pass | - permit</parameter></para> - - <para>These keywords are equivalent as they allow packets - that match the rule to exit the firewall rule processing. - The search terminates at this rule.</para> - - <para><parameter>check-state</parameter></para> - - <para>Checks the packet against the dynamic rules 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 <literal>limit</literal> - rule.</para> - - <para><parameter>deny | drop</parameter></para> - - <para>Both words mean the same thing, which is to discard - packets that match this rule. The search - terminates.</para> - </listitem> - </varlistentry> + <para>A rule can be associated with one of the following + actions. The specified action will be executed when the + packet matches the selection criterion of the + rule.</para> + + <para><parameter>allow | accept | pass | + permit</parameter></para> + + <para>These keywords are equivalent as they allow packets + that match the rule to exit the firewall rule + processing. The search terminates at this rule.</para> + + <para><parameter>check-state</parameter></para> + + <para>Checks the packet against the dynamic rules 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 + <literal>limit</literal> rule.</para> + + <para><parameter>deny | drop</parameter></para> + + <para>Both words mean the same thing, which is to discard + packets that match this rule. The search + terminates.</para> + </listitem> + </varlistentry> <varlistentry> <term>Logging</term> <listitem> - <para>When a packet matches a rule with the - <literal>log</literal> keyword, a message will be logged - 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 <literal>logamount</literal> parameter. If no - <literal>logamount</literal> is specified, the limit is - taken from the <command>sysctl</command> value of - <varname>net.inet.ip.fw.verbose_limit</varname>. In both - cases, 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 - conditions have been met, and before performing the - final action on the packet. The administrator decides - which rules to enable logging on.</para> - </note> - </listitem> - </varlistentry> + <para>When a packet matches a rule with the + <literal>log</literal> keyword, a message will be logged + 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 <literal>logamount</literal> parameter. + If no <literal>logamount</literal> is specified, the + limit is taken from the <command>sysctl</command> value + of <varname>net.inet.ip.fw.verbose_limit</varname>. In + both cases, 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 + conditions have been met, and before performing the + final action on the packet. The administrator decides + which rules to enable logging on.</para> + </note> + </listitem> + </varlistentry> <varlistentry> <term>Selection</term> <listitem> - <para>The keywords described in this section are used to - describe attributes of the packet to be checked when - determining whether rules match the packet or not. - The following general-purpose attributes are provided for - matching, and must be used in this order:</para> - - <para><parameter>udp | tcp | icmp</parameter></para> - - <para>Any other protocol names found in - <filename>/etc/protocols</filename> can be used. The - value specified is the protocol to be matched against. - This is a mandatory keyword.</para> - - <para><parameter>from src to dst</parameter></para> - - <para>The <literal>from</literal> and <literal>to</literal> - keywords are used to match against IP addresses. Rules - must specify <emphasis>both</emphasis> source and - destination parameters. <literal>any</literal> is a - special keyword that matches any IP address. - <literal>me</literal> is a special keyword that matches - any IP address configured on an interface in the &os; - system to represent the PC the firewall is running on. - Example usage includes <literal>from me to any</literal>, - <literal>from any to me</literal>, - <literal>from 0.0.0.0/0 to any</literal>, - <literal>from any to 0.0.0.0/0</literal>, - <literal>from 0.0.0.0 to any</literal>, - <literal>from any to 0.0.0.0</literal>, - and <literal>from me to 0.0.0.0</literal>. IP addresses - are specified in dotted IP address format followed by the - mask in CIDR notation, or as a single host in dotted IP - address format. This keyword is a mandatory requirement. - The <package>net-mgmt/ipcalc</package> port may be used to - assist the mask calculation.</para> - - <para><parameter>port number</parameter></para> - - <para>For protocols which support port numbers, such as - <acronym>TCP</acronym> and <acronym>UDP</acronym>, it - is mandatory to include the port number of the service - that will be matched. Service names from - <filename>/etc/services</filename> may be used instead - of numeric port values.</para> - - <para><parameter>in | out</parameter></para> - - <para>Matches incoming or outgoing packets. It is mandatory - that one or the other is included as part of the rule - matching criterion.</para> - - <para><parameter>via IF</parameter></para> - - <para>Matches packets going through the interface specified - by device name. The <literal>via</literal> keyword causes - the interface to always be checked as part of the match - process.</para> - - <para><parameter>setup</parameter></para> - - <para>This mandatory keyword identifies the session start - request for <acronym>TCP</acronym> packets.</para> - - <para><parameter>keep-state</parameter></para> - - <para>This is a mandatory keyword. Upon a match, the - firewall will create a dynamic rule, whose default - behavior is to match bidirectional traffic between source - and destination IP/port using the same protocol.</para> - - <para><parameter>limit {src-addr | src-port | dst-addr | - dst-port}</parameter></para> - - <para>The firewall will only allow - <replaceable>N</replaceable> connections with the same - set of parameters as specified in the rule. One or more - of source and destination addresses and ports can be - specified. <literal>limit</literal> and - <literal>keep-state</literal> can not be used on the same - rule as they provide the same stateful function.</para> - </listitem> - </varlistentry> + <para>The keywords described in this section are used to + describe attributes of the packet to be checked when + determining whether rules match the packet or not. The + following general-purpose attributes are provided for + matching, and must be used in this order:</para> + + <para><parameter>udp | tcp | icmp</parameter></para> + + <para>Any other protocol names found in + <filename>/etc/protocols</filename> can be used. The + value specified is the protocol to be matched against. + This is a mandatory keyword.</para> + + <para><parameter>from src to dst</parameter></para> + + <para>The <literal>from</literal> and + <literal>to</literal> keywords are used to match against + IP addresses. Rules must specify + <emphasis>both</emphasis> source and destination + parameters. <literal>any</literal> is a special keyword + that matches any IP address. <literal>me</literal> is a + special keyword that matches any IP address configured + on an interface in the &os; system to represent the PC + the firewall is running on. Example usage includes + <literal>from me to any</literal>, + <literal>from any to me</literal>, + <literal>from 0.0.0.0/0 to any</literal>, + <literal>from any to 0.0.0.0/0</literal>, + <literal>from 0.0.0.0 to any</literal>, + <literal>from any to 0.0.0.0</literal>, and + <literal>from me to 0.0.0.0</literal>. IP addresses + are specified in dotted IP address format followed by + the mask in CIDR notation, or as a single host in dotted + IP address format. This keyword is a mandatory + requirement. The <package>net-mgmt/ipcalc</package> + port may be used to assist the mask calculation.</para> + + <para><parameter>port number</parameter></para> + + <para>For protocols which support port numbers, such as + <acronym>TCP</acronym> and <acronym>UDP</acronym>, it is + mandatory to include the port number of the service + that will be matched. Service names from + <filename>/etc/services</filename> may be used instead + of numeric port values.</para> + + <para><parameter>in | out</parameter></para> + + <para>Matches incoming or outgoing packets. It is + mandatory that one or the other is included as part of + the rule matching criterion.</para> + + <para><parameter>via IF</parameter></para> + + <para>Matches packets going through the interface + specified by device name. The <literal>via</literal> + keyword causes the interface to always be checked as + part of the match process.</para> + + <para><parameter>setup</parameter></para> + + <para>This mandatory keyword identifies the session start + request for <acronym>TCP</acronym> packets.</para> + + <para><parameter>keep-state</parameter></para> + + <para>This is a mandatory keyword. Upon a match, the + firewall will create a dynamic rule, whose default + behavior is to match bidirectional traffic between + source and destination IP/port using the same + protocol.</para> + + <para><parameter>limit {src-addr | src-port | dst-addr | + dst-port}</parameter></para> + + <para>The firewall will only allow + <replaceable>N</replaceable> connections with the same + set of parameters as specified in the rule. One or more + of source and destination addresses and ports can be + specified. <literal>limit</literal> and + <literal>keep-state</literal> can not be used on the + same rule as they provide the same stateful + function.</para> + </listitem> + </varlistentry> - <varlistentry> - <term>Stateful Rule Option</term> - <listitem> - <para>The <literal>check-state</literal> option is used to - identify where in the <application>IPFW</application> ruleset the packet is to be - tested against the dynamic rules facility. On a match, the - packet exits the firewall to continue on its way and a new - rule is dynamically created for the next anticipated packet - being exchanged during this session. On a no match, the - packet advances to the next rule in the ruleset for - testing.</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 keyword limits the number of simultaneous sessions by - checking that rule's source or destinations fields and using - the packet's IP address in a search of the open dynamic - rules, counting the number of times this rule and IP address - combination occurred. If this count is greater than the - value specified by <literal>limit</literal>, the packet is - discarded.</para> - </listitem> - </varlistentry> - </variablelist> + <varlistentry> + <term>Stateful Rule Option</term> + <listitem> + <para>The <literal>check-state</literal> option is used to + identify where in the <application>IPFW</application> + ruleset the packet is to be tested against the dynamic + rules facility. On a match, the packet exits the + firewall to continue on its way and a new rule is + dynamically created for the next anticipated packet + being exchanged during this session. On a no match, the + packet advances to the next rule in the ruleset for + testing.</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 keyword limits the + number of simultaneous sessions by checking that rule's + source or destinations fields and using the packet's IP + address in a search of the open dynamic rules, counting + the number of times this rule and IP address + combination occurred. If this count is greater than the + value specified by <literal>limit</literal>, the packet + is discarded.</para> + </listitem> + </varlistentry> + </variablelist> <sect3> <title>Logging Firewall Messages</title> @@ -2061,16 +2068,17 @@ ipfw add deny out</programlisting> <secondary>logging</secondary> </indexterm> - <para>Even with the logging facility enabled, <application>IPFW</application> will not - generate any rule logging on its own. The firewall - administrator decides which rules in the ruleset will be - logged, and adds the <literal>log</literal> keyword to those - rules. Normally only deny rules are logged. It is - customary to duplicate the <quote>ipfw default deny - everything</quote> rule with the <literal>log</literal> - 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.</para> + <para>Even with the logging facility enabled, + <application>IPFW</application> will not generate any rule + logging on its own. The firewall administrator decides + which rules in the ruleset will be logged, and adds the + <literal>log</literal> keyword to those rules. Normally + only deny rules are logged. It is customary to duplicate + the <quote>ipfw default deny everything</quote> rule with + the <literal>log</literal> 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.</para> <para>Logging is a two edged sword. If one is not careful, an over abundance of log data or a DoS attack can fill the @@ -2102,15 +2110,15 @@ ipfw add deny out</programlisting> <sect3 xml:id="firewalls-ipfw-rules-script"> <title>Building a Rule Script</title> - <para>Most experienced <application>IPFW</application> 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.</para> + <para>Most experienced <application>IPFW</application> 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.</para> <para>This example script is compatible with the syntax used by the &man.sh.1;, &man.csh.1;, and &man.tcsh.1; shells. @@ -2367,12 +2375,13 @@ pif="dc0" # public interface name of <para>There are some additional configuration statements that need to be enabled to activate the <acronym>NAT</acronym> - function of <application>IPFW</application>. For a customized kernel, the kernel - configuration file needs + function of <application>IPFW</application>. For a + customized kernel, the kernel configuration file needs <literal>option IPDIVERT</literal> added to the other <literal>IPFIREWALL</literal> options.</para> - <para>In addition to the normal <application>IPFW</application> options in + <para>In addition to the normal + <application>IPFW</application> options in <filename>/etc/rc.conf</filename>, the following are needed:</para> @@ -2380,10 +2389,9 @@ pif="dc0" # public interface name of natd_interface="rl0" # interface name of public Internet NIC natd_flags="-dynamic -m" # -m = preserve port numbers if possible</programlisting> - <para>Utilizing stateful rules with a - <literal>divert natd</literal> rule complicates the ruleset - logic. The positioning of the - <literal>check-state</literal>, and + <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 @@ -3442,8 +3450,9 @@ map dc0 10.0.10.0/29 -> 0/32</program <acronym>NAT</acronym> if they match the third rule.</para> <para>Without the <acronym>FTP</acronym> proxy, the following - firewall rules would instead be needed. Note that without the proxy, - all ports above <literal>1024</literal> need to be allowed:</para> + firewall rules would instead be needed. Note that without the + proxy, all ports above <literal>1024</literal> need to be + allowed:</para> <programlisting># Allow out LAN PC client FTP to public Internet # Active and passive modes @@ -3455,13 +3464,13 @@ pass out quick on rl0 proto tcp from any # Active mode let data channel in from FTP server pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state</programlisting> - <para>Whenever the file containing the <acronym>NAT</acronym> rules - is edited, run - <command>ipnat</command> with <option>-CF</option> to delete - the current <acronym>NAT</acronym> rules and flush the - contents of the dynamic translation table. Include - <option>-f</option> and specify the name - of the <acronym>NAT</acronym> ruleset to load:</para> + <para>Whenever the file containing the <acronym>NAT</acronym> + rules is edited, run <command>ipnat</command> with + <option>-CF</option> to delete the current + <acronym>NAT</acronym> rules and flush the contents of the + dynamic translation table. Include <option>-f</option> and + specify the name of the <acronym>NAT</acronym> ruleset to + load:</para> <screen>&prompt.root; <userinput>ipnat -CF -f /etc/ipnat.rules</userinput></screen> @@ -3633,35 +3642,35 @@ sh /etc/ipf.rules.script</programlisting TCP cksum fails(in): 0 (out): 0 Packet log flags set: (0)</screen> - <para>Several options are available. When supplied with either <option>-i</option> for inbound - or <option>-o</option> for outbound, the command will retrieve - and display the appropriate list of filter rules currently - installed and in use by the kernel. To also see the rule - numbers, include <option>-n</option>. For example, - <command>ipfstat -on</command> displays the outbound - rules table with rule numbers:</para> + <para>Several options are available. When supplied with either + <option>-i</option> for inbound or <option>-o</option> for + outbound, the command will retrieve and display the + appropriate list of filter rules currently installed and in + use by the kernel. To also see the rule numbers, include + <option>-n</option>. For example, <command>ipfstat + -on</command> displays the outbound rules table with rule + numbers:</para> <screen>@1 pass out on xl0 from any to any @2 block out on dc0 from any to any @3 pass out quick on dc0 proto tcp/udp from any to any keep state</screen> - <para>Include <option>-h</option> to - prefix each rule with a count of how - many times the rule was matched. For example, - <command>ipfstat -oh</command> displays the outbound - internal rules table, prefixing each rule with its usage count:</para> + <para>Include <option>-h</option> to prefix each rule with a + count of how many times the rule was matched. For example, + <command>ipfstat -oh</command> displays the outbound internal + rules table, prefixing each rule with its usage count:</para> <screen>2451423 pass out on xl0 from any to any 354727 block out on dc0 from any to any 430918 pass out quick on dc0 proto tcp/udp from any to any keep state</screen> - <para>To display the state table in a format similar to &man.top.1;, use - <command>ipfstat -t</command>. When the firewall is - under attack, this option provides the ability to identify - and see the attacking packets. The optional sub-flags give - the ability to select the destination or source <acronym>IP</acronym>, port, or - protocol to be monitored in real time. Refer to - &man.ipfstat.8; for details.</para> + <para>To display the state table in a format similar to + &man.top.1;, use <command>ipfstat -t</command>. When the + firewall is under attack, this option provides the ability to + identify and see the attacking packets. The optional + sub-flags give the ability to select the destination or source + <acronym>IP</acronym>, port, or protocol to be monitored in + real time. Refer to &man.ipfstat.8; for details.</para> </sect2> <sect2> @@ -3676,16 +3685,17 @@ sh /etc/ipf.rules.script</programlisting </indexterm> <para><application>IPF</application> provides - <command>ipmon</command>, which can be used to write the firewall's logging - information in a human readable format. It requires that - <literal>options IPFILTER_LOG</literal> be first added - to a custom kernel using the instructions in <xref linkend="kernelconfig"/>.</para> - - <para>This command is typically run in - daemon mode in order to provide a continuous system log file so that - logging of past events may be reviewed. Since &os; has a built in - &man.syslogd.8; facility to automatically rotate system logs, the default - <filename>rc.conf</filename> + <command>ipmon</command>, which can be used to write the + firewall's logging information in a human readable format. It + requires that <literal>options IPFILTER_LOG</literal> be first + added to a custom kernel using the instructions in <xref + linkend="kernelconfig"/>.</para> + + <para>This command is typically run in daemon mode in order to + provide a continuous system log file so that logging of past + events may be reviewed. Since &os; has a built in + &man.syslogd.8; facility to automatically rotate system logs, + the default <filename>rc.conf</filename> <literal>ipmon_flags</literal> statement uses <option>-Ds</option>:</para> @@ -3701,20 +3711,19 @@ sh /etc/ipf.rules.script</programlisting <para>Once the logging facility is enabled in <filename>rc.conf</filename> and started with <command>service - ipmon start</command>, <application>IPF</application> will only - log the rules which contain the <literal>log</literal> keyword. The firewall - administrator decides which rules in the ruleset should be - logged and normally - only deny rules are logged. It is customary to include the - <literal>log</literal> keyword in the - last rule in the ruleset. This makes it possible to see all - the packets that did not match any of the rules in the - ruleset.</para> + ipmon start</command>, <application>IPF</application> will + only log the rules which contain the <literal>log</literal> + keyword. The firewall administrator decides which rules in + the ruleset should be logged and normally only deny rules are + logged. It is customary to include the + <literal>log</literal> keyword in the last rule in the + ruleset. This makes it possible to see all the packets that + did not match any of the rules in the ruleset.</para> <para>By default, <command>ipmon -Ds</command> mode uses - <literal>local0</literal> as - the logging facility. The following logging levels can be - used to further segregate the logged data:</para> + <literal>local0</literal> as the logging facility. The + following logging levels can be used to further segregate the + logged data:</para> <screen>LOG_INFO - packets logged using the "log" keyword as the action rather than pass or block. LOG_NOTICE - packets logged which are also passed @@ -3798,11 +3807,13 @@ LOG_ERR - packets which have been logged letters corresponding to any flags that were set. Refer to &man.ipf.5; for a list of letters and their flags.</para> - <para>If the packet is an <acronym>ICMP</acronym> packet, there will be two fields - at the end: the first always being <quote>icmp</quote> and - the next being the <acronym>ICMP</acronym> message and sub-message type, - separated by a slash. For example: <literal>icmp 3/3</literal> for a port - unreachable message.</para> + <para>If the packet is an <acronym>ICMP</acronym> packet, there + will be two fields at the end: the first always being + <quote>icmp</quote> and the next being the + <acronym>ICMP</acronym> message and sub-message type, + separated by a slash. For example: + <literal>icmp 3/3</literal> for a port unreachable + message.</para> </sect2> </sect1> - </chapter> +</chapter>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201402251940.s1PJeE0u078960>