Nessus's Nmap competitor

[Fyodor <fyodor () insecure org>]

I suppose I should pay more attention to the Tenable Blog -- it turns
out that they released a command-line scanner named nessuscmd in beta
last year.  They describe it at
http://blog.tenablesecurity.com/2007/07/nessus-32-beta-.html .  To
determine what tool inspired this, you only need to look at their
first command-line example:

nessuscmd -sS -v -O -p 1-1024 192.168.20.24 

Wow, where have we seen that syntax before?  Many of the other option
flags are the same as Nmap.  There is nothing wrong with this, but I
figured it was worth taking a look at and/or discussing the tool.
Here is the usage screen:

> > /opt/nessus/bin/nessuscmd -h
> nessuscmd 3.2.0 - (C) 2006 - 2008 Tenable Network Security, Inc.
>
> Usage:
>  nessuscmd <option> target...
>
> Port Scan options:
> ------------------
>  -p <port_range> : Enable the port scanner and scan this port range
>                   (use 'default' for the Nessus default port range)
>  -sT : Perform a TCP connect()
>  -sS : Perform a SYN scan
>  -sP : Perform a PING scan
>
>  -O  : Enable OS Fingerprinting

These are all about the same as Nmap.  We don't offer the "default"
keyword for the port range, but you can simply not specify -p with
Nmap to get the default behavior.  Note that Nessus does not have a
TCP/IP stack fingerprinting system which is nearly as comprehensive as
Nmap's, so they focus more on application-layer techniques.  See
http://blog.tenablesecurity.com/2007/05/enhanced_operat.html .  We
could consider making some of these into NSE scripts (or getting the
info from version detection, if the protocols are simple enough).  In
particular, I see:

# os_fingerprint_mdns.nasl If an mDNS server is present, will perform a highly accurate identification of Apple OS X 
systems.
# os_fingerprint_msrprc.nasl Identifies the remote version and service pack of Windows by making certain MSRPC requests 
against the remote Windows box.
# os_fingerprint_ntp.nasl Queries the Network Time Protocol daemon to perform a highly accurate OS guess.
# os_fingerprint_smb.nasl Identifies the remote Windows OS based on a query to SMB.
# os_fingerprint_snmp.nasl If credentials are available to perform an SNMP query, data from the 'sysDesc' parameter is 
reported.
# os_fingerprint_ssh.nasl Attempts to identify the remote OS by the SSH banner.
# os_fingerprint_telnet.nasl Attempts to identify the remote OS by the Telnet banner.

Some of these we have, but others we don't (or perhaps not as well).
Having application-level OS detection checks in addition to stack
fingerprinting is useful, because it helps understand cases such as
port forwarding/DNAT where a load balancer or firewall might forward
certain ports to completely different systems.  As that OS detection
blog entry is more than a year old, there might be other
os_fingerprint_* plugins by now.

> Ping options:
> --------------
>  -P0 : Do not ping the remote hosts prior to a scan
>  -PI : Do an ICMP ping
>  -PT : Do a TCP ping
>  -PA : Do an ARP ping (only on the local subnet)
>  Ping options can be combined - ie: -PIT performs a TCP and an ICMP ping

This is a subset of Nmap ping options.

> Vulnerability Scan options:
> ---------------------------

OK, now we're getting into Nessus's bread and butter.

>  -i <plugin_id> : Enable plugin <plugin_id,plugin_id,...>
>     This option can be used multiple times - ie: -i 12209 -i 20368 -i 16337,10884
>     See http://www.nessus.org/scripts.php for a list of plugins

This is similar to our --script option.  Instead of numbers, we have
script IDs.  Of course we also allow categories, filenames, etc. as
arguments to --script.

>  -N : do NOT enable plugin dependencies

We don't really have dependencies in the same way as Nessus does.  We
do offer the runLevel directive and categories, which can help.  And
of course we have libraries which handle dependency-related stuff.
But we might need formal dependencies at some point.

>  -V : Display the complete report of the plugins

This might be similar to Nmap when you have one or more -v or -d
options.  Though maybe -V gives you the script summary text, etc.
Nmap does not currently provide that information, though we will soon
have a documentation site available with it.  And we do have a system
in place for obtaining that information in the future if we decide to
print it in Nmap (or include it in the XML output).

>  -q : Only display wether a plugin matches or not

Nmap's default output is generally pretty brief, though not that brief.

>  -U : DISABLE safe checks

We use categories for this.

> Credentials:
> ---------------------------
> SMB : (Windows)
>  --smb-login           : SMB login
>  --smb-password        : SMB password to use
>
>  --smb-domain          : SMB domain to log into
>
>  --smbi                : Interactively ask for SMB credentials
>
> SSH : 
>  --ssh-login           : SSH login
>  --ssh-password        : SSH password to use
>  --ssh-pubkey           : SSH public key to use
>  --ssh-privkey          : SSH private key to use
>  --sshi                : Interactively ask for SSH credentials

Nmap does not do much in the way of credentialed scans.  Maybe we will
go there someday.

> Warning: Using ssh credentials for the scan makes you vulnerable to a mitm attack

LOL :).

> Telnet/Rlogin/Rsh: 
>  --cleartext-login     : Clear text login
>  --cleartext-password  : Clear text password to use
> Warning: Using clear text credentials for a scan is dangerous
>
> Using a .audit file:
> ---------------------------------------
>  --unix-audit <FILE>        : .audit file to use for the local Unix compliance checks
>  --windows-audit <FILE>        : .audit file to use for the local Unix compliance checks

The .audit file is an interesting idea.  I think they botched the
--windows-audit description by simply copying --unix-audit and not
changing it.

> Connecting to a remote Nessus scanner :
> ---------------------------------------
>  --remote <IP>         : Connect to the remote Nessus host <IP>
>  --remote-port <PORT>  : Connect to the remote Nessus on port <PORT>
>  --login <LOGIN>       : Connect to the remote Nessus with the login <LOGIN> [optional]
>  --password <PASS>     : Connect to the remote Nessus with the password <PASS> [optional]

Nmap does not do this.  When you want to run Nmap from a remote
server, you generally log in with ssh (or whatever) and run Nmap
directly from there.  I'm assuming that nessuscmd requires that you
have a Nessus daemon running somewhere.  Maybe it tries localhost by
default, or reads some sort of .nessusrc.

> Other options:
> --------------
>  -v : Be verbose during the scan
>  -h : Display this help

These are the same as Nmap.

>  --recv-timeout : Plugins recv() timeout
>  --max-hosts : Number of hosts to scan in parallel

Nmap has timing options (and/or script options) similar to these.

>  -o name=value : nessusd option

Nmap uses --script-args for this.

>  -f /path/to/socket : use an alternative Unix socket

Maybe this is to connect with nessusd.  I'm not sure.

> Examples :
> ----------
>  nessuscmd -p 1-1024 localhost
>  nessuscmd -O 10.0.1.2
>  nessuscmd -V -i 10884 172.16.1.1

And that wraps it up!  You can see nessuscmd output examples at
http://blog.tenablesecurity.com/2007/05/enhanced_operat.html .

Does anyone here regularly use nessuscmd?  Is there any part of it you
find particularly useful?

Cheers,
-F


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