[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

iptables blocking rules



This is not a Debian-specific question but I've tried to post this thing
twice on comp.os.linux.security and my ISP is (temporarily, I hope) not
sending posts out, it seems, so I'd like to ask here.

My iptables rules were installed by firestarter.  My system is strictly
desktop and I have no outward-facing services.


The rules in question are these.  I have a string of rules like this:

#Block nonroutable IPs
$IPT -t filter -A INPUT -s 1.0.0.0/8 -i $IF -j $STOP
$IPT -t filter -A INPUT -s 2.0.0.0/8 -i $IF -j $STOP
$IPT -t filter -A INPUT -s 5.0.0.0/8 -i $IF -j $STOP

This includes IP's beginning with 72 of the first 128 #'s, plus 172,
197, 221, 223, and 240

Now, as an overview, and this is not all-inclusive, but as it applies to
this question, my firewall first sets my policy to drop for all three
major targets, sets these rules mentioned above (among other things), -
well, actually, it goes through a pretty long series of ports that it
sends to a defined rule "STOP", which is actually basically a DROP rule.

Then, there' this:

$IPT  -A INPUT -p tcp --dport 1024:65535 -j STATE

State is this:
# Create a new 'stateful module check' (STATE) convenience chain.
$IPT -I STATE -m state --state ESTABLISHED,RELATED -j ACCEPT
# Try without this line...
#$IPT -A STATE -m state --state NEW -i ! lo -j ACCEPT
$IPT -A STATE -j LOG --log-prefix "STATE: "
$IPT -A STATE -j DROP


BTW.. note the commented-out rule with lo.  I commented this out.. I
ran the firestarter wizard on the latest (testing) package and now it's
-j DROP ( which would be correct), but quite a serious bug here..


Finally, the last rule in the chain (remember, policy is already DROP)
# Deny everything not let through earlier
$IPT -A INPUT -j DROP

Now, finally, the question.  

I don't see any need whatsoever for the "rules in question" above.  And
I think they are causing me some problems.  pricewatch.com, for one,
whose address is, I believe 69.20.62.194, falls in this group, as well,
I think, as skylane.? which is the pgp keyserver I've been trying to
use.  My firewall is dropping their (pricewatch's, at least) SYN ACK's
and they won't connect - or wouldn't - I commented out the 69.0.0.0/8
rule to DROP and can now connect.

Now, the question.  Are these rules needless?  I probably could put the
ESTABLISHED,RELATED rule prior to these rules, but in my case, it looks
like nothing should get in unless I specifically name it, seeing as my
policy is DROP and if that's not enough, that last rule should get them,
anyway.

Actually, the whole ruleset from firestarter seems a bit complex for my
setup.  Wouldn't it be pretty sufficient for a single-system setup to
have something basically like this:

set policy for INPUT & FORWARD to DROP ( leave OUTPUT to ACCEPT?)
set INPUT ESTABLISHED,RELATED to ACCEPT
< add some logging facilities >
< allow some icmp requests, maybe? >

Wouldn't that pretty well take care of it?

Sorry for the long post, but I wanted to include everything.



Reply to: