Best defense for syn-floods...?

[Jeff Gordon <jeff.gordon@wellnow.com>]

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."