Re: [NSE] DB2 library and scripts

[Patrik Karlsson <patrik () cqure net>]

On 12 maj 2010, at 08.38, Fyodor wrote:

> On Tue, May 11, 2010 at 07:57:34PM +0200, Patrik Karlsson wrote:
> > Hi again,
> >
> > I'm attaching yet another version of the DB2-brute script.
> > In this version, I've used the excellent code provided by Patrick (thanks!) and changed the behavior/design 
> > according to Fyodor's suggestions [1].
> > I'm also providing some *very* simple benchmarking of this new script and the old single threaded one running 
> > against DB2 on Linux.
>
> Thanks Patrik.  And David had a great idea (which he already posted)
> about running 10 non-parallelized scripts separately and seeing how
> that compares.
I just posted the results of these tests, and the threaded version was faster.

> > So this rudimentary benchmark suggests a 25% performance increase
> > when running with 10 threads.  Increasing the threads to 20 by using
> > the db2-brute.threads argument did not show any additional
> > performance increase.
>
> Perhaps the number of threads should be dynamic?  Maybe it should
> start with one and try to increase the number by one (up to a
> configured maximum) every X seconds.  Then it could crack another X
> seconds and look at whether the rate increased or decreased in this
> segment vs. the one before the increase.  If the rate increased, bump
> up the threads again.  But if the rate stayed the same or decreased,
> bump the thread count back down.
>
> This is very similar to how Nmap's port scanning algorithm works.  It
> is always trying to go faster, but then slows down if accuracy is
> hurt.

I think this is a great idea. Perhaps this could be considered, when/if implementing a more generic brute force 
framework as proposed by Martin Swende [1] ?
The brute scripts I've been writing lately are very similar (code is heavily duplicated) and mainly consists of the 
username and password iterators while the main logic lies in the respective library.
This could make them suitable candidates for such a framework.

> Admittedly this is much more of a pain to implement, but the
> performance gains may be worth it.
>
> Cheers,
> -F


[1] http://seclists.org/nmap-dev/2010/q1/801

//Patrik
--
Patrik Karlsson
http://www.cqure.net
http://www.twitter.com/nevdull77





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