docs/61713: maintainer update of dialup firewall article
Marc Silver
marcs at draenor.org
Thu Jan 22 08:20:31 UTC 2004
>Number: 61713
>Category: docs
>Synopsis: maintainer update of dialup firewall article
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: freebsd-doc
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: maintainer-update
>Submitter-Id: current-users
>Arrival-Date: Thu Jan 22 00:20:20 PST 2004
>Closed-Date:
>Last-Modified:
>Originator: Marc Silver
>Release: FreeBSD 4.9-STABLE i386
>Organization:
>Environment:
System: FreeBSD riffraff.plig.net 4.9-STABLE FreeBSD 4.9-STABLE #4: Mon Jan 5 11:52:58 GMT 2004 keet at riffraff.plig.net:/usr/src/sys/compile/RIFFRAFF i386
>Description:
An update was submitted to the dialup firewall article a few months
ago by another user, and since then I've had multiple reports of
failures resulting from the rules in this article. I've now
re-written the document to cover IPFW2 and newer versions of
FreeBSD.
>How-To-Repeat:
Just try and run the rulebase with natd, and you'll find it very
broken.
>Fix:
Patch attached:
--- article.sgml-orig Wed Jan 21 08:29:00 2004
+++ article.sgml Thu Jan 22 10:01:37 2004
@@ -36,7 +36,9 @@
<para>This article documents how to set up a firewall using a PPP
dialup with FreeBSD and IPFW, and specifically with firewalling over
a dialup with a dynamically assigned IP address. This document does
- not cover setting up your PPP connection in the first place.</para>
+ not include information on setting up an initial PPP connection.
+ For more information on setting up a PPP connection, consult
+ the &man.ppp.8; man page.</para>
</abstract>
</articleinfo>
@@ -45,40 +47,36 @@
<para>Dialup Firewalling with FreeBSD</para>
- <para>This document covers the process that is required to set up
+ <para>This document outlines the steps required to set up
firewalling with FreeBSD when an IP address is assigned dynamically
by your ISP. While every effort has been made to make this document
- as informative and correct as possible, you are welcome to mail your
- comments/suggestions to the <email>marcs at draenor.org</email>.</para>
+ as informative and correct as possible, you are welcome to mail
+ any corrections, comments or suggestions to the author at
+ <email>marcs at draenor.org</email>.</para>
</sect1>
<sect1 id="kernel">
<title>Kernel Options</title>
- <para>The first thing you will need to do is recompile your kernel.
- If you need more information on how to recompile the kernel,
- then the best place to start is the <ulink
- URL="../../books/handbook/kernelconfig.html">kernel
- configuration section in the Handbook</ulink>. You need to add the
- following options into your kernel configuration file:</para>
+ <para>In order to use IPFW, support for it must be compiled into the
+ kernel. For more information on how to recompile the kernel,
+ please see the <ulink
+ URL="../../books/handbook/kernelconfig.html">kernel configuration
+ section in the Handbook</ulink>. The following options must be
+ added into your kernel configuration file for IPFW support:</para>
<variablelist>
<varlistentry>
<term><literal>options IPFIREWALL</literal></term>
<listitem>
- <para>Enables the kernel's firewall code.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>options IPFW2</literal></term>
-
- <listitem>
- <para>Enables the new version of IPFW.</para>
- <important><para>Only do this if you're running FreeBSD 4.X,
- this is the default in newer versions of
- FreeBSD.</para></important>
+ <para>Enables the kernel firewall code.</para>
+ <note><para>This document assumes that you are running
+ FreeBSD 5.x. Users running FreeBSD 4.x will need to
+ recompile their kernels with <emphasis>IPFW2</emphasis>
+ support. FreeBSD 4.x users should consult the &man.ipfw.8;
+ man page for more information on using IPFW2 on their
+ systems.</para></note>
</listitem>
</varlistentry>
@@ -92,64 +90,37 @@
<varlistentry>
<term><literal>options
- IPFIREWALL_VERBOSE_LIMIT=<replaceable>100</replaceable></literal></term>
-
- <listitem>
- <para>Limits the number of times a matching entry is logged. This
- prevents your log file from filling up with lots of repetitive
- entries.
- <replaceable>100</replaceable> is a reasonable number to use, but
- you can adjust it based on your requirements.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>options IPDIVERT</literal></term>
+ IPFIREWALL_VERBOSE_LIMIT=<replaceable>500</replaceable></literal></term>
<listitem>
- <para>Enables <emphasis>divert</emphasis> sockets, which will be
- shown later.</para>
+ <para>Limits the number of times a matching entry may be logged.
+ This allows you to log firewall activity without the risk of
+ syslog flooding in the event of a denial of service attack.
+ <replaceable>500</replaceable> is a reasonable number to use, but
+ may be adjusted based on your requirements.</para>
</listitem>
</varlistentry>
</variablelist>
- <para>There are some other <emphasis>optional</emphasis> items that you
- can compile into the kernel for some added security. These are not
- required in order to get firewalling to work, but some more paranoid
- users may want to use them.</para>
-
- <variablelist>
- <varlistentry>
- <term><literal>options TCP_DROP_SYNFIN</literal></term>
-
- <listitem>
- <para>This option ignores TCP packets with SYN and FIN. This
- prevents tools like <filename role="package">security/nmap</filename> from identifying the TCP/IP
- stack of the machine, but breaks support for RFC1644
- extensions. This is <emphasis>not</emphasis> recommended if the
- machine will be running a web server.</para>
- </listitem>
- </varlistentry>
- </variablelist>
+ <warning><para>Once the kernel recompile has been completed,
+ <emphasis>do not reboot</emphasis> your system. Doing so may result
+ in you being locked out of your own system. You must only reboot
+ once the ruleset is in place and all the relevant configuration
+ files have been updated.</para></warning>
- <para>Do not reboot once you have recompiled the kernel. Hopefully,
- we will only need to reboot once to complete the installation of the
- firewall.</para>
</sect1>
<sect1 id="rcconf">
<title>Changing <filename>/etc/rc.conf</filename> to load the
firewall</title>
- <para>We now need to make some changes to
- <filename>/etc/rc.conf</filename> in order to tell it about the
- firewall. Simply add the following lines:</para>
+ <para><filename>/etc/rc.conf</filename> needs to be slightly
+ modified in order to tell the system about the firewall and to
+ specify the location for our rules file. Add the following lines
+ to <filename>/etc/rc.conf</filename>:</para>
<programlisting>firewall_enable="YES"
-firewall_script="/etc/firewall/fwrules"
-natd_enable="YES"
-natd_interface="tun0"
-natd_flags="-dynamic"</programlisting>
+firewall_script="/etc/firewall/fwrules"</programlisting>
<para>For more information on the functions of these statements take
a look at <filename>/etc/defaults/rc.conf</filename> and read
@@ -157,101 +128,85 @@
</sect1>
<sect1>
- <title>Disable PPP's network address translation</title>
-
- <para>You may already be using PPP's built in network address
- translation (NAT). If that is the case then you will have to disable
- it, as these examples use &man.natd.8; to do the same.</para>
+ <title>Enable PPP's network address translation</title>
- <para>If you already have a block of entries to
- automatically start PPP, it probably looks like this:</para>
+ <para>In order to allow clients on your network to connect our via
+ your gateway, you will need to enable PPP's network address
+ translation (NAT). In order to use PPP's NAT functions, add the
+ following lines to <filename>/etc/rc.conf</filename>:</para>
<programlisting>ppp_enable="YES"
ppp_mode="auto"
ppp_nat="YES"
-ppp_profile="<replaceable>profile</replaceable>"</programlisting>
+ppp_profile="<replaceable>your_profile</replaceable>"</programlisting>
- <para>If so, you will need to specifically disable
- <literal>ppp_nat</literal> by making sure you have
- <literal>ppp_nat="NO"</literal> in <filename>/etc/rc.conf</filename>. You will
- also need to remove any <literal>nat enable yes</literal> or
- <literal>alias enable yes</literal> in
- <filename>/etc/ppp/ppp.conf</filename>.</para>
+ <note><para>Take care to change <literal>your_profile</literal> to
+ the name of your own dialup profile.</para></note>
</sect1>
<sect1 id="rules">
<title>The rule set for the firewall</title>
- <para>We are nearly done now. All that remains now is to define
- the firewall rules and then we can reboot and the firewall
- should be up and running. I realize that everyone will want
- something slightly different when it comes to their rule base.
- What I have tried to do is write a rule base that suits most dialup
- users. You can obviously modify it to your needs by using the
- following rules as the foundation for your own rule base. First,
- let's start with the basics of closed firewalling. What you
- want to do is deny everything by default and then only open up
- for the things you really need. Rules should be in the order of
- allow first and then deny. The premise is that you add the
- rules for your allows, and then everything else is
- denied. :)</para>
+ <para>This is the point where we define the firewall rules for your
+ system. The ruleset that we're about to describe is a generic
+ template for most dialup users. While it wont suit the exact
+ needs of every user, it provides you with a basic idea of how IPFW
+ works and should be fairly easy to customize.</para>
+
+ <para>First, let's start with the basics of closed firewalling.
+ Closed firewalling is based on the idea that everything is denied
+ by default. The system administrator may then explicitly add
+ rules for traffic that he or she would like to allow. Rules
+ should be in the order of allow first, and then deny. The premise
+ is that you add the rules for everything you would like to allow,
+ and then everything else is automatically denied.</para>
- <para>Now, let's make the dir <filename
+ <para>First off, let's create the directory where we will store our
+ firewall rules. In this example, we'll use <filename
class="directory">/etc/firewall</filename>. Change into the
directory and edit the file <filename>fwrules</filename> as we
specified in <filename>rc.conf</filename>. Please note that you
- can change this filename to anything you wish. This guide just
- gives an example of a filename. </para>
+ can change this filename to anything you wish. This guide merely
+ gives an example of a filename you may want to use.</para>
- <para>Now, let's look at a sample firewall file, that is commented
- nicely.</para>
+ <para>Now, let's look at a nicely commented sample firewall
+ file.</para>
<programlisting># Define the firewall command (as in /etc/rc.firewall) for easy
# reference. Helps to make it easier to read.
fwcmd="/sbin/ipfw"
+# Define our outside interface. With userland-ppp this
+# defaults to tun0.
+oif="tun0"
+
# Force a flushing of the current rules before we reload.
$fwcmd -f flush
-# Divert all packets through the tunnel interface.
-$fwcmd add divert natd all from any to any via tun0
-
-# Allow all connections that have dynamic rules built for them,
+# Allow all connections that we initiate, and keep their state,
# but deny established connections that don't have a dynamic rule.
-# See ipfw(8) for details.
$fwcmd add check-state
-$fwcmd add deny tcp from any to any established
-
-# Allow all localhost connections
-$fwcmd add allow tcp from me to any out via lo0 setup keep-state
-$fwcmd add deny tcp from me to any out via lo0
-$fwcmd add allow ip from me to any out via lo0 keep-state
-
-# Allow all connections from my network card that I initiate
-$fwcmd add allow tcp from me to any out xmit any setup keep-state
-$fwcmd add deny tcp from me to any
-$fwcmd add allow ip from me to any out xmit any keep-state
-
-# Everyone on the Internet is allowed to connect to the following
-# services on the machine. This example specifically allows connections
-# to sshd and a webserver.
-$fwcmd add allow tcp from any to me dst-port 22,80 in recv any setup keep-state
-
-# This sends a RESET to all ident packets.
-$fwcmd add reset log tcp from any to me 113 in recv any
+$fwcmd add allow ip from me to any out via $oif keep-state
+$fwcmd add deny tcp from any to any established in via $oif
-# Enable ICMP: remove type 8 if you don't want your host to be pingable
-$fwcmd add allow icmp from any to any icmptypes 0,3,8,11,12,13,14
+# Allow internet users to connect to the port 22 and 80.
+# This example specifically allows connections to the sshd and a
+# webserver.
+$fwcmd add allow tcp from any to me dst-port 22,80 in via $oif setup keep-state
+
+# Allow ICMP packets: remove type 8 if you don't want your host
+# to be pingable.
+$fwcmd add allow icmp from any to any via $oif icmptypes 0,3,8,11,12
-# Deny all the rest.
+# Deny and log all the rest.
$fwcmd add deny log ip from any to any</programlisting>
- <para>You now have a fully functional firewall that will allow on
+ <para>You now have a fully functional firewall that only allows
connections to ports 22 and 80 and will log any other connection
- attempts. Now, you should be able to safely reboot and your firewall
- should come up fine. If you find this incorrect in anyway or experience
- any problems, or have any suggestions to improve this page, please
- email me.</para>
+ attempts. You may now safely safely reboot and the firewall should
+ be automatically started and the ruleset loaded. If you find this
+ incorrect in anyway or experience any problems, or have any
+ suggestions to improve this page, please email me.</para>
</sect1>
<sect1>
@@ -259,70 +214,27 @@
<qandaset>
<qandaentry>
- <question>
- <para>Why are you using &man.natd.8; and &man.ipfw.8; when
- you could be using the built in &man.ppp.8;
- filters?</para>
- </question>
-
- <answer>
- <para>I will have to be honest and say there is no definitive
- reason why I use <command>ipfw</command> and
- <command>natd</command> instead of the built in
- <command>ppp</command> filters. From the discussions I have
- had with people the consensus seems to be that while
- <command>ipfw</command> is certainly more powerful and
- more configurable than the <command>ppp</command> filters,
- what it makes up for in functionality it loses in being
- easy to customize. One of the reasons I use it is because
- I prefer firewalling to be done at a kernel level rather
- than by a userland program.</para>
- </answer>
- </qandaentry>
-
- <qandaentry>
<question>
- <para>I get messages like <errorname>limit 100 reached on entry
- 2800</errorname> and after that I never see more denies in my
- logs. Is my firewall still working?</para>
+ <para>I get messages like <errorname>limit 500 reached on entry
+ 2800</errorname> and after that I my machine stops logging
+ denied packets that match that rule number. Is my firewall
+ still working?</para>
</question>
<answer>
<para>This merely means that the maximum logging count for
the rule has been reached. The rule itself is still
working, but it will no longer log until such time as you
- reset the logging counters. You can reset the logging
- counters with the <command>ipfw resetlog</command>
- command. Alternatively, you may increase the log limit in
+ reset the logging counters. An example of how to clear your
+ counters can be found below:</para>
+ <screen>&prompt.root; <userinput>ipfw resetlog</userinput></screen>
+ <para>Alternatively, you may increase the log limit in
your kernel configuration with the
<option>IPFIREWALL_VERBOSE_LIMIT</option> option as
described above. You may also change this limit (without
recompiling your kernel and having to reboot) by using the
net.inet.ip.fw.verbose_limit &man.sysctl.8; value.</para>
</answer>
- </qandaentry>
-
- <qandaentry>
- <question>
- <para>If I am using private addresses internally, such as in the
- 192.168.0.0 range, could I add a command like <literal>$fwcmd add
- deny all from any to 192.168.0.0:255.255.0.0 via tun0</literal>
- to the firewall rules to prevent outside attempts to connect to
- internal machines?</para>
- </question>
-
- <answer>
- <para>The simple answer is no. The reason for this is that
- <command>natd</command> is doing address translation for
- <emphasis>anything</emphasis> being diverted through the
- <devicename>tun0</devicename> device. As far as it is
- concerned incoming packets will speak only to the
- dynamically assigned IP address and <emphasis>not</emphasis> to
- the internal network. Note though that you can add a rule like
- <literal>$fwcmd add deny all from 192.168.0.4:255.255.0.0
- to any via tun0</literal> which would limit a host on your
- internal network from going out via the firewall.</para>
- </answer>
</qandaentry>
<qandaentry>
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-doc
mailing list