Date: Wed, 26 Feb 2014 22:19:05 +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: r44080 - in head/en_US.ISO8859-1/books/handbook: advanced-networking firewalls Message-ID: <201402262219.s1QMJ53n033818@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: dru Date: Wed Feb 26 22:19:04 2014 New Revision: 44080 URL: http://svnweb.freebsd.org/changeset/doc/44080 Log: Prep work for merging Advanced Networking NAT section into IPFW Configuring NAT section. Move Configuring NAT to after Example Ruleset. Next commit will start to merge the deleted content into the NAT section. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Wed Feb 26 21:53:13 2014 (r44079) +++ head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Wed Feb 26 22:19:04 2014 (r44080) @@ -48,10 +48,6 @@ </listitem> <listitem> - <para>How to set up network address translation.</para> - </listitem> - - <listitem> <para>How to set up <acronym>IPv6</acronym> on a &os; machine.</para> </listitem> @@ -4740,386 +4736,6 @@ Received 264951 bytes in 0.1 seconds</sc </sect2> </sect1> - <sect1 xml:id="network-natd"> - <info> - <title>Network Address Translation</title> - - <authorgroup> - <author> - <personname> - <firstname>Chern</firstname> - <surname>Lee</surname> - </personname> - <contrib>Contributed by </contrib> - </author> - </authorgroup> - </info> - - <sect2 xml:id="network-natoverview"> - <title>Overview</title> - - <indexterm> - <primary>&man.natd.8;</primary> - </indexterm> - - <para>&os;'s Network Address Translation - (<acronym>NAT</acronym>) daemon, &man.natd.8;, accepts - incoming raw <acronym>IP</acronym> packets, changes the - source to the local machine, and injects these packets back - into the outgoing <acronym>IP</acronym> packet stream. The - source <acronym>IP</acronym> address and port are changed - such that when data is received back, it is able to determine - the original location of the data and forward it back to its - original requester.</para> - - <indexterm> - <primary>Internet connection sharing</primary> - </indexterm> - <indexterm> - <primary><acronym>NAT</acronym></primary> - </indexterm> - - <para>The most common use of <acronym>NAT</acronym> is to - perform what is commonly known as Internet Connection - Sharing.</para> - </sect2> - - <sect2 xml:id="network-natsetup"> - <title>Setup</title> - - <para>Due to the diminishing <acronym>IP</acronym> address - space in <acronym>IPv4</acronym> and the increased number of - users on high-speed consumer lines such as cable or - <acronym>DSL</acronym>, people are increasingly in need of - an Internet Connection Sharing solution. The ability to - connect several computers online through one connection and - <acronym>IP</acronym> address makes &man.natd.8; a reasonable - choice.</para> - - <para>Most commonly, a user has a machine connected to a cable - or <acronym>DSL</acronym> line with one <acronym>IP</acronym> - address and wishes to use this one connected computer to - provide Internet access to several more over a - <acronym>LAN</acronym>.</para> - - <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> - - <note> - <para>There are many ways to get a <acronym>LAN</acronym> - connected to the Internet through a &os; gateway. This - example will only cover a gateway with at least two - <acronym>NIC</acronym>s.</para> - </note> - - <mediaobject> - <imageobject> - <imagedata fileref="advanced-networking/natd"/> - </imageobject> - - <textobject> - <literallayout class="monospaced"> _______ __________ ________ - | | | | | | - | Hub |-----| Client B |-----| Router |----- Internet - |_______| |__________| |________| - | - ____|_____ -| | -| Client A | -|__________|</literallayout> - </textobject> - - <textobject> - <phrase>Network Layout</phrase> - </textobject> - </mediaobject> - - <para>A setup like this is commonly used to share an Internet - connection. One of the <acronym>LAN</acronym> machines is - connected to the Internet and the rest of the machines access - the Internet through that <quote>gateway</quote> - machine.</para> - </sect2> - - <sect2 xml:id="network-natdloaderconfiguration"> - <title>Boot Loader Configuration</title> - - <indexterm> - <primary>boot loader</primary> - <secondary>configuration</secondary> - </indexterm> - - <para>The kernel features for &man.natd.8; are not enabled in - the <filename>GENERIC</filename> kernel, but they can be - loaded at boot time by adding a couple of options to - <filename>/boot/loader.conf</filename>:</para> - - <programlisting>ipfw_load="YES" -ipdivert_load="YES"</programlisting> - - <para>Additionally, the - <literal>net.inet.ip.fw.default_to_accept</literal> tunable - option should be set to <literal>1</literal>:</para> - - <programlisting>net.inet.ip.fw.default_to_accept="1"</programlisting> - - <note> - <para>It is a good idea to set this option during the first - attempts to setup a firewall and <acronym>NAT</acronym> - gateway. 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> - </sect2> - - <sect2 xml:id="network-natdkernconfiguration"> - <title>Kernel Configuration</title> - - <indexterm> - <primary>kernel</primary> - <secondary>configuration</secondary> - </indexterm> - - <para>When modules are not an option or if it is preferable to - build all the required features into a custom kernel, the - following options must be in the custom kernel configuration - file:</para> - - <programlisting>options IPFIREWALL -options IPDIVERT</programlisting> - - <para>Additionally, the following may also be suitable:</para> - - <programlisting>options IPFIREWALL_DEFAULT_TO_ACCEPT -options IPFIREWALL_VERBOSE</programlisting> - </sect2> - - <sect2 xml:id="network-natdsystemconfiguration"> - <title>System Startup Configuration</title> - - <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" <co xml:id="co-natd-gateway-enable"/> -firewall_enable="YES" <co xml:id="co-natd-firewall-enable"/> -firewall_type="OPEN" <co xml:id="co-natd-firewall-type"/> -natd_enable="YES" -natd_interface="<replaceable>fxp0</replaceable>" <co xml:id="co-natd-natd-interface"/> -natd_flags="" <co xml:id="co-natd-natd-flags"/></programlisting> - - <calloutlist> - <callout arearefs="co-natd-gateway-enable"> - <para>Sets up the machine to act as a gateway. Running - <command>sysctl net.inet.ip.forwarding=1</command> would - have the same effect.</para> - </callout> - - <callout arearefs="co-natd-firewall-enable"> - <para>Enables the firewall rules in - <filename>/etc/rc.firewall</filename> at boot.</para> - </callout> - - <callout arearefs="co-natd-firewall-type"> - <para>This specifies a predefined firewall ruleset that - allows anything in. See - <filename>/etc/rc.firewall</filename> for additional - types.</para> - </callout> - - <callout arearefs="co-natd-natd-interface"> - <para>Indicates which interface to forward packets through. - This is the interface that is connected to the - Internet.</para> - </callout> - - <callout arearefs="co-natd-natd-flags"> - <para>Any additional configuration options passed to - &man.natd.8; on boot.</para> - </callout> - </calloutlist> - - <para>These - <filename>/etc/rc.conf</filename> options will run - <command>natd -interface fxp0</command> at boot. This can - also be run manually after boot.</para> - - <note> - <para>It is also possible to use a configuration file for - &man.natd.8; when there are too many options to pass. In - this case, the configuration file must be defined by adding - the following line to - <filename>/etc/rc.conf</filename>:</para> - - <programlisting>natd_flags="-f /etc/natd.conf"</programlisting> - - <para>A list of configuration options, one per line, can be - added to <filename>/etc/natd.conf</filename>. For - example:</para> - - <programlisting>redirect_port tcp 192.168.0.2:6667 6667 -redirect_port tcp 192.168.0.3:80 80</programlisting> - - <para>For more information about this configuration file, - consult &man.natd.8;.</para> - </note> - - <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 - xlink:href="ftp://ftp.isi.edu/in-notes/rfc1918.txt">RFC - 1918</link>, and have a default gateway of the - &man.natd.8; machine's internal <acronym>IP</acronym> - address.</para> - - <para>For example, client <systemitem>A</systemitem> and - <systemitem>B</systemitem> behind the <acronym>LAN</acronym> - have <acronym>IP</acronym> addresses of <systemitem - class="ipaddress">192.168.0.2</systemitem> and <systemitem - class="ipaddress">192.168.0.3</systemitem>, while the - &man.natd.8; machine's <acronym>LAN</acronym> interface has an - <acronym>IP</acronym> address of <systemitem - class="ipaddress">192.168.0.1</systemitem>. The default - gateway of clients <systemitem>A</systemitem> and - <systemitem>B</systemitem> must be set to that of the - &man.natd.8; machine, <systemitem - class="ipaddress">192.168.0.1</systemitem>. The - &man.natd.8; machine's external Internet interface does not - require any special modification for &man.natd.8; to - work.</para> - </sect2> - - <sect2 xml:id="network-natdport-redirection"> - <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 syntax for <option>-redirect_port</option> is as - follows:</para> - - <programlisting> -redirect_port proto targetIP:targetPORT[-targetPORT] - [aliasIP:]aliasPORT[-aliasPORT] - [remoteIP[:remotePORT[-remotePORT]]]</programlisting> - - <para>In the above example, the argument should be:</para> - - <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>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> - </sect2> - - <sect2 xml:id="network-natdaddress-redirection"> - <title>Address Redirection</title> - - <indexterm> - <primary>address redirection</primary> - </indexterm> - - <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> - - <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> - </sect2> - </sect1> - <sect1 xml:id="network-ipv6"> <info> <title><acronym>IPv6</acronym></title> Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 26 21:53:13 2014 (r44079) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 26 22:19:04 2014 (r44080) @@ -2120,177 +2120,9 @@ pif="dc0" # interface name of NIC at <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 # 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>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201402262219.s1QMJ53n033818>