diff options
| author | Dru Lavigne <dru@FreeBSD.org> | 2014-02-26 22:19:04 +0000 |
|---|---|---|
| committer | Dru Lavigne <dru@FreeBSD.org> | 2014-02-26 22:19:04 +0000 |
| commit | 64070fd28642d8d721a82958c02188c1a8595a22 (patch) | |
| tree | 7bf6a62d5d314a04d83aa9c7e2f99724c507bd57 /en_US.ISO8859-1/books/handbook/firewalls/chapter.xml | |
| parent | c7a70e1afa0f5d70b3ffa70cdc86e44e10649844 (diff) | |
| download | doc-64070fd28642d8d721a82958c02188c1a8595a22.tar.gz doc-64070fd28642d8d721a82958c02188c1a8595a22.zip | |
Prep work for merging Advanced Networking NAT section
into IPFW Configuring NAT section.
Move Configuring NAT to after Example Ruleset.
Next commit will start to merge the deleted content
into the NAT section.
Sponsored by: iXsystems
Notes
Notes:
svn path=/head/; revision=44080
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> |