Date: Thu, 09 Sep 1999 14:41:33 +0100 From: Karl Pielorz <kpielorz@tdx.co.uk> To: Darren Reed <avalon@coombs.anu.edu.au> Cc: Stas Kisel <stas@sonet.crimea.ua>, freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: mbuf shortage situations Message-ID: <37D7B90D.B252B4E6@tdx.co.uk> References: <199909091315.XAA05192@cheops.anu.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Darren Reed wrote: > > It is evil connection. Good applications do read data from their sockets, > > and evil ones do not. And ever if it is good, but silly or busy > > application, good clients do not send so much data that application > > can not process it. Am I wrong, there are any examples? > > So what if someone manages to crash a program due to a DOS attack ? > An easy one that comes to mind is syslogd. It's often stuck in disk-wait > and can easily be targetted with a large number of packets. Isn't syslog UDP? - i.e. no ACK? - you could argue (to a point) that this might even be by design? :) (with regard to if syslog is in diskwait, and over burdened with traffic, data gets dropped). This, could be construed as a DoS (in fact it probably is)... If you look to real life, not many systems are DoS proof - Most real life scenarios work by detection and subsequent action, e.g. if you start calling the firemen out all over town (DoS'ing the fire service) - you will hopefully be detected, and removed :) You could try to prevent this, by having say limits on buffers per process, or through something like Inetd (i.e. throttling). You could even take Inetd a stage further and say "if excessive from same IP, stop responding to that IP for 'x' time), but even then people who are determined will only (and easily with the current Internet) start launching multi-homed attack's DoS's etc. How long before servers only accept connections from hosts presenting a valid 'certificate'? - How long until the certificates themselves are forged? At the end of the day, you have 1 box with limited resources - trying to handle the situation. Even if it's well behaved (doesn't crash) - something has to give, i.e. the service may shutdown for a while. The sad fact is, this is exactly what a DoS is trying to achieve, and will achieve until some intervening action is taken, you can only slow & detect it - you can't readily stop it - there is no 'easy' fix for this... [You could argue, SysAdmin's are a fix? No?] Just my $0.02+1's worth -Karl 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?37D7B90D.B252B4E6>