On Tue, Oct 26, 2004 at 04:37:47PM +0200, Thomas Springer wrote:
> Renaud,
>
> first of all, thanks for Nessus as it is - I like it and I use it.
>
> >All kind of traceroute (tcp or udp) is an icmp traceroute in the end -
> >the very basis of traceroute is to receive an ICMP unreach message from
> >the gateways on the way. So if a firewall on the way decides to block all
>
> TCP-Traceroute is different! It uses TCP-SYN-Packets an doesn't rely
> on ICMP unreachable. Therefore it gets often behind firewalls that
> Block ICMP-Packets.
Errr.... According to the source code (that I admit having looked at
very quickly) it seems to send a TCP probe, but still expects an ICMP
unreach in return.
Run tcpdump while the tcptraceroute is going on :
# tcpdump -ln 'icmp and ( icmp[0] = 3 or icmp[0] = 11)'
You'll see the time exceeded in transit error messages popping up.
[...]
> See the difference?
> Many firewalled hosts respond with natted adresses or at least more
> detailed routing when queried with tcptraceroute.
Yes, because the probe can go further since it's TCP based. However the
reply is still ICMP based.
Don't get me wrong - TCP probes are definitely better than UDP probes.
> After having a look at the plugin i'm even more confused:
> It does tcp, udp and icmp, but
> it stops after the first successful trace
Yes. Because they're in order of likely success.
> it doesn't tell wich trace was successful
This is correct. We could improve that.
> it has no port-management for tcptrace.
It uses get_host_open_port() which returns a port which is _known_ to be
open on the remote host. If there's no known open port, we fall back to
port 80.
> This seems unperfect.
> what i'd love to see would be
> 1) the result of an (even incomplete) icmp-trace, labeled as ICMP-Trace
> 2) the result of a tcp-trace to at least one open port on the host
> (based on the portscan-results rather than the actual fixed
> "if(!dport)dport = 80;", labeled as "tcp-trace to port xx".
> 3) the result of a udp-trace to at least one open port on the (based
> on portscan-results oder fixed to dns/ntp/snmp/iskamp) labeled as such
> 4) finally a notification if the traces differ
So you want 3 traceroutes instead of one. It's not something I'm really
interested in doing but if someone volunteers and produces a plugin
whose execution time is still reasonable, I'll be happy to commit it.
-- Renaud
_______________________________________________
Nessus mailing list
[EMAIL PROTECTED]
http://mail.nessus.org/mailman/listinfo/nessus