Skip site navigation (1)Skip section navigation (2)
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;&nbsp;8.<replaceable>X</replaceable> and prior is
 	  using the same version of <acronym>PF</acronym> as
-	  OpenBSD&nbsp;4.1.  &os;&nbsp;9.<replaceable>X</replaceable> and
-	  later is using the same version of <acronym>PF</acronym> as
-	  OpenBSD&nbsp;4.5.</para>
+	  OpenBSD&nbsp;4.1.  &os;&nbsp;9.<replaceable>X</replaceable>
+	  and later is using the same version of <acronym>PF</acronym>
+	  as OpenBSD&nbsp;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&mdash;device
-	for every rule that has the <literal>log</literal>
-	keyword.</para>
+	<devicename>ipl</devicename> packet logging
+	pseudo&mdash;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 &amp; 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 -&gt;
 	    symbol, and the destination address and port, e.g.:
-	    <literal>209.53.17.22,80 -&gt; 198.73.220.17,1722</literal>.</para>
+	    <literal>209.53.17.22,80 -&gt;
+	      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>&dollar;</literal>.</para>
@@ -998,11 +1025,11 @@ pass out quick on &dollar;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>