On Wed, 20 Sep 2006, Michel Arboi wrote:
On Wed Sep 20 2006 at 01:25, A User wrote:
Is there a way to enable "find_service" to use UDP results?
No, but external_svc_ident.nasl can do that.
Ok - thanks.
There are devices that people may not be allowed local accounts as
this can be intrusive
A find_service_udp would be much more intrusive.
But again - what about those devices where we can't get local accounts?
Based on those comments
Which are untrue, because you forgot that UDP standard ports are
tested.
Nessus is not giving a true picture
What is a "true" picture?
An idea of what services are being provided by a device and if possible,
understand the vulnerabilities associated with it. There are devices that
run on non-standard UDP ports and it's a little narrow minded to ignore
these in a complete review.
and personally I find it frustrating not being able to use one piece of
software to perform a complete and thorough review.
Can you afford to run nmap -sU -sV for days to get this true picture?
netstat -p would give it instantly.
For a complete review that needs to be performed where I technically
cannot or am prohibited by the system admin to do this, then yes! It's
simply not acceptable to not do this where a complete remote only review
is required.
It should be possible for those users who properly understand the
limitations of certain OSes / TCP/IP stacks to be able to get a full
picture.
If such a find_service_udp were written, it would be disabled if
(safe_checks || ! thorough_checks)
As most people are running in safe checks and do not set "thorough
tests", this would be useless for 99% of users.
Right, but at least the gives those technically minded users a *choice*
which is what this is really about. People would like the *option* to do
this in scenarios where they have have no choice but to do this.
Otherwise you end up making an unreasonable compromise between speed
and accuracy.
You have to.
For those who which to fire a quick vulnerability scan off yes, I agree.
But as per my previous comment, give us the option with the appropriate
warnings.
Cheers,
A.
----
_______________________________________________
Nessus mailing list
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus
