Re: Clever firewall rules

From: Scott Gifford (sgifford@tir.com)
Date: 09/14/01


To: "Rob 'Feztaa' Park" <fezziker@home.com>
Subject: Re: Clever firewall rules
From: Scott Gifford <sgifford@tir.com>
Date: 13 Sep 2001 22:27:40 -0400
Message-ID: <ly3d5qo6ar.fsf@gfn.org>

Thanks for posting these; I'd love to see others follow suit, and
maybe we can put together a "recommended" ruleset for a couple
different configurations.

A few comments...

"Rob 'Feztaa' Park" <fezziker@home.com> writes:

> On Thu, 13 Sep 2001, Darin Wayrynen (dis)graced my inbox with this:
>
> > Ok, stop teasing already! :-) What are you favorites [iptables rules]?
>
> Well, here are the ones I think are good to have:
>
> * iptables -A INPUT -i eth0 -p tcp -m state --state NEW ! --syn -j REJECT
> --reject with host-unreach
>
> This one drops all incoming packets that are not SYN packets, and are not
> part of existing connections. This will automatically prevent portscans
> that use anything but SYN packets from seeing anything (So I'm invincible
> to FIN, NULL, and XMAS packet scans).
>
> * iptables -A INPUT -i eth0 -m state --state INVALID -j REJECT
> --reject-with host-unreach
>
> I used to think this would automatically drop malformed packets like
> NULL and XMAS, but then I read the man page on iptables and it seems more
> like this rule does what the last one is supposed to do, so I'm sort of
> confused as to whether #1 actually does anything (I'm starting to think
> that all packets that aren't part of established connections are NEW for
> SYN's, and INVALID for everything else.)
>
> Either way, both rules are in my firewall, and it produces the results I'm
> looking for. Having both certainly isn't hurting anything, and redundancy
> is good in the security world :). Although, if anybody can clear up the
> states for me, that'd be nice :)

Those two are pretty slick!

>
> * iptables -A INPUT -p icmp --icmp-type 8 -j REJECT --reject-with
> host-unreach
>
> Prevents people from pinging me without crippling my ability to
> ping/traceroute other people. Mainly this is just a minor annoyance for
> people trying to portscan me with programs like nmap that ping the host
> first, they just have to add -P0 and try again. Then again, this might
> stop some really stupid script kiddies. I'm thinking about setting up a
> similar rule that would log people who ping me, just for fun.
>
> Oh, and I suppose this rule does immunize me against ping bomb attacks...

I wonder how much this rule helps? For each ping packet they send, it
looks like they'll get an ICMP Host Unreachable message, which hints
that a host is there (generally you'll just get no response if there's
no host there), and if they send a storm of echo-requests, they'll get
a storm of host unreachables back...

I'm not at all convinced of the utility of dropping diagnostic
packets, like ICMP echo-request and echo-reply, and other
traceroute-related packets, but if you're going to do it, it seems
like you should just drop them on the floor.

>
> * iptables -A INPUT -i eth0 -f -j REJECT --reject-with host-unreach
>
> Just drops fragments. I'm not really an expert on this, but I heard that
> fragments can be used maliciously (in port scans and such) and have little
> to no valid use nowadays, so I thought it might be smart to block them.

This might not be a great idea, either; the only time fragmented
packets are insecure is if your firewall doesn't reassemble them
before inspecting them, and it should be straightforward to configure
iptables to always reassemble packets before inspecting them.

While fragmentation doesn't happen much nowadays, there are probably
still places where it's necessary and PMTU-D is not supported, so
dropping them seems unwise when you can instead have them reassembled
and inspected.

Thanks again for posting these!

----ScottG.

[...]