Nmap Development mailing list archives

Re: [NSE] snmp-brute port to brute framework


From: Gorjan Petrovski <mogi57 () gmail com>
Date: Thu, 14 Jul 2011 21:38:16 +0200

Actually, I see now that the coroutine would not be redundant, since
the script needs to respect the unpwdb script-args supplied.

On Thu, Jul 14, 2011 at 9:23 PM, Gorjan Petrovski <mogi57 () gmail com> wrote:
Ok, so porting the snmp-brute script to the brute library is not a
good idea, since it's most optimal to use unconnected sockets, in
other words, unpwdb. So making a special coroutine would be redundant
in this case, right?

On Wed, Jul 13, 2011 at 12:05 AM, Patrik Karlsson <patrik () cqure net> wrote:
I found a half-bad workaround port forwarding a port on my wireless router to the virtual machine.
This way the packets leave my box and then come back again allowing me to pick them up with pcap.
I've ran the script a few times, but don't get very consistent results. The last few times I ran it, it took approx 
25 seconds without and missing reponses.
Then suddenly I got 3316 missing responses....

I'll see if I can get a more stable testing platform tomorrow.

//Patrik

On Jul 12, 2011, at 5:22 PM, Gorjan Petrovski wrote:

Oh, and ignore the description and categories, they're copied from the
future snmp-brute :)

On Tue, Jul 12, 2011 at 5:21 PM, Gorjan Petrovski <mogi57 () gmail com> wrote:
I've hacked together a script to test the throughput of the snmp
server, and my tests against a Net-SNMP server on a Ubuntu 11.04
desktop edition showed that it processes all the probes fine. It uses
threads so it should make for a pretty precise measurement.

If you can, please test the attached script against your servers. The
command you need to use to test it with 10000 probes (which I
recommend for virtual machines) is:

nmap -sU -p U:161 --script test --script-args
test.probes=10000,test.community=<community_string> <target> -d

Thanks a lot! :D
Gorjan

On Tue, Jul 12, 2011 at 8:19 AM, Patrik Karlsson <patrik () cqure net> wrote:

On Jul 12, 2011, at 12:30 AM, Gorjan Petrovski wrote:

Thanks for the suggestions. Currently I'm testing the throughput with
unconnected sockets. I'm using a virtual machine so any limitations
would be due to slow processing of requests on the server's part. I'm
gonna add the default passwords after I resolve the issues with
communication and losses of passwords. Currently my criteria are that
under no circumstances we should DoS the server, and as a result of
that miss testing some passwords. My thoughts are going toward using
unconnected sockets but somehow limiting the number of probes sent per
second. The host.times.timeout will definitely be of use, but I'll
have to add a heuristic multiplier to that, so now I have to find what
value that multiplier will be.

Patrik, did you test the responsiveness of the server using multiple
probes with the correct password, or was there some mysterious net-fu
of yours at play? I'm asking because AFAIK the only way to find if a
password is wrong is a timeout on a socket (no returned response), so
we can't reliably test the snmp-brute script itself, but we can test
the servers throughput.


Yes, as far as I can tell the only way of determining whether a probe was correct or not is to wait for a) an 
answer or b) a timeout.
I didn't get very far in testing concurrent probes and server responsiveness.
I only did some limited testing and realized that it would be possible to run a number of parallel probes that I 
could wait on simultaneously.
Like I mentioned in my post, I moved on to SIP instead as my goal was really to implement an UDP based brute 
script.
If you need help testing, feel free to send me your current script. I have some virtual machines running SNMP I 
can test against.

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





--
Gorjan




--
Gorjan

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





--
Gorjan




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


Current thread: