also sprach Pascal Hambourg <pascal.mail@plouf.fr.eu.org> [2006.07.04.1143 +0200]: > > -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT > > -A INPUT -p tcp -m tcp --dport 22 --syn -j ACCEPT > > I'd add a condition on state NEW in the second rule. What's the difference between state NEW and --syn? > This way of building rulesets, first blocking "bad" packets and > then accepting "good" packets assuming that "bad" packets were > already blocked, is wrong. What happens when, for any reason you > might imagine, the rule which is supposed to block first is > ineffective ? Your firewall has a hole. The right way is accepting > the "good" packets first and then dropping the rest. You are absolutely right. However, I wonder whether that hole you're mentioning doesn't already exist anyway, thanks to the "feature" of connection pickup. > Actually, both rulesets are wrong. What you want is a combination that > takes the best of each (state NEW *and* SYN flag) : > > -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT > -A INPUT -m conntrack --ctstate NEW -p tcp --syn --dport 22 -j ACCEPT Okay. So a good way to do this would be: -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -m conntrack --ctstate NEW -p tcp --syn -j open-tcp-ports -A INPUT -m conntrack --ctstate NEW -p udp -j open-udp-ports -A open-tcp-ports --dport 22 -j ACCEPT ... ? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <madduck@debian.org> : :' : proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system "i don't think so," said rene descartes. just then, he vanished.
Attachment:
signature.asc
Description: Digital signature (GPG/PGP)