This is a multi-part message in MIME format.
--------------C9093E3CB3F7EABCE07FECA1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Well..this is just something i picked off BugTraq..worths looking into?
If it's old news - pardon me...
--Ugen
--------------C9093E3CB3F7EABCE07FECA1
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Return-Path: <owner-bugtraq@netspace.org>
Received: from umka.undp.org ([192.168.69.1]) by inet01.hq.undp.org
(Netscape Messaging Server 3.6) with ESMTP id AAZ5B3B;
Thu, 13 May 1999 18:15:24 -0400
Received: from nygate.undp.org ([192.124.42.3]) by umka.undp.org
(Netscape Messaging Server 3.6) with ESMTP id AAA4C8F;
Thu, 13 May 1999 18:15:21 -0400
Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143])
by nygate.undp.org (8.9.3/8.9.3/1.3) with ESMTP id SAA20304;
Thu, 13 May 1999 18:12:46 -0400 (EDT)
Received: from netspace.org ([128.148.157.6]:3424 "EHLO netspace.org" ident: "TIMEDOUT2") by brimstone.netspace.org with ESMTP id <47249-24199>; Thu, 13 May 1999 17:36:39 -0400
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8d) with
spool id 865650 for BUGTRAQ@NETSPACE.ORG; Thu, 13 May 1999 21:34:58
+0000
Approved-By: aleph1@UNDERGROUND.ORG
Received: from puffer.quadrunner.com (humble@puffer.quadrunner.com
[205.166.195.4]) by netspace.org (8.8.7/8.8.7) with ESMTP id OAA19748
for <bugtraq@netspace.org>; Thu, 13 May 1999 14:33:55 -0400
Received: from localhost (humble@localhost) by puffer.quadrunner.com
(8.9.2/QUAD-2.1) with ESMTP id LAA25414 for <bugtraq@netspace.org>;
Thu, 13 May 1999 11:35:43 -0700 (PDT)
X-Authentication-Warning: puffer.quadrunner.com: humble owned process doing -bs
X-Sender: humble@puffer.quadrunner.com
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-1496513341-362697548-926620543=:25123"
Message-ID: <Pine.LNX.4.10.9905131002330.24435-200000@puffer.quadrunner.com>
Date: Thu, 13 May 1999 11:35:43 -0700
Reply-To: Richard Steenbergen <humble@LIGHTNING.NET>
Sender: Bugtraq List <BUGTRAQ@netspace.org>
From: Richard Steenbergen <humble@LIGHTNING.NET>
Subject: SYN floods against FreeBSD
To: BUGTRAQ@netspace.org
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
---1496513341-362697548-926620543=:25123
Content-Type: TEXT/PLAIN; charset=US-ASCII
Here's a quickie for the people who have been plagued with high bandwidth
syn flood attacks, a kernel patch for FreeBSD 3.1-STABLE which rate limits
SYN processing. Its messy but functional and I don't have time to make it
better (thats the fbsd developers job, not mine :P), cd /usr/src/sys,
patch < synlim, add "options SYN_RATELIM" (I highly recommend ICMP_BANDLIM
as well) to your kernel, recompile, and sysctl net.inet.tcp.synlim will be
available (default to 100). This is the maximium number of SYNs per second
that will be processed, the rest will be silently discarded. On my test
system (P2 450 running 3.1-stable being hit w/15,000 packets per sec),
this has successfully brought CPU usage from 100% to ~20% (against an open
port which is replying with unacknowledged ACKs).
Which brings us to the more sticky topic of kernel panics when under SYN
flood (which I believe to be the cause of some earlier posts from certain
people at Exodus Communications *cough*). Lord knows I found enough of
them when doing this testing, but the one that seems to be the biggie for
crashing when under syn flood is as follows (heh just turned off the
synlim and panic'd within 8 seconds while writing this):
panic: free: multiple frees
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:285
#1 0xc0138c09 in panic (fmt=0xc02192b7 "free: multiple frees")
at ../../kern/kern_shutdown.c:446
#2 0xc0135aaf in free (addr=0xc0cdd600, type=0xc0239330)
at ../../kern/kern_malloc.c:333
#3 0xc01768f4 in ifafree (ifa=0xc0cdd600) at ../../net/route.c:262
#4 0xc0176876 in rtfree (rt=0xc34ce700) at ../../net/route.c:236
#5 0xc0176c84 in rtrequest (req=2, dst=0xc34cbac0, gateway=0xc34cbad0,
netmask=0x0, flags=393223, ret_nrt=0x0) at ../../net/route.c:536
#6 0xc017b34d in in_rtqkill (rn=0xc34ce700, rock=0xc0231610)
at ../../netinet/in_rmx.c:242
#7 0xc0176064 in rn_walktree (h=0xc0cd9e00, f=0xc017b2fc <in_rtqkill>,
w=0xc0231610) at ../../net/radix.c:956
#8 0xc017b3ec in in_rtqtimo (rock=0xc0cd9e00) at ../../netinet/in_rmx.c:283
#9 0xc013d19b in softclock () at ../../kern/kern_timeout.c:124
Which after a quick examination seems to be a perioditic routing table
cleanup. It seems that in_rtqtimo is scheduled to run every
net.inet.ip.rtexpire seconds (which is dynamicly adjusted and can never go
lower then net.inet.ip.rtminexpire). When the system is under heavy load
from processing lots of small packets (they don't even have to be SYNs,
anything which can get routed will do the trick, though the packet kiddies
would get very little gain from just sending an ip header since its going
to be padded to 64 bytes for the eth frame anyhow), this route cleanup
code will go wacking at routes it shouldn't and free some memory twice. In
the course of testing I've gotten my rtq_reallyold to -3 and seen lots of
"tvotohz: negative time difference -2 sec 0 usec". Perhaps someone with
free time or more specific knowledge of this area would like to FIX IT? =)
Perhaps when I get more free time I'll test some other *nix's. I would
really recommend putting all this rate limiting code at an ipfw level.
If you would like to contact me regarding this please use
humble@quadrunner.com (at least if you want a quick reply), thanks.
-- Richard Steenbergen <humble@lightning.net> humble@EFNet PGP ID: 0x741D0374 PGP Key Fingerprint: C6EF EFA0 83B2 071F 1AB6 B879 1F70 4303 741D 0374 http://users.quadrunner.com/humble---1496513341-362697548-926620543=:25123 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=synlim Content-Transfer-Encoding: BASE64 Content-ID: <Pine.LNX.4.10.9905131135430.25123@puffer.quadrunner.com> Content-Description: SYN rate limit patch for fbsd 3.1 Content-Disposition: attachment; filename=synlim
KioqIGNvbmYvb3B0aW9ucy5vbGQJU2F0IE1heSAxNSAyMzowODowMyAxOTk5 DQotLS0gY29uZi9vcHRpb25zCVNhdCBNYXkgMTUgMjM6NDA6MjEgMTk5OQ0K KioqKioqKioqKioqKioqDQoqKiogNjgsNzMgKioqKg0KLS0tIDY4LDc0IC0t LS0NCiAgU1lTVlNITQkJb3B0X3N5c3ZpcGMuaA0KICBVQ09OU09MRQ0KICBJ Q01QX0JBTkRMSU0NCisgU1lOX1JBVEVMSU0NCiAgDQogICMgUE9TSVgga2Vy bmVsIG9wdGlvbnMNCiAgUDEwMDNfMUIJb3B0X3Bvc2l4LmgNCioqKiBuZXRp bmV0L3RjcF92YXIuaC5vbGQJU2F0IE1heSAxNSAyMzoyNTozOSAxOTk5DQot LS0gbmV0aW5ldC90Y3BfdmFyLmgJU2F0IE1heSAxNSAyMzo0NTowNSAxOTk5 DQoqKioqKioqKioqKioqKioNCioqKiA0MCw0NSAqKioqDQotLS0gNDAsNDkg LS0tLQ0KICAgKiBLZXJuZWwgdmFyaWFibGVzIGZvciB0Y3AuDQogICAqLw0K ICANCisgI2lmZGVmIEtFUk5FTA0KKyAjaW5jbHVkZSAib3B0X3N5bl9yYXRl bGltLmgiDQorICNlbmRpZg0KKyANCiAgLyoNCiAgICogVGNwIGNvbnRyb2wg YmxvY2ssIG9uZSBwZXIgdGNwOyBmaWVsZHM6DQogICAqIE9yZ2FuaXplZCBm b3IgMTYgYnl0ZSBjYWNoZWxpbmUgZWZmaWNpZW5jeS4NCioqKioqKioqKioq KioqKg0KKioqIDMwNSwzMTEgKioqKg0KICAjZGVmaW5lCVRDUENUTF9SRUNW U1BBQ0UJOQkvKiByZWNlaXZlIGJ1ZmZlciBzcGFjZSAqLw0KICAjZGVmaW5l CVRDUENUTF9LRUVQSU5JVAkJMTAJLyogcmVjZWl2ZSBidWZmZXIgc3BhY2Ug Ki8NCiAgI2RlZmluZQlUQ1BDVExfUENCTElTVAkJMTEJLyogbGlzdCBvZiBh bGwgb3V0c3RhbmRpbmcgUENCcyAqLw0KISAjZGVmaW5lIFRDUENUTF9NQVhJ RAkJMTINCiAgDQogICNkZWZpbmUgVENQQ1RMX05BTUVTIHsgXA0KICAJeyAw LCAwIH0sIFwNCi0tLSAzMDksMzE2IC0tLS0NCiAgI2RlZmluZQlUQ1BDVExf UkVDVlNQQUNFCTkJLyogcmVjZWl2ZSBidWZmZXIgc3BhY2UgKi8NCiAgI2Rl ZmluZQlUQ1BDVExfS0VFUElOSVQJCTEwCS8qIHJlY2VpdmUgYnVmZmVyIHNw YWNlICovDQogICNkZWZpbmUJVENQQ1RMX1BDQkxJU1QJCTExCS8qIGxpc3Qg b2YgYWxsIG91dHN0YW5kaW5nIFBDQnMgKi8NCiEgI2RlZmluZSBUQ1BDVExf U1lOTElNCQkxMgkvKiBSYXRlIGxpbWl0aW5nIG9mIFNZTnMgKi8NCiEgI2Rl ZmluZSBUQ1BDVExfTUFYSUQJCTEzDQogIA0KICAjZGVmaW5lIFRDUENUTF9O QU1FUyB7IFwNCiAgCXsgMCwgMCB9LCBcDQoqKioqKioqKioqKioqKioNCioq KiAzMjAsMzI1ICoqKioNCi0tLSAzMjUsMzMxIC0tLS0NCiAgCXsgInJlY3Zz cGFjZSIsIENUTFRZUEVfSU5UIH0sIFwNCiAgCXsgImtlZXBpbml0IiwgQ1RM VFlQRV9JTlQgfSwgXA0KICAJeyAicGNibGlzdCIsIENUTFRZUEVfU1RSVUNU IH0sIFwNCisgCXsgInN5bmxpbSIsIENUTFRZUEVfSU5UIH0sIFwNCiAgfQ0K ICANCiAgI2lmZGVmIEtFUk5FTA0KKioqIG5ldGluZXQvdGNwX2lucHV0LmMu b2xkCVNhdCBNYXkgMTUgMjM6MDg6MTAgMTk5OQ0KLS0tIG5ldGluZXQvdGNw X2lucHV0LmMJCVN1biBNYXkgMTYgMDE6MzM6NTEgMTk5OQ0KKioqKioqKioq KioqKioqDQoqKiogNzIsNzcgKioqKg0KLS0tIDcyLDg1IC0tLS0NCiAgc3Rh dGljIHN0cnVjdAl0Y3BpcGhkciB0Y3Bfc2F2ZXRpOw0KICAjZW5kaWYNCiAg DQorICNpZmRlZiBTWU5fUkFURUxJTSANCisgc3RhdGljIGludCAgICAgIHN5 bmxpbSA9IDEwMDsNCisgU1lTQ1RMX0lOVChfbmV0X2luZXRfdGNwLCBUQ1BD VExfU1lOTElNLCBzeW5saW0sIENUTEZMQUdfUlcsICZzeW5saW0sIDAsICIi KTsNCisgI2Vsc2UNCisgc3RhdGljIGludCAgICAgIHN5bmxpbSA9IC0xOw0K KyBTWVNDVExfSU5UKF9uZXRfaW5ldF90Y3AsIFRDUENUTF9TWU5MSU0sIHN5 bmxpbSwgQ1RMRkxBR19SRCwgJnN5bmxpbSwgMCwgIiIpOw0KKyAjZW5kaWYN CisgDQogIHN0YXRpYyBpbnQJdGNwcmV4bXR0aHJlc2ggPSAzOw0KICB0Y3Bf c2VxCXRjcF9pc3M7DQogIHRjcF9jYwl0Y3BfY2NnZW47DQoqKioqKioqKioq KioqKioNCioqKiA5OCwxMDQgKioqKg0KICAJICAgIHN0cnVjdCB0Y3BpcGhk ciAqLCBzdHJ1Y3QgbWJ1ZiAqKSk7DQogIHN0YXRpYyBpbnQJIHRjcF9yZWFz cyBfX1AoKHN0cnVjdCB0Y3BjYiAqLCBzdHJ1Y3QgdGNwaXBoZHIgKiwgc3Ry dWN0IG1idWYgKikpOw0KICBzdGF0aWMgdm9pZAkgdGNwX3htaXRfdGltZXIg X19QKChzdHJ1Y3QgdGNwY2IgKiwgaW50KSk7DQohIA0KICANCiAgLyoNCiAg ICogSW5zZXJ0IHNlZ21lbnQgdGkgaW50byByZWFzc2VtYmx5IHF1ZXVlIG9m IHRjcCB3aXRoDQotLS0gMTA2LDExMiAtLS0tDQogIAkgICAgc3RydWN0IHRj cGlwaGRyICosIHN0cnVjdCBtYnVmICopKTsNCiAgc3RhdGljIGludAkgdGNw X3JlYXNzIF9fUCgoc3RydWN0IHRjcGNiICosIHN0cnVjdCB0Y3BpcGhkciAq LCBzdHJ1Y3QgbWJ1ZiAqKSk7DQogIHN0YXRpYyB2b2lkCSB0Y3BfeG1pdF90 aW1lciBfX1AoKHN0cnVjdCB0Y3BjYiAqLCBpbnQpKTsNCiEgc3RhdGljIGlu dAkgc3luX3JhdGVsaW0odm9pZCk7DQogIA0KICAvKg0KICAgKiBJbnNlcnQg c2VnbWVudCB0aSBpbnRvIHJlYXNzZW1ibHkgcXVldWUgb2YgdGNwIHdpdGgN CioqKioqKioqKioqKioqKg0KKioqIDEzMCwxMzUgKioqKg0KLS0tIDEzOCwx ODMgLS0tLQ0KICAJfSBcDQogIH0NCiAgDQorICNpZmRlZiBTWU5fUkFURUxJ TQ0KKyBpbnQgc3luX3JhdGVsaW0odm9pZCkNCisgew0KKyAJc3RhdGljIGlu dCBsdGlja3M7DQorIAlzdGF0aWMgaW50IGxwYWNrZXRzOw0KKyAJaW50IGR0 aWNrczsNCisgDQorIAkvKg0KKyAJICogUmV0dXJuIG9rIHN0YXR1cyBpZiBm ZWF0dXJlIGRpc2FibGVkIG9yIGFyZ3VtZW50IG91dCBvZg0KKyAJICogcmFu YWdlLg0KKyAJICovDQorIA0KKyAJaWYgKHN5bmxpbSA8PSAwKQ0KKyAJCXJl dHVybigwKTsNCisgDQorIAlkdGlja3MgPSB0aWNrcyAtIGx0aWNrczsNCisg DQorIAkvKg0KKyAJICogcmVzZXQgc3RhdHMgd2hlbiBjdW11bGF0aXZlIGR0 IGV4Y2VlZHMgb25lIHNlY29uZC4NCisgCSAqLw0KKyANCisgCWlmICgodW5z aWduZWQgaW50KWR0aWNrcyA+IGh6KSB7DQorIAkJaWYgKGxwYWNrZXRzID4g c3lubGltKQ0KKyAJCQlwcmludGYoInN5biByYXRlIGxpbWl0IHJlYWNoZWQg JWQvJWQgcHBzXG4iLCBscGFja2V0cywgc3lubGltKTsNCisgCQlsdGlja3Mg PSB0aWNrczsNCisgCQlscGFja2V0cyA9IDA7DQorIAl9DQorIA0KKyAJLyoN CisgCSAqIGJ1bXAgcGFja2V0IGNvdW50DQorIAkgKi8NCisgDQorIAlpZiAo KytscGFja2V0cyA+IHN5bmxpbSkgew0KKyAJCXJldHVybigtMSk7DQorIAl9 DQorIA0KKyAJcmV0dXJuKDApOw0KKyB9DQorICNlbmRpZg0KKyANCiAgc3Rh dGljIGludA0KICB0Y3BfcmVhc3ModHAsIHRpLCBtKQ0KICAJcmVnaXN0ZXIg c3RydWN0IHRjcGNiICp0cDsNCioqKioqKioqKioqKioqKg0KKioqIDM3OSwz ODQgKioqKg0KLS0tIDQyNyw0MzggLS0tLQ0KICAJCWlwX2Z3X2Z3ZF9hZGRy ID0gTlVMTDsNCiAgCX0gZWxzZQ0KICAjZW5kaWYJLyogSVBGSVJFV0FMTF9G T1JXQVJEICovDQorIA0KKyAjaWZkZWYgU1lOX1JBVEVMSU0NCisgCWlmICgo dGlmbGFncyAmIFRIX1NZTikgJiYgISh0aWZsYWdzICYgVEhfQUNLKSkNCisg CQlpZiAoc3luX3JhdGVsaW0oKSA8IDApDQorIAkJCWdvdG8gZHJvcDsNCisg I2VuZGlmDQogIA0KICAJaW5wID0gaW5fcGNibG9va3VwX2hhc2goJnRjYmlu Zm8sIHRpLT50aV9zcmMsIHRpLT50aV9zcG9ydCwNCiAgCSAgICB0aS0+dGlf ZHN0LCB0aS0+dGlfZHBvcnQsIDEpOw0K ---1496513341-362697548-926620543=:25123--
--------------C9093E3CB3F7EABCE07FECA1--
To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message -- end of forwarded message --
-- С тем, что не помешает никогда, Kittle