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

[Patrick Donnelly <batrick () batbytes com>]

Hi Gutek,

On Sun, May 22, 2011 at 6:47 AM, Gutek <ange.gutek () gmail com> wrote:
> -----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.

I have some comments:

o Don't change the random seed. I just made a commit in 23266 making
this unnecessary for scripts. NSE does it on your behalf.

o You can use a mutex so that you can run against multiple hosts but
only one slowloris script is ever running (so you don't overload the
host system). Something like nmap.mutex("slowloris") with a lock and
unlock at the beginning and end of the action function would suffice.

o The formatting makes the script really hard to follow. Can you try fixing it?

o You can move the doHalfhttp and doMonitor functions outside of the
action function. There are no upvalues (external local variables [1])
that these functions need access to inside the action function.

o I don't think you need to use the registry in this script. Why not
use local variables at the start of the script like:

local threads = 0 -- previously: nmap.registry[host.ip]['slowloris_threads']
local sockets = 0 -- previously: nmap.registry[host.ip]['slowloris_sockets']
local queries = 0 -- previously: nmap.registry[host.ip]['slowloris_queries']
local serverup = true -- previously:
nmap.registry[host.ip]['httpmonitor_serverup']


> 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.

I just don't see a reason to be using the registry at all for this
script, as I said above. As for the concurrent attacks, this is a
non-issue if you use a mutex to serialize the denial-of-service
attacks.

[There are actually a lot of scripts and libraries that needlessly use
the registry. It's unfortunately become common practice.]

[1] http://www.lua.org/manual/5.1/manual.html#2.6

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