Test and fix http-slowloris for running against multiple services at once.

[dmiller-nmap]

The http-slowloris script has lots of script-level variables that will probably conflict with each other when scanning multiple services. Example: the Bestopt variable keeps track of whether to use SSL or not. Running against a plaintext and an HTTPS service at the same time would probably result in conflicts. Need to test and fix, or just rewrite the script to be cleaner.

[h4ck3rk3y]

Hi,
I tried replacing all the script level variables with function parameters. This failed as stdnse.new_thread doesn't return the functions outputs. Then I decided to make all script level variables tables, indexed by getKey function which generates a unique key index based on host.ip,port.number and port.service. Please comment on this approach. I have attached the script using this approach[1].

[1]https://github.com/h4ck3rk3y/nmap/blob/master/test_scripts/http-slowloris.nse

Gyani

[dmiller-nmap]

@h4ck3rk3y I would instead make those variables into indices in a table local to the action function. Then pass that table as an argument to the thread function via stdnse.new_thread.

I do notice now, though, that the original author included a workaround for this problem by using a mutex to ensure only one instance of the script runs at any given time. We should probably look into how to best handle scanning multiple services, since doing so with the runforever script-arg would mean that only the first service would ever be attacked.

[h4ck3rk3y]

@h4ck3rk3y I would instead make those variables into indices in a table local to the action function. Then pass that table as an argument to the thread function via stdnse.new_thread.

Some of the functions that are run through stdnse.new_thread change the values of the script level variables. If these variables are indexed into a table and passed to the functions, I am not sure how the updated values will be retrieved.

I do notice now, though, that the original author included a workaround for this problem by using a mutex to ensure only one instance of the script runs at any given time. We should probably look into how to best handle scanning multiple services, since doing so with the runforever script-arg would mean that only the first service would ever be attacked.

Some sort of port specification ? The user can specify which port to run the script forever on. Others open ports will be skipped.

[dmiller-nmap]

Tables are passed by reference; all threads would have the same table. This means that any of the threads which updates a value would have to use a mutex or something to avoid concurrency issues, but for reads there would be no problems.

[h4ck3rk3y]

Ah, that should work then. My implementation really reduced the readability of code and made it look messy.