From owner-freebsd-security Thu May 13 21:38:26 1999 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 6129C154AD for ; Thu, 13 May 1999 21:38:24 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA97604; Thu, 13 May 1999 21:38:16 -0700 (PDT) (envelope-from dillon) Date: Thu, 13 May 1999 21:38:16 -0700 (PDT) From: Matthew Dillon Message-Id: <199905140438.VAA97604@apollo.backplane.com> To: Brett Glass Cc: Jared Mauch , Thamer Al-Herbish , security@FreeBSD.ORG Subject: Re: Forwarded from BUGTRAQ: SYN floods against FreeBSD References: <4.2.0.37.19990513161529.00c1e3f0@localhost> <4.2.0.37.19990513202450.0444fca0@localhost> 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 IP addresses are usually spoofed during SYN Floods. They are typically either random or sequentially incrementing. The newer flooding programs randomize the source IP address. It is impossible to tell the difference between a SYN spoof and a real SYN. Putting code in to handle excessive SYNs from a particular IP address is a waste of time, IMHO. The only way to fix a SYN flood is for routers to automatically test the source IP against the source interface on a global scale. The only way to mitigate the SYN flooding problem on the host side is to greatly increase the size of the listen queue, but even this does not work too well. -Matt Matthew Dillon :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