Re: Writeup on `brute.lua` Modification v.2. Resource Management Feature.

[Daniel Miller <bonsaiviking () gmail com>]

Sergey,


> local socket = nmap.new_socket()
> local stats = socket:get_stats()
>
> Keep in mind that creating a socket does not yield the script (the
> actual socket is created during connect I believe).
Is there a reason why the script itself needs to handle resource management
like this? It seems like we'll be fighting lots of the standard concurrency
problems with shared resources, and duplicating a lot of code for all the
various scripts that spawn multiple threads (ssl-enum-ciphers, brute-*,
http spider scripts, etc.). I have another idea that is a bit more radical
but might be worth considering:

Instead of the script querying the engine to determine state and then
spawning threads dependent on that, what if the script requested a number
of threads from the engine and then was granted them as the engine saw fit?
Remove the spawn/wait loop from the script/library itself and instead
introduce an API that means essentially "do this thing with as much
parallelism as you can." The engine could internally use a similar timing
approach to ultrascan, using pings to detect network problems and slow
hosts and distributing threads more generously to fast hosts and in smaller
numbers to slow hosts to avoid drops.




> > # GENERAL CONSERN
> >
> > I need to find a good metric to alert the engine to stop, as for now
> > the `Engine` is too stubborn and, theoretically, might never give up
> > on retrying bruteforce attempts.
>
> Indeed! I think Devin nearly finished a feature in 2014 to add
> debugging to NSE -- and in particular killing running scripts! -- but
> a segmentation fault prevented us from merging. You might want to
> revisit that if you're interested.

You could also check out Abhishek's --script-timeout feature (#330) which
will just kill scripts after a set time running against a host. This
doesn't give the script a chance to output anything, but could be useful if
you're just checking periodic debug output.
https://github.com/nmap/nmap/pull/330

Dan

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