Date: Tue, 1 Dec 1998 17:50:36 +1100 From: "John Saunders" <john.saunders@scitec.com.au> To: "Matthew Dillon" <dillon@apollo.backplane.com>, <freebsd-current@FreeBSD.ORG> Subject: RE: D.O.S. attack protection enhancements commit (ICMP_BANDLIM) Message-ID: <005b01be1cf6$e6368da0$6cb611cb@saruman.scitec.com.au> In-Reply-To: <199812010607.WAA03051@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> The ICMP rate limiter limits the number of ICMP error responses the
> machine will return. There are currently several D.O.S. attacks that
> can cause the machine to crash or become totally unusable due to it
> trying to send an ICMP response to each one. This rate limiter has
> been installed on BEST machines for several months and has probably
saved
> us two or three dozen crashes from attacks.
Q1: Why does FreeBSD crash or become totally unstable under
what can only be described as high network load?
>From my thinking there are two steps:
1: Make FreeBSD run stable as a rock while being pounded with
DoS attacks. Although under such an attack it is not expected
to be able to perform much real work due to network saturation
and shortage of mbufs.
2: Include the ICMP rate limiting patch so that while under
a DoS attack real work can continue to happen. Although this
patch only removes work from the transmission path, DoS ICMP
messages will continue to be received and processed to the
point of being discarded. However most servers have plenty
of reception bandwidth available but not much transmission
bandwidth so this patch works in our favour.
I think that this patch may simply mask the real stability
problem in the IP stack. Although I do support the idea of
having this facility. Would setting the packet rate to 0
effectively disable the rate limiting?
> Since it only limits ICMP error responses, the default rate limit is
set
> relatively low at 100 packets per second. The only time I have ever
> hit the limit has been during an attack, even on our most heavily
loaded
> web boxes. I believe 100 to be an excellent default value.
This sounds OK, on my network I wouldn't see even 2 packets
per second.
> The UDP_BANDLIM section is presented for discussion, but I do not plan
> to request a commit for it in its current incarnation. This section
was
> designed to prevent hostile users from being able to perpetrate
attacks
> or take down a machine from a hacked account and it does in fact do a
> pretty good job at it, but there are obvious ways to circumvent the
> problem. I really need to change the hack and add a new per-user
resource
> limit 'maximum allowed network I/O bandwidth' that actually
rate-limits
> network traffic from a user rather then dropping excessive packet
traffic.
When you get all the way to a per-uid resource limit this would
be really good. I would like to see both TCP and UDP included.
However for the moment it seems to be a serious step to limit
UDP to some artificial rate. There are valid uses for high
volume UDP (VoIP, ICP, RealPlayer).
Cheers.
-- . +-------------------------------------------------------+
,--_|\ | John Saunders mailto:John.Saunders@scitec.com.au |
/ Oz \ | SCITEC LIMITED Phone +61294289563 Fax +61294289933 |
\_,--\_/ | "By the time you make ends meet, they move the ends." |
v +-------------------------------------------------------+
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?005b01be1cf6$e6368da0$6cb611cb>