Nmap Development mailing list archives

Re: DNS fuzzer


From: Fyodor <fyodor () insecure org>
Date: Fri, 2 Apr 2010 16:54:38 -0700

On Fri, Apr 02, 2010 at 07:01:56PM -0400, Michael Pattrick wrote:

Other scripts take time arguments in seconds, not minutes. It's not the
best for this script but I'd like it if you make this script work that
way too. In the future we should have a standard function for parsing a
time specification like "60s" or "1m".

I have implemented it to stay consistent with the new argument name,
but I don't think it works well... No one would be running a fuzzer
for less then one minute.

Yeah, it will be better when we have a custom time parsing function
for NSE like David suggested.  We already have one for Nmap proper.
I've added it to docs/TODO.

But for now, I think standardizing on seconds like you've done makes
sense.  While it may be slightly annnoying to type in 1200 rather than
20 to run for 20 minutes, it beats having to look up the documentation
each time or to get it wrong.

Running without the dns-fuzz.fuzztime argument gives
53/udp open|filtered domain  no-response
| dns-fuzz-2: Cannot fuzz for zero minutes, please enter a valid length of time to fuzz for.
|_Or -1 to fuzz for an unlimited amount of time.
Other scripts have the convention that 0 means unlimited. In case the
script argument is not specified, use a default limit of 10 minutes.

That's by design, to prevent the script from being run accidentally.

It's not a default script, so if someone specifies "--script dns-fuzz"
or "--script fuzzers", they probably want it to run for at least some
period.  It should probably work the same way as our brute force
scripts, which also have this issue.  Maybe unpwdb.timelimit() would
be a good approach, but it does sort of feel wrong to use an unpwdb
function in this context.  Maybe we should have a general timing
library and timelimit() should be moved there.

Now I plan on adding support for different modes of corruption.

Sounds great!

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


Current thread: