Re: [NSE] DB2 library and scripts

[David Fifield <david () bamsoftware com>]

On Fri, May 14, 2010 at 01:53:16PM +0200, Patrik Karlsson wrote:
> On 14 maj 2010, at 09.23, Patrick Donnelly wrote:
>
> > Hi Fyodor,
> >
> > On Wed, May 12, 2010 at 2:01 PM, Fyodor <fyodor () insecure org> wrote:
> > > On Wed, May 12, 2010 at 05:33:30PM +0200, Patrik Karlsson wrote:
> > > > 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] ?
> > >
> > > I agree that a brute force library/framework or is the way to go,
> > > especially as the scripts get more complex due to parallelisms and
> > > algorithm optimizations.
> > >
> > > That being said, it sometimes is easiest to start with one script and
> > > experiment/benchmark to figure out what works best.  Then that can be
> > > ported to a new generalized library.  In other cases (or for other
> > > people), starting with the generalized library is easier.
> >
> > It seems to me this is something best handled in the NSock Lua
> > binding. That is, if a server is "misbehaving" by slowing down replies
> > or dropping connections then we should lower the parallelism against
> > the server? This is probably too low level though.
> >
> > That said, I'm curious why the parallel implementation performed so
> > poorly. Patrik, do you know how the server was reacting? Was it
> > dropping connections? Slowing down replies? How does your db2.lua
> > library handle dropped connection attempts? Does it retry?
>
> First off, like I mentioned before, this is a server running in
> VirtualBox on my laptop.
> Secondly, this is a default installed DB2 server without any tweaking
> made on the OS or the DB.
> So it probably doesn't server well as a testing reference.
>
> While running the script against the server the CPU goes up to 70% and
> stays there for the complete duration of the scan.
> Even though it's not 100% I'm guessing this is what's limiting it from
> going faster.
>
> I've added some missing checks for socket errors in the library, but
> no retry attempts are made.
> I would appreciate it a lot if someone with a "real" db2 server could
> test it out and report some performance statistics.

I think the library looks fine and the rewritten db2-info is a nice
improvement. There are some questions about what's causing
less-than-expected performance in parallelized brute forcing, but that
will be easier to test out when it's under revision control. So I'd like
you to commit the library and the two scripts when you can.

Congratulations on being able to figure out so much about this
once-mysterious protocol.

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