[Blake]

The traceroute tool is available on practically all Unix-like operating systems. Variants with similar functionality are also available, such as tracepath on modern Linux installations and tracert on Microsoft Windows operating systems. Windows NT-based operating systems also provide pathping, which provides similar functionality.


Read More

[SlippyG]

GSECURE: ICMP Traceroutes typically don't pull LOC information though. The article seems to be about locating IPs geographically rather than flat listing nodes in the route.



Nice article, if only it were actually possible. The headline is definately very misleading.

Firstly, what you're seeing is voluntarily supplied, theres no trick and you don't need additional software. Secondly, the router in your home does not store its location... the information you get back relates to ISP equipment location and may not be accurate, in fact - often you don't even get the same state with national ISP's.

If you're VERY lucky you might get the remote DSLAM advertising its location but that is very rare - normally it is a router somewhere above the DSLAM which may or may not even be located in the same distribution facility. As topologies change and routers are redeployed one of the very LAST things on the techs mind is pulling the Long:Lat info from a GPS and updating the config.

So no, the claim to trace 'any IP address' is false. There is no actual 'trace' beyond that supplied by traceroute and only ISP equipment will ever show up - It CANNOT locate actual subscriber endpoints (which is what most people want to use this for) and those IP's constitute the vast majority of the useable IP addressing space.

These tools are best used for impressing people who don't know any better ... family members, journalists, etc.



Having said that, heres a few ways to pull any and all available LOC info on those remote equipment IP's:


CAIDA NETGEO

Almost 10 years ago CAIDA, the Cooperative Association for Internet Data Analysis, started a project called 'NetGeo'. The idea was to create a database of IP locations (Quite a grand goal considering the maintenance prospects) they pretty much abandoned that ship... you can still use the database though:

browse: http://netgeo.caida....?target=a.b.c.d (where a.b.c.d is the IP address sought)

or visit http://www.caida.org...ilities/netgeo/


DNS LOC

Then there is the 'DNS LOC' method, where location information is stored with the DNS entry and can be queried along with the rest of the record (No tools needed, you probably already have the required DNS CLI tools installed on your chosen O.S) - This is one of the easiest ways to get the LOC information on an IP... of course, again, subscribers don't set DNS LOC, so you have to try hitting their upstream equipment instead and hope the DNS LOC info is accurate and the ISP equipment is located in the same city (Sometimes there are transparent distribution equipment such as DSLAMS which can place the visible upstream hop well outside of the subscribers city) If you don't have a dns tool that can return the LOC RR's then have a look for 'host'

To do a DNS LOC lookup try:

'host -t LOC' followed by the IP or hostname.
... or use the appropriate native DNS query tools bundled with your OS.


WHOIS

For websites you have 'whois' which may include LOC information, and certainly provides links to administrative personel either with the hosting/colocation company or perhaps a physical head office of the website staff (note that the latter case has nothing at all to do with the installation address)


RDNS + Hostname fishing

As a last resort you can pull an RDNS to find the hostname of the subscriber IP and a few hops of the upstream equipment... Often you will find city names and abbreviations used in the naming scheme. These are often obvious and are more likely to be accurately maintained than the DNS LOC information. If they are not obvious then you could try checking with the US Geospatial Intelligence Agencies 'GNS' service (GEOnet Names Server) which has lookups for some of the abbreviations used in various ISPs equipment, site and path-naming conventions.


Then, historicaly, there are common dialup tricks

Not so common anymore but could be if someone is trying to force dialup access into your routers config. If the modem doesn't have the guard time between data and command modes (None Hayes modems removed the guard time to get around the hayes patent). The technique is more useful if you stumble across a dialup configuration port to, say, a cisco and want to find its location or the business entity to which it belongs.

Get the remote end to echo the command signal followed by a dial command with ';' suffix... With any luck the modem will drop carrier and the line will clear down, then, your other phone will ring... take the caller-ID of that call** and run it through normal reverse lookup. For example, in a cisco you can enter it in the command line and then do a refresh, in others you could add it as a comment or field in the config then list the running config, etc.

In order to force the call initiator to echo the sequence there are a number of tricks including terminal macros. As an example, one could try the ANSI control sequences for remapping strings onto keys. Simnply change the MOTD to map [Enter] to the sequence at the hackers next login and then wait for him to hit [enter] at the login screen.

**You may also want to try prefixing the call with the codes to re-enable callerID for a single call... this will thwart CallerID default blocking options and often cut through most outgoing dial restrictions.

SG

[SlippyG]

Sorry, double-posted ... so shoot me ; )


Having fun with IP tracers

To keep it simple - the way these tracers work is that they send a packet with the TTL (Time-To-Live) set to 1 hop. This means that the packet will only pass ONE device before it expires prematurely. When the packet expires the device holding it discards it and sends back an error. The trace program receives this error and notes the source IP (The IP for the first device in the path)

Then it sends out an identical packet with the TTL set to two... the first device deducts one from the TTL and passes it on, the second device deducts one from the TTL and the packet expires (TTL=0)... again, a return error is generated and the devices IP is noted. This continues until the packet is finally sent with enough TTL to reach its destination - at which time the tracerout is complete and we have the IP of every *responsive* device in the path.

Next we reverse query the DNS records (Get a hostname for the IP) of each of those IP's and also check to see if their DNS record contains LOC information. If so, we note the LOC information for that hop and display it on a map.


Heres how we have fun...

You can assume that you are being tracerouted when a packet arrives with the TTL set to one (Just enough to get it there) ... So, lets pretend that we are NOT the destination and instead send back an error indicating the TTL was exceeded en-route. We send this with a major backbone address.

Now, we receive a similar packet with a TTL of 2 ... we send another error, but this time with a major trunk in washington DC (One that has a nice hostname that indicates washington)

Now with a TTL of 3... lets send back an error saying the packet timed out at a .mil or .gov gateway address

Then with another .mil address.
Then perhaps with a pentagon address.

From the casual tracers point of view your connection appears to be originating from somewhere in the .mil space... and he has pentagon and washington keywords in the list of hostnames at the remote end. Obviously, the more educated observer will spot that the route first goes through subscriber facing equipment at a domestic ISP, and will question the validity of any results after that point... but most users will simply crap a live elephant.


Another fun thing to do is to simultaneously traceroute the person tracerouting you... and have their results do a round trip back to themselves. You could just bounce at random between capital cities until no hops remain... not very realistic, but certainly fun to watch.



So, if you have a little coding skill grab a packet capture/injection API (libpcap/winpcap is ideal) and write an app that watches for these packets with the TTL expiring, and generate ICMP responses for that packet and each subsequent packet with higher TTL. One caveat is that if a legitimate packet is expiring when it reaches you, your reply will cause the remote side tol fail so don't make TTL the only criteria when deciding to fake an ICMP for TTL expiry. You might also make it warn the console so that you can impress the culprit with your awareness ; )

SG

[meep]

Anyone got a mirror of the movie? The video has been removed due to terms of use violation.

[st3@1th]

Good to see you back SG. Great posts as always. I'll have to start reading the forums again now.

[DiabloHorn]

there are 2 fakeroute apps that do that for *nix SlippyG but they both need modification since they are both aimed at udp.

[Jeremy]

And on a side note, SG's method is cute but useless. No one has an accurate LOC record in DNS and those that do aren't accurate because the LOC points to a CO or LEC (old school terms like you are used to) that have nothing to do with the end user.