Re: [NSE] http-slowloris, check if a webserver is prone to the Slowloris DoS attack

[Gutek <ange.gutek () gmail com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here is a new test script against the slowloris attack.
The monitoring function has been rewritten and now the attack is more
efficient, for example with the use of POST requests instead of GET
ones, which in some cases can bypass some filtering modules.

With a --max-parallelism of 300 it take a few minutes to bring a
(internet) webserver down, or a few seconds if the server has been
configured with a small maxClients (but this case is not a slowloris,
it's more kinda 'http flood').
By the way, a word about the video demonstrating Slowloris at
http://vimeo.com/7618090 (demo is at 30:00). Their demo takes the
webserver down at the very moment they launch the slowloris script.
Plus, the screen shows that the process has sent the header, but not
started to feed the streams with "X-a: b" yet. At the moment the
webserver is down, the script is in fact in the
"240-seconds-wait-before-feeding" process. With no offense, I'm
wondering if there is a little cheat here: my bet is that in fact the
webserver is down *not because of the slowloris attack itself*, but
because of a max concurrent sockets exhaustion.
As the author said in the introduction, a real slowloris attack should
take a couple of minutes on a good (weak) server.

The targets prone to 'Slowloris'
- -------------------------------

The 'best' testing targets are the shared-hosting solutions: the
ressources allowed to each website is often very low on cheap offers.
The downside (speaking about slowloris) is that they also come with a
very low maxClients (often about 30-50). Bringing them down is a blitz,
but still: this is not slowloris.
A really good candidate is the one who is shared-hosted, and with a high
maxClients. For obviously privacy reasons I can't name examples here
publicly, but you can find such exposed websites with a Google query
that reveals a web hoster that meets those conditions ('"/homepages/28/"
warning:', strip simple quotes).

Efficient usage is:
  nmap -v -n -p80 --script http-slowloris --max-parallelism 300 <target>

The nmap.registry variables
- ---------------------------

The slowloris attack needs a high number of concurrent sockets to
succeed, that's why this script is designed to aim a single target at
once with all available local ressources. I don't think that it could be
efficient in a reasonnable time against multiple targets at the same
time (or even just efficient). It is faster to test the candidates one
after another.
That's why the nmap.registry tables have been replaced by a per-host.ip
table (eg nmap.registry[host.ip]['slowloris_sockets']), but for
consolidation reasons and not to allow multiple concurrent attacks.
I've heard the concerns about using the nmap registry here but I'm not
sure to understand why it could be an issue.

All the best,

A.G.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAk3Y6a8ACgkQ3aDTTO0ha7h2jgCeMZ2dyHF3akqtfw7hcZD+Z4sJ
xIsAn2yOnGHOdoha13ZveHDnZ+0eoDf0
=NnBc
-----END PGP SIGNATURE-----

Attachment: http-slowloris.nse
Description:

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/