299 lines
11 KiB
Text
299 lines
11 KiB
Text
<!--
|
|
The FreeBSD Documentation Project
|
|
|
|
$FreeBSD: doc/en_US.ISO_8859-1/articles/dialup-firewall/article.sgml,v 1.3 2000/07/11 10:21:49 nbm Exp $
|
|
-->
|
|
|
|
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V3.1-Based Extension//EN" [
|
|
<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
|
|
%man;
|
|
]>
|
|
|
|
<article>
|
|
<artheader>
|
|
<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>$Date: 2000-08-19 20:51:20 $</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>
|
|
</artheader>
|
|
|
|
<sect1 id="preface">
|
|
<title>Preface</title>
|
|
|
|
<para>Dialup Firewalling with FreeBSD</para>
|
|
|
|
<para>This document aims to cover the process that is required in
|
|
order to setup firewalling with FreeBSD when are dynamically
|
|
assigned an IP address 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
|
|
<ulink URL="mailto:marcs@draenor.org">maintainer</ulink>.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="kernel">
|
|
<title>Kernel Options</title>
|
|
|
|
<para>The first thing you'll need to do is recompile your kernel in
|
|
FreeBSD. If you need more information on how to recompile the kernel,
|
|
then the best place to start is the <ulink
|
|
URL="http://www.freebsd.org/handbook/kernelconfig.html">kernel
|
|
configuration section in the Handbook</ulink>. You need to compile the
|
|
following options into the kernel: </para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><literal>options IPFIREWALL</literal></term>
|
|
|
|
<listitem>
|
|
<para>Enables the kernel's firewall code.</para>
|
|
</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
|
|
stops your log files 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 also some other OPTIONAL 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_RESTRICT_RST</literal></term>
|
|
|
|
<listitem>
|
|
<para>This option blocks all TCP RST packets. This is
|
|
best used for systems that might be exposed to SYN
|
|
flooding (IRC Servers are a good example) or for those who
|
|
do not want to be easily portscannable.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>options TCP_DROP_SYNFIN</literal></term>
|
|
|
|
<listitem>
|
|
<para>This option ignores TCP packets with SYN and FIN. This
|
|
prevents tools such as nmap etc from identifying the TCP/IP
|
|
stack of the machine, but breaks support for RFC1644
|
|
extensions. This is NOT recommended if the machine will be
|
|
running web server.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>Don't reboot once you have recompiled the kernel. Hopefully, we will
|
|
need to reboot just once in order to complete the installing 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 what the above do 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 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, remove the <literal>ppp_nat="YES"</literal> line. 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're 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 realise that everyone will want something slightly different
|
|
when it comes to their rulebase. What I've tried to do is write a
|
|
rulebase that suits most dialup users. You can obviously modify it to
|
|
your needs by simply 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 premis is that you add the
|
|
rules for your allows, and then everything else is denied. :)</para>
|
|
|
|
<para>Now, let's make the dir /etc/firewall. Change into the directory and
|
|
edit the file fwrules as we specified in rc.conf. Please note that you
|
|
can change this filename to be anything you wish. This guide just gives
|
|
an example of a filename. </para>
|
|
|
|
<para>Now, let's look at a sample firewall file, and we'll detail
|
|
everything in it. </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
|
|
# 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 I initiate.
|
|
$fwcmd add allow tcp from any to any out xmit tun0 setup
|
|
|
|
# Once connections are made, allow them to stay open.
|
|
$fwcmd add allow tcp from any to any via tun0 established
|
|
|
|
# Everyone on the internet is allowed to connect to the following
|
|
# services on the machine. This example shows that people may connect
|
|
# to ssh and apache.
|
|
$fwcmd add allow tcp from any to any 80 setup
|
|
$fwcmd add allow tcp from any to any 22 setup
|
|
|
|
# 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 65435 allow icmp from any to any
|
|
|
|
# Deny all the rest.
|
|
$fwcmd add 65435 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
|
|
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 natd and ipfw when you could be using
|
|
the built in ppp-filters?</para>
|
|
</question>
|
|
|
|
<answer>
|
|
<para>I'll have to be honest and say there's no definitive reason
|
|
why I use ipfw and natd instead of the built in ppp filters. From
|
|
the discussions I've had with people the consensus seems to be
|
|
that while ipfw is certainly more powerful and more configurable
|
|
than the ppp filters, what it makes up for in functionality it
|
|
loses in being easy to customise. 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>If I'm 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 natd is
|
|
doing address translation for <emphasis>anything</emphasis> being
|
|
diverted through the tun0 device. As far as it's concerned
|
|
incoming packets will speak only to the dynamically assigned IP
|
|
address and NOT 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>
|
|
</qandaset>
|
|
</sect1>
|
|
</article>
|