[TriLUG] IPTables help

[Tanner Lovelace]

On Mon, 2002-09-16 at 15:38, jeffj at ro.com wrote:
> I've put down one way which I think will work. I made a couple scripts
> that call iptables directly to do what I wanted, so I'm not sure it's
> exactly what you were looking for.

Well, I'm open to different ways of setting things up. Redhat provides
a program called iptables-save that will save the running iptables
setup in the correct files to use with their default setup, so
how it's originally setup is less of an issue.
 
> Leave the default policy to accept. We'll fix the problems with that
> shortly.

I'd prefer to be more explicit with this.  Something similar to
what Spot did with loopback in the presentation he mentioned here
recently.  What reason do you have for doing it your way?
 
> # make a chain called block
> /sbin/iptables -N block
> # allow data to come in from the internet
> /sbin/iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
> # allow new connections from the trusted LAN
> /sbin/iptables -A block -m state --state NEW -i eth1 -j ACCEPT
> # disallow anything else
> /sbin/iptables -A block -j DROP

You know.  This looked *very* familiar.  So familiar, in fact, that I
pulled out the magazine I was reading yesterday and sure enough, there
it was.  It referred to the following web page:
http://www.netfilter.org/unreliable-guides/packet-filtering-HOWTO/packet-filtering-HOWTO.linuxdoc-5.html

What I'd like to know is 1) What is this doing? (yes, I see the
comments, but I'd like some more explanation, especially as to
why you're creating a special "chain" and not putting it directly
on the INPUT one.), 2) Why should we deal with eth1 here instead
of handling it directly?
 
> # make a chain called servers
> /sbin/iptables -N servers
> # allow data to come in to the FTP server
> /sbin/iptables -A servers -p udp --dport 20 -j ACCEPT
> /sbin/iptables -A servers -p tcp --dport 20 -j ACCEPT
> /sbin/iptables -A servers -p udp --dport 21 -j ACCEPT
> /sbin/iptables -A servers -p tcp --dport 21 -j ACCEPT
> # allow data to come in to the HTTP server
> /sbin/iptables -A servers -p udp --dport 80 -j ACCEPT
> /sbin/iptables -A servers -p tcp --dport 80 -j ACCEPT
> # other servers . . .

Once again, why make a special chain for this?  I suppose
it does make it stand out more, but I'm more used to
not using chains.  Are there any other advantages of
chains?
 
> That is done at the end of the block chain, although I didn't add logging.

Okay, that makes sense.  I've seen something that looked interesting
along this line in Spot's recent presentation...
 
> Now to link everything together:
> 
> # connect the custom chains to the predefined ones
> /sbin/iptables -A INPUT -j servers
> /sbin/iptables -A INPUT -j block
> /sbin/iptables -A FORWARD -j block

Why are you using the block chain for FORWARD?  The block
chain seems to allow some things through.  I'd rather not
be forwarding at all.  Why shouldn't I just have it drop
anything that needs to be forwarded.  This isn't a router at
all.

> You may need to load modules at the start if you're writing a script 
> like I did.
> 
> # load modules
> /sbin/modprobe ip_conntrack
> /sbin/modprobe ip_conntrack_ftp
> /sbin/modprobe ip_tables
> /sbin/modprobe iptable_filter
> /sbin/modprobe iptable_mangle

Understood.  Anyone know how the default redhat install
manages this?  I can always add it to one of the init
scripts, but I'm pretty sure they've already thought of that. :-)

Thanks much!
Tanner
-- 
Tanner Lovelace | lovelace at wayfarer.org | http://wtl.wayfarer.org/
--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
GPG Fingerprint = A66C 8660 924F 5F8C 71DA  BDD0 CE09 4F8E DE76 39D4
GPG Key can be found at http://wtl.wayfarer.org/lovelace.gpg.asc
--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
          Si hoc legere scis, nimium eruditionis habes.