Date: Sat, 19 Jan 2013 21:09:12 +0000 (UTC) From: Benedict Reuschling <bcr@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r40685 - head/en_US.ISO8859-1/books/handbook/firewalls Message-ID: <201301192109.r0JL9Ce8088801@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: bcr Date: Sat Jan 19 21:09:11 2013 New Revision: 40685 URL: http://svnweb.freebsd.org/changeset/doc/40685 Log: Whitespace fixes for the entire firewalls chapter. Translators can ignore this. Submitted by: Dru Lavigne 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 Sat Jan 19 17:40:46 2013 (r40684) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Sat Jan 19 21:09:11 2013 (r40685) @@ -36,15 +36,15 @@ <sect1 id="firewalls-intro"> <title>Introduction</title> - <para>Firewalls make it possible to filter - incoming and outgoing traffic that flows through your system. - A firewall can use one or more sets of <quote>rules</quote> to - inspect the network packets as they come in or go out of your - network connections and either allows the traffic through or - blocks it. The rules of a firewall can inspect one or more - characteristics of the packets, including but not limited to the - protocol type, the source or destination host address, and the - source or destination port.</para> + <para>Firewalls make it possible to filter incoming and outgoing + traffic that flows through your system. A firewall can use one + or more sets of <quote>rules</quote> to inspect the network + packets as they come in or go out of your network connections + and either allows the traffic through or blocks it. The rules + of a firewall can inspect one or more characteristics of the + packets, including but not limited to the protocol type, the + source or destination host address, and the source or + destination port.</para> <para>Firewalls can greatly enhance the security of a host or a network. They can be used to do one or more of @@ -125,18 +125,20 @@ reverse. It only allows traffic matching the rules through and blocks everything else.</para> - <para>An inclusive firewall offers much better control of the outgoing - traffic, making it a better choice for systems that offer services to - the public Internet. It also controls the type of traffic originating - from the public Internet that can gain access to your private network. - All traffic that does not match the rules, is blocked and logged by - design. Inclusive firewalls are generally safer than exclusive - firewalls because they significantly reduce the risk of allowing - unwanted traffic to pass through them.</para> + <para>An inclusive firewall offers much better control of the + outgoing traffic, making it a better choice for systems that + offer services to the public Internet. It also controls the + type of traffic originating from the public Internet that can + gain access to your private network. All traffic that does + not match the rules, is blocked and logged by design. Inclusive + firewalls are generally safer than exclusive firewalls because + they significantly reduce the risk of allowing unwanted traffic + to pass through them.</para> <note> <para>Unless noted otherwise, all configuration and example - rulesets in this chapter, create inclusive type firewalls.</para> + rulesets in this chapter, create inclusive type + firewalls.</para> </note> <para>Security can be tightened further using a <quote>stateful @@ -157,21 +159,22 @@ <para>&os; has three different firewall packages built into the base system. They are: <emphasis>IPFILTER</emphasis> (also known as <acronym>IPF</acronym>), - <emphasis>IPFIREWALL</emphasis> (also known as <acronym>IPFW</acronym>), - and <emphasis>OpenBSD's PacketFilter</emphasis> (also known as - <acronym>PF</acronym>). &os; also has two built in packages for - traffic shaping (basically controlling bandwidth usage): - &man.altq.4; and &man.dummynet.4;. Dummynet has traditionally been - closely tied with <acronym>IPFW</acronym>, and + <emphasis>IPFIREWALL</emphasis> (also known as + <acronym>IPFW</acronym>), and <emphasis>OpenBSD's + PacketFilter</emphasis> (also known as <acronym>PF</acronym>). + &os; also has two built in packages for traffic shaping + (basically controlling bandwidth usage): &man.altq.4; and + &man.dummynet.4;. Dummynet has traditionally been closely + tied with <acronym>IPFW</acronym>, and <acronym>ALTQ</acronym> with - <acronym>PF</acronym>. Traffic shaping for IPFILTER can currently - be done with IPFILTER for NAT and filtering and + <acronym>PF</acronym>. Traffic shaping for IPFILTER can + currently be done with IPFILTER for NAT and filtering and <acronym>IPFW</acronym> with &man.dummynet.4; <emphasis>or</emphasis> by using <acronym>PF</acronym> with <acronym>ALTQ</acronym>. - IPFW, and PF all use rules to control the access of packets to and - from your system, although they go about it different ways and - have a different rule syntax.</para> + IPFW, and PF all use rules to control the access of packets + to and from your system, although they go about it different + ways and have a different rule syntax.</para> <para>The reason that &os; has multiple built in firewall packages is that different people have different requirements and @@ -193,16 +196,16 @@ </sect1> <sect1 id="firewalls-pf"> - <sect1info> - <authorgroup> - <author> - <firstname>John</firstname> - <surname>Ferrell</surname> - <contrib>Revised and updated by </contrib> - <!-- 24 March 2008 --> - </author> - </authorgroup> - </sect1info> + <sect1info> + <authorgroup> + <author> + <firstname>John</firstname> + <surname>Ferrell</surname> + <contrib>Revised and updated by </contrib> + <!-- 24 March 2008 --> + </author> + </authorgroup> + </sect1info> <title>The OpenBSD Packet Filter (PF) and <acronym>ALTQ</acronym></title> @@ -239,36 +242,35 @@ <sect2> <title>Using the PF Loadable Kernel Modules</title> - <para>To load the PF Kernel Module add the following line to - <filename>/etc/rc.conf</filename>:</para> + <para>To load the PF Kernel Module add the following line to + <filename>/etc/rc.conf</filename>:</para> <programlisting>pf_enable="YES"</programlisting> - <para>Then run the startup script to load the module:</para> + <para>Then run the startup script to load the module:</para> <screen>&prompt.root; <userinput>/etc/rc.d/pf start</userinput></screen> <para>Note that the PF Module will not load if it cannot find the ruleset config file. The default location is <filename>/etc/pf.conf</filename>. If the PF ruleset is - located somewhere else, PF can be instructed to look there by - adding a line like the following to + located somewhere else, PF can be instructed to look there + by adding a line like the following to <filename>/etc/rc.conf</filename>:</para> <programlisting>pf_rules="<replaceable>/path/to/pf.conf</replaceable>"</programlisting> <para>The sample <filename>pf.conf</filename> can be found in <filename - class="directory">/usr/share/examples/pf/</filename>. - </para> + class="directory">/usr/share/examples/pf/</filename>.</para> - <para>The <acronym>PF</acronym> module can also be loaded manually - from the command line:</para> + <para>The <acronym>PF</acronym> module can also be loaded + manually from the command line:</para> <screen>&prompt.root; <userinput>kldload pf.ko</userinput></screen> <para>Logging support for PF is provided by the - <literal>pflog.ko</literal> and can be loaded by adding the + <literal>pflog.ko</literal> and can be loaded by adding the following line to <filename>/etc/rc.conf</filename>:</para> <programlisting>pflog_enable="YES"</programlisting> @@ -278,7 +280,8 @@ <screen>&prompt.root; <userinput>/etc/rc.d/pflog start</userinput></screen> <para>If you need other <acronym>PF</acronym> features you will - need to compile <acronym>PF</acronym> support into the kernel.</para> + need to compile <acronym>PF</acronym> support into the + kernel.</para> </sect2> <sect2> @@ -303,33 +306,36 @@ </indexterm> <para>While it is not necessary that you compile - <acronym>PF</acronym> support into the &os; kernel, you may want - to do so to take advantage of one of PF's advanced features that - is not included in the loadable module, namely &man.pfsync.4;, which - is a pseudo-device that exposes certain changes to - the state table used by <acronym>PF</acronym>. It can be - paired with &man.carp.4; to create failover firewalls using - <acronym>PF</acronym>. More information on + <acronym>PF</acronym> support into the &os; kernel, you may + want to do so to take advantage of one of PF's advanced + features that is not included in the loadable module, namely + &man.pfsync.4;, which is a pseudo-device that exposes certain + changes to the state table used by <acronym>PF</acronym>. + It can be paired with &man.carp.4; to create failover + firewalls using <acronym>PF</acronym>. More information on <acronym>CARP</acronym> can be found in <xref linkend="carp"/> of the Handbook.</para> <para>The <acronym>PF</acronym> kernel options can be found in - <filename>/usr/src/sys/conf/NOTES</filename> and are reproduced - below:</para> + <filename>/usr/src/sys/conf/NOTES</filename> and are + reproduced below:</para> <programlisting>device pf device pflog device pfsync</programlisting> - <para>The <literal>device pf</literal> option enables support for the - <quote>Packet Filter</quote> firewall (&man.pf.4;).</para> - - <para>The <literal>device pflog</literal> option enables the optional - &man.pflog.4; pseudo network device which can be used to log - traffic to a &man.bpf.4; descriptor. The &man.pflogd.8; daemon - can be used to store the logging information to disk.</para> + <para>The <literal>device pf</literal> option enables support + for the <quote>Packet Filter</quote> firewall + (&man.pf.4;).</para> + + <para>The <literal>device pflog</literal> option enables the + optional &man.pflog.4; pseudo network device which can be + used to log traffic to a &man.bpf.4; descriptor. The + &man.pflogd.8; daemon can be used to store the logging + information to disk.</para> - <para>The <literal>device pfsync</literal> option enables the optional + <para>The <literal>device pfsync</literal> option enables the + optional &man.pfsync.4; pseudo-network device that is used to monitor <quote>state changes</quote>.</para> </sect2> @@ -359,12 +365,13 @@ pflog_flags="" # additi <para><acronym>PF</acronym> reads its configuration rules from &man.pf.conf.5; (<filename>/etc/pf.conf</filename> by - default) and it modifies, drops, or passes packets according to - the rules or definitions specified there. The &os; + default) and it modifies, drops, or passes packets according + to the rules or definitions specified there. The &os; installation includes several sample files located in - <filename>/usr/share/examples/pf/</filename>. Please refer to - the <ulink url="http://www.openbsd.org/faq/pf/">PF FAQ</ulink> - for complete coverage of <acronym>PF</acronym> rulesets.</para> + <filename>/usr/share/examples/pf/</filename>. Please refer + to the <ulink url="http://www.openbsd.org/faq/pf/">PF + FAQ</ulink> for complete coverage of <acronym>PF</acronym> + rulesets.</para> <warning> <para>When browsing the <ulink @@ -373,9 +380,9 @@ pflog_flags="" # additi contain different versions of PF. Currently, &os; 8.<replaceable>X</replaceable> and prior is using the same version of <acronym>PF</acronym> as - OpenBSD 4.1. &os; 9.<replaceable>X</replaceable> and - later is using the same version of <acronym>PF</acronym> as - OpenBSD 4.5.</para> + OpenBSD 4.1. &os; 9.<replaceable>X</replaceable> + and later is using the same version of <acronym>PF</acronym> + as OpenBSD 4.5.</para> </warning> <para>The &a.pf; is a good place to ask questions about @@ -402,31 +409,37 @@ pflog_flags="" # additi <tbody> <row> - <entry><command>pfctl <option>-e</option></command></entry> + <entry><command>pfctl + <option>-e</option></command></entry> <entry>Enable PF</entry> </row> <row> - <entry><command>pfctl <option>-d</option></command></entry> + <entry><command>pfctl + <option>-d</option></command></entry> <entry>Disable PF</entry> </row> <row> - <entry><command>pfctl <option>-F</option> all <option>-f</option> /etc/pf.conf</command></entry> - <entry>Flush all rules (nat, filter, state, table, etc.) and - reload from the file <filename>/etc/pf.conf</filename></entry> + <entry><command>pfctl <option>-F</option> all + <option>-f</option> /etc/pf.conf</command></entry> + <entry>Flush all rules (nat, filter, state, table, etc.) + and reload from the file + <filename>/etc/pf.conf</filename></entry> </row> <row> - <entry><command>pfctl <option>-s</option> [ rules | nat | state ]</command></entry> + <entry><command>pfctl <option>-s</option> [ rules | nat + state ]</command></entry> <entry>Report on the filter rules, nat rules, or state table</entry> </row> <row> - <entry><command>pfctl <option>-vnf</option> /etc/pf.conf</command></entry> - <entry>Check <filename>/etc/pf.conf</filename> for errors, - but do not load ruleset</entry> + <entry><command>pfctl <option>-vnf</option> + /etc/pf.conf</command></entry> + <entry>Check <filename>/etc/pf.conf</filename> for + errors, but do not load ruleset</entry> </row> </tbody> </tgroup> @@ -437,13 +450,14 @@ pflog_flags="" # additi <title>Enabling <acronym>ALTQ</acronym></title> <para><acronym>ALTQ</acronym> is only available by compiling - support for it into the &os; kernel. <acronym>ALTQ</acronym> is - not supported by all of the available network card drivers. + support for it into the &os; kernel. <acronym>ALTQ</acronym> + is not supported by all of the available network card drivers. Please see the &man.altq.4; manual page for a list of drivers that are supported in your release of &os;.</para> <para>The following kernel options will enable - <acronym>ALTQ</acronym> and add additional functionality:</para> + <acronym>ALTQ</acronym> and add additional + functionality:</para> <programlisting>options ALTQ options ALTQ_CBQ # Class Bases Queuing (CBQ) @@ -456,33 +470,36 @@ options ALTQ_NOPCC # Requir <para><literal>options ALTQ</literal> enables the <acronym>ALTQ</acronym> framework.</para> - <para><literal>options ALTQ_CBQ</literal> enables <emphasis>Class Based - Queuing</emphasis> (<acronym>CBQ</acronym>). <acronym>CBQ</acronym> + <para><literal>options ALTQ_CBQ</literal> enables + <emphasis>Class Based Queuing</emphasis> + (<acronym>CBQ</acronym>). <acronym>CBQ</acronym> allows you to divide a connection's bandwidth into different classes or queues to prioritize traffic based on filter rules.</para> - <para><literal>options ALTQ_RED</literal> enables <emphasis>Random Early - Detection</emphasis> (<acronym>RED</acronym>). <acronym>RED</acronym> is - used to avoid network congestion. <acronym>RED</acronym> does - this by measuring the length of the queue and comparing it to - the minimum and maximum thresholds for the queue. If the - queue is over the maximum all new packets will be dropped. + <para><literal>options ALTQ_RED</literal> enables + <emphasis>Random Early Detection</emphasis> + (<acronym>RED</acronym>). <acronym>RED</acronym> is + used to avoid network congestion. <acronym>RED</acronym> + does this by measuring the length of the queue and comparing + it to the minimum and maximum thresholds for the queue. If + the queue is over the maximum all new packets will be dropped. True to its name, <acronym>RED</acronym> drops packets from different connections randomly.</para> - <para><literal>options ALTQ_RIO</literal> enables <emphasis>Random Early - Detection In and Out</emphasis>.</para> + <para><literal>options ALTQ_RIO</literal> enables + <emphasis>Random Early Detection In and Out</emphasis>.</para> <para><literal>options ALTQ_HFSC</literal> enables the - <emphasis>Hierarchical Fair Service Curve Packet Scheduler</emphasis>. For more - information about <acronym>HFSC</acronym> see: <ulink - url="http://www-2.cs.cmu.edu/~hzhang/HFSC/main.html"></ulink>.</para> - - <para><literal>options ALTQ_PRIQ</literal> enables <emphasis>Priority - Queuing</emphasis> (<acronym>PRIQ</acronym>). <acronym>PRIQ</acronym> - will always pass traffic that is in a higher queue - first.</para> + <emphasis>Hierarchical Fair Service Curve Packet + Scheduler</emphasis>. For more information about + <acronym>HFSC</acronym> see: <ulink + url="http://www-2.cs.cmu.edu/~hzhang/HFSC/main.html"></ulink>.</para> + + <para><literal>options ALTQ_PRIQ</literal> enables + <emphasis>Priority Queuing</emphasis> + (<acronym>PRIQ</acronym>). <acronym>PRIQ</acronym> will + always pass traffic that is in a higher queue first.</para> <para><literal>options ALTQ_NOPCC</literal> enables <acronym>SMP</acronym> support for <acronym>ALTQ</acronym>. @@ -509,24 +526,24 @@ options ALTQ_NOPCC # Requir <para>IPFILTER is based on a kernel-side firewall and <acronym>NAT</acronym> mechanism that can be controlled and - monitored by userland interface programs. The firewall rules can - be set or deleted with the &man.ipf.8; utility. The + monitored by userland interface programs. The firewall rules + can be set or deleted with the &man.ipf.8; utility. The <acronym>NAT</acronym> rules can be set or deleted with the &man.ipnat.8; utility. The &man.ipfstat.8; utility can print run-time statistics for the kernel parts of IPFILTER. The - &man.ipmon.8; program can log IPFILTER actions to the system log - files.</para> + &man.ipmon.8; program can log IPFILTER actions to the system + log files.</para> - <para>IPF was originally written using a rule processing logic of - <quote>the last matching rule wins</quote> and used only + <para>IPF was originally written using a rule processing logic + of <quote>the last matching rule wins</quote> and used only stateless type of rules. Over time IPF has been enhanced to - include a <quote>quick</quote> option and a stateful <quote>keep - state</quote> option which drastically modernized the rules - processing logic. IPF's official documentation covers only the legacy - rule coding parameters and rule file processing + include a <quote>quick</quote> option and a stateful + <quote>keep state</quote> option which drastically modernized + the rules processing logic. IPF's official documentation covers + only the legacy rule coding parameters and rule file processing logic. The modernized functions are only included as additional - options, completely understating their benefits in producing a - far superior and more secure firewall.</para> + options, completely understating their benefits in producing + a far superior and more secure firewall.</para> <para>The instructions contained in this section are based on using rules that contain the <quote>quick</quote> option and the @@ -535,16 +552,16 @@ options ALTQ_NOPCC # Requir <para>For detailed explanation of the legacy rules processing method see: <ulink - url="http://www.munk.me.uk/ipf/ipf-howto.html"></ulink> + url="http://www.munk.me.uk/ipf/ipf-howto.html"></ulink> and <ulink - url="http://coombs.anu.edu.au/~avalon/ip-filter.html"></ulink>.</para> + url="http://coombs.anu.edu.au/~avalon/ip-filter.html"></ulink>.</para> <para>The IPF FAQ is at <ulink - url="http://www.phildev.net/ipf/index.html"></ulink>.</para> + url="http://www.phildev.net/ipf/index.html"></ulink>.</para> - <para>A searchable archive of the open-source IPFilter mailing list is - available at <ulink - url="http://marc.theaimsgroup.com/?l=ipfilter"></ulink>.</para> + <para>A searchable archive of the open-source IPFilter mailing + list is available at <ulink + url="http://marc.theaimsgroup.com/?l=ipfilter"></ulink>.</para> <sect2> <title>Enabling IPF</title> @@ -555,15 +572,17 @@ options ALTQ_NOPCC # Requir <secondary>enabling</secondary> </indexterm> - <para>IPF is included in the basic &os; install as a separate run - time loadable module. The system will dynamically load the IPF - kernel loadable module when the <filename>rc.conf</filename> statement - <literal>ipfilter_enable="YES"</literal> is used. The loadable - module was created with logging enabled and the - <literal>default pass all</literal> options. There is no need - to compile IPF into the &os; kernel just to change the default - to <literal>block all</literal>. This can be done just by adding - a <literal>block all</literal> rule at the end of your ruleset.</para> + <para>IPF is included in the basic &os; install as a separate + run time loadable module. The system will dynamically load + the IPF kernel loadable module when the + <filename>rc.conf</filename> statement + <literal>ipfilter_enable="YES"</literal> is used. The + loadable module was created with logging enabled and the + <literal>default pass all</literal> options. There is no + need to compile IPF into the &os; kernel just to change the + default to <literal>block all</literal>. This can be done + just by adding a <literal>block all</literal> rule at the + end of your ruleset.</para> </sect2> <sect2> @@ -607,28 +626,28 @@ options ALTQ_NOPCC # Requir options IPFILTER_LOG options IPFILTER_DEFAULT_BLOCK</programlisting> - <para><literal>options IPFILTER</literal> enables support for the - <quote>IPFILTER</quote> firewall.</para> + <para><literal>options IPFILTER</literal> enables support for + the <quote>IPFILTER</quote> firewall.</para> <para><literal>options IPFILTER_LOG</literal> enables the option to have IPF log traffic by writing to the - <devicename>ipl</devicename> packet logging pseudo—device - for every rule that has the <literal>log</literal> - keyword.</para> + <devicename>ipl</devicename> packet logging + pseudo—device for every rule that has the + <literal>log</literal> keyword.</para> <para><literal>options IPFILTER_DEFAULT_BLOCK</literal> changes the default behavior so any packet not matching a firewall <literal>pass</literal> rule gets blocked.</para> - <para>These settings will take effect only after installing a kernel - that has been built with the above options set.</para> + <para>These settings will take effect only after installing a + kernel that has been built with the above options set.</para> </sect2> <sect2> <title>Available <filename>rc.conf</filename> Options</title> - <para>To activate IPF at boot time, the following statements need to - be added to <filename>/etc/rc.conf</filename>:</para> + <para>To activate IPF at boot time, the following statements + need to be added to <filename>/etc/rc.conf</filename>:</para> <programlisting>ipfilter_enable="YES" # Start ipf firewall ipfilter_rules="/etc/ipf.rules" # loads rules definition text file @@ -639,8 +658,8 @@ ipmon_flags="-Ds" # D = # n = map IP & port to names</programlisting> <para>If there is a LAN behind this firewall that uses the - reserved private IP address ranges, the following lines will have to - be added to enable <acronym>NAT</acronym> + reserved private IP address ranges, the following lines will + have to be added to enable <acronym>NAT</acronym> functionality:</para> <programlisting>gateway_enable="YES" # Enable as LAN gateway @@ -663,8 +682,8 @@ ipnat_rules="/etc/ipnat.rules" # rule <para><option>-Fa</option> means flush all internal rules tables.</para> - <para><option>-f</option> means this is the file to read for the - rules to load.</para> + <para><option>-f</option> means this is the file to read for + the rules to load.</para> <para>This gives you the ability to make changes to your custom rules file, run the above IPF command, and thus update the @@ -677,8 +696,8 @@ ipnat_rules="/etc/ipnat.rules" # rule flags available with this command.</para> <para>The &man.ipf.8; command expects the rules file to be a - standard text file. It will not accept a rules file written as - a script with symbolic substitution.</para> + standard text file. It will not accept a rules file written + as a script with symbolic substitution.</para> <para>There is a way to build IPF rules that utilizes the power of script symbolic substitution. For more information, see @@ -696,12 +715,12 @@ ipnat_rules="/etc/ipnat.rules" # rule <secondary>statistics</secondary> </indexterm> - <para>The default behavior of &man.ipfstat.8; is to retrieve and - display the totals of the accumulated statistics gathered as a - result of applying the user coded rules against packets going - in and out of the firewall since it was last started, or since - the last time the accumulators were reset to zero by the - <command>ipf -Z</command> command.</para> + <para>The default behavior of &man.ipfstat.8; is to retrieve + and display the totals of the accumulated statistics gathered + as a result of applying the user coded rules against packets + going in and out of the firewall since it was last started, + or since the last time the accumulators were reset to zero + by the <command>ipf -Z</command> command.</para> <para>See the &man.ipfstat.8; manual page for details.</para> @@ -727,8 +746,8 @@ ipnat_rules="/etc/ipnat.rules" # rule Packet log flags set: (0)</screen> <para>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 + 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.</para> <para><command>ipfstat -in</command> displays the inbound @@ -759,14 +778,14 @@ ipnat_rules="/etc/ipnat.rules" # rule <para>One of the most important functions of the <command>ipfstat</command> command is the <option>-t</option> - flag which displays the state table in a way similar to the way - &man.top.1; shows the &os; running process table. When your - firewall is under attack, this function gives you the ability to - identify, drill down to, and see the attacking packets. The - optional sub-flags give the ability to select the destination - or source IP, port, or protocol that you want to monitor in - real time. See the &man.ipfstat.8; manual page for - details.</para> + flag which displays the state table in a way similar to the + way &man.top.1; shows the &os; running process table. When + your firewall is under attack, this function gives you the + ability to identify, drill down to, and see the attacking + packets. The optional sub-flags give the ability to select + the destination or source IP, port, or protocol that you want + to monitor in real time. See the &man.ipfstat.8; manual page + for details.</para> </sect2> <sect2> @@ -780,21 +799,23 @@ ipnat_rules="/etc/ipnat.rules" # rule <secondary>logging</secondary> </indexterm> - <para>In order for <command>ipmon</command> to work properly, the - kernel option <literal>IPFILTER_LOG</literal> must be turned on. This command has - two different modes that it can be used in. Native mode is the - default mode when the command is typed on the command line - without the <option>-D</option> flag.</para> + <para>In order for <command>ipmon</command> to work properly, + the kernel option <literal>IPFILTER_LOG</literal> must be + turned on. This command has two different modes that it can + be used in. Native mode is the default mode when the command + is typed on the command line without the <option>-D</option> + flag.</para> <para>Daemon mode is for when a continuous - system log file is desired, so that logging of past events may be - reviewed. This is how &os; and IPFILTER are configured to - work together. &os; has a built in facility to automatically - rotate system logs. That is why outputting the log information - to &man.syslogd.8; is better than the default of outputting to a - regular file. In the default <filename>rc.conf</filename> file, - the <literal>ipmon_flags</literal> statement uses the <option>-Ds</option> - flags:</para> + system log file is desired, so that logging of past events + may be reviewed. This is how &os; and IPFILTER are configured + to work together. &os; has a built in facility to + automatically rotate system logs. That is why outputting the + log information to &man.syslogd.8; is better than the default + of outputting to a regular file. In the default + <filename>rc.conf</filename> file, the + <literal>ipmon_flags</literal> statement uses the + <option>-Ds</option> flags:</para> <programlisting>ipmon_flags="-Ds" # D = start as daemon # s = log to syslog @@ -804,8 +825,8 @@ ipnat_rules="/etc/ipnat.rules" # rule <para>The benefits of logging are obvious. It provides the ability to review, after the fact, information such as which packets had been dropped, what addresses they came from and - where they were going. These can all provide a significant edge - in tracking down attackers.</para> + where they were going. These can all provide a significant + edge in tracking down attackers.</para> <para>Even with the logging facility enabled, IPF will not generate any rule logging on its own. The firewall @@ -815,8 +836,8 @@ ipnat_rules="/etc/ipnat.rules" # rule <para>It is very customary to include a default deny everything rule with the log keyword included as your 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> + ruleset. This makes it possible to see all the packets that + did not match any of the rules in the ruleset.</para> </sect2> <sect2> @@ -824,12 +845,11 @@ ipnat_rules="/etc/ipnat.rules" # rule <para><application>Syslogd</application> uses its own special method for segregation of log data. It uses special groupings - called <quote>facility</quote> and <quote>level</quote>. IPMON - in <option>-Ds</option> mode uses <literal>local0</literal> - as the <quote>facility</quote> - name by default. - The following levels can be - used to further segregate the logged data if desired:</para> + called <quote>facility</quote> and <quote>level</quote>. + IPMON in <option>-Ds</option> mode uses + <literal>local0</literal> as the <quote>facility</quote> + name by default. The following levels can be used to further + segregate the logged data if desired:</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 @@ -839,16 +859,18 @@ LOG_ERR - packets which have been logged <!-- XXX: "can be considered short" == "with incomplete header" --> <para>To setup IPFILTER to log all data to - <filename>/var/log/ipfilter.log</filename>, the file will need to be - created beforehand. The following command will do that:</para> + <filename>/var/log/ipfilter.log</filename>, the file will + need to be created beforehand. The following command will + do that:</para> <screen>&prompt.root; <userinput>touch /var/log/ipfilter.log</userinput></screen> - <para>The &man.syslogd.8; function is controlled by definition statements - in the <filename>/etc/syslog.conf</filename> file. The - <filename>syslog.conf</filename> file offers considerable - flexibility in how <application>syslog</application> will deal with system messages issued - by software applications like IPF.</para> + <para>The &man.syslogd.8; function is controlled by definition + statements in the <filename>/etc/syslog.conf</filename> file. + The <filename>syslog.conf</filename> file offers considerable + flexibility in how <application>syslog</application> will + deal with system messages issued by software applications + like IPF.</para> <para>Add the following statement to <filename>/etc/syslog.conf</filename>:</para> @@ -860,21 +882,21 @@ LOG_ERR - packets which have been logged file location.</para> <para>To activate the changes to <filename>/etc/syslog.conf - </filename> you can reboot or bump the &man.syslogd.8; daemon into - re-reading <filename>/etc/syslog.conf</filename> by running - <command>/etc/rc.d/syslogd reload</command></para> + </filename> you can reboot or bump the &man.syslogd.8; + daemon into re-reading <filename>/etc/syslog.conf</filename> + by running <command>/etc/rc.d/syslogd reload</command></para> <para>Do not forget to change - <filename>/etc/newsyslog.conf</filename> to rotate the new log - created above.</para> + <filename>/etc/newsyslog.conf</filename> to rotate the new + log created above.</para> </sect2> <sect2> <title>The Format of Logged Messages</title> - <para>Messages generated by <command>ipmon</command> consist of - data fields separated by white space. Fields common to all - messages are:</para> + <para>Messages generated by <command>ipmon</command> consist + of data fields separated by white space. Fields common to + all messages are:</para> <orderedlist> <listitem> @@ -883,13 +905,13 @@ LOG_ERR - packets which have been logged <listitem> <para>The time of packet receipt. This is in the form - HH:MM:SS.F, for hours, minutes, seconds, and fractions of a - second (which can be several digits long).</para> + HH:MM:SS.F, for hours, minutes, seconds, and fractions + of a second (which can be several digits long).</para> </listitem> <listitem> - <para>The name of the interface the packet was processed on, - e.g., <devicename>dc0</devicename>.</para> + <para>The name of the interface the packet was processed + on, e.g., <devicename>dc0</devicename>.</para> </listitem> <listitem> @@ -898,33 +920,36 @@ LOG_ERR - packets which have been logged </listitem> </orderedlist> - <para>These can be viewed with <command>ipfstat - -in</command>.</para> + <para>These can be viewed with + <command>ipfstat -in</command>.</para> <orderedlist> <listitem> <para>The action: p for passed, b for blocked, S for a short - packet, n did not match any rules, L for a log rule. The - order of precedence in showing flags is: S, p, b, n, L. A - capital P or B means that the packet has been logged due to - a global logging setting, not a particular rule.</para> + packet, n did not match any rules, L for a log rule. + The order of precedence in showing flags is: S, p, b, n, + L. A capital P or B means that the packet has been logged + due to a global logging setting, not a particular + rule.</para> </listitem> <listitem> <para>The addresses. This is actually three fields: the source address and port (separated by a comma), the -> symbol, and the destination address and port, e.g.: - <literal>209.53.17.22,80 -> 198.73.220.17,1722</literal>.</para> + <literal>209.53.17.22,80 -> + 198.73.220.17,1722</literal>.</para> </listitem> <listitem> - <para><literal>PR</literal> followed by the protocol name or - number, e.g.: <literal>PR tcp</literal>.</para> + <para><literal>PR</literal> followed by the protocol name + or number, e.g.: <literal>PR tcp</literal>.</para> </listitem> <listitem> <para><literal>len</literal> followed by the header length - and total length of the packet, e.g.: <literal>len 20 40</literal>.</para> + and total length of the packet, e.g.: + <literal>len 20 40</literal>.</para> </listitem> </orderedlist> @@ -935,9 +960,10 @@ LOG_ERR - packets which have been logged flags.</para> <para>If the packet is an ICMP packet, there will be two fields - at the end, the first always being <quote>ICMP</quote>, and the - next being the ICMP message and sub-message type, separated by - a slash, e.g., ICMP 3/3 for a port unreachable message.</para> + at the end, the first always being <quote>ICMP</quote>, and + the next being the ICMP message and sub-message type, + separated by a slash, e.g., ICMP 3/3 for a port unreachable + message.</para> </sect2> <sect2 id="firewalls-ipf-rules-script"> @@ -945,17 +971,18 @@ LOG_ERR - packets which have been logged Substitution</title> <para>Some experienced IPF users create a file containing the - rules and code them in a manner compatible with running them as - a script with symbolic substitution. The major benefit of - doing this is that only the value associated - with the symbolic name needs to be changed, and when the script is run all the rules - containing the symbolic name will have the value substituted in - the rules. Being a script, symbolic substitution can be used - to code frequently used values and substitute them in multiple - rules. This can be seen in the following example.</para> + rules and code them in a manner compatible with running them + as a script with symbolic substitution. The major benefit + of doing this is that only the value associated with the + symbolic name needs to be changed, and when the script is + run all the rules containing the symbolic name will have the + value substituted in the rules. Being a script, symbolic + substitution can be used to code frequently used values and + substitute them in multiple rules. This can be seen in the + following example.</para> - <para>The script syntax used here is compatible with the &man.sh.1;, &man.csh.1;, - and &man.tcsh.1; shells.</para> + <para>The script syntax used here is compatible with the + &man.sh.1;, &man.csh.1;, and &man.tcsh.1; shells.</para> <para>Symbolic substitution fields are prefixed with a dollar sign: <literal>$</literal>.</para> @@ -998,11 +1025,11 @@ pass out quick on $oif proto tcp EOF ################## End of IPF rules script ########################</programlisting> - <para>That is all there is to it. The rules are not important in - this example; how the symbolic substitution fields are + <para>That is all there is to it. The rules are not important + in this example; how the symbolic substitution fields are populated and used are. If the above example was in a file - named <filename>/etc/ipf.rules.script</filename>, these rules could be - reloaded by entering the following command:</para> + named <filename>/etc/ipf.rules.script</filename>, these rules + could be reloaded by entering the following command:</para> <screen>&prompt.root; <userinput>sh /etc/ipf.rules.script</userinput></screen> @@ -1029,9 +1056,10 @@ EOF value) into <filename>/etc/rc.conf</filename> file.</para> <para>Add a script like the following to your - <filename class="directory">/usr/local/etc/rc.d/</filename> startup - directory. The script should have an obvious name like - <filename>ipf.loadrules.sh</filename>. The + <filename + class="directory">/usr/local/etc/rc.d/</filename> + startup directory. The script should have an obvious + name like <filename>ipf.loadrules.sh</filename>. The <filename>.sh</filename> extension is mandatory.</para> <programlisting>#!/bin/sh @@ -1053,30 +1081,31 @@ sh /etc/ipf.rules.script</programlisting <para>A ruleset is a group of IPF rules coded to pass or block packets based on the values contained in the packet. The - bi-directional exchange of packets between hosts comprises a - session conversation. The firewall ruleset processes both the - packets arriving from the public Internet, as well as the packets - produced by the system as a response to them. + bi-directional exchange of packets between hosts comprises + a session conversation. The firewall ruleset processes both + the packets arriving from the public Internet, as well as the + packets produced by the system as a response to them. Each <acronym>TCP/IP</acronym> service (i.e.: telnet, www, - mail, etc.) is predefined by its protocol and privileged (listening) - port. Packets destined for a specific service, originate from the - source address using an unprivileged (high order) port and target the - specific service port on the destination address. All the above - parameters (i.e.: ports and addresses) can be used as selection - criteria to create rules which will pass or block services.</para> + mail, etc.) is predefined by its protocol and privileged + (listening) port. Packets destined for a specific service, + originate from the source address using an unprivileged (high + order) port and target the specific service port on the + destination address. All the above parameters (i.e.: ports + and addresses) can be used as selection criteria to create + rules which will pass or block services.</para> <indexterm> <primary>IPFILTER</primary> <secondary>rule processing order</secondary> - </indexterm> + </indexterm> - <para>IPF was originally written using a rules processing logic - of <quote>the last matching rule wins</quote> and used only - stateless rules. Over time IPF has been enhanced to include a - <quote>quick</quote> option and a stateful <quote>keep - state</quote> option which drastically modernized the rule - processing logic.</para> + <para>IPF was originally written using a rules processing + logic of <quote>the last matching rule wins</quote> and used + only stateless rules. Over time IPF has been enhanced to + include a <quote>quick</quote> option and a stateful + <quote>keep state</quote> option which drastically modernized + the rule processing logic.</para> <para>The instructions contained in this section are based on using rules that contain the <quote>quick</quote> option and @@ -1086,8 +1115,8 @@ sh /etc/ipf.rules.script</programlisting <warning> <para>When working with the firewall rules, be <emphasis>very - careful</emphasis>. Some configurations <emphasis>will - lock you out</emphasis> of the server. To be on the safe + careful</emphasis>. Some configurations <emphasis>will + lock you out</emphasis> of the server. To be on the safe side, you may wish to consider performing the initial firewall configuration from the local console rather than doing it remotely e.g., via @@ -1104,27 +1133,28 @@ sh /etc/ipf.rules.script</programlisting <secondary>rule syntax</secondary> </indexterm> - <para>The rule syntax presented here has been simplified to only - address the modern stateful rule context and <quote>first - matching rule wins</quote> logic. For the complete legacy rule - syntax description see the &man.ipf.8; manual page.</para> - - <para>A <literal>#</literal> character 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>Rules contain keywords. These keywords have to be coded in - a specific order from left to right on the line. Keywords are - identified in bold type. Some keywords have sub-options which - may be keywords themselves and also include more sub-options. - Each of the headings in the below syntax has a bold section - header which expands on the content.</para> + <para>The rule syntax presented here has been simplified to + only address the modern stateful rule context and <quote>first + matching rule wins</quote> logic. For the complete legacy + rule syntax description see the &man.ipf.8; manual + page.</para> + + <para>A <literal>#</literal> character 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>Rules contain keywords. These keywords have to be coded + in a specific order from left to right on the line. Keywords + are identified in bold type. Some keywords have sub-options + which may be keywords themselves and also include more + sub-options. Each of the headings in the below syntax has + a bold section header which expands on the content.</para> <!-- This section is probably wrong. See the OpenBSD flag --> <!-- What is the "OpenBSD flag"? Reference please --> - <para><replaceable>ACTION IN-OUT OPTIONS SELECTION STATEFUL PROTO - SRC_ADDR,DST_ADDR OBJECT PORT_NUM TCP_FLAG + <para><replaceable>ACTION IN-OUT OPTIONS SELECTION STATEFUL + PROTO SRC_ADDR,DST_ADDR OBJECT PORT_NUM TCP_FLAG STATEFUL</replaceable></para> <para><replaceable>ACTION</replaceable> = block | pass</para> @@ -1132,19 +1162,20 @@ sh /etc/ipf.rules.script</programlisting <para><replaceable>IN-OUT</replaceable> = in | out</para> <para><replaceable>OPTIONS</replaceable> = log | quick | on - interface-name</para> + interface-name</para> <para><replaceable>SELECTION</replaceable> = proto value | - source/destination IP | port = number | flags - flag-value</para> + source/destination IP | port = number | flags + flag-value</para> <para><replaceable>PROTO</replaceable> = tcp/udp | udp | tcp | - icmp</para> + icmp</para> <para><replaceable>SRC_ADD,DST_ADDR</replaceable> = all | from - object to object</para> + object to object</para> - <para><replaceable>OBJECT</replaceable> = IP address | any</para> + <para><replaceable>OBJECT</replaceable> = IP address | + any</para> <para><replaceable>PORT_NUM</replaceable> = port number</para> @@ -1160,8 +1191,8 @@ sh /etc/ipf.rules.script</programlisting <emphasis>must</emphasis> have an action. The following actions are recognized:</para> - <para><literal>block</literal> indicates that the packet should *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201301192109.r0JL9Ce8088801>