I highly recommend reading Alan Cox's e-mail post on this patch archived at Chris's site below. There are some caveats and other mods to daemons such as inetd, etc: ------------------ Return-Path: owner-linux-net-outgoing@vger.rutgers.edu Return-Path: owner-linux-net-outgoing@vger.rutgers.edu Received: from mailbox.syr.edu (root@mailbox.syr.edu [128.230.1.5]) by odin.nyser.net (8.8.Beta.1/8.7.5) with ESMTP id XAA10780 for <blizzard@odin.nyser.net>; Sat, 21 Sep 1996 23:15:07 -0400 Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by mailbox.syr.edu (8.7.5/8.7.3) with ESMTP id XAA14905 for <cdblizza@mailbox.syr.edu>; Sat, 21 Sep 1996 23:15:11 -0400 (EDT) Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <75616-11295>; Sun, 22 Sep 1996 05:38:01 +0300 Received: by vger.rutgers.edu id <112520-17924>; Sat, 21 Sep 1996 22:27:58 -0400 Message-Id: <m0v4b1J-0005aMC@lightning.swansea.linux.org.uk> Date: Sat, 21 Sep 96 23:59 BST From: alan@lxorguk.ukuu.org.uk (Alan Cox) To: linux-net@vger.rutgers.edu Subject: Linux TCP Changes for protection against the SYN attack Sender: owner-linux-net@vger.rutgers.edu Precedence: bulk [Bcc the network development list and a few relevant people] Various people have asked about this so here is a sort of status report: I've tried several experimental ideas put forward on the end2end and some other lists, and a couple of my own. As I write this my machine is sustaining a continuous 64Kbit/second of spoof SYN frames and web access is slightly impaired (a few 3 second pauses) but not bad. Sustaining the equivalent of a modem based attack the machine is not noticably harmed at all. There are however some side effects. To get this level of protection at 200 spoofed frames/second needs typically a backlog of up to 512 sockets. That means in real terms a server thats capable of surviving this kind of attack is probably going to be using up to 150Kbytes/service protected of extra non swappable memory. It also means modifying inetd and sendmail to request large queues. In practical terms I think turning this on, patching the binaries needed and adding 4Mb of RAM to the machine will give a box that has the same performance under attack as without protection before. A big thanks goes to Vern Schryver who implemented this algorithm on the SGI machines and posted it to end2end. It seems to work rather well. Oh the other gotcha - when you apply the patch (if you do ;)) you will need to rebuild your modules (and yes if you have the infamous binary only AFS I've probably broken it again...) Also included is a fix to the problem of talking to netblazers and other KA9Q stacks running with syndata enabled. Can people whom can do a bit of testing to give these patches a good hammering, and folks being attacked may as well try them too... If they seem OK I'll submit them on for the next 2.0.x kernel proper. Alan Cox Linux Networking Project --patch--