(Cc'ing nessus-list, it could be of interests from other ppl).
George A. Theall escribió:
>> - you should check 3.2.1 Windows version and the "remote host dead"
>> problem. In my opinion, it's *serious* (I had to downgrade).
>
> Renaud is looking into it.
Looking to hear an official response. I'm curious to know what the problem is.
>> - I don't understand why the diferent ping probes (tcp, icmp, etc) are
>> AND'ed instead of OR'ed.
>
> Looking at the plugin further, the answer I gave was not quite correct -
> it will mark a host as alive and exit if one of the checks succeeds. The
This sounds logical to me: a logical "OR". You scared me when you told the
behaviour was an AND (inmediately I stripped "icmp" from my config ;-)).
> exception is if you enable an arp ping and the target is on the same
> network segment as the Nessus server -- then the plugin marks the host
> as dead or alive based on the result and exits without trying any of the
> other checks.
Also very reasonable. I only can think of one (*very* strange) scenario
where it would fail: one with all arp being filtered, and hosts using fixed
MAC file (/etc/ethers) to "resolve" IP to MAC addreses. In practice, I've
never found that.
>> - it's also unclear where to find the list of ports used in tcp ping.
>> Why don't you include them in "ping remote host" advanced tab? (or at
>> least some kind of reference).
>
> There is a field for them in that section - "TCP ping destination
> port(s)". You can specify a single port, a list of ports, or the
> keywords "built-in" or "extended". And the specific ports for the two
> keywords can be found in the plugin itself, at the top.
>
>> It should be clearly stated that "port scanner range" in options tab
>> is different for the tcp ping ports used.
So you have two boxes where you can enter ports:
Options -> Port scanner range
Advanced -> Ping remote host -> TCP ping destination ports
I see two problems:
1) From a user's perspective, I shouldn't need to look at plug-in source to
determine what "built-in" or "extended" means. Indeed, I wouldn't have
known about the second keyword if you don't tell it to me.
2) If I set a broader "port scanner range" than "TCP ping destination
ports", there will be cases (false negative) where Nessus will mark a host
as dead while in fact it should have been detected as alive by the normal
port-scan (using port scanner range). It's easier to see with one example:
if I suspect that a host may be using strange ports to hide services
(security by obscurity, yes...), I'll set port scanner range to 1-65535 and
I *will* expect that Nessus could detect any of them. Nevertheless, the
reality is that "ping plug-in" will stop it! (it will mark the host as dead
and normal port-scanning phase will not even begin!). You're loosing accuracy.
The other case is when a host has a mix of "well-known" ports and "hidden"
ports. In this case, the current behaviour of Nessus is good (and faster),
because the ping plug-in will mark the host as alive (due to the 1st group
of ports) and the normal scan phase will detect the 2nd group (hidden ports).
In both cases, there are ports which are being scanned twice!!!
My suggestions:
- problem #1 is easy to solve: let's show only the list of ports, not any
keyword. In this way, it's clear and clean, and you can even add/remove
ports easily to/from the list (now you'd have to create an entire new list
from scratch or see comments on ping plug-in's source and then copy&paste).
- problem #2 is not trivial. The more obvious solution would be that TCP
ping should compare "tcp ping ports" with "port scanner range", and should
add missing ports. But in this case, when I set up 1-65535 port scanner
range, you'll be duplicating scanning time (ping plug-in and scanner phase
will scan the full 65535 ports) and that's not desirable. Perhaps I'd apply
the former sugestion *optionally*. So let's:
+ Add a checkbox "Complete missing TCP-Ping ports (secure but slower)".
+ Add a checkbox near "port scanner range" letting "disable ping
plug-in
at all".
+ Last but not least, I'd *document* what the exact used algorithm is
and
what do different checks mean.
Think about how "Nmap" solves it:
+ ping is enabled by default but you can use a "-P0" to disable it
+ by default, Nmap sends an ICMP echo request and a TCP ACK packet to
port 80.
+ if you mark -p1-65535, then all ports are scanned.
So if I use "-p1-65535 -P0", I know that accuracy will be probably
maximum... (and the full-scan is only performed once).
>> I also don't understand why Tenable doesn't want to let include Nessus
>> in a live-CD distro like Backtrack. It's getting probably a bad image,
>> knowing that Nessus was born as a community effort (different people
>> writing plug-ins). Why is backtrack incompatible with Tenable's
>> business model?
>
> I'm not involved in these sorts of business decisions.
I suppose this is a FAQ but anyway it would be nice if someone at Tenable
could answer it ;-)
--
Saludos,
-Roman
PGP Fingerprint:
09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742
[Key ID: 0xEAD56742. Available at KeyServ]
_______________________________________________
Nessus mailing list
[email protected]
http://mail.nessus.org/mailman/listinfo/nessus
