Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 16 May 1999 10:16:17 -0700 (PDT)
From:      Richard Steenbergen <humble@lightning.net>
To:        security@freebsd.org
Subject:   Re: SYN floods against FreeBSD (fwd)
Message-ID:  <Pine.LNX.4.10.9905160955490.16134-100000@puffer.quadrunner.com>

next in thread | raw e-mail | index | archive | help
>    I think this patch is a bad idea.
>
>    I recall fixing a bug in the route table code that could cause a
>    double-free panic, but I do not remember if it was before or after
>    the 3.1 release.  In anycase, a double-free panic has nothing to do
>    with a high volume of SYN traffic apart from ticking some new bug.
>    The appropriate fix is *not* to try to limit the sync traffic but
>    instead to track down, locate, and fix the double-free.
>
>    I will go over the route table code to see if the softclock interrupt
>    is being properly masked while the route table is being manipulated.

The SYN rate limit patch was not intended to address the double free
problem or the backlogging of incoming incomplete handshakes. It was done
for one purpose and one purpose only, CPU. When you are being hit with
100kpps (which is not terribly unheard of against EFNet IRC servers), all
the queueing in the world isn't going to help (imagine trying to do MD5
hashing like this?). At a certain point, the goal shifts from "how do we
keep this service alive for new connections" to "how to we keep the
existing connections alive". Prior to this the only effective defense
against such high bandwidth attacks was Committed Access Rates on the
router, which has been cost & cpu prohibitive for a number of people. The
fact that not processing syns past a certain amount keeps the machine from
panicing is simply a nice side effect until the true cause of the problem
can be fixed.

What I would like to see done with all this rate limiting stuff
(icmp_bandlim also) is an interface similar to cisco's CAR, through ipfw,
with the ability to limit any protocol, with any set of matching rules,
via any interface, with the ability to specify actions for conform/exceed
behaviors, and the ability to burst higher for small amounts of time.
Probably a pipe dream. =)

-- 
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



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?Pine.LNX.4.10.9905160955490.16134-100000>