Re: [NSE] Prerule considerations and concerns

[Patrik Karlsson <patrik () cqure net>]

On 17 okt 2010, at 00.24, Fyodor wrote:

> On Sat, Oct 16, 2010 at 10:32:09AM -0500, Tom Sellers wrote:
> > Here are my concerns with the current behavior:
> >
> > 1.  In most cases the results have no relevance to my target.  The
> > current scripts broadcast looking for certain data, and that
> > functionality is handy as hell, but it doesn't have any bearing on
> > my target 4 hops away.
>
> Hi Tom, you make some good points.  A related example is the scan
> "nmap -A scanme.nmap.org".  It ends up doing a pre-scan script with 5
> scripts, when none of that functionality is really desired for that
> scan.  The biggest problem is the time and bandwidth used for the
> undesired functionality, but it also bloats the Nmap output with some
> extra text:
>
> NSE: Script Pre-scanning.
> NSE: Starting runlevel 1 (of 1) scan.
> Initiating NSE at 15:01
> Completed NSE at 15:01, 5.00s elapsed
>
> The five scripts which are running by default are:
>
> snmp-interfaces
> dns-zone-transfer
> upnp-info
> ms-sql-info
> dns-service-discovery
>
> Let's start with the first two, as those are simpler to resolve.
> These don't actually function as prerules unless you pass in special
> NSE arguments (snmp-interfaces and dnszonetransfer, respectively).
> The only "problem" they can cause is Nmap having to do the prerule
> action phase and print out the extra information.  It would probably
> be better for these to check for the required arguments in the
> prerule() itself rather than in the action.
>
> Now lets look at the other three:
>
> upnp-info
> ms-sql-info
> dns-service-discovery
>
> These all have prerules which send a broadcast or multicast network
> query.  That is probably not something we want Nmap to do by default
> every time it runs with scripting.  But these three also have
> hostrules and/or postrules which act against the specified targets and
> which we probably do want to run by default.  I see a couple options
> for resolving this:
>
> 1) We could split off the broadcast functionality of these scripts
>   into new scripts (upnp-broadcast or something) and maybe add them to a
>   new category ("broadcast"?  "broadcastdiscovery"?).  The way users
>   who want all the broadcast discovery scripts (or individual ones)
>   could easily get them, but it avoids them running by default when you
>   only care about your list of targets.
>
> 2) Or we could add a general NSE Arg for enabling the broadcast
>   discovery.  This would be like the recently added "newtargets"
>   argument.
>
> I'm open to either option, but I think I favor #1.  In the case of
> "newtargets", the script behavior is almost identical whether it is
> specified or not.  You find the IPs in any case and print them, and
> newtargets just controls whether they are also added to the scan
> queue.  But upnp-info, ms-sql-info, and dns-service-discovery actually
> have quite different functionality in broadcast discovery prerule mode
> and normal hostrule/portrule mode.  And hopefully most of their common
> functionality could be shared in their related libraries.

I'm open to either option as well. What's important to me is to be able to do broadcast discovery without the need to 
use newtargets.
So a new category or an option similar to "newtargets" would do fine.

Just let me know what you think is best and I'll change the scripts accordingly.

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


//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/