Mailing List Archive: Port Specification in Nessus

Port Specification in Nessus

Jun 18, 2004, 2:57 AM

Post #1 of 3 (1737 views)

Dear Nessus Developers,

The way Nessus 2.0.x manages port specifications is not ideal and
could be improved (I did not look at 2.1.x yet, sorry). The basic idea
is that the protocol information should be taken into account in a
more consistent way. Here are some of the things that could/should be
improved.

(1) we currently use script_require_ports() and script_require_udp_ports();
I'm not sure what the second does (it's not documented in
nasl_guide.tex!) but they should really be symmetric (and I would
really prefer to have script_require_tcp_ports() to be more explicit)

(2) the ports to scan can only be specified via the single port_range
configuration parameter; either there should be one parameter per
protocol or Nessus should support a syntax close to the one of Nmap:

When scanning both TCP and UDP ports, you can spec
ify a particular protocol by preceding the port
numbers by "T:" or "U:". The qualifier lasts until
you specify another qualifier. For example, the
argument "-p U:53,111,137,T:21-25,80,139,8080"
would scan UDP ports 53,111,and 137, as well as the
listed TCP ports.

the GUI would probably be more natural with one port range box per
protocol (with maybe a checkbox to specify if the protocol should
be scanned or not) but I have no strong opinion on this

(3) the result XML file of course needs to match what is done
elsewhere: it must reflect which protocols and ports have been
scanned

(4) finally, Nessus has a nice, lightweight TCP port scanner (SYN
Scan) but no UDP port scanner; users must have and use Nmap for
UDP port scans; it would be nice to add a lightweight builtin UDP
scanner

I hope these suggestions make sense...

Thanks for your attention,
__________________________________________________________
Lionel Cons http://cern.ch/lionel.cons
CERN http://www.cern.ch

Re: Port Specification in Nessus [ In reply to ]

deraison at nessus

Jun 18, 2004, 5:47 AM

Post #2 of 3 (1677 views)

Permalink

On Fri, Jun 18, 2004 at 11:57:39AM +0200, Lionel CONS wrote:
> (1) we currently use script_require_ports() and script_require_udp_ports();
> I'm not sure what the second does (it's not documented in
> nasl_guide.tex!) but they should really be symmetric (and I would
> really prefer to have script_require_tcp_ports() to be more explicit)

UDP scanning is such an unreliable technology that
script_require_udp_ports() should simply disappear.

>
> (2) the ports to scan can only be specified via the single port_range
> configuration parameter; either there should be one parameter per
> protocol or Nessus should support a syntax close to the one of Nmap:
[..]
> the GUI would probably be more natural with one port range box per
> protocol (with maybe a checkbox to specify if the protocol should
> be scanned or not) but I have no strong opinion on this

We support this syntax if you use Nmap. Once again, the problem is that
UDP scanning is too unreliable to be used seriously, so why bother
having a nice GUI which will make more people want to use UDP port scans
whereas it does not work ?

> (4) finally, Nessus has a nice, lightweight TCP port scanner (SYN
> Scan) but no UDP port scanner; users must have and use Nmap for
> UDP port scans; it would be nice to add a lightweight builtin UDP
> scanner

UDP port scan is simply unreliable. Why ? Because you send a packet to
the remote UDP port, and if you get no ICMP-unreach message in return,
you'll assume that the port is open. That simply does not scale - if you
have a firewall on the way which blocks only a few ports (say, 31337),
then your portscanner will proudly tell you that port 31337 is open no
matter what. If a firewall block ICMP unreach message, the scanner will
consider that all scanned ports are open. Many OSes do a rate-limitation
on the ICMP errors (Solaris comes to mind, but I think FreeBSD started
to implent it as well), which of course alters the result of the scan.
ICMP unreach messages also get lost on the way, and so on.

I prefer to develop a set of application-level probes (which will
generate real replies from the remote port), than just a UDP port
scanner.

-- Renaud

Re: Port Specification in Nessus [ In reply to ]

rich at westpoint

Jun 18, 2004, 5:54 AM

Post #3 of 3 (1672 views)

Permalink

Renaud Deraison wrote:

> I prefer to develop a set of application-level probes (which will
> generate real replies from the remote port), than just a UDP port
> scanner.

Perhaps these could be hidden behind an API that made it look similar
to the TCP scan? I don't know if it's worth the bother, but it could
probably be done fairly easily by pulling the results for a particular
UDP port from the knowledge base (assuming the application level probes
were run fairly early in the tests).

Cheers

Rich.