Attachment 36253 Details for Bug 58202 – security-chapter.sgml-patch

security-chapter.sgml-patch

security-chapter.sgml-patch (text/plain; charset=us-ascii), 9.30 KB, created by Marc Silver on 2004-01-17 13:40:52 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Marc Silver

Created: 2004-01-17 13:40:52 UTC

Size: 9.30 KB

patch

obsolete

>--- chapter.sgml-orig	Sat Jan 17 11:13:40 2004
>+++ chapter.sgml	Sat Jan 17 15:35:07 2004
>@@ -2874,99 +2874,129 @@
>         <secondary>enabling</secondary>
>       </indexterm>
>       
>-      <para>As the main part of the IPFW system
>-	lives in the kernel, you will need to add one or more options to your
>-	kernel configuration file, depending on what facilities you want, and
>-	recompile your kernel.  See "Reconfiguring your Kernel" (<xref
>-	linkend="kernelconfig">)
>-	for more details on how to recompile your
>-	kernel.</para>
>-
>-      <warning>
>-	<para>IPFW defaults to a policy of <literal>deny ip from any to
>-	  any</literal>.  If you do not add other rules during startup to
>-	  allow access, <emphasis>you will lock yourself out</emphasis> of the
>-	  server upon rebooting into a firewall-enabled kernel.  We suggest
>-	  that you set <literal>firewall_type=open</literal> in your
>-	  <filename>/etc/rc.conf</filename> file when first enabling this
>-	  feature, then refining the firewall rules in
>-	  <filename>/etc/rc.firewall</filename> after you have tested that the
>-	  new kernel feature works properly.  To be on the safe side, you may
>-	  wish to consider performing the initial firewall configuration from
>-	  the local console rather than via
>-	  <application>ssh</application>.  Another option is to build a kernel
>-	  using both the <literal>IPFIREWALL</literal> and
>-	  <literal>IPFIREWALL_DEFAULT_TO_ACCEPT</literal> options.  This will
>-	  change the default rule of IPFW to <literal>allow ip from any to
>-	  any</literal> and avoid the possibility of a lockout.</para>
>-      </warning>
>+      <para>There are currently two methods in which you may enable IPFW
>+      	on your system.  Because IPFW interacts with IP packets, it is required 
>+	to run at the kernel level of operation.  This means that the
>+	system administrator may choose to either load a dynamic kernel
>+	module, or may statically compile IPFW into the system kernel.  </para>
>+
>+      <sect3 id="statically-enabling-ipfw"> 
>+        <title>Compiling IPFW into the kernel</title>
>+        <para>In order to add IPFW support to the kernel, you will
>+      	  need to add one or more options to your kernel configuration
>+  	  file, depending on what facilities you want, and recompile your
>+	  kernel.  See "Reconfiguring your Kernel" (<xref
>+	  linkend="kernelconfig">) for more details on how to recompile
>+	  your kernel.</para>
>+
>+      	<warning>
>+	  <para>IPFW defaults to a policy of <literal>deny ip from any to
>+	    any</literal>.  If you do not add other rules during startup
>+	    to allow access, <emphasis>you will lock yourself
>+	    out</emphasis> of the server upon rebooting into a
>+	    firewall-enabled kernel.  We suggest that you set
>+	    <literal>firewall_type=open</literal> in your
>+	    <filename>/etc/rc.conf</filename> file when first enabling
>+	    this feature, then refining the firewall rules in
>+	    <filename>/etc/rc.firewall</filename> after you have tested
>+	    that the new kernel feature works properly.  To be on the
>+	    safe side, you may wish to consider performing the initial
>+	    firewall configuration from the local console rather than
>+	    via <application>ssh</application>.  Another option is to
>+	    build a kernel using both the <literal>IPFIREWALL</literal>
>+	    and <literal>IPFIREWALL_DEFAULT_TO_ACCEPT</literal> options.
>+	    This will change the default rule of IPFW to <literal>allow
>+	    ip from any to any</literal> and avoid the possibility of a
>+	    lockout.</para> 
>+        </warning>
> 
>-      <para>There are currently four kernel configuration options relevant to
>-	IPFW:</para>
>+        <para>There are currently four kernel configuration options relevant to
>+          IPFW:</para>
> 	  
>-      <variablelist>
>-	<varlistentry>
>-	  <term><literal>options IPFIREWALL</literal></term>
>-
>-	  <listitem>
>-	    <para>Compiles into the kernel the code for packet
>-	      filtering.</para>
>-	  </listitem>
>-	</varlistentry>
>+        <variablelist>
>+  	  <varlistentry>
>+	    <term><literal>options IPFIREWALL</literal></term>
>+
>+	    <listitem>
>+	      <para>Compiles into the kernel the code for packet
>+	        filtering.</para>
>+	    </listitem>
>+	  </varlistentry>
> 	      
>-	<varlistentry>
>-	  <term><literal>options IPFIREWALL_VERBOSE</literal></term>
>+	  <varlistentry>
>+	    <term><literal>options IPFIREWALL_VERBOSE</literal></term>
> 		
>-	  <listitem>
>-	    <para>Enables code to allow logging of packets through
>-		&man.syslogd.8;.  Without this option, even if you specify
>-	      that packets should be logged in the filter rules, nothing will
>-	      happen.</para>
>-	  </listitem>
>-	</varlistentry>
>+	    <listitem>
>+	      <para>Enables code to allow logging of packets through
>+	 	&man.syslogd.8;.  Without this option, even if you specify
>+	        that packets should be logged in the filter rules, nothing will
>+	        happen.</para>
>+	    </listitem>
>+	  </varlistentry>
> 
>-	<varlistentry>
>-	  <term><literal>options IPFIREWALL_VERBOSE_LIMIT=10</literal></term>
>+	  <varlistentry>
>+	    <term><literal>options IPFIREWALL_VERBOSE_LIMIT=10</literal></term>
> 		
>-	  <listitem>
>-	    <para>Limits the number of packets logged through
>-		&man.syslogd.8; on a per entry basis.  You may wish to use
>-	      this option in hostile environments in which you want to log
>-	      firewall activity, but do not want to be open to a denial of
>-	      service attack via syslog flooding.</para>
>-
>-	    <para>When a chain entry reaches the packet limit specified,
>-	      logging is turned off for that particular entry.  To resume
>-	      logging, you will need to reset the associated counter using the
>-		&man.ipfw.8; utility:</para>
>+	    <listitem>
>+	      <para>Limits the number of packets logged through
>+	 	&man.syslogd.8; on a per entry basis.  You may wish to use
>+	        this option in hostile environments in which you want to log
>+	        firewall activity, but do not want to be open to a denial of
>+	        service attack via syslog flooding.</para>
>+
>+              <para>When a chain entry reaches the packet limit specified,
>+                logging is turned off for that particular entry.  To resume
>+                logging, you will need to reset the associated counter using the
>+  	       &man.ipfw.8; utility:</para>
> 	    
>-	    <screen>&prompt.root; <userinput>ipfw zero 4500</userinput></screen>
>-	    <para>Where 4500 is the chain entry you wish to continue
>-	      logging.</para>
>-	  </listitem>
>-	</varlistentry>
>-
>-	<varlistentry>
>-	  <term><literal>options IPFIREWALL_DEFAULT_TO_ACCEPT</literal></term>
>-
>-	  <listitem>
>-	    <para>This changes the default rule action from <quote>deny</quote>
>-	      to <quote>allow</quote>.  This avoids the possibility of locking
>-	      yourself out if you happen to boot a kernel with
>-	      <literal>IPFIREWALL</literal> support but have not configured
>-	      your firewall yet.  It is also very useful if you often use
>-	      &man.ipfw.8; as a filter for specific problems as they arise.
>-	      Use with care though, as this opens up the firewall and changes
>-	      the way it works.</para>
>-	  </listitem>
>-	</varlistentry>
>-      </variablelist>
>+	      <screen>&prompt.root; <userinput>ipfw zero 4500</userinput></screen>
>+	      <para>Where 4500 is the chain entry you wish to continue
>+	        logging.</para>
>+	    </listitem>
>+	  </varlistentry>
>+
>+	  <varlistentry>
>+	    <term><literal>options IPFIREWALL_DEFAULT_TO_ACCEPT</literal></term>
>+
>+	    <listitem>
>+	      <para>This changes the default rule action from <quote>deny</quote>
>+	        to <quote>allow</quote>.  This avoids the possibility of locking
>+	        yourself out if you happen to boot a kernel with
>+	        <literal>IPFIREWALL</literal> support but have not configured
>+	        your firewall yet.  It is also very useful if you often use
>+	        &man.ipfw.8; as a filter for specific problems as they arise.
>+	        Use with care though, as this opens up the firewall and changes
>+	        the way it works.</para>
>+	    </listitem>
>+	  </varlistentry>
>+        </variablelist>
>       
>-      <note><para>Previous versions of FreeBSD contained an
>-	<literal>IPFIREWALL_ACCT</literal>  option.  This is now obsolete as
>-	the firewall code automatically  includes accounting
>-	facilities.</para>
>-      </note>
>+        <note><para>Previous versions of FreeBSD contained an
>+          <literal>IPFIREWALL_ACCT</literal>  option.  This is now obsolete as
>+          the firewall code automatically  includes accounting
>+          facilities.</para>
>+        </note>
>+      </sect3>
>+
>+      <sect3 id="dynamically-enabling-ipfw"> 
>+        <title>Loading IPFW as a kernel module</title>
>+        <para>IPFW may be loaded as a kernel module by using the
>+	  &man.kldload.8; utility.</para>
>+      	<warning>
>+	  <para>The IPFW kernel module defaults to a policy of 
>+	    <literal>deny ip from any to any</literal>.  If you load the
>+	      kernel module remotely, you <emphasis>must</emphasis> also
>+	      add an initial rule to allow ip packets.</para>
>+        </warning>
>+	<para>An example of how to load the IPFW kernel module can be
>+	  seen below:</para>
>+	<screen>&prompt.root; <userinput>kldload ipfw.ko && ipfw add 00100 allow ip from any to any</userinput></screen>
>+	<note><para>The firewall options in <filename>/etc/rc.conf</filename>
>+	  will automatically load the IPFW kernel module if needed at
>+	  startup.</para>
>+	</note>
>+      </sect3>
>+
>     </sect2>
> 
>     <sect2>

Actions: View

Attachments on bug 58202: 36253