Date: Fri, 14 May 1999 09:32:10 +0000 From: Ugen Antsilevitch <ugen@xonix.com> To: hackers@freebsd.org Subject: [Fwd: SYN floods against FreeBSD] Message-ID: <373BED99.DA4FF4C1@xonix.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?373BED99.DA4FF4C1>