ratelimiting/concurrency limits both inadequate to stop TCP/IP DoS

[bert hubert <ahu () DS9A NL>]

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