diff --git a/en_US.ISO8859-1/articles/dialup-firewall/article.sgml b/en_US.ISO8859-1/articles/dialup-firewall/article.sgml
index ef04596daa..d25137e5dd 100644
--- a/en_US.ISO8859-1/articles/dialup-firewall/article.sgml
+++ b/en_US.ISO8859-1/articles/dialup-firewall/article.sgml
@@ -1,379 +1,378 @@
<!--
The FreeBSD Documentation Project
-->
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
%man;
]>
<article>
<articleinfo>
<title>Dialup firewalling with FreeBSD</title>
<authorgroup>
<author>
<firstname>Marc</firstname>
<surname>Silver</surname>
<affiliation>
<address><email>marcs@draenor.org</email></address>
</affiliation>
</author>
</authorgroup>
<pubdate>$FreeBSD$</pubdate>
<abstract>
<para>This article documents how to setup 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>
</abstract>
</articleinfo>
<sect1 id="preface">
<title>Preface</title>
<para>Dialup Firewalling with FreeBSD</para>
<para>This document covers the process that is required to setup
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@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>
<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>
+ </listitem>
+ </varlistentry>
+
<varlistentry>
<term><literal>options IPFIREWALL_VERBOSE</literal></term>
<listitem>
<para>Sends logged packets to the system logger.</para>
</listitem>
</varlistentry>
<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>
<listitem>
<para>Enables <emphasis>divert</emphasis> sockets, which will be
shown later.</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>
<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>
<programlisting>firewall_enable="YES"
firewall_script="/etc/firewall/fwrules"
natd_enable="YES"
natd_interface="tun0"
natd_flags="-dynamic"</programlisting>
<para>For more information on the functions of these statements take
a look at <filename>/etc/defaults/rc.conf</filename> and read
&man.rc.conf.5;</para>
</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>
<para>If you already have a block of entries to
automatically start PPP, it probably looks like this:</para>
<programlisting>ppp_enable="YES"
ppp_mode="auto"
ppp_nat="YES"
ppp_profile="<replaceable>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>
</sect1>
<sect1 id="rules">
<title>The ruleset 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 rulebase.
What I have tried to do is write a rulebase that suits most dialup
users. You can obviously modify it to your needs by using the
following rules as the foundation for your own rulebase. 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>Now, let's make the dir <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>
<para>Now, let's look at a sample firewall file, that is commented
nicely.</para>
- <programlisting># Firewall rules
-# Written by Marc Silver (marcs@draenor.org)
-# http://draenor.org/ipfw
-# Freely distributable
-
-
-# Define the firewall command (as in /etc/rc.firewall) for easy
+ <programlisting># Define the firewall command (as in /etc/rc.firewall) for easy
# reference. Helps to make it easier to read.
fwcmd="/sbin/ipfw"
# 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 data from my network card and localhost. Make sure you
-# change your network card (mine was fxp0) before you reboot. :)
-$fwcmd add allow ip from any to any via lo0
-$fwcmd add allow ip from any to any via fxp0
+# Allow all connections that have dynamic rules built for them,
+# 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 connections that I initiate.
-$fwcmd add allow tcp from any to any out xmit tun0 setup
+# 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
-# Once connections are made, allow them to stay open.
-$fwcmd add allow tcp from any to any via tun0 established
+# 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
+# Everyone on the Internet is allowed to connect to the following
# services on the machine. This example specifically allows connections
-# to ssh and apache.
-$fwcmd add allow tcp from any to any 80 setup
-$fwcmd add allow tcp from any to any 22 setup
+# 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 any 113 in recv tun0
-
-# Allow outgoing DNS queries ONLY to the specified servers.
-$fwcmd add allow udp from any to <replaceable>x.x.x.x</replaceable> 53 out xmit tun0
-
-# Allow them back in with the answers... :)
-$fwcmd add allow udp from <replaceable>x.x.x.x</replaceable> 53 to any in recv tun0
-
-# Allow ICMP (for ping and traceroute to work). You may wish to
-# disallow this, but I feel it suits my needs to keep them in.
-$fwcmd add allow icmp from any to any
+$fwcmd add reset log tcp from any to me 113 in recv any
# Deny 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
- connections to ports 80 and 22 and will log any other connection
+ 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>
</sect1>
<sect1>
<title>Questions</title>
<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>
</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
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>
<question>
<para>There must be something wrong. I followed your instructions
to the letter and now I am locked out.</para>
</question>
<answer>
<para>This tutorial assumes that you are running
<emphasis>userland-ppp</emphasis>, therefore the supplied ruleset
operates on the <devicename>tun0</devicename> interface, which
corresponds to the first connection made with &man.ppp.8; (a.k.a.
<emphasis>user-ppp</emphasis>). Additional connections would use
<devicename>tun1</devicename>, <devicename>tun2</devicename> and so
on.</para>
<para>You should also note that &man.pppd.8; uses the
<devicename>ppp0</devicename> interface instead, so if you
start the connection with &man.pppd.8; you must substitute
<devicename>tun0</devicename> for
<devicename>ppp0</devicename>. A quick way to edit the
firewall rules to reflect this change is shown below. The
original ruleset is backed up as
<filename>fwrules_tun0</filename>.</para>
<screen> &prompt.user; <userinput>cd /etc/firewall</userinput>
/etc/firewall&prompt.user; <userinput>su</userinput>
<prompt>Password:</prompt>
/etc/firewall&prompt.root; <userinput>mv fwrules fwrules_tun0</userinput>
/etc/firewall&prompt.root; <userinput>cat fwrules_tun0 | sed s/tun0/ppp0/g > fwrules</userinput>
</screen>
<para>To know whether you are currently using &man.ppp.8; or
&man.pppd.8; you can examine the output of
&man.ifconfig.8; once the connection is up. E.g., for a
connection made with &man.pppd.8; you would see something
like this (showing only the relevant lines):</para>
<screen> &prompt.user; <userinput>ifconfig</userinput>
<emphasis>(skipped...)</emphasis>
ppp0: flags=<replaceable>8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1524</replaceable>
inet <replaceable>xxx.xxx.xxx.xxx</replaceable> --> <replaceable>xxx.xxx.xxx.xxx</replaceable> netmask <replaceable>0xff000000</replaceable>
<emphasis>(skipped...)</emphasis>
</screen>
<para>On the other hand, for a connection made with
&man.ppp.8; (<emphasis>user-ppp</emphasis>) you should see
something similar to this:</para>
<screen> &prompt.user; <userinput>ifconfig</userinput>
<emphasis>(skipped...)</emphasis>
ppp0: flags=<replaceable>8010<POINTOPOINT,MULTICAST> mtu 1500</replaceable>
<emphasis>(skipped...)</emphasis>
tun0: flags=<replaceable>8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1524</replaceable>
<emphasis>(IPv6 stuff skipped...)</emphasis>
inet <replaceable>xxx.xxx.xxx.xxx</replaceable> --> <replaceable>xxx.xxx.xxx.xxx</replaceable> netmask <replaceable>0xffffff00</replaceable>
Opened by PID <replaceable>xxxxx</replaceable>
<emphasis>(skipped...)</emphasis></screen>
</answer>
</qandaentry>
</qandaset>
</sect1>
</article>