Re: New Denial of Service Attack ...
----- Begin Included Message ----- Subject: Re: FW: Latest attacks.... Date: Thu, 19 Sep 1996 08:39:02 +0100 From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> problem solved: this just in on your trusty end2end research group's list (sorry, i know some of you may already read it) this guy is usually technically excellent, so i think we can trust that this solution is valid, will propagate, and is deployable for server sites that worry (you only need kernel reconfig rights for unix to add this - NT and MAC servers may have a tad more of a problem:-). cheers jon ------- Forwarded Message Date: Wed, 18 Sep 1996 14:32:14 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Subject: SYN bombing defense As reported here, in article <vxjiv9hkmcb.fsf_-_@dominator.eecs.harvard.edu> in comp.protocols.tcp-ip, Robert Morris <rtm@dominator.eecs.harvard.edu> wrote:
Perhaps TCP's listen queue should use random early drop (RED), a technique used by routers to prevent any one source from monopolizing a queue. See http://www-nrg.ee.lbl.gov/floyd/abstracts.html#FJ93 or rfc1254. ...
I've just hacked IRIX 6.3 to do random-drop when sonewconn() in tcp_input.c fails. It works great! An IP22 receiving 1200 bogus SYN's per second directed to port 23 continues to answer requests for new telnet as if nothing is happening. I don't think that random <<Early>> drop is necessary or desirable. It is not as if we're trying to drop packets early to trigger slow start in the sources. As I figure it, as long as the length of the queue is longer than RTT of the real telnet client times the rate of bogus SYNs, the real clients have an excellent probability of getting through on their first attempt. For example, at 1200 bogus SYNs/sec and the IRIX 6.3 telnet listen queue of 383, there should be no trouble with peers with RTT up to about 300 milliseconds. I've tested with a telnet client 250 milliseconds away while simultaneously bombing the machine from nearby with ~1200 SYNs/sec, and see no telnet TCP retransmissions. Vernon Schryver, vjs@sgi.com ------- End of Forwarded Message ----- End Included Message -----
In message <199609250552.AA19213@zen.isi.edu>, postel@ISI.EDU writes: :----- Begin Included Message ----- : :Subject: Re: FW: Latest attacks.... :Date: Thu, 19 Sep 1996 08:39:02 +0100 :From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> : : :Date: Wed, 18 Sep 1996 14:32:14 -0600 :From: vjs@mica.denver.sgi.com (Vernon Schryver) :Subject: SYN bombing defense : :As reported here, in article <vxjiv9hkmcb.fsf_-_@dominator.eecs.harvard.edu> :in comp.protocols.tcp-ip, Robert Morris <rtm@dominator.eecs.harvard.edu> wrot :e: : :>Perhaps TCP's listen queue should use random early drop (RED), a :>technique used by routers to prevent any one source from monopolizing :>a queue. See http://www-nrg.ee.lbl.gov/floyd/abstracts.html#FJ93 or :>rfc1254. :> ... : :I've just hacked IRIX 6.3 to do random-drop when sonewconn() in :tcp_input.c fails. It works great! An IP22 receiving 1200 bogus :SYN's per second directed to port 23 continues to answer requests :for new telnet as if nothing is happening. : Alan Cox just released a patch vs Linux 2.0.21 that does this. It works quite well. As best I can tell from the patch and the mail that preceded it it attempts to maintain about 30% free in the receive queue. I've been running it for a couple of days and it does quite well defending against these attacks. I've stuck it on my web page. http://odin.nyser.net/~blizzard/linux/ --Chris : :Vernon Schryver, vjs@sgi.com : :------- End of Forwarded Message : :----- End Included Message ----- ------------------------------------------------------------------- Christopher Blizzard | "The truth knocks on the door and you say blizzard@nysernet.org | 'Go away. I'm looking for the truth,' and NYSERNet, Inc. | so it goes away." --Robert Pirsig -------------------------------------------------------------------
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--
In message <199609251608.MAA14668@cactus.silkroad.com>, Tim Bass writes: : :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: : : :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. : I agree with Tim. This patch hasn't caused any real problems with my setup however it may with other people. I know that it can result in a kernel oops under a load if you have compiled it with a funky compiler. If you do have problems with it, please mail me or Alan. If you do end up mailing me about it, I'm just going to forward it to Alan anyway. I'm not a kernel hacker by any stretch of the imagination. :) --Chris :Alan Cox :Linux Networking Project : :--patch-- ------------------------------------------------------------------- Christopher Blizzard | "The truth knocks on the door and you say blizzard@nysernet.org | 'Go away. I'm looking for the truth,' and NYSERNet, Inc. | so it goes away." --Robert Pirsig -------------------------------------------------------------------
participants (3)
-
Christopher Blizzard -
postel＠ISI.EDU -
Tim Bass