Rabbit Hutch

DoS con Slowloris.pl

Buenas hackers en esta PoC, os muestro esta genial herramienta que permite realizar un ataque de denegación de servicio a un servidor Linux. Esto genera que ese servicio sea inaccesible a los usuarios legítimos. En este caso mantiene conexiones abiertas el máximo tiempo posible a base del envío de peticiones http a una tasa de datos muy baja.. Para esta prueba de concepto se realizará en un entorno virtualizado controlado, usando una máquina atacante Kali Linux y un servidor Ubuntu como víctima.

Slowloris.pl esta escrita en perl y disponible en Github

Requirimientos y los pasos a seguir

How use Slowloris

# sudo apt-get update
# sudo apt-get install perl
# sudo apt-get install libwww-mechanize-shell-perl
# sudo apt-get install perl-mechanize

1)Download slowloris.pl
2)Open Terminal
2)# cd /thePathToYourSlowloris.plFile
3)# ./slowloris.pl
4)# perl slowloris.pl -dns (Victim URL or IP) -options


Laera Loris"

Documento de ayuda


Version 0.7 Beta


RSnake <h@ckers.org> with threading from John Kinsella

Slowloris both helps identify the timeout windows of a HTTP server or
Proxy server, can bypass httpready protection and ultimately performs a
fairly low bandwidth denial of service. It has the added benefit of
allowing the server to come back at any time (once the program is killed),
and not spamming the logs excessively. It also keeps the load nice and low
on the target server, so other vital processes don't die unexpectedly, or
cause alarm to anyone who is logged into the server for other reasons.

Apache 1.x, Apache 2.x, dhttpd, GoAhead WebServer, others...?

IIS6.0, IIS7.0, lighttpd, nginx, Cherokee, Squid, others...?

Slowloris is designed so that a single machine (probably a Linux/UNIX
machine since Windows appears to limit how many sockets you can have open
at any given time) can easily tie up a typical web server or proxy server
by locking up all of it's threads as they patiently wait for more data.
Some servers may have a smaller tolerance for timeouts than others, but
Slowloris can compensate for that by customizing the timeouts. There is an
added function to help you get started with finding the right sized
timeouts as well.

As a side note, Slowloris does not consume a lot of resources so modern
operating systems don't have a need to start shutting down sockets when
they come under attack, which actually in turn makes Slowloris better than
a typical flooder in certain circumstances. Think of Slowloris as the HTTP
equivalent of a SYN flood.

If the timeouts are completely unknown, Slowloris comes with a mode to
help you get started in your testing:

Testing Example:
./slowloris.pl -dns www.example.com -port 80 -test

This won't give you a perfect number, but it should give you a pretty good
guess as to where to shoot for. If you really must know the exact number,
you may want to mess with the @times array (although I wouldn't suggest
that unless you know what you're doing).
Once you find a timeout window, you can tune Slowloris to use certain
timeout windows. For instance, if you know that the server has a timeout
of 3000 seconds, but the the connection is fairly latent you may want to
make the timeout window 2000 seconds and increase the TCP timeout to 5
seconds. The following example uses 500 sockets. Most average Apache
servers, for instance, tend to fall down between 400-600 sockets with a
default configuration. Some are less than 300. The smaller the timeout the
faster you will consume all the available resources as other sockets that
are in use become available - this would be solved by threading, but
that's for a future revision. The closer you can get to the exact number
of sockets, the better, because that will reduce the amount of tries (and
associated bandwidth) that Slowloris will make to be successful. Slowloris
has no way to identify if it's successful or not though.

HTTP DoS Example:
./slowloris.pl -dns www.example.com -port 80 -timeout 2000 -num 500 -tcpto

HTTPReady Bypass
HTTPReady only follows certain rules so with a switch Slowloris can bypass
HTTPReady by sending the attack as a POST verses a GET or HEAD request
with the -httpready switch.

HTTPReady Bypass Example
./slowloris.pl -dns www.example.com -port 80 -timeout 2000 -num 500 -tcpto
5 -httpready
  Stealth Host DoS
If you know the server has multiple webservers running on it in virtual
hosts, you can send the attack to a seperate virtual host using the -shost
variable. This way the logs that are created will go to a different
virtual host log file, but only if they are kept separately.

Stealth Host DoS Example:
./slowloris.pl -dns www.example.com -port 80 -timeout 30 -num 500 -tcpto 1
-shost www.virtualhost.com

Slowloris does support SSL/TLS on an experimental basis with the -https
switch. The usefulness of this particular option has not been thoroughly
tested, and in fact has not proved to be particularly effective in the
very few tests I performed during the early phases of development. Your
mileage may vary.

HTTPS DoS Example:
./slowloris.pl -dns www.example.com -port 443 -timeout 30 -num 500 -https

HTTP Cache
Slowloris does support cache avoidance on an experimental basis with the
-cache switch. Some caching servers may look at the request path part of
the header, but by sending different requests each time you can abuse more
resources. The usefulness of this particular option has not been
thoroughly tested. Your mileage may vary.

HTTP Cache Example:
./slowloris.pl -dns www.example.com -port 80 -timeout 30 -num 500 -cache

Slowloris is known to not work on several servers found in the NOT
AFFECTED section above and through Netscalar devices, in it's current
incarnation. They may be ways around this, but not in this version at this
time. Most likely most anti-DDoS and load balancers won't be thwarted by
Slowloris, unless Slowloris is extremely distrubted, although only
Netscalar has been tested.

Slowloris isn't completely quiet either, because it can't be. Firstly, it
does send out quite a few packets (although far far less than a typical
GET request flooder). So it's not invisible if the traffic to the site is
typically fairly low. On higher traffic sites it will unlikely that it is
noticed in the log files - although you may have trouble taking down a
larger site with just one machine, depending on their architecture.

For some reason Slowloris works way better if run from a *Nix box than
from Windows. I would guess that it's probably to do with the fact that
Windows limits the amount of open sockets you can have at once to a fairly
small number. If you find that you can't open any more ports than ~130 or
so on any server you test - you're probably running into this "feature" of
modern operating systems. Either way, this program seems to work best if
run from FreeBSD.

Once you stop the DoS all the sockets will naturally close with a flurry
of RST and FIN packets, at which time the web server or proxy server will
write to it's logs with a lot of 400 (Bad Request) errors. So while the
sockets remain open, you won't be in the logs, but once the sockets close
you'll have quite a few entries all lined up next to one another. You will
probably be easy to find if anyone is looking at their logs at that point
- although the DoS will be over by that point too.

What is a slow loris?
What exactly is a slow loris? It's an extremely cute but endangered mammal
that happens to also be poisonous. Check this out:


Proof of concept 

Un saludo Naivenom

2 comentarios en “DoS con Slowloris.pl

  1. Buenas, el referido ataque no se trata de consumir el ancho de banda sino de mantener conexiones abiertas el máximo tiempo posible a base de justamente lo contrario, el envío de peticiones http a una tasa de datos muy baja.

Los comentarios están cerrados.