Clever Firewall Rules, Second Edition

From: Rob 'Feztaa' Park (fezziker@home.com)
Date: 09/16/01 

Date: Sun, 16 Sep 2001 11:38:45 -0600 (MDT)
From: Rob 'Feztaa' Park <fezziker@home.com>
To: Bugtraq - Focus Linux <focus-linux@securityfocus.com>
Subject: Clever Firewall Rules, Second Edition
Message-ID: <Pine.LNX.4.33L2.0109161047430.1436-100000@feztron.ath.cx>

Thanks to the help of many on this list, I have revised my iptables
rulesets. I think it is now different enough to warrant another round of
scrutiny :)

I think, for the most part, the order of these rules *is* important,
improper order can lead to screwy results.

* iptables -P INPUT DROP

Should the firewall fail, for whatever reason, we are left with a
situation where the firewall mistrusts the internet by default, which is
probably a good thing.

* iptables -A INPUT -p tcp -m state --state NEW ! --syn -j DROP

We already covered this one, but quick recap: Drops all new packets that
are not SYN packets, which are most likely evil (prevents against FIN,
NULL, and XMAS packet scans).

* iptables -A INPUT -m state --state INVALID -j DROP

Drop's invalid packets, already covered.

[then I have some ordinary rules for blocking ports that I don't want
people to connect to, like MySQL and X. No need to cover those]

* iptables -A INPUT -p tcp --syn -m limit --limit 5/m --limit-burst 5 \
     -j ACCEPT
* iptables -A INPUT -p tcp --syn -j REJECT

Ok, I think these two rules will be a little bit controvercial. Let me
explain them first, though :)

These two rules limit the number of incoming SYN packets. First of all,
yes I do realize that these rules will be a Very Bad Thing(tm) for a
high-traffic server. However, on a very low-traffic server like mine,
these rules are great. The benefits are simple: anybody running a SYN or
TCP connect scan doesn't see which ports of mine are open (yes, I am now
invulnerable to *ANY* type of port scan).

Actually, that's not entirely true. If somebody knows exactly what they're
looking for, they'll be able to find open ports. What I mean is, somebody
scanning many different hosts on port 80 will see that I have port 80
open. However, somebody scanning all the ports <1024 will probably see
that port 80 is filtered.

The key word there is probably. Yes, I know, it *is* possible for the scan
to reveal that port 80 is open, but it's not likely to happen. I've
scanned myself many many times, and I've yet to see port 80 report as open
on a normal scan.

One downside to this rule is that it *does* let SYN packets through to any
port, but just in a limited amount. That's why there has to be a section
on closing evil ports just before these two rules.

These two rules do have one funny aspect to them, in my opinion: Due to
nmap's port randomizing ability, anybody scanning me will see that I have
a small number of closed ports, and the rest are filtered. If they were to
scan me again, they'd see that a completely different set of ports are
closed, and the rest filtered. In fact, they'd never get the same results
twice. Anybody scanning me would be led to believe that I have ports that
randomly flicker between being closed and filtered, which makes no sense,
and I find that funny :)

Another note about these rules: They open me up to a kind of DoS attack.
It's not serious, but it could be annoying. If somebody wanted to prevent
access to my website, they could just scan me continuously, using up the
whole limit for their scan. Since I would be dropping most of those SYNs
and all others, nobody could connect to me. I don't think that would be
worth the effort, though. I'd really like to set up a way to temporarily
ban everybody who floods me with SYN packets, as in a port scan... but I
don't know how to go about doing that.

And finally, you'll notice that this is the only case in which I use
REJECT instead of DROP. This is merely because this *does* have the
potential to block legitimate access to my machine, and somebody trying to
access my website while somebody else is portscanning me shouldn't have to
timeout. In all other cases, though, I prefer to DROP.

* iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Already covered, just allows packets belonging to known-good connections
are kept. This rule, combined with an empty output chain, allows me to
connect to anything I want, without having to worry about opening ports or
silly nonsense like that.

* iptables -A INPUT -p icmp --icmp-type 8 -m limit --limit 1/m -j ACCEPT
* iptables -A INPUT -p icmp --icmp-type 8 -j DROP
* iptables -A INPUT -p icmp -j ACCEPT

Some simple rules. The first two limit the amount of incoming pings I can
receive. That way, I can still be pinged for diagnostic reasons, but I am
protected from ping floods. The third simply accepts all other ICMP types,
which is necessary because my INPUT table drops packets that don't match
any rules by default.

* iptables -A INPUT -i lo -j ACCEPT

I'm not sure if anybody else has experienced this, but it seems I am
unable to log into my computer from my very own terminal unless traffic on
lo is accepted by default.

* iptables -A INPUT -i eth0 -j DROP

I just threw in this rule because it looked like the INPUT table was
actually just rejecting unmatched packets, instead of actually dropping
them.

As always, I am interested to hear what everybody thinks about these
rules, what's good about them, and what's bad. Don't hold back! :) 

-- 
Rob 'Feztaa' Park
fezziker@home.com
ICQ#: 49781692
:wq!

Relevant Pages

  • Re: Trouble accessing Outlook Web Access from behind firewall
    ... When starting the firewall I also set ... > rejected and dropped packets are logged, however I see nothing in my log ... > # Higher ports needed to accept incoming/outgoing calls ...
    (comp.security.firewalls)
  • Clever firewall rules
    ... This one drops all incoming packets that are not SYN packets, ... Either way, both rules are in my firewall, and it produces the results I'm ... similar rule that would log people who ping me, ... I have some basic rules that just open the ports that I ...
    (Focus-Linux)
  • Re: HELP ME
    ... > transparently either by using a stealth firewall or a totally transparent ... > firewall any attackers that try to connect to firewalled ports will get ... > [The firewall should be configured to drop offending packets silently, ... >> DO IF SOME TCP CONNECTION RECIVE TO MY BOX, THE KERNEL IGNORE IT AND ...
    (FreeBSD-Security)
  • Re: Help With firewall ports
    ... make design of your firewall. ... recommend "default deny" approach. ... into your box except to ports you explicitly allow. ... close all packets with FIN, URG and PSH flags on ...
    (Security-Basics)
  • Fw: Help With firewall ports
    ... Mostly the better way is to check which ports you really need. ... all other packets will be dropped. ... a "standart firewall configuration" usually doesn't make very much ... delivering to the intended recipient, be advised that you have received ...
    (Security-Basics)