Update of the content by maintainer.
Approved by: simon(mentor) PR: docs/61713 Submitted by: Marc Silver <marcs@draenor.org>
This commit is contained in:
Josef El-Rayes
parent
350d7186fd
commit
83248c9694
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=19825
1 changed files with 94 additions and 179 deletions
|
|
@ -6,6 +6,9 @@
|
|||
<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
|
||||
%man;
|
||||
|
||||
<!ENTITY % freebsd PUBLIC "-//FreeBSD//ENTITIES DocBook Miscellaneous FreeBSD Entities//EN">
|
||||
%freebsd;
|
||||
|
||||
<!ENTITY % trademarks PUBLIC "-//FreeBSD//ENTITIES DocBook Trademark Entities//EN">
|
||||
%trademarks;
|
||||
]>
|
||||
|
|
@ -36,7 +39,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; manual page.</para>
|
||||
</abstract>
|
||||
</articleinfo>
|
||||
|
||||
|
|
@ -45,40 +50,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@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@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
|
||||
&os; 5.X. Users running &os; 4.X will need to
|
||||
recompile their kernels with <emphasis>IPFW2</emphasis>
|
||||
support. &os; 4.X users should consult the &man.ipfw.8;
|
||||
manual page for more information on using IPFW2 on their
|
||||
systems.</para></note>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
|
@ -92,64 +93,37 @@
|
|||
|
||||
<varlistentry>
|
||||
<term><literal>options
|
||||
IPFIREWALL_VERBOSE_LIMIT=<replaceable>100</replaceable></literal></term>
|
||||
IPFIREWALL_VERBOSE_LIMIT=<replaceable>500</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>
|
||||
<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>
|
||||
<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>
|
||||
|
||||
<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>
|
||||
<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,143 +131,107 @@ natd_flags="-dynamic"</programlisting>
|
|||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Disable PPP's network address translation</title>
|
||||
<title>Enable 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>
|
||||
<para>In order to allow clients on your network to connect 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 will not 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>Now, let's make the dir <filename
|
||||
<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>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
|
||||
$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
|
||||
|
||||
# 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 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 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
|
||||
# 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
|
||||
|
||||
# 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
|
||||
|
||||
# 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
|
||||
|
||||
# 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>
|
||||
<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>
|
||||
<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
|
||||
|
|
@ -302,29 +240,6 @@ $fwcmd add deny log ip from any to any</programlisting>
|
|||
</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
|
||||
|
|
|
|||
Loading…
Reference in a new issue