Re: Writeup on `brute.lua` Modification

[Patrick Donnelly <batrick () batbytes com>]

Hello Sergey,

On Sat, May 28, 2016 at 3:11 AM, Sergey Khegay <g.sergeykhegay () gmail com> wrote:
> Hello,
>
> I have updated the performance table.
>
> o. Some statistics
> ||=====================================================================||
> || # accounts   |          nmap          |  ncrack   |  hydra          ||
> ||              | original  |  modified  |           |                 ||
> ||--------------|-----------|------------|-----------|-----------------||
> || 80           | 29.13 (+) | 40.27  (+) | 24.03 (+) | 16.76 (+)       ||
> || 400          | 126.24 (+)| 85.06  (+) | 60.07 (+) | 90.06 (+)       ||
> || 80 *         | 3.62(-) ! | 85.00  (+) | 15.01 (-) | did not stop (-)||
> || 400 *        | 7.22(-) ! | 318.06 (+) | 12.07 (-) | did not stop (-)||
> ||---------------------------------------------------------------------||
>
> tested script: ftp-brute
>
>  *  - special conditions: the number of connections per IP were set to 5
> (+) - correct credentials were found
> (-) - no credentials were found even though they were in the list
>  -  - test was not conducted
>  !  - almost the same time with assumed bug with max_retries and without it
>
>
> As you can see the modified version performs slower than the original one
> on the small sets of account on a reliable network. This can be explained
> by the way we grow the number of coroutines.
>
> In the modified version, I start with 1 coroutine, then gradually grow that
> number until `max_threads` limit is reached (the default value of
> `max_threads` for the modified version is 50, so there can be maximum of 50
> coroutines). Maybe I should start with more coroutines initially and
> introduce
> a new parameter for user tuning.

The default value of 50 won't make sense with the default max
parallelism (--max-parallelism), no? The default max parallelism is 20
so only 20 threads can use sockets concurrently (at least, that is the
intended behavior...). See this block of code:

https://github.com/nmap/nmap/blob/3749c0431005c29b83597dc4d6b33bed2a5f9fda/nse_nsock.cc#L150-L185

Also, you should consider how the brute library will utilize sockets
when there may be other scripts running. It's important that the brute
library not exhaust the pool of sockets which would prevent other
scripts from doing work. You may need to add a function to the nsock
binding to access the limits and any other information you need (e.g.
is there pressure to get sockets from other scripts?). Also, does it
make sense to have only one brute script running at a time? If not,
what is the performance when they are competing for resources?

Also, maybe the default max parallelism of 20 should be adjusted. NSE
has seen a lot of changes since that limit was changed. See also:

http://seclists.org/nmap-dev/2009/q3/143

Thanks for your work on this Sergey, I look forward to seeing the
development. Let me know if you have any questions concerning NSE and
I'll be happy to help.

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