GF> Date: Tue, 23 Jul 2002 15:04:40 +0100 GF> From: Graeme Fowler
GF> To answer everyone else's points too; it _is_ possible to GF> effectively squash TCP SYN flood attacks without needing to GF> enable something as resource-intensive as TCP Intercept at GF> your network boundary. A similar effect can be gained by GF> rate-limiting SYN packets to a predetermined percentage of GF> your line speed, and permitting them to burst to a slightly GF> higher rate. Except this blocks valid SYN requests, too. If you normally get 50 kbps of SYN and set a limit of 250 kbps, one easily can drown you with 5000 kbps. The box doesn't crash, but you still have a DoS due to dropped packets. Yes, I've used rate-limiting when no better alternative was available. I'd consider it a last resort, along with per-IP blocking. (Note that, when the TCP handshake is incomplete or gets RST, there's a good chance you're blocking someone you shouldn't.) GF> It still means it has to be done at your network edge, GF> though, so if have no control over your router you'll have to GF> ask whoever does. Or run a TCP stack that isn't as vulnerable to this sort of thing. *shrug* People demand Linux, they get Linux.[1] Without suggesting that Cobalt should consider a BSD-based product *cough*, you might look at: http://www.cymru.com/~robt/Docs/Articles/ip-stack-tuning.html Try increasing the queue depth. If you're CPU-bound, this will make things _worse_, however. How to harden a stack against SYN floods has been discussed on many mailing lists. It seems that some sort of drop algorithm, perhaps coupled with a known-{good | bad} cache, is the best way to deal with SYN floods. [1] Disclaimer: I'm a BSD bigot, and don't know how Linux 2.4 handles this. No, the BSD family isn't perfect. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to be blocked. _______________________________________________ cobalt-security mailing list [EMAIL PROTECTED] http://list.cobalt.com/mailman/listinfo/cobalt-security
