Re: Questions: nmap, nessus unreliability, setting up a packet capture box, using Impacket
From: Renaud Deraison (deraison_at_nessus.org)
Date: 04/27/04
- Previous message: roberto unbaggi: "asp restriction configuration weaknesses"
- In reply to: Anders Thulin: "Re: Questions: nmap, nessus unreliability, setting up a packet capture box, using Impacket"
- Next in thread: James Davis: "Re: Questions: nmap, nessus unreliability, setting up a packet capture box, using Impacket"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 27 Apr 2004 13:22:38 -0400 To: pen-test@securityfocus.com
On Tue, Apr 27, 2004 at 08:49:09AM +0200, Anders Thulin wrote:
> nessus -- I don't trust it. It may provide leads, but each needs to be
> verified
> independently. Haven't checked it recently, but I remember that I found
> that testing
> vulnerabilities in ONC RPC services trusted the portmapper data entirely,
> and
> didn't even check that the identified ports did in fact run the announced
> services,
> and that was below the reporting quality I want. (That can be useful for
> assessing
> a vulnerability assesment, by the way ... let portmapper announce rex on
> some port,
> but run a web server on it instead.)
In that particular case, Nessus would identify that a web service is
running on the port _and_ would tell you that the portmapper announced rex.
The problem with enumeration plugins like the ONC RPC or DCE RPC ones,
is the question of what people really want to see : some will say that
what they are interested in is to know which RPC service is running on
which port - and that it does not matter if you can actually reach the
port or not (and for UDP services it would actually be quite easy to
reach the port, as many firewalls are configured to let in incoming UDP
traffic with a source port set to 53). Of course, if port 135/111 is
reachable from the network, you have issues.
Other people are asking to see only the services which are really
reachable, which is not necessarily true from the point of view of
the scanner.
In the end, it's very difficult to make both groups happy, and adding an
option in the config would probably solve the issue on a rethorical point
of view, but in practice would add more complexity.
So in our case, we take the (ONC|DCE) RPC outputs, and we just tell the
user that this is the service advertised.
That being said, I will probably add some code to "double check"
advertised services, though, as it should not be too intrusive, and I
think you for your input.
If you or any other person on this list have any gripe with Nessus, once
again feel free to let me know and I'll try to fix it. Nessus is not
written in stone and can evolve quite rapidly.
-- Renaud
-- Renaud Deraison http://www.nessus.org ------------------------------------------------------------------------------ Ethical Hacking at the InfoSec Institute. Mention this ad and get $545 off any course! All of our class sizes are guaranteed to be 10 students or less to facilitate one-on-one interaction with one of our expert instructors. Attend a course taught by an expert instructor with years of in-the-field pen testing experience in our state of the art hacking lab. Master the skills of an Ethical Hacker to better assess the security of your organization. Visit us at: http://www.infosecinstitute.com/courses/ethical_hacking_training.html -------------------------------------------------------------------------------
- Previous message: roberto unbaggi: "asp restriction configuration weaknesses"
- In reply to: Anders Thulin: "Re: Questions: nmap, nessus unreliability, setting up a packet capture box, using Impacket"
- Next in thread: James Davis: "Re: Questions: nmap, nessus unreliability, setting up a packet capture box, using Impacket"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
