On Wed, 2005-08-03 at 11:15 +0200, Jörg Harmuth wrote: > 3.) The other box sends the 3rd packet of the handshake => ACK. This > packet gets dropped, because there is no rule in INPUR that > permits ESTABLISHED packets. At this point the connection is > basically dropped. > > You should be able to see this, when you tcpdump on the respective > interface, eth0 in this case. Solution: Add the following rule. > > iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT When I initially summarized my ruleset I was mostly talking about OUTPUT rules and so I left out the above rule. Keep in mind the packets I have seen getting dropped are coming FROM my server so the INPUT rules should not effect them. > Briefly, the following rules should get you starting: > > iptables -P INPUT DROP > ## I don't like - up to you. > iptables -P OUTPUT DROP > ## You want this :) > iptables -P FORWARD DROP > > iptables -A INPUT -i lo -j ACCEPT > iptables -A INPUT -m state --state ESTABLISHED,RELATED \ > -j ACCEPT > iptables -A INPUT -p tcp --dport 80 --syn -j ACCEPT > > iptables -A OUTPUT -o lo -j ACCEPT > iptables -A OUTPUT -m state --state ESTABLISHED,RELATED \ > -j ACCEPT This is basically exactly what I have which is why its still a mystery to me why some packets are being dropped coming FROM the web server to clients. Regarding "OUTPUT -P DROP"; I used to believe as you do that it was excessively complicated and not worth it but recently I've changed my mind. We have seen a dramatic increase in the number of exploits which target vulnerable PHP software (mostly phpBB). This exploits invariably launch a process which makes an outbound connection of some kind where they receive further code or instructions. Preventing the exploit is obviously the best thing but the second best thing is preventing the attacker from being able to utilize it. Blocking OUTPUT is one of the tools that helps. Frankly, I think the Linux kernel security model is seriously broken in this regard. Why the kernel allows any random process to take over ports with no security check what-so-ever is beyond my understanding but that is a topic for another list... See my posting on the linux kernel list here: http://www.ussg.iu.edu/hypermail/linux/kernel/0310.0/0224.html -- John Lange
