Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: Output|Input pipe and forcing script run
From: Martin Holst Swende <martin () swende se>
Date: Thu, 16 Jun 2011 19:48:43 +0200

On 06/16/2011 12:09 AM, Ron wrote:
On Sat, 30 Apr 2011 00:53:22 -0700 David Fifield <david () bamsoftware com> wrote:
I want to reopen discussion about forcing a script to run. I tried
this patch and it works as I expect. The problem I see is that there
are easy ways to accidentally and confusingly use it.

nmap --script-args force -d2 localhost -sC -F

This is going to run every default script against every open port:

...

I think that a global "force" option only makes sense if 1) you are
narrowly targeting a list of ports and 2) you are narrowly limiting
the set of scripts. Can we think of a way to make this work naturally
without strange cases like the above?

My first thought is that you usually only want one or a few scripts to
be forced. So what if we invent a new syntax that allows applying the
force script to one script only? I don't think this is a good syntax,
but it will illustrate what I mean:

nmap www.google.com -p80 --script force:firewalk

This is no more typing in the (expected) case when only one script is
used. It would be possible to run one script forced and one
non-forced, though I don't have a realistic use case for that.

David Fifield
I realize that I'm a couple months late to the party, but I'm trying to catch up on lists again and wanted to 
comment. :)

Anyway, here's a use case that I think we should look at targeting: I'm running Zenmap, and I discover a SMB server 
on the network. I want to run smb-os-discovery. I do, and get the results. Then I decide to run smb-enum-users. And 
maybe some others. Then I move to the FTP port and run ftp-brute.nse, using the list of usernames I got from SMB. It 
gets a password, and I run to run ftp-list-files or whatever.  

With the current version of Nmap, I need to do a new scan every time. Even if it's just the one port, it means I have 
to re-configure the scanner to just scan 445 now. Additionally, the registry would need to be persisted for this to 
work, but that's another problem. 

It'd be really nice if there was an interactive script mode where I can try the scripts one by one, and not have to 
re-run the full or partial scan for each one. 

Any thoughts about that? 

Ron
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/
Sorry for not replying on this thread earlier, but I kind of shifted
into the named-probes idea instead of --force.


Let me list a few usecases that have been discussed:
1) Known service, want to run script without doing "-sV --version-all"
each time.  (Example: rmi)
2) Known service, want to select different scripts after seeing results
of the earlier scripts (like Ron).

Also, a few ideas that have been proposed:
1) force: force scripts to run. Difficulties in determining what to do
if there are several ports or several scripts
2) named probes: let the user determine what probe(s) to use.
3) interactivity: let the user decide what scripts to run interactively.
Perhaps even defer script arguments until later as suggested in [1] or
get interactive help on the potential scripts.

The problem of rescanning a service just to identify it is only
half-solved by (3), since the port would have to be rescanned if the
nmap "session" is closed.

I definitely support named probes. Otoh, I also like the idea of
interactivity. I believe that adding interactivity to nse_main.lua would
not be very difficult, but I may be wrong (?)

[1] http://seclists.org/nmap-dev/2010/q2/47

ps. I would really like to have one of these. I don't have the time to
implement named probes, since I haven't even looked at the nmap c-code
and haven't done c-programming for a loong time. The other two can be
implemented in lua space (methinks).

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]