Problems with OUTPUT rules ESTABLISHED,RELATED
john.lange at open-it.ca
Wed Aug 3 18:34:28 CEST 2005
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
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
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:
More information about the netfilter