Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 13 May 1999 20:29:38 -0600
From:      Brett Glass <brett@lariat.org>
To:        Jared Mauch <jared@puck.Nether.net>, Thamer Al-Herbish <shadows@whitefang.com>
Cc:        security@FreeBSD.ORG
Subject:   Re: Forwarded from BUGTRAQ: SYN floods against FreeBSD
Message-ID:  <4.2.0.37.19990513202450.0444fca0@localhost>
In-Reply-To: <19990513222133.A23982@puck.nether.net>
References:  <Pine.BSF.4.05.9905131824250.267-100000@rage.whitefang.com> <4.2.0.37.19990513161529.00c1e3f0@localhost> <Pine.BSF.4.05.9905131824250.267-100000@rage.whitefang.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.2.0.37.19990513202450.0444fca0>