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

Reply via email to