Date: Mon, 30 Nov 1998 23:08:50 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "John Saunders" <john.saunders@scitec.com.au> Cc: "Matthew Dillon" <dillon@apollo.backplane.com>, <freebsd-current@FreeBSD.ORG> Subject: Re: RE: D.O.S. attack protection enhancements commit (ICMP_BANDLIM) Message-ID: <199812010708.XAA03688@apollo.backplane.com> References: <005b01be1cf6$e6368da0$6cb611cb@saruman.scitec.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:>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.
As far as I can tell, it starves the mbuf pool and/or outgoing
packet queues. When we get D.O.S. attacks greater then 20,000
packets per second or so, and the machine tries to send 20,000
pps worth of ICMP error replies, other packet traffic gets
thrown away. Furthermore, if the reply is to a non-existant
IP on the local LAN, the ICMP replies get buffered while
the machine tries to ARP the destination. If not, the xmit
traffic goes to the switch which starts collisioning-out packets
when the router beyond the switch saturates. It isn't possible
for the xmit rate to exceed the recv rate in that situation,
so packets build up.
: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?
It's a real problem. When you are receiving a 20Kpps
attack you do not want to be transmitting 20Kpps in ICMP
replies to a possibly spoofed address.
I definitely do *not* want to play with the outgoing packet
queues or network memory allocation subsystem. Not only
is doing so a much more complicated task, but it is also
a matter of fixing the problem after the patient has died.
With the cpu already at saturation, trying to do fancy dequeueing
and prioritization of insanely huge packet queues will only make
things worse. Rate limiting the error responses (not even trying
to respond if the rate is too high) prevents cpu and network xmit
starvation from occuring in the first place while still allowing
legitimate traffic through.
: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.
:
:-- . +-------------------------------------------------------+
: ,--_|\ | John Saunders mailto:John.Saunders@scitec.com.au |
-Matt
Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet
Communications & God knows what else.
<dillon@backplane.com> (Please include original email in any response)
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?199812010708.XAA03688>