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

[Martin T <m4rtntns () gmail com>]

Demetris,
if I'll execute nmap traceroute with "--packet-trace" option, results
are following:

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

Starting Nmap 5.00 ( http://nmap.org ) at 2011-03-03 02:22 EET
SENT (0.0570s) ICMP 192.168.1.68 > 217.146.69.201 echo request
(type=8/code=0) ttl=46 id=50887 iplen=28
SENT (0.0570s) TCP 192.168.1.68:44611 > 217.146.69.201:443 S ttl=57
id=47830 iplen=44  seq=681219199 win=2048 <mss 1460>
SENT (0.0570s) TCP 192.168.1.68:44611 > 217.146.69.201:80 A ttl=56
id=37497 iplen=40  seq=681219199 win=1024 ack=3130554079
SENT (0.0580s) ICMP 192.168.1.68 > 217.146.69.201 Timestamp request
(type=13/code=0) ttl=37 id=39312 iplen=40
RCVD (0.0790s) ICMP 217.146.69.201 > 192.168.1.68 echo reply
(type=0/code=0) ttl=57 id=42928 iplen=28
SENT (0.1940s) ICMP 192.168.1.68 > 217.146.69.201 echo request
(type=8/code=0) ttl=255 id=0 iplen=28
RCVD (0.1940s) ICMP 192.168.1.68 > 217.146.69.201 echo request
(type=8/code=0) ttl=255 id=50505 iplen=28
RCVD (0.2150s) ICMP 217.146.69.201 > 192.168.1.68 echo reply
(type=0/code=0) ttl=57 id=42929 iplen=28
SENT (0.2150s) ICMP 192.168.1.68 > 217.146.69.201 echo request
(type=8/code=0) ttl=8 id=0 iplen=28
RCVD (0.2150s) ICMP 192.168.1.68 > 217.146.69.201 echo request
(type=8/code=0) ttl=8 id=50506 iplen=28
SENT (0.2150s) ICMP 192.168.1.68 > 217.146.69.201 echo request
(type=8/code=0) ttl=9 id=0 iplen=28
RCVD (0.2150s) ICMP 192.168.1.68 > 217.146.69.201 echo request
(type=8/code=0) ttl=9 id=50507 iplen=28
RCVD (0.2350s) ICMP 217.146.69.201 > 192.168.1.68 echo reply
(type=0/code=0) ttl=57 id=42930 iplen=28
SENT (0.2360s) ICMP 192.168.1.68 > 217.146.69.201 echo request
(type=8/code=0) ttl=7 id=0 iplen=28
RCVD (0.2360s) ICMP 192.168.1.68 > 217.146.69.201 echo request
(type=8/code=0) ttl=7 id=50508 iplen=28
SENT (0.2360s) ICMP 192.168.1.68 > 217.146.69.201 echo request
(type=8/code=0) ttl=6 id=0 iplen=28
RCVD (0.2360s) ICMP 192.168.1.68 > 217.146.69.201 echo request
(type=8/code=0) ttl=6 id=50509 iplen=28
RCVD (0.2360s) ICMP 217.146.69.201 > 192.168.1.68 echo reply
(type=0/code=0) ttl=57 id=42931 iplen=28
SENT (0.2360s) ICMP 192.168.1.68 > 217.146.69.201 echo request
(type=8/code=0) ttl=5 id=0 iplen=28
RCVD (0.2360s) ICMP 192.168.1.68 > 217.146.69.201 echo request
(type=8/code=0) ttl=5 id=50510 iplen=28
RCVD (0.2570s) ICMP 212.47.215.26 > 192.168.1.68 TTL=0 during transit
(type=11/code=0) ttl=58 id=55566 iplen=56
SENT (0.2570s) ICMP 192.168.1.68 > 217.146.69.201 echo request
(type=8/code=0) ttl=4 id=0 iplen=28
RCVD (0.2570s) ICMP 192.168.1.68 > 217.146.69.201 echo request
(type=8/code=0) ttl=4 id=50511 iplen=28
RCVD (0.2590s) ICMP 212.47.201.86 > 192.168.1.68 TTL=0 during transit
(type=11/code=0) ttl=249 id=0 iplen=56
SENT (0.2590s) ICMP 192.168.1.68 > 217.146.69.201 echo request
(type=8/code=0) ttl=3 id=0 iplen=28
RCVD (0.2590s) ICMP 192.168.1.68 > 217.146.69.201 echo request
(type=8/code=0) ttl=3 id=50512 iplen=28
RCVD (0.2590s) ICMP 195.250.170.22 > 192.168.1.68 TTL=0 during transit
(type=11/code=0) ttl=250 id=0 iplen=56
SENT (0.2590s) ICMP 192.168.1.68 > 217.146.69.201 echo request
(type=8/code=0) ttl=2 id=0 iplen=28
RCVD (0.2590s) ICMP 192.168.1.68 > 217.146.69.201 echo request
(type=8/code=0) ttl=2 id=50513 iplen=28
RCVD (0.2780s) ICMP 194.126.123.94 > 192.168.1.68 TTL=0 during transit
(type=11/code=0) ttl=251 id=0 iplen=56
SENT (0.2780s) ICMP 192.168.1.68 > 217.146.69.201 echo request
(type=8/code=0) ttl=1 id=0 iplen=28
RCVD (0.2780s) ICMP 192.168.1.68 > 217.146.69.201 echo request
(type=8/code=0) ttl=1 id=50514 iplen=28
RCVD (0.2800s) ICMP 90.190.134.144 > 192.168.1.68 TTL=0 during transit
(type=11/code=0) ttl=253 id=42175 iplen=168
RCVD (0.2810s) ICMP 90.191.144.2 > 192.168.1.68 TTL=0 during transit
(type=11/code=0) ttl=253 id=0 iplen=56
RCVD (0.3600s) ICMP 192.168.1.254 > 192.168.1.68 TTL=0 during transit
(type=11/code=0) ttl=64 id=1033 iplen=72
Host 217.146.69.201 is up, received echo-reply (0.021s latency).

TRACEROUTE (using proto 1/icmp)
HOP RTT   ADDRESS
1   81.66 192.168.1.254
2   21.70 90.191.144.2
3   21.46 90.190.134.144
4   21.07 194.126.123.94
5   22.80 195.250.170.22
6   23.00 212.47.201.86
7   21.61 212.47.215.26
8   20.24 217.146.69.201

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

..as you can see, if we don't count in nmap "ping"(-sP) which is
addressed directly to end-host, there is no other traffic than ICMP.

However, traceroute(1) output is following:

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  35.658 ms
 2  90.191.144.2  22.341 ms
 3  *
 4  *
 5  *
 6  *
 7  217.146.69.201  20.985 ms
root@martin-desktop:~#

..but the techniques are pretty much similar(ICMP while playing with
the TTL value):

root@martin-desktop:~# tcpdump -n -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
02:30:40.248760 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 24647, seq 1, length 40
02:30:40.248906 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 24647, seq 2, length 40
02:30:40.248944 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 24647, seq 3, length 40
02:30:40.248977 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 24647, seq 4, length 40
02:30:40.249009 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 24647, seq 5, length 40
02:30:40.249053 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 24647, seq 6, length 40
02:30:40.249087 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 24647, seq 7, length 40
02:30:40.249118 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 24647, seq 8, length 40
02:30:40.249149 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 24647, seq 9, length 40
02:30:40.249181 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 24647, seq 10, length 40
02:30:40.249221 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 24647, seq 11, length 40
02:30:40.249252 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 24647, seq 12, length 40
02:30:40.249291 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 24647, seq 13, length 40
02:30:40.249324 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 24647, seq 14, length 40
02:30:40.249355 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 24647, seq 15, length 40
02:30:40.249386 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 24647, seq 16, length 40
02:30:40.271245 IP 90.191.144.2 > 192.168.1.68: ICMP time exceeded
in-transit, length 36
02:30:40.271391 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 24647, seq 17, length 40
02:30:40.284411 IP 192.168.1.254 > 192.168.1.68: ICMP time exceeded
in-transit, length 52
02:30:40.285295 IP 192.168.1.68 > 217.146.69.201: ICMP echo request,
id 24647, seq 18, length 40
02:30:40.292372 IP 217.146.69.201 > 192.168.1.68: ICMP echo reply, id
24647, seq 17, length 40
02:30:40.305921 IP 217.146.69.201 > 192.168.1.68: ICMP echo reply, id
24647, seq 18, length 40
^C
22 packets captured
22 packets received by filter
0 packets dropped by kernel
root@martin-desktop:~#


Why is nmap traceroute able to detect all the hops while traceroute(1)
is not? I mean for some reason, less nodes send back the "ICMP time
exceeded in-transit" message when using traceroute(1) then they do
when one uses nmap.


regards,
martin


2011/3/2 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
------------------------------------------------------------------------