diff options
Diffstat (limited to 'en_US.ISO8859-1/books/handbook/firewalls/chapter.xml')
| -rw-r--r-- | en_US.ISO8859-1/books/handbook/firewalls/chapter.xml | 339 |
1 files changed, 169 insertions, 170 deletions
diff --git a/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml b/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml index 4311b79595..85d8c594b9 100644 --- a/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml @@ -2120,177 +2120,9 @@ pif="dc0" # interface name of NIC attached to Internet</programlisting> <programlisting># Everything else is denied and logged $cmd 00999 deny log all from any to any</programlisting> </sect2> - - <sect2 xml:id="firewalls-ipfw-cmd"> - <title>The <application>IPFW</application> Command</title> - - <indexterm><primary><command>ipfw</command></primary></indexterm> - - <para><command>ipfw</command> 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.</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> - - <para>To list all the running rules in sequence:</para> - - <screen>&prompt.root; <userinput>ipfw list</userinput></screen> - - <para>To list all the running rules with a time stamp of when - the last time the rule was matched:</para> - - <screen>&prompt.root; <userinput>ipfw -t list</userinput></screen> - - <para>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.</para> - - <screen>&prompt.root; <userinput>ipfw -a list</userinput></screen> - - <para>To list dynamic rules in addition to static rules:</para> - - <screen>&prompt.root; <userinput>ipfw -d list</userinput></screen> - <para>To also show the expired dynamic rules:</para> - - <screen>&prompt.root; <userinput>ipfw -d -e list</userinput></screen> - - <para>To zero the counters:</para> - - <screen>&prompt.root; <userinput>ipfw zero</userinput></screen> - - <para>To zero the counters for just the rule with number - <replaceable>NUM</replaceable>:</para> - - <screen>&prompt.root; <userinput>ipfw zero NUM</userinput></screen> - - <sect3> - <title>Logging Firewall Messages</title> - - <indexterm> - <primary><application>IPFW</application></primary> - - <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>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 - <application>syslogd</application>, but also are displayed - on the root console screen and soon become annoying.</para> - - <para>The <literal>IPFIREWALL_VERBOSE_LIMIT=5</literal> - 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 <application>syslogd</application> and - the remainder identical consecutive messages would be - counted and posted to <application>syslogd</application> - with a phrase like the following:</para> - - <programlisting>last message repeated 45 times</programlisting> - - <para>All logged packets messages are written by default to - <filename>/var/log/security</filename>, which is - defined in <filename>/etc/syslog.conf</filename>.</para> - </sect3> - - <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>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 ("").</para> - - <para>Start the rules file like this:</para> - - <programlisting>############### 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 ############</programlisting> - - <para>The rules are not important as the focus of this example - is how the symbolic substitution fields are - populated.</para> - - <para>If the above example was in - <filename>/etc/ipfw.rules</filename>, the rules could be - reloaded by the following command:</para> - - <screen>&prompt.root; <userinput>sh /etc/ipfw.rules</userinput></screen> - - <para><filename>/etc/ipfw.rules</filename> can be located - anywhere and the file can have any name.</para> - - <para>The same thing could be accomplished by running these - commands by hand:</para> - - <screen>&prompt.root; <userinput>ipfw -q -f flush</userinput> -&prompt.root; <userinput>ipfw -q add check-state</userinput> -&prompt.root; <userinput>ipfw -q add deny all from any to any frag</userinput> -&prompt.root; <userinput>ipfw -q add deny tcp from any to any established</userinput> -&prompt.root; <userinput>ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state</userinput> -&prompt.root; <userinput>ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state</userinput> -&prompt.root; <userinput>ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state</userinput></screen> - </sect3> - - <sect3> - <title>An Example <acronym>NAT</acronym> and Stateful - Ruleset</title> + <sect2 xml:id="network-natd"> + <title>Configuring <acronym>NAT</acronym></title> <indexterm> <primary>NAT</primary> @@ -2599,6 +2431,173 @@ pif="rl0" # public interface name of NIC # 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 ###############################</programlisting> + </sect2> + + <sect2 xml:id="firewalls-ipfw-cmd"> + <title>The <application>IPFW</application> Command</title> + + <indexterm><primary><command>ipfw</command></primary></indexterm> + + <para><command>ipfw</command> 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.</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> + + <para>To list all the running rules in sequence:</para> + + <screen>&prompt.root; <userinput>ipfw list</userinput></screen> + + <para>To list all the running rules with a time stamp of when + the last time the rule was matched:</para> + + <screen>&prompt.root; <userinput>ipfw -t list</userinput></screen> + + <para>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.</para> + + <screen>&prompt.root; <userinput>ipfw -a list</userinput></screen> + + <para>To list dynamic rules in addition to static rules:</para> + + <screen>&prompt.root; <userinput>ipfw -d list</userinput></screen> + + <para>To also show the expired dynamic rules:</para> + + <screen>&prompt.root; <userinput>ipfw -d -e list</userinput></screen> + + <para>To zero the counters:</para> + + <screen>&prompt.root; <userinput>ipfw zero</userinput></screen> + + <para>To zero the counters for just the rule with number + <replaceable>NUM</replaceable>:</para> + + <screen>&prompt.root; <userinput>ipfw zero NUM</userinput></screen> + + <sect3> + <title>Logging Firewall Messages</title> + + <indexterm> + <primary><application>IPFW</application></primary> + + <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>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 + <application>syslogd</application>, but also are displayed + on the root console screen and soon become annoying.</para> + + <para>The <literal>IPFIREWALL_VERBOSE_LIMIT=5</literal> + 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 <application>syslogd</application> and + the remainder identical consecutive messages would be + counted and posted to <application>syslogd</application> + with a phrase like the following:</para> + + <programlisting>last message repeated 45 times</programlisting> + + <para>All logged packets messages are written by default to + <filename>/var/log/security</filename>, which is + defined in <filename>/etc/syslog.conf</filename>.</para> + </sect3> + + <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>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 ("").</para> + + <para>Start the rules file like this:</para> + + <programlisting>############### 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 ############</programlisting> + + <para>The rules are not important as the focus of this example + is how the symbolic substitution fields are + populated.</para> + + <para>If the above example was in + <filename>/etc/ipfw.rules</filename>, the rules could be + reloaded by the following command:</para> + + <screen>&prompt.root; <userinput>sh /etc/ipfw.rules</userinput></screen> + + <para><filename>/etc/ipfw.rules</filename> can be located + anywhere and the file can have any name.</para> + + <para>The same thing could be accomplished by running these + commands by hand:</para> + + <screen>&prompt.root; <userinput>ipfw -q -f flush</userinput> +&prompt.root; <userinput>ipfw -q add check-state</userinput> +&prompt.root; <userinput>ipfw -q add deny all from any to any frag</userinput> +&prompt.root; <userinput>ipfw -q add deny tcp from any to any established</userinput> +&prompt.root; <userinput>ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state</userinput> +&prompt.root; <userinput>ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state</userinput> +&prompt.root; <userinput>ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state</userinput></screen> </sect3> </sect2> </sect1> |