Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: Output|Input pipe and forcing script run
From: Patrik Karlsson <patrik () cqure net>
Date: Thu, 16 Jun 2011 20:09:49 +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?

Sent through the nmap-dev mailing list
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).

Named probes would sure save a lot of wasted time, network communication,
and juggling with changes to probes and scripts.
I did look at it, but felt kind of lost, tried to do some changes that
didn't work, gave up.
Maybe I'll give it another shot or maybe someone will surprise me with a
patch ... ;)
I've still got a bunch of scripts on my TODO before I'll have another look.

Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/

Patrik Karlsson

Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/

  By Date           By Thread  

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