On Monday 01 September 2003 14:20, Jos� Guzm�n wrote: > I�d also set the default policy to DROP and log whatever is dropped in the > end:
I specifically avoid doing that on the INPUT and OUTPUT chains for the single reason that a non-careful use of 'iptables -F' can break your access to the machine, generally requiring physical access to it to recover, not so good when you remotely manage all of your servers. I have no problem setting the policy to DROP for the FORWARD chain though. > #!/bin/sh > iptables -F > iptables -X > > for tabla in nat mangle ; do > iptables -F -t $tabla > iptables -X -t $tabla > done You miss the default 'filter' table above. 'for tabla in filter nat mangle ; do' > Also, if I had the chance and time, I�d be more picky about accepting > every new connection in the OUTPUT chain, call me paranoid but I prefer to > allow only what�s needed and nothing more; although it may be less flexible > and requires more maintenance. The only packets that should hit the OUTPUT chain are packets that originate on the machine itself. I'm usually not too concerned about it because if someone has gained access to the box in the first place then you're already in trouble. That said, yes, you could lock down the OUTPUT chain to, say, only allow established ssh traffic to a machine on your local network, or whatever. It would depend on what other services this machine is using/offering. Simply dropping '--state NEW' from the OUTPUT chain might be enough if you are worried about the machine being compromised and used for illegitimate outbound traffic. I tend to leave these sort of rules for the INPUT chain, and leave the OUTPUT chain fairly sparse to reduce complexity. I often find that increasing the complexity of firewalls tends to increase the chance of making errors (and thus allowing undesired traffic). t -- GPG: http://n12turbo.com/tarragon/public.key
