From owner-freebsd-doc@FreeBSD.ORG Thu Jan 22 00:20:31 2004 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06BD516A4D0 for ; Thu, 22 Jan 2004 00:20:31 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A19C43D39 for ; Thu, 22 Jan 2004 00:20:20 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) i0M8KKFR042579 for ; Thu, 22 Jan 2004 00:20:20 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i0M8KK34042578; Thu, 22 Jan 2004 00:20:20 -0800 (PST) (envelope-from gnats) Resent-Date: Thu, 22 Jan 2004 00:20:20 -0800 (PST) Resent-Message-Id: <200401220820.i0M8KK34042578@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Marc Silver Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DDC916A4CE for ; Thu, 22 Jan 2004 00:13:01 -0800 (PST) Received: from riffraff.plig.net (riffraff.plig.net [195.40.6.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 327E043D39 for ; Thu, 22 Jan 2004 00:12:57 -0800 (PST) (envelope-from marcs@riffraff.plig.net) Received: by riffraff.plig.net (Postfix, from userid 3010) id 62C2AFA514; Thu, 22 Jan 2004 08:12:56 +0000 (GMT) Message-Id: <20040122081256.62C2AFA514@riffraff.plig.net> Date: Thu, 22 Jan 2004 08:12:56 +0000 (GMT) From: Marc Silver To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: docs/61713: maintainer update of dialup firewall article X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Marc Silver List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2004 08:20:31 -0000 >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@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 @@ 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. + 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. @@ -45,40 +47,36 @@ Dialup Firewalling with FreeBSD - This document covers the process that is required to set up + 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 marcs@draenor.org. + as informative and correct as possible, you are welcome to mail + any corrections, comments or suggestions to the author at + marcs@draenor.org. Kernel Options - 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 kernel - configuration section in the Handbook. You need to add the - following options into your kernel configuration file: + 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 kernel configuration + section in the Handbook. The following options must be + added into your kernel configuration file for IPFW support: options IPFIREWALL - Enables the kernel's firewall code. - - - - - options IPFW2 - - - Enables the new version of IPFW. - Only do this if you're running FreeBSD 4.X, - this is the default in newer versions of - FreeBSD. + Enables the kernel firewall code. + This document assumes that you are running + FreeBSD 5.x. Users running FreeBSD 4.x will need to + recompile their kernels with IPFW2 + support. FreeBSD 4.x users should consult the &man.ipfw.8; + man page for more information on using IPFW2 on their + systems. @@ -92,64 +90,37 @@ options - IPFIREWALL_VERBOSE_LIMIT=100 - - - Limits the number of times a matching entry is logged. This - prevents your log file from filling up with lots of repetitive - entries. - 100 is a reasonable number to use, but - you can adjust it based on your requirements. - - - - - options IPDIVERT + IPFIREWALL_VERBOSE_LIMIT=500 - Enables divert sockets, which will be - shown later. + 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. + 500 is a reasonable number to use, but + may be adjusted based on your requirements. - There are 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. - - - - options TCP_DROP_SYNFIN - - - This option ignores TCP packets with SYN and FIN. This - prevents tools like security/nmap 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 a web server. - - - + Once the kernel recompile has been completed, + do not reboot 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. - Do not reboot once you have recompiled the kernel. Hopefully, - we will only need to reboot once to complete the installation of the - firewall. Changing <filename>/etc/rc.conf</filename> to load the firewall - We now need to make some changes to - /etc/rc.conf in order to tell it about the - firewall. Simply add the following lines: + /etc/rc.conf 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 /etc/rc.conf: firewall_enable="YES" -firewall_script="/etc/firewall/fwrules" -natd_enable="YES" -natd_interface="tun0" -natd_flags="-dynamic" +firewall_script="/etc/firewall/fwrules" For more information on the functions of these statements take a look at /etc/defaults/rc.conf and read @@ -157,101 +128,85 @@ - Disable PPP's network address translation - - 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. + Enable PPP's network address translation - If you already have a block of entries to - automatically start PPP, it probably looks like this: + 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 /etc/rc.conf: ppp_enable="YES" ppp_mode="auto" ppp_nat="YES" -ppp_profile="profile" +ppp_profile="your_profile" - If so, you will need to specifically disable - ppp_nat by making sure you have - ppp_nat="NO" in /etc/rc.conf. You will - also need to remove any nat enable yes or - alias enable yes in - /etc/ppp/ppp.conf. + Take care to change your_profile to + the name of your own dialup profile. The rule set for the firewall - 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. :) + 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. + + 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. - Now, let's make the dir First off, let's create the directory where we will store our + firewall rules. In this example, we'll use /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 anything you wish. This guide just - gives an example of a filename. + can change this filename to anything you wish. This guide merely + gives an example of a filename you may want to use. - Now, let's look at a sample firewall file, that is commented - nicely. + Now, let's look at a nicely commented sample firewall + file. # 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 - You now have a fully functional firewall that will allow on + 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. + 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. @@ -259,70 +214,27 @@ - - Why are you using &man.natd.8; and &man.ipfw.8; when - you could be using the built in &man.ppp.8; - filters? - - - - I will have to be honest and say there is no definitive - reason why I use ipfw and - natd instead of the built in - ppp filters. From the discussions I have - 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 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. - - - - - I get messages like limit 100 reached on entry - 2800 and after that I never see more denies in my - logs. Is my firewall still working? + I get messages like limit 500 reached on entry + 2800 and after that I my machine stops logging + denied packets that match that rule number. Is my firewall + still working? 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 ipfw resetlog - 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: + &prompt.root; ipfw resetlog + Alternatively, you may increase the log limit in your kernel configuration with the 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. - - - - - If I am using private addresses internally, such as in the - 192.168.0.0 range, could I add a command like $fwcmd add - deny all from any to 192.168.0.0:255.255.0.0 via tun0 - to the firewall rules to prevent outside attempts to connect to - internal machines? - - - - The simple answer is no. The reason for this is that - natd is doing address translation for - anything being diverted through the - tun0 device. As far as it is - 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 - $fwcmd add deny all from 192.168.0.4:255.255.0.0 - to any via tun0 which would limit a host on your - internal network from going out via the firewall. - >Release-Note: >Audit-Trail: >Unformatted: