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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
