From owner-freebsd-security Thu May 13 19:29:55 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 492BA14BE7 for ; Thu, 13 May 1999 19:29:51 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id UAA20729; Thu, 13 May 1999 20:29:40 -0600 (MDT) Message-Id: <4.2.0.37.19990513202450.0444fca0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.37 (Beta) Date: Thu, 13 May 1999 20:29:38 -0600 To: Jared Mauch , Thamer Al-Herbish From: Brett Glass Subject: Re: Forwarded from BUGTRAQ: SYN floods against FreeBSD Cc: security@FreeBSD.ORG In-Reply-To: <19990513222133.A23982@puck.nether.net> References: <4.2.0.37.19990513161529.00c1e3f0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org How often are the IP addresses spoofed during SYN floods? (I know it's perfectly practical to do so, since the flooder doesn't care about responses, but routers may preclude it.) It could be that discarding SYNS from addresses that send excessive numbers of them would let the legitimate folk keep working. As a backup, there could also be a random discard mechanism. --Brett At 10:21 PM 5/13/99 -0400, Jared Mauch wrote: > What would be ideal is to have a fair-queue such as this: > > real-queue = 16 > extended-queue = 32 > > once the real-queue fills with syns, fill the extended >queue, (these are folks that need syn-ack, btw), once the >extended queue fills, begin sequentially dropping elements from the >real-queue > > index++; > index = index%16; > drop(real_q[index]); > move(real_q[index], extend_q[index]); > (making extend_q[index] avail for the current syn to be put in) > > and sequentially add elements from index on > > if there is nothing in extend_q[index], you should not need >to drop real_q[index] > > (I picked 16 & 32 as arbitary numbers, those can obviously >be any size, preferably equal); > > Obviously, doing prefered drops (based on dst port on our side), >ie: we have 200 syns for port 80, but only 3 for port 22, deal with the >3 that are not causing a problem first, so we can get ssh in, but let the >web folks go a bit slower. > > Doing truly random drops are always better, but on the average server >will induce more load than you'll save (IMHO). > > - jared > >On Thu, May 13, 1999 at 06:27:13PM -0700, Thamer Al-Herbish wrote: > > On Thu, 13 May 1999, Brett Glass wrote: > > > > > 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 > > > > If I'm reading this correctly, it would not be very effective. I > > believe the OpenBSD fix was to randomly drop ports per a syn flooded > > port. So it would be "fair." Dropping all SYNs after a number of SYNs > > come in seems to be counter productive. > > > > Or does this actually work? > > > > -- > > Thamer Al-Herbish PGP public key: > > shadows@whitefang.com http://www.whitefang.com/pgpkey.txt > > [ The Secure UNIX Programming FAQ http://www.whitefang.com/sup/ ] > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > >-- >Jared Mauch | pgp key available via finger from jared@puck.nether.net >clue++; | http://puck.nether.net/~jared/ My statements are only mine. > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message