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. Have a look at the Website or at the rel
From the Description: ----snip---- tcptraceroute is a traceroute implementation using TCP packets.
The more traditional traceroute(8) sends out either UDP or ICMP ECHO packets with a TTL of one, and increments the TTL until the destination has been reached. By printing the gateways that generate ICMP time exceeded messages along the way, it is able to determine the path packets are taking to reach the destination.
The problem is that with the widespread use of firewalls on the modern Internet, many of the packets that traceroute(8) sends out end up being filtered, making it impossible to completely trace the path to the destination. However, in many cases, these firewalls will permit inbound TCP packets to specific ports that hosts sitting behind the firewall are listening for connections on. By sending out TCP SYN packets instead of UDP or ICMP ECHO packets, tcptraceroute is able to bypass the most common firewall filters.
---snap----
if you want to see the difference between the "traditional" trace, try a trace for pages.ebay.de with unix/windows and tcptraceroute - this is a typical www-site behind a firewall.
"normal" trace:
traceroute pages.ebay.de:
2 217.5.209.2 (217.5.209.2) 0.563 ms 0.649 ms 0.471 ms
3 m-ea1.m.de.net.dtag.de (62.154.10.157) 0.769 ms 0.517 ms 0.414 ms
4 paix-gw12.sfo.us.net.dtag.de (62.154.5.245) 174.288 ms 174.391 ms 178.049 ms
5 * * *
6 * * *
etc etc.
tcptraceroute pages.ebay.de 80
2 217.5.209.2 (217.5.209.2) 0.413 ms 0.482 ms 0.391 ms
3 m-ea1.m.de.net.dtag.de (62.154.10.157) 0.462 ms 0.476 ms 0.577 ms
4 paix-gw12.SFO.US.net.DTAG.DE (62.154.5.245) 174.570 ms 173.888 ms 173.887 ms
5 62.159.124.58 (62.159.124.58) 175.358 ms 175.000 ms 176.118 ms
6 66.135.207.54 (66.135.207.54) 176.008 ms 177.131 ms 180.360 ms
7 10.6.1.30 (10.6.1.30) 179.083 ms 173.245 ms 175.367 ms
8 10.8.1.106 (10.8.1.106) 173.462 ms 173.378 ms 173.474 ms
9 * * *
10 pages.ebay.de (66.135.208.85) [open] 173.799 ms 175.331 ms 173.942 ms
See the difference?
Many firewalled hosts respond with natted adresses or at least more detailed routing when queried with tcptraceroute.
For more examples see http://michael.toren.net/code/tcptraceroute/examples.txt
Besides implementing a TCP-Trace as plugin I'm not happy with the behaviour of traceroute.nasl (plugin #10287).
I looked a the nasl-code meanwhile (should have done that before!).
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
it doesn't tell wich trace was successful
it has no port-management for tcptrace.Or did I get the nasl-code wrong?
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
sorry to say that this goes beyond my nasl-capabilities.
--
Thomas Springer TUEV ICS - IT-Security
-- Nach mir der Synflood. _______________________________________________ Nessus mailing list [EMAIL PROTECTED] http://mail.nessus.org/mailman/listinfo/nessus
