Home page logo
/

basics logo Security Basics mailing list archives

Re: difference between "traceroute -I <host>" and "nmap -sP --traceroute <host>" ?
From: Martin T <m4rtntns () gmail com>
Date: Thu, 3 Mar 2011 02:37:03 +0200

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
------------------------------------------------------------------------


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]