From <@vm.gmd.de:
[email protected]> Sat Apr 29 16:48:20 1995
Return-Path: <@vm.gmd.de:
[email protected]>
Received: from coli-gate.coli.uni-sb.de (coli-gate.coli.uni-sb.de [134.96.68.11]) by jurix.jura.uni-sb.de (8.6.11/8.6.9) with ESMTP id QAA02358 for <
[email protected]>; Sat, 29 Apr 1995 16:48:19 +0200
Received: from mxrelay.gmd.de (mxrelay.gmd.de [192.88.97.99]) by coli-gate.coli.uni-sb.de (8.6.10/8.6.4) with ESMTP id QAA21604 for <
[email protected]>; Sat, 29 Apr 1995 16:48:13 +0200
Received: from vm.gmd.de by mxrelay.gmd.de (SF for OpenVMS v1.0-a) with SMTP id 4E3609C8 ; Sat, 29 Apr 1995 12:36:25 +0200
Received: from VM.GMD.DE by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 9999;
Sat, 29 Apr 95 12:29:52 +0200
Received: from VM.GMD.DE (NJE origin LISTSERV@DEARN) by VM.GMD.DE (LMail V1.2a/1.8a) with BSMTP id 0744; Sat, 29 Apr 1995 12:29:51 +0200
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8a) with
spool id 14639 for
[email protected]; Fri, 28 Apr 1995 14:03:10
-0400
Received: from distrib.com (www.distrib.com [204.119.65.18]) by netspace.org
(8.6.10/8.6.9) with SMTP id OAA23884 for <
[email protected]>;
Fri, 28 Apr 1995 14:02:22 -0400
Received: by distrib.com (Smail3.1.28.1 #64) id m0s4XDy-000EWtC; Thu, 27 Apr 95
10:19 PDT
Message-ID: <
[email protected]>
Date: Thu, 27 Apr 1995 10:19:00 PDT
Reply-To: Linux Servers mailing list <
[email protected]>
Sender: Linux Servers mailing list <
[email protected]>
From: Andrew Cromarty <
[email protected]>
Subject: How to use ipfw under Linux
To: Multiple recipients of list BIG-LINUX <
[email protected]>
Status: RO
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
References: <
[email protected]> <
[email protected]>
Organization: Distributed Systems Technology
In article <
[email protected]>,
Bryan Phillippe <
[email protected]> 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.
