RE: difference between "traceroute -I <host>" and "nmap -sP --traceroute <host>" ?

["Demetris Papapetrou" <dpapapetrou () internalaudit gov cy>]

Dear Martin,

I think that the reason you have a hard time identifying the problem behind
your traceroutes is because you instruct tcpdump to display only ICMP
traffic hence you don't get the full picture.

Try tcpdump without the icmp switch or better yet use the --packet-trace
option in your NMAP scan. You can also play with different NMAP scan options
during your traceroute attempts (e.g. -sS, -sA, etc). Perhaps, the
intermediate hosts do not reply to ICMP echo requests but to TCP SYN packets
instead. Using only the information that you provided it is hard to identify
the source of the problem.

Just to let you know, using the -sP (ping scan) option in NMAP doesn't send
only ICMP echo requests. It sends an ICMP echo requests, ICMP timestamp
requests, TCP SYN packets to port 443 and TCP ACK packets to port 80 of the
target host.


Demetris Papapetrou


-----Original Message-----
From: listbounce () securityfocus com [mailto:listbounce () securityfocus com] On
Behalf Of Martin T
Sent: Saturday, February 26, 2011 9:04 PM
To: security-basics () securityfocus com
Subject: difference between "traceroute -I <host>" and "nmap -sP
--traceroute <host>" ?

Both "traceroute -I <host>" and "nmap -sP --traceroute <host>" make
use of "ICMP echo request" with changing the TTL value and wait for
"ICMP time-to-live exceeded"(only fundamental difference should be the
smarter scanning technique of nmap, which makes it a lot faster)
messages. However, "nmap -sP --traceroute <host>" is able to get "ICMP
time-to-live exceeded" from more hosts where traditional "traceroute
-I <host>" prints asterisk marks.

Please take a look at the following examples. If I execute nmap traceroute:

root@martin-desktop:~# nmap -sP --traceroute --reason -n 217.146.69.201

Starting Nmap 5.00 ( http://nmap.org ) at 2011-02-26 20:55 EET
Host 217.146.69.201 is up, received echo-reply (0.021s latency).

TRACEROUTE (using proto 1/icmp)
HOP RTT   ADDRESS
1   13.14 192.168.1.254
2   20.89 90.191.144.2
3   20.30 90.190.134.144
4   20.88 194.126.123.94
5   23.02 195.250.170.22
6   22.28 212.47.201.86
7   26.21 212.47.215.26
8   21.39 217.146.69.201

Nmap done: 1 IP address (1 host up) scanned in 0.34 seconds
root@martin-desktop:~#


.. I tcpdump following data:

root@martin-desktop:/# tcpdump -n -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
20:55:19.083117 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 25024, seq 0, length 8
20:55:19.083185 IP 192.168.1.68 > 217.146.69.201: ICMP time stamp
query id 54676 seq 0, length 20
20:55:19.104431 IP 217.146.69.201 > 192.168.1.68: ICMP echo reply, id
25024, seq 0, length 8
20:55:19.214969 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 40755, seq 42096, length 8
20:55:19.235985 IP 217.146.69.201 > 192.168.1.68: ICMP echo reply, id
40755, seq 42096, length 8
20:55:19.236053 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 40756, seq 39168, length 8
20:55:19.236087 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 40757, seq 57369, length 8
20:55:19.257437 IP 217.146.69.201 > 192.168.1.68: ICMP echo reply, id
40756, seq 39168, length 8
20:55:19.257487 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 40758, seq 2207, length 8
20:55:19.257525 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 40759, seq 40080, length 8
20:55:19.258021 IP 217.146.69.201 > 192.168.1.68: ICMP echo reply, id
40757, seq 57369, length 8
20:55:19.258060 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 40760, seq 16055, length 8
20:55:19.279807 IP 212.47.201.86 > 192.168.1.68: ICMP time exceeded
in-transit, length 36
20:55:19.279876 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 40761, seq 65517, length 8
20:55:19.281076 IP 195.250.170.22 > 192.168.1.68: ICMP time exceeded
in-transit, length 36
20:55:19.281176 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 40762, seq 60216, length 8
20:55:19.283693 IP 212.47.215.26 > 192.168.1.68: ICMP time exceeded
in-transit, length 36
20:55:19.283748 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 40763, seq 61356, length 8
20:55:19.300756 IP 194.126.123.94 > 192.168.1.68: ICMP time exceeded
in-transit, length 36
20:55:19.300848 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 40764, seq 27567, length 8
20:55:19.301457 IP 90.190.134.144 > 192.168.1.68: ICMP time exceeded
in-transit, length 148
20:55:19.304630 IP 90.191.144.2 > 192.168.1.68: ICMP time exceeded
in-transit, length 36
20:55:19.313981 IP 192.168.1.254 > 192.168.1.68: ICMP time exceeded
in-transit, length 52
^C
23 packets captured
23 packets received by filter
0 packets dropped by kernel
root@martin-desktop:/#


As you can see, with nmap route is constructed using "ICMP time
exceeded" messages from hosts. Nmap is able to get "ICMP time
exceeded" from all the hosts on the way.
If I execute "traceroute -I" towards the same host:

root@martin-desktop:~# traceroute -I -q 1 -n 217.146.69.201
traceroute to 217.146.69.201 (217.146.69.201), 30 hops max, 60 byte packets
 1  192.168.1.254  60.820 ms
 2  90.191.144.2  21.551 ms
 3  *
 4  *
 5  *
 6  *
 7  217.146.69.201  21.508 ms
root@martin-desktop:~#

..I do not receive "ICMP time exceeded" response from every host as I
did with nmap:

root@martin-desktop:/# tcpdump -n -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
20:56:19.458241 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 15327, seq 1, length 40
20:56:19.458271 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 15327, seq 2, length 40
20:56:19.458282 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 15327, seq 3, length 40
20:56:19.458294 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 15327, seq 4, length 40
20:56:19.458304 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 15327, seq 5, length 40
20:56:19.458314 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 15327, seq 6, length 40
20:56:19.458325 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 15327, seq 7, length 40
20:56:19.458335 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 15327, seq 8, length 40
20:56:19.458345 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 15327, seq 9, length 40
20:56:19.458354 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 15327, seq 10, length 40
20:56:19.458362 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 15327, seq 11, length 40
20:56:19.458370 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 15327, seq 12, length 40
20:56:19.458379 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 15327, seq 13, length 40
20:56:19.458387 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 15327, seq 14, length 40
20:56:19.458396 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 15327, seq 15, length 40
20:56:19.458405 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 15327, seq 16, length 40
20:56:19.479820 IP 90.191.144.2 > 192.168.1.68: ICMP time exceeded
in-transit, length 36
20:56:19.479975 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 15327, seq 17, length 40
20:56:19.501474 IP 217.146.69.201 > 192.168.1.68: ICMP echo reply, id
15327, seq 17, length 40
20:56:19.519052 IP 192.168.1.254 > 192.168.1.68: ICMP time exceeded
in-transit, length 52
^C
20 packets captured
20 packets received by filter
0 packets dropped by kernel
root@martin-desktop:/#


What might cause such behavior?

regards,
martin

------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL
certificate.  We look at how SSL works, how it benefits your company and how
your customers can tell if a site is secure. You will find out how to test,
purchase, install and use a thawte Digital Certificate on your Apache web
server. Throughout, best practices for set-up are highlighted to help you
ensure efficient ongoing management of your encryption keys and digital
certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727
d1
------------------------------------------------------------------------


------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, how 
it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, 
install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are 
highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------