thomas springer on 30 Nov 2004 16:58:03 -0000


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [tcptra-dev] tcpdump showing more than tcptraceroute 

Michael,

you're totally right!

Michael C. Toren wrote:

That's interesting.  Can you try the experiment again, but this time giving
tcptraceroute the "-d" (debug) option?  From my point of view, I can also
observe that the next to the last hop times out when tracing to ebay.com,
however with debugging enabled I see:


same here..

tcptraceroute pages.ebay.de -d
-- works until here...
debug: Sent probe 3 of 3 for hop 7, IP ID 62216, source port 35073, SYN
debug: received 56 byte IP packet from pcap_next()
debug: Received icmp packet
debug: displayed hop
  176.553 ms

-- this doesnt show without -d
debug: Sent probe 1 of 3 for hop 8, IP ID 40268, source port 35074, SYN
debug: received 56 byte IP packet from pcap_next()
debug: Received icmp packet
debug: Ignoring ICMP packet with incorrect quoted destination (10.6.35.66, not 66.135.192.85)
debug: select() timeout
debug: timeout
debug: displayed hop
8 *

further investigation:
tcptraceroute pages.ebay.de --track-port -q 100 -f 9 -d
(just show the "questionable" host...
parallel: tethereal -i eth1 proto ICMP

)
Tracing the path to pages.ebay.de (66.135.208.85) on TCP port 80, 30 hops max
debug: Generating a new batch of 512 IP ID's
debug: Sent probe 1 of 100 for hop 9, IP ID 3210, source port 36119, SYN
debug: received 56 byte IP packet from pcap_next()
debug: Received icmp packet
debug: Ignoring ICMP packet with incorrect quoted destination (10.8.35.74, not 66.135.208.85)
debug: select() timeout
debug: select() timeout
debug: timeout
debug: displayed hop
9 *

debug: Sent probe 2 of 100 for hop 9, IP ID 62990, source port 36120, SYN
debug: received 56 byte IP packet from pcap_next()
debug: Received icmp packet
debug: Ignoring ICMP packet with incorrect quoted destination (10.8.35.77, not 66.135.208.85)
debug: select() timeout
debug: select() timeout
debug: timeout
debug: displayed hop
*

debug: Sent probe 3 of 100 for hop 9, IP ID 47383, source port 36121, SYN
debug: received 56 byte IP packet from pcap_next()
debug: Received icmp packet
debug: Ignoring ICMP packet with incorrect quoted destination (10.8.35.73, not 66.135.208.85)

the ip-adresses change here - this should be a loadbalancer, located on this internal ip:

tethereal -i eth1 proto ICMP
Capturing on eth1
  0.000000  10.8.105.14 -> xx.xx.192.133 ICMP Time-to-live exceeded
  3.010781  10.8.105.14 -> xx.xx.192.133 ICMP Time-to-live exceeded
  6.020783  10.8.105.14 -> xx.xx.192.133 ICMP Time-to-live exceeded
  9.029966  10.8.105.14 -> xx.xx.192.133 ICMP Time-to-live exceeded
 12.040306  10.8.105.14 -> xx.xx.192.133 ICMP Time-to-live exceeded
 15.050194  10.8.105.14 -> xx.xx.192.133 ICMP Time-to-live exceeded
 18.060156  10.8.105.14 -> xx.xx.192.133 ICMP Time-to-live exceeded
 21.070196  10.8.105.14 -> xx.xx.192.133 ICMP Time-to-live exceeded
 24.080000  10.8.105.14 -> xx.xx.192.133 ICMP Time-to-live exceeded
 27.090331  10.8.105.14 -> xx.xx.192.133 ICMP Time-to-live exceeded
 30.100496  10.8.105.14 -> xx.xx.192.133 ICMP Time-to-live exceeded
 33.110345  10.8.105.14 -> xx.xx.192.133 ICMP Time-to-live exceeded
 36.120673  10.8.105.14 -> xx.xx.192.133 ICMP Time-to-live exceeded
 39.130185  10.8.105.14 -> xx.xx.192.133 ICMP Time-to-live exceeded
 58.453225  10.8.105.14 -> xx.xx.192.133 ICMP Time-to-live exceeded
 61.460979  10.8.105.14 -> xx.xx.192.133 ICMP Time-to-live exceeded
 64.470291  10.8.105.14 -> xx.xx.192.133 ICMP Time-to-live exceeded
 67.480456  10.8.105.14 -> xx.xx.192.133 ICMP Time-to-live exceeded

If I run the same test again with "--track-port" (to send each probe with a
new TCP source port) and "-q 10" (to increase the number of probes for each
hop), the IP address the ICMP packet incorrectly quotes fluctuates between
10.8.35.73, 10.8.35.74, 10.8.35.75, 10.8.35.76, and 10.8.35.77.  My guess is
that this is revealing a layer of load-balancing that may be related to NAT
in some way, which does not appear to be correctly rewriting the addresses
in the IP packet quoted by the ICMP message.


what a perfect explanation. why didn't i get to this myself??

To get to the point: that would be exactly this what I'd want tcptraceroute to do for penetration-tests: to show private ip's and load-balancers!!

tcptraceroute seems to take care for changing ip's at least partially:
tcptraceroute www.travelchannel.de (a site i know using a loadbalancer!)

[...] 7 ge0-0-0-1.gr0.tcams.nl.easynet.net (207.162.205.113) 28.047 ms 27.247 ms 29.477 ms
8 so0-3-0-0.gr0.saams.nl.easynet.net (207.162.205.94) 27.843 ms 29.197 ms 27.864 ms
9 so0-1-0-0.gr0.weham.de.easynet.net (207.162.205.46) 35.877 ms 35.766 ms 35.869 ms
10 ge0-3-0-1.br1.weham.de.easynet.net (207.162.206.101) 26.594 ms 26.584 ms 26.557 ms
11 ge0-0-0-100.br0.isham.de.easynet.net (194.64.4.230) 26.612 ms
ge0-0-0-100.br1.isham.de.easynet.net (194.64.4.229) 25.519 ms
ge0-0-0-100.br0.isham.de.easynet.net (194.64.4.230) 26.595 ms
12 vl40.as0-r0.isham.de.easynet.net (212.224.4.225) 25.302 ms 25.416 ms 25.406 ms
13 www.travelchannel.de (195.179.67.95) [open] 26.455 ms 26.474 ms 27.235 ms

See Hop 11??

Maybe it would be possible to implement this for the "private" ip's as well, i mean, besides the debug output?
Would it be possible to show the internal behaviour of sites like pages.ebay.de in a "normal" output?
- i use tcptraceroute for penetration-tests and i definitely like to surprise customers showing them their internal ips and load-balancer-infrastructures.

tom

_______________________________________________
tcptraceroute-dev mailing list
tcptraceroute-dev@netisland.net
http://lists.netisland.net/mailman/listinfo/tcptraceroute-dev