*BSD News Article 54763


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!col.hp.com!usenet.eel.ufl.edu!gatech2!news.sprintlink.net!murphy.servtech.com!btoy1.rochester.ny.us!not-for-mail
From: consult@btoy1.rochester.ny.us (Unix Consulting)
Newsgroups: comp.security.firewalls,comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.bsd.bsdi.misc
Subject: Re: FAQ on ipfw or ipfwadm somewhere ?
Followup-To: comp.security.firewalls,comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.bsd.bsdi.misc
Date: 14 Nov 1995 05:32:05 -0500
Organization: A private site
Lines: 200
Message-ID: <489r75$1r9@btoy3.btoy1.rochester.NY.US>
References: <309F95E8.3E351E3A@hda.hydro.com> <4884i3$2ah@mindy.vnet.net>
Reply-To: consult@btoy1.rochester.ny.us
NNTP-Posting-Host: btoy3.btoy1.rochester.ny.us
X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
Xref: euryale.cc.adfa.oz.au comp.security.firewalls:352 comp.os.linux.networking:19659 comp.unix.bsd.netbsd.misc:1313 comp.unix.bsd.bsdi.misc:1468

Bill Aycock (wda@nr.infi.net) wrote:
: I thought there was something like an unofficial FAQ at ftp.eves.com (or
: perhaps www.eves.com?).
: 
: 	Bill
: 

> From <@vm.gmd.de:owner-big-linux@NETSPACE.ORG>  Sat Apr 29 16:48:20 1995
> Date:         Thu, 27 Apr 1995 10:19:00 PDT
> Reply-To: Linux Servers mailing list <BIG-LINUX@NETSPACE.ORG>
> Sender: Linux Servers mailing list <BIG-LINUX@NETSPACE.ORG>
> From: Andrew Cromarty <andy@DISTRIB.COM>
> Subject:      How to use ipfw under Linux
> To: Multiple recipients of list BIG-LINUX <BIG-LINUX@NETSPACE.ORG>

I've been asked by some BIG-LINUX readers to post instructions on how
to use ipfw.  Enclosed below is a detailed message about how to use
ipfw that I posted on some of the comp.os.linux newsgroups a couple
weeks ago.  My apologies to those of you who have seen this info already.

The explanation enclosed below refers to nettools 1.1.95, but
apparently v. 1.2.0 of the nettools package was just released.  If I
determine that there are any significant changes from 1.1.95 to 1.2.0,
I'll post an update here (or perhaps Alan Cox will kindly correct this
note as required).

To ward off detailed technical questions: I'm not involved in ipfw's
development (but Alan is). I just had the unfortunate experience of
reading the source code a while back so I could figure out how to use
it.  This is a recurring question, and every time I post an answer I get
scads of unsolicited email "thank-you" messages, so as soon as I have
the time, I'll try to assemble a Mini-HOWTO or FAQ, or even just an
improved man page, for ipfw.

Incidentally, someone said here a day or two ago that ipfw now is
called "ipadm".  I certainly don't see any evidence of that, at least
for Linux's version.  In nettools 1.2.0, it's still called ipfw.

        good luck,                              asc

p.s. I realize that the original author of ipfw probably is not on this list.
     But please, guys, in your own freeware efforts, don't program complex
     recursive descent parsers in C, especially without providing profuse
     and truly useful usage documentation.  My mind threw up several times
     while reading this source (25 pages of parser, 100 lines of real work).
     This is not what C is for.  A screwdriver is not a hammer.
     (...There, I feel better now.)

> Newsgroups: comp.os.linux.networking,comp.os.linux.setup,comp.os.linux.misc
> Organization: Distributed Systems Technology

In article <Pine.LNX.3.91.950404114409.136A-100000@bryan.seanet.com>,
Bryan Phillippe <admin@bryan.seanet.com> wrote:

>         I am in DESPERATE need of being able to firewall a particular
> site from my host; I need to deny ALL access: smtp, finger, telnet, ftp,
> everything!  I need any help you can offer me.  I am using Linux 1.2.2
> and pppd on a static IP addressing scheme.  [...]

OK, there seems to be a lot of confusion about this topic; the ipfw docs
are pretty bad, and the hinted-at FAQ hasn't materialized yet.  Here are
the steps you need to follow to use Linux's kernel support for firewalls.
(The other quite reasonable alternative, not discussed here, is to use the
TIS FWTK; see http://www.tis.com/ for more info.)

First, I'll assume you're running a 1.2.x kernel.  It must be 1.2.1
or later.  Kernel 1.2.0 is broken for firewalls; if you have it and need
firewalls, upgrade your kernel by getting the patches from sunsite.unc.edu
or ftp.funet.fi and follow the directions in /usr/src/linux/README.)

Your kernel must be built with CONFIG_IP_FIREWALL enabled (y).
If you're not sure, rebuild your kernel, using the instructions in
the above-mentioned README file.

You also need the nettools-1.1.95 (or later) package.  It is
available via anonymous FTP from ftp.linux.org.uk.  Untar it (into,
say, /usr/local/src/nettools) and "make" it.  Read any READMEs and
the Makefile to be sure you understand what it's doing---it replaces
old copies of some programs with updated versions.

You now have all the tools you need.

Now let's consider a couple examples.  Throughout these examples,
I will assume you have set your IP address to the shell variables
"MYADDR" and "MYLAN".  For example, in /bin/sh or /bin/bash, if your
IP address is 11.22.33.44, then

      MYADDR=11.22.33.44
      MYLAN=$MYADDR/24     # ASSUMES CLASS C NETWORK

OK, here we go:

1. To build an IP firewall that excludes everything in the world
    except incoming mail (just for example--not necessarily a good idea),
    you would use the following commands, as root:

   ipfw add blocking deny tcp from 0/0 to $MYADDR 1-24
   ipfw add blocking deny tcp from 0/0 to $MYADDR 26-1024
   ipfw add blocking deny udp from 0/0 to $MYADDR 1-1024

    These two commands deny all TCP and UDP connects from anywhere
    ("0/0") to your machine ($MYADDR), except for one on port 25.
    (Port 25 is the standard incoming SMTP, i.e. email, port; see
    /etc/services.)  But note that this disables other services some
    mailers might prefer to see (e.g. ident), so things still are a
    little sticky.

   The firewall blocking specification can be checked using the command
      ipfw list blocking
   which can be abbreviated to "ipfw l b".

2. To build a firewall that lets all the machines on a (i.e. your) Class C
   LAN use the r-commands (rlogin, rsh, etc.), but denies access
   to anyone outside your Class C LAN, you use the following commands
   ON EVERY MACHINE ON YOUR CLASS C NETWORK:


   ipfw add blocking accept all from $MYLAN to 0/0
   ipfw add blocking deny   tcp from 0/0 to $MYLAN exec
   ipfw add blocking deny   tcp from 0/0 to $MYLAN login
   ipfw add blocking deny   tcp from 0/0 to $MYLAN shell

   These commands accept r-command connections from your Class C LAN's
   nodes to "anywhere" and deny them from everyone else.  THEY DO NOT
   PREVENT ANY OTHER FORM OF ACCESS; you'd need additional ipfw commands
   for the other services to handle that.

3. To augment the above example by doing "accounting" (counting the
   number of packets) on the accepted intraLAN connections in example
   2, you use the following additional commands:

   ipfw add accounting tcp from 0/0 to $MYLAN/24 exec
   ipfw add accounting tcp from 0/0 to $MYLAN/24 login
   ipfw add accounting tcp from 0/0 to $MYLAN/24 shell

   The accounting records can then be checked using the command
      ipfw list accounting
   which can be abbreviated to "ipfw l a".

4. To prevent own-address IP spoofing attacks like the recently
   publicized Mitnick/Shimomura breakin, IF YOU ARE USING JUST ONE
    MACHINE ON A PPP/SLIP LINK, try this ipfw command:

   ipfw add blocking deny tcp from $MYADDR to $MYADDR

    This says "don't accept any packets from me."  There shouldn't be
    any, of course.  You can see ways to generalize this; however, if you
    are on a LAN rather than a single PP/SLIP-connected machine, then to
    prevent IP spoofing into your LAN, YOU MUST RECONFIGURE YOUR ROUTER
    to reject incoming (from your ISP) packets claiming to come from
    machines on your side of the router/firewall.


These examples are enough to get everyone started.  A few important points
to remember:

1. TEST EVERYTHING.  Don't assume there are no errors or typos here.
   Think like a cracker and try to break into your own system.
2. UNDERSTAND WHAT EACH SERVICE IS FOR.  If you don't know, try reading
   /etc/services and looking through the RFC's.  For example, you can't
   just blindly shut off everything except port 21 (listed as "ftp" in
   your /etc/services) and expect FTP to work, because FTP happens to
   also need port 20 ("ftp-data").
3. AUGMENT YOUR FIREWALL WITH OTHER TOOLS.  There are lots.  For any
   service you don't firewall, at least use tcp wrappers in inetd.conf.
   Try man hosts_access and man hosts_options for more info.  Also, look
   on some of the security-related FTP and web sites for more tools,
   such as COPS, tiger, iss, s/key, crack, etc.  Try these sites:

      ftp://ftp.bellcore.com/pub/nmh/
      http://ciac.llnl.gov/
      http://www.first.org/first/
      http://www.cs.purdue.edu/homes/spaf/hotlists/csec.html
      ftp://ftp.win.tue.nl/pub/security/
      http://www.tis.com/

4. MAINTAIN YOUR PERSPECTIVE.  Despite all the hype about SATAN, for example,
   people whose opinion on security seems worth respecting say that it
   contains nothing new; it's just the same old attacks in a shiny new
   package.  The thing that's different about it is that now any clueless
   emotionally disturbed troglodyte can try to crack your system using
   SATAN, whereas previously only well-informed emotionally disturbed
   troglodytes knew how to do it.  Using the tools mentioned above, you
   can pretty much catch someone in the act of trying to break into your
   system.  Most breakins are because of poorly chosen passwords and sloppy
   FTP, NFS/NIS, or r-command configuration anyway.  Just clean up your
   site and you'll stop most attacks; and of course you can FTP SATAN
   or other tools and try cracking your system yourself before someone
   else does, if you're worried.  And remember, you can always pull
   the plug on the Internet connection, or flip the power switch... :-)

    good luck,              asc

p.s. Standard disclaimer: you are responsible for everything you do or
      don't do with/to your computer.  I'm not.
-- 
-------- Thomas Bullinger ------- Specializing in Linux systems --------
* Installation * Setup * Maintenance * Training * Software * Information
* Email: consult@btoy1.rochester.ny.us    FAX: +1-716-377-6732
* WWW:   http://btoy1-gw.roc.servtech.com/~consult