Bugtraq mailing list archives
ratelimiting/concurrency limits both inadequate to stop TCP/IP DoS
From: bert hubert <ahu () DS9A NL>
Date: Wed, 28 Feb 2001 01:03:51 +0100
On Tue, Feb 27, 2001 at 02:02:16AM +0100, Peter van Dijk wrote:
inetd replacements like xinetd and tcpserver (http://cr.yp.to/ucspi-tcp.html) have real ratelimiting which preventes *real* problems, as opposed to inetd ratelimiting which actually only *creates* problems.
This is not quite correct, or complete. Quickly repeating what is considered a DoS: any action that can disallow large numbers of others access to your service, using a limited amount of resources. Anybody with a 10gbit/s connection can deny service to a site that has 2mbit/s connectivity, yet this is not considered special in any way. The 'limited resources' part is when we consider it a DoS trick worth doing. Back to inetd and TCP/IP servers in general: Concurrency limiting -------------------- This actually helps you DoS a site - just open N sockets to the port, and the site goes down until your connections time out. Depending on the service offered, this means that as little as 1 SYN/SYN|ACK/ACK triplet per second can effectively block a service. Ratelimiting ------------ This means that at any single moment, no more than N connections per second are accepted. Doing so raises the bar a bit - to effectively deny service, you need to generate perhaps 10 SYN/SYN|ACK/ACK triplets per second. The number of people who are able to generate 1 per second, but not 10, must be pretty limited. Effectively, the bar is still low enough to trip over. Ratelimiting should also be combined with concurrency limiting - at 10 connections per second, I can still flood your process table pretty quickly. Solution using /16 or /24 grouped limits ---------------------------------------- TCP/IP is rather smart DoS-wise, considering its age. The exchange of sequence numbers means that it is very hard to spoof a TCP/IP connection from an arbitrary IP address. Effectively, if a host runs a modern operating system with proper randomly generated sequence numbers, TCP/IP connection spoofing can be ruled out. This means that the perpetrator of a DoS attack over TCP/IP is *unable* to simulate having a large number of IP addresses [1]. So all that is needed to limit the scope of a DoS is to actually only concurrency limit *blocks of IP addresses*. This means that somebody is only able to deny service to computers in his own subnet/IP block - there are far easier ways to accomplish a local DoS :-) I'm not certain weather its best to group ip addresses by /16 or /24 - /24 might consume too much memory, /16 might be too broad. Perhaps this should be a tunable parameter. Anyhow, I urge authors of TCP/IP servers to implement /N grouped concurrency limits - I know that my software will do so soon. Regards, bert hubert [1] he can simulate all IP address for which the return SYN|ACK passes through a network he can sniff -- http://www.PowerDNS.com Versatile DNS Services Trilab The Technology People 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
Current thread:
- inetd DoS exploit Serega[linux] (Feb 26)
- Re: inetd DoS exploit Jose Nazario (Feb 27)
- Re: inetd DoS exploit David Malone (Feb 27)
- Re: inetd DoS exploit Charles M. Hannum (Feb 27)
- Re: inetd DoS exploit Peter Werner (Feb 27)
- Re: inetd DoS exploit Peter van Dijk (Feb 27)
- ratelimiting/concurrency limits both inadequate to stop TCP/IP DoS bert hubert (Feb 28)
- Re: inetd DoS exploit Jose Nazario (Feb 27)