search

rustybird / corridor

Tor traffic whitelisting gateway
ISC License
68 stars 6 forks source link

consider iptables policy drop #4

Closed adrelanos closed 9 years ago

adrelanos commented 9 years ago

I think it would be much more secure and leak-proof, if corridor was using at the beginning of the firewall rules.

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

And then white-list all allowed traffic from there.

rustybird commented 9 years ago

I agree that at least traffic leaving the machine must be default-deny, but that's basically already the situation:

In FORWARD, the jump to the CORRIDOR chain is inserted at the top, and that chain's last rule is a REJECT. (Which cannot even be used as a policy, only nasty old DROP.)

OUTPUT would be similar to FORWARD after #3 is implemented.

And INPUT firewalling seems out of scope for corridor, that's more for a machine's admin to fine tune if they like.

So with iptables -P being syntactic sugar (and too limited in its capabilites), I'm closing this issue. But please comment if there's an error in my reasoning.

adrelanos commented 9 years ago

In FORWARD, the jump to the CORRIDOR chain is inserted at the top, and that chain's last rule is a REJECT. (Which cannot even be used as a policy, only nasty old DROP.)

So with iptables -P being syntactic sugar (and too limited in its capabilites)

Keep the REJECT as last rule. No need to omit it. 99,99% packets should hit it. But...

Think of iptables -P as a safety net. I think if you can enable default policy drop (and your packages are still rejected because of REJECT as last rule) and your firewall is still working, then this is a good indication that you got your firewall rules under full control. If a default policy drop would make a difference, iptables rules need tweaking, I think.

rustybird commented 9 years ago

Keep the REJECT as last rule. No need to omit it. 99,99% packets should hit it. But...

But what? :) I just don't see that setting a DROP policy would ever make things more robust.

It would however complicate the integration into systems that already have other firewall rules: Currently a packet is either REJECTed, or it goes on to any later non-corridor rules, which can block it for other reasons, do some logging, etc. This works because corridor doesn't explicitly ACCEPT packets.

By the way, nftables didn't even bother to implement policies last time I checked.