From nik@crf-consulting.co.uk  Sat Oct 18 05:43:50 2003
Return-Path: <nik@crf-consulting.co.uk>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 1024E16A4B3
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 18 Oct 2003 05:43:50 -0700 (PDT)
Received: from crf-consulting.co.uk (82-44-218-46.cable.ubr10.haye.blueyonder.co.uk [82.44.218.46])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 3526D43FAF
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 18 Oct 2003 05:43:48 -0700 (PDT)
	(envelope-from nik@crf-consulting.co.uk)
Received: from clan.nothing-going-on.org (clan.nothing-going-on.org [192.168.1.20])
	by crf-consulting.co.uk (8.12.8p1/8.12.3) with ESMTP id h9IChlc5064964
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 18 Oct 2003 13:43:47 +0100 (BST)
	(envelope-from nik@catkin)
Received: from clan.nothing-going-on.org (localhost [127.0.0.1])
	by clan.nothing-going-on.org (8.12.8/8.12.8) with ESMTP id h9IChlAg048224
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 18 Oct 2003 13:43:47 +0100 (BST)
	(envelope-from nik@clan.nothing-going-on.org)
Received: (from nik@localhost)
	by clan.nothing-going-on.org (8.12.8/8.12.8/Submit) id h9IChkiG048223;
	Sat, 18 Oct 2003 13:43:46 +0100 (BST)
Message-Id: <200310181243.h9IChkiG048223@clan.nothing-going-on.org>
Date: Sat, 18 Oct 2003 13:43:46 +0100 (BST)
From: Nik Clayton <nik@crf-consulting.co.uk>
Reply-To: Nik Clayton <nik@crf-consulting.co.uk>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: handbook doesn't mention kldload'ness of ipfw
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         58202
>Category:       docs
>Synopsis:       handbook doesn't mention kldload'ness of ipfw
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kensmith
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          doc-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Oct 18 05:50:21 PDT 2003
>Closed-Date:    Sat Dec 24 03:21:31 GMT 2005
>Last-Modified:  Sat Dec 24 03:21:31 GMT 2005
>Originator:     Nik Clayton
>Release:        FreeBSD 4.8-RC i386
>Organization:
>Environment:
System: FreeBSD clan.nothing-going-on.org 4.8-RC FreeBSD 4.8-RC #3: Fri Mar 28 07:59:28 GMT 2003 nik@clan.nothing-going-on.org:/local/1/usr/src/sys/compile/CLAN i386


>Description:

The Handbook's section on enabling ipfw (10.8.3) doesn't mention it's
kldload'ness, just that a kernel recompile is necessary.  Since rc.conf
will load ipfw.ko on demand, this deserves a mention (along with necessary 
anti-foot shooting incantations to avoid looking yourself out of the box).

>How-To-Repeat:
>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-doc->kensmith 
Responsible-Changed-By: kensmith 
Responsible-Changed-When: Sat Oct 18 06:23:49 PDT 2003 
Responsible-Changed-Why:  

I'll take this one, it meshes a little bit with an older PR I was 
looking at regarding IPFW in the advanced networking section. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=58202 

From: Marc Silver <marcs@draenor.org>
To: freebsd-gnats-submit@FreeBSD.org, nik@crf-consulting.co.uk
Cc:  
Subject: Re: docs/58202: handbook doesn't mention kldload'ness of ipfw
Date: Sat, 17 Jan 2004 13:40:52 +0000

 --Bn2rw/3z4jIqBvZU
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 Hi Nik,
 
 I've done some work on this PR and I've included a patch in this email.
 If it's not quite right, or you would like something added or changed,
 I'd be more than willing to help, so please let me know.
 
 Thanks,
 Marc
 
 --Bn2rw/3z4jIqBvZU
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename="security-chapter.sgml-patch"
 
 --- 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>
 
 --Bn2rw/3z4jIqBvZU--

From: "Siebrand Mazeland" <s.mazeland@xs4all.nl>
To: <freebsd-gnats-submit@FreeBSD.org>, <nik@crf-consulting.co.uk>
Cc:  
Subject: Re: docs/58202: handbook doesn't mention kldload'ness of ipfw
Date: Mon, 28 Feb 2005 00:02:59 +0100

 This PR [1] can be closed. kldload'ness of ipfw is in 24.6.1 Enabling IPFW
 [2].
 
 Cheers!
 
 [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=docs/58202
 [2]
 http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.htm
 l#FIREWALLS-IPFW-ENABLE
 
State-Changed-From-To: open->closed 
State-Changed-By: linimon 
State-Changed-When: Sat Dec 24 03:20:39 UTC 2005 
State-Changed-Why:  
Apparently this text or something like it has already been committed (see 
Audit-Trail). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=58202 
>Unformatted:
