Now that I've got ipt_recent installed and running, I'd be grateful for comments or rule samples that could work best to ameliorate syn-floods. (The site I'm working on has been the target of moderate-to-large-sized syn-floods for a few months now, ongoing.) I've been using this approach: -N syn-flood -A syn-flood -m limit --limit 6/s --limit-burst 10 -j RETURN -A syn-flood -j LOG --log-prefix "SYN-FLOOD: " -A syn-flood -j DROP -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -i eth0 -p tcp --syn -j syn-flood ...and, on the high-traffic site involved, have had occasions when the machine became unreachable, the server load too high. Someone suggested ipt_recent could handle this matter more accurately. I found a rule on the web that someone was using, and tried that a few minutes ago, with this approach: -N syn-flood -A syn-flood -j LOG --log-prefix "SYN-FLOOD: " -A syn-flood -j DROP -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -i eth0 -p tcp --syn -m recent --hitcount 10 --update \ --seconds 60 -j syn-flood ...but very soon _no one_ could get a server connection, with that. My 'mental model' of how ipt_recent is working must not be correct -- at least, I don't understand why the '--limit' ruleset seems to allow normal traffic under most conditions but the '-m recent' rule kept normal users from getting in, just a few minutes ago. If anyone knows what I'm missing in my understanding of this, or has a ruleset that works well to ameliorate syn-flooding, please let me know. Thanks kindly, -- -- Jeff -- <http://www.wellnow.com> "There's nothing left in the world to prove. All that's worth doing is to love one another, using whatever means are available to serve."
