Previous Section  < Day Day Up >  Next Section

traceroute (UNIX) or tracert (Windows): Network Diagnostic Tools

traceroute (UNIX) or tracert (Windows)

Author/primary contact:


Web sites:


Most UNIX and all Windows platforms



UNIX manual pages:

Type man traceroute at any UNIX command prompt.

This command is similar to ping, but it provides a lot more information about the remote host. Basically, traceroute pings a host, but when it sends out the first packet, it sets the TTL (Time to Live) setting on the packet to one. This setting controls how many hops a packet will take before dying. So the first packet will only go to the first router or machine beyond yours on the Internet, and then a message acknowledging that the packet has "expired" will return. Then, the next packet is set with a TTL of 2, and so on until it reaches your target. This shows the virtual path (the route) that the packets took. The name of each host along the way is resolved, so you can see how your traffic traverses the Internet. It can be very interesting to see how a packet going from Houston to Dallas might bounce from the East Coast to the West Coast, traveling thousands of miles before reaching its target a fraction of a second later.

This tool comes in handy when you are trying to track down the source or location of a perpetrator you have found in your log files or alerts. You can traceroute to the IP address and learn a number of things about it. The output might tell you if they are a home user or inside a company, who their ISP is (so you can file an abuse complaint), what type of service they have and how fast it is, and where geographically they are (sometimes, depending on the descriptiveness of the points in-between). Listings 2.1 and 2.2 show examples of traceroutes.

Listing 2.1. traceroute Example 1

Tracing route to

over a maximum of 30 hops:

1   <10 ms  <10 ms  <10 ms

2   40 ms  60 ms  160 ms

3   30ms  40ms   100ms

4   100 ms  120 ms  100 ms


5   70 ms  100 ms  70 ms


6   61 ms  140 ms  70 ms


7   70 ms  71 ms  150 ms


8   60 ms  60 ms  91 ms

9   70 ms  140 ms  100 ms


10  101 ms  130 ms  200 ms


11  180 ms  190 ms  70 ms


12  110 ms  110 ms  100 ms []

Trace complete.

In Listing 2.1, the DNS names have been changed to generic names, but you get the general idea. From this simple command, you can tell that the IP address in question belongs to a company called Acme, that it is probably a Web server, it is inside their firewall or on the DMZ, their ISP is Sprint, and they are in Houston. Many network administrators and large ISPs use geographical abbreviations or initials to name their routers, so by looking at the DNS name and following the trail of routers, you can deduce that is a Sprint router in Houston.

Listing 2.2. traceroute Example 2

Tracing route to []

over a maximum of 30 hops:

1   <1 ms  <1 ms  <1 ms

2   12 ms   7 ms   8 ms

3   26 ms  28 ms  11 ms


4   37 ms  15 ms  12 ms


5   51 ms  49 ms  47 ms


6   52 ms  55 ms  65 ms


7   73 ms  63 ms  58 ms


8   94 ms  67 ms  55 ms


9   56 ms  56 ms  60 ms


10  64 ms  63 ms  61 ms

10  67 ms  59 ms  55 ms


11  56 ms  61 ms  62 ms


12  58 ms  59 ms  57 ms


13  59 ms  57 ms  64 ms


15  74 ms  62 ms  61 ms

16  68 ms  67 ms  68 ms


17  80 ms 2968 ms  222 ms []

18  75 ms 2337 ms  227 ms []

19  74 ms  65 ms  72 ms


Trace complete.

From the traceroute example in Listing 2.2 you can tell that the IP in question is probably being used by a student at Plymouth State University in Plymouth, New Hampshire. How can you tell this? First of all, the final domain name is a giveaway. If you follow the traceroute, it goes from bos (Boston) to man (Manchester), then to The .edu means that it's a university. This was an educated guess, but you can verify it by going to the Web site. Also, the resolved host name is resnet169-136. The name suggests it is the network for their student residences.

As you can see, sometimes reading traceroutes is like being a detective, more of an art than a science, but over time you will learn more and get better at recognizing what each abbreviation means.

Traceroute gives lots of information to use to follow up on this IP if it was the source of an intrusion or attack. In the example in Listing 2.1, you could look up the company Web site to find a main number. You can call their ISP and complain. Larger ISPs usually have a main e-mail or contact to use for complaints, and will usually enforce their terms of service with the customer. Or you can use the next command, whois, to find specific technical contacts for the company or organization.

whois: A DNS Query Tool


Author/Primary contact:


Web site:



Most UNIX platforms



UNIX manual pages:

Type man whois at any UNIX command prompt.

The whois command is useful when trying to track down a contact for someone causing trouble on your network. This command queries the primary domain name servers and returns all the information that Internic (or whoever their name registrar is) has. Internic used to be the quasi-government agency that was responsible for keeping track of all the domain names on the Internet. Internic became a commercial company called Network Solutions, and was then acquired by VeriSign. Now that name registration has been opened up for competition, there are literally dozens of official name registrars. However, you can still usually find out who owns a domain by using the whois command.

This command is useful for attacks coming both from within companies or within ISP networks. Either way, you can track down the person responsible for that network and report your problems to them. They won't always be helpful, but at least you can try. The syntax is:


The variable is the domain name you are looking for information on. Listing 2.3 shows the kinds of information returned that might be returned.

Listing 2.3. whois Results


Example Corp (EXAMPLE.DOM)

  123 Elm, Suite 123

  New York, NY 10000



  Domain Name: EXAMPLE.COM

  Administrative Contact:

   Jones, Jane (JJ189)

    123 Elm, Ste 123

    New York, NY 10000


  Technical Contact:

   John Smith  (JS189)

    123 Elm, Ste 123

    New York, NY 10000


  Record expires on 06-Oct-2006.

  Record created on 05-Oct-2002.

  Database last updated on 30-Apr-2004 21:34:52 EDT.

  Domain servers in listed order:



As you can see, you can contact the technical person in charge of that domain directly. If that doesn't work, you can always try the administrative person. The whois command usually displays an e-mail address, a mailing address, and sometimes phone numbers. It tells when the domain was created and if they've made recent changes to their whois listing. It also shows the domain name servers responsible for that domain name. Querying these numbers with the dig command (described next) can generate even more information about the remote network's configuration.

Unfortunately, whois is not built into the Windows platforms, but there are plenty of Web-based whois engines, including the one located on Network Solutions Web site at:


Flamey the Tech Tip:

Don't Drop Your Corporate Drawers on whois!

If you administer domains of your own, you should make sure your whois listing is both up to date and as generic as possible. Putting real e-mail addresses and names in the contact information fields gives information that an outsider can use either for social engineering or password-cracking attacks. Also, people might leave the company, making your record outdated. It is better to use generic e-mail addresses, such as or You can forward these e-mails to the people responsible, and it doesn't give out valuable information on your technical organization structure.

dig: A DNS Query Tool


Author/primary contact:

Andrew Scherpbeir

Web site:


Most UNIX Platforms



UNIX manual pages:

Type man dig at any UNIX command prompt.

The dig command queries a name server for certain information about a domain. Dig is an updated version of the nslookup command, which is being phased out. You can use it to determine the machine names used on a network, what the IP addresses tied to those machines are, which one is their mail server, and other useful tidbits of information. The general syntax is:

dig @server domain type

where server is the DNS server you want to query, domain is the domain you are asking about, and type is the kind of information you want on it. You will generally want to query the authoritative DNS for that domain; that is, the one listed in their whois record as being the final authority on that domain. Sometimes the company runs this server; other times its ISP runs the server. Table 2.2 lists the kinds of records you can ask for with the type option.

Table 2.2. dig Record Types




Attempts to get the whole file for the domain or "zone" file. Some servers are now configured not to allow zone file transfers, so you may have to ask for specific records.


Returns any "A" records. "A" records are individual host names on the network, such as and


Returns the registered mail host name for that domain. This is useful if you want to contact an administrator (try or


Returns any CNAMED hosts, also known as aliases. For example: =


Returns any information it can generate on the domain. Sometimes this works when AXFR doesn't.

Listing 2.4 shows an example of results of the dig command. As you can see, their whole domain zone file has been downloaded. This yields valuable information, such as the host name of their mail server, their DNS server, and other important machines on their network. If you run a DNS server, you should be able to configure it to respond only to these kinds of request from authorized machines.

Listing 2.4. Output from dig AXFR

; <<>> DiG 9.2.1 <<>> ANY

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54042

;; flags: qr aa rd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 4


;   IN  ANY

;; ANSWER SECTION:  86400  IN  MX   10  2560   IN  SOA 1070057380 16384 2048 1048576 2560  259200  IN  NS  259200  IN  NS  86400   IN  A

;; ADDITIONAL SECTION:  86400  IN  A    86400  IN  86400  IN  A   86400  IN  A   86400  IN  A

;; Query time: 107 msec


;; WHEN: Wed Dec 31 18:39:24 2003

;; MSG SIZE rcvd: 247

finger: A User Information Service


Author/primary contact:


Web site:

Various including:


Most UNIX and Windows platforms



UNIX manual pages:

Type man finger at any command prompt.

Finger is an old UNIX command that isn't used much anymore, but it is still running on many machines as a legacy service. It was originally designed when the Internet was a friendlier place and users didn't mind people halfway across the world knowing their schedule, office numbers, and other information. Most competent system administrators turn this daemon off now because it has been associated with many security holes. However, you'd be surprised how many servers still run it. Many routers come with it (I can't figure out why, except maybe the vendor implemented a TCP stack that included it), and some UNIX operating systems still enable it by default on installation, and people forget or don't know how to turn it off.

The finger command lets you query the remote system for information on its users. The syntax is:


Replace the variables user with the username you are trying to find out about and with the fully qualified host name. You can also use an IP address. Listing 2.5 shows the results of a finger query run on the user bsmith on

Listing 2.5. finger Query Results

Login name: bsmith In real life: Bob Smith

Directory: /home/bsmith Shell: /bin/bash

Last Login: 7/03/04 0800:02

No unread mail

Project: Writing a book

Plan:  I'll be on vacation in Europe from September 1-15th.

As you can see, there quite a bit of information on Bob available through finger, including the last time he logged on, if he has any new e-mail, and any personal information he entered. He was also kind enough to let us know when he will be out of the office. This could be used by hackers to divine information about Bob for use in social engineering. It also can help them to learn his log-on habits and schedule so they could attempt to crack his account when he is out of town.

Another crafty use of finger is to send the command without a user name. This generates a list of all the users currently logged on. Listing 2.6 shows the results of what this query might look like on the fictitious You can see who is logged on and what their real names are. You can also see if they have been idle (perhaps they forgot to log out) and for how long. Finally, it lists what station they are coming from (whether they are local or remote) and the hostname or IP of where they are logging on from if it is not local. You can see one user is logged on multiple times with one session idle. A malicious viewer of this data might decide to attempt to hijack this idle session.

You could also run full finger queries on any of those users that looked worth pursuing further. Using the command finger l generates a full finger query on every user logged in at that moment.

Listing 2.6. finger l with No Username


User   Real Name   What  Idle TTY Host  Console Location

bsmith  Bob Smith           2 lab1-30 (

ajohnson Andrew Johnson         2 lab1-10 (

bjones  Becky Jones             co lab3-22

atanner Allen H Tanner          0:50 co lab3-9

atanner Allen H Tanner          co lab3-1

atanner Allen H Tanner          4:20 co lab3-8

cgarcia Charles Garcia          3 lab1-10

ps: A UNIX Process Query Command


Author/primary contact:


Web sites:

Various, including


Most UNIX platforms



UNIX manual pages:

Type man ps at any UNIX command prompt.

The ps command, short for process, shows you all the processes running on a system. This can be very useful to determine if there is some daemon or process running that shouldn't be. It can also be used to debug many of the tools in this book. Table 2.3 lists some useful ps switches.

Table 2.3. ps Switches




Shows all users' processes.


Shows users' processes for all processes with a tty.


Shows the name of the process user.


Displays processes with controlling ttys.

Listing 2.7 shows the output from a ps command with the -aux switch.

Listing 2.7. ps -aux Output


root     1 0.1 0.7 1288 484 ?    S  18:00  0:04 init [3]

root     2 0.0 0.0   0  0 ?    SW  18:00  0:00 [keventd]

root     3 0.0 0.0   0  0 ?    SW  18:00  0:00 [kapmd]

root     5 0.0 0.0   0  0 ?    SW  18:00  0:00 [kswapd]

root     6 0.0 0.0   0  0 ?    SW  18:00  0:00 [bdflush]

root     7 0.0 0.0   0  0 ?    SW  18:00  0:00[kupdated]

root     8 0.0 0.0   0  0 ?    SW< 18:00  0:00 [mdrecoveryd]

root    12 0.0 0.0   0  0 ?    SW  18:00  0:00 [kjournald]

root    137 0.0 0.0   0  0 ?    SW  18:00  0:00 [khubd]

root    682 0.0 1.0 1412 660 ?    S  18:01  0:00 /sbin/cardmgr

rpc    700 0.0 0.8 1416 532 ?    S  18:01  0:00 portmap

root    720 0.0 1.2 1640 788 ?    S  18:01  0:00 syslogd -m 0

root    757 0.0 1.8 1940 1148 ?    S  18:01  0:00 klogd -2

root    797 0.0 0.8 1336 500 ?    S  18:01  0:00 gpm -t ps/2 -m

xfs    869 0.0 5.8 5048 3608 ?    S  18:01  0:00 xfs -port -1

daemon   884 0.0 0.8 1312 504 ?    S  18:01  0:00 /usr/sbin/atd

root    928 0.0 2.0 2660 1244 ?    S  18:01  0:01 /usr/sbin/SSHd

root    949 0.0 1.5 2068 948 ?    S  18:01  0:00 xinetd -stayalive

root    951 0.0 0.7 1292 496 ?    S  18:01  0:00 /sbin/dhcpcd -h m

root   1078 0.0 1.0 1492 628 ?    S  18:01  0:00 crond

root   1132 0.0 3.4 3808 2152 ?    S  18:01  0:02 nessusd: waiting

root   1134 0.0 1.9 2276 1224 ?    S  18:01  0:00 login -- tony

tony   1394 0.0 2.6 2732 1624 tty1   S  18:29  0:00 -bash

tony   1430 0.0 2.6 2744 1636 tty1   S  18:29  0:00 bash

tony   1805 0.0 1.2 2676 796 tty1   R  18:56  0:00 ps -aux

You can see each process running on the system with its process ID. This is important if you want to kill the service or take some other action. The u switch shows the user at the far left. This readout shows various system processes owned by root. It also shows a user running the ps command. If you see some mysterious service running, you should investigate it further. This listing shows what might be a suspicious service: the nessusd daemon, which is the vulnerability scanner you will use in Chapter 5. However, this is your security tool system, so it is all right for it to be running here.

You can also pipe the ps command into a grep command to search for specific services running. For example, the command

ps ax |grep snort

will tell you if Snort is running on your system and its associated process ID (PID). So, as you'll find with many of the operating system level tools in this book, the ps command can be useful for all kinds of system administration activities, not just security.

OpenSSH Client: A Secure Terminal Service

SSH is such a useful tool that there is a separate section on it in Chapter 9 as a server-side tool. However, I highly recommend using the client whenever possible for interactive logins in lieu of Telnet or some other nonsecure method. You will be using it so much I want to give some basic details and syntax of the client here. SSH (secure shell) is a remote access tool that allows you to log into a remote system securely. A major Achilles' heel of most networks is the fact that inter-system communications are generally passed over a network in plain text. So you can harden the individual machines all you want, but if you log into them remotely with an insecure terminal program, thieves could still grab your log-on credentials off the network with a sniffer. They can then log on as you without breaking a sweat. One of the most popular remote access tools, Telnet, suffers from this deficiency. SSH fixes this problem by encrypting all the communications from the first keystroke.


SSH is an open source program that is available on almost every platform, and it comes by default with most Linux-based operating systems. There is a commercial version, available at the Web site, which is also open source. The one I review here is OpenSSH, the free version that comes with most Linux distributions and is on the CD-ROM that comes with this book. While there are a few differences, most of the commands and syntax should work and the two are interoperable.

In order to access a remote system with SSH, you need an SSH client on your end and there must be an SSH server running on the remote side. While SSH isn't as widespread as Telnet, it is catching on. Cisco is finally installing SSH on it routers, although it still leaves the Telnet server enabled by default while SSH is optional.

SSH is released under an open source license that is similar in effect to the BSD license. Make sure you are using version 3.6 or newer; some earlier versions had flaws in their implementation of cryptographic protocols and are susceptible to being cracked. In fact, it is a good idea to make sure you have the latest version available, as the code is constantly being improved and the algorithms are being tweaked.

SSH has a number of really interesting uses other than just logging into a remote system securely. It can be used to tunnel almost any service through an encrypted channel between servers (this application is discussed more in later chapters). Basic SSH syntax to log in remotely is:

ssh l login hostname

Replace login with your login name on that remote system and hostname with the host you are trying to SSH into. You can also use:

ssh login@hostname

So, to log onto the Web server called using my login of tony, I would type


I can also use ssh l tony to log into the server using SSH. If you simply type ssh, the server will assume the same user name as your system login.

Table 2.4 lists some more SSH options.

Table 2.4. More SSH Options



-c protocol

Uses a specific cryptographic protocol. Replace protocol with blowfish, 3des, or des, depending on the cryptographic algorithm you want to use. Note that your version of SSH must support these algorithms.

-p port#

Connects to a specific port number rather than the default SSH port of 22.

-P port#

Uses a specific port that is not part of the standard list of proprietary ports. This usually means a port number above 1024. This can be useful if you have a firewall that knocks down communications on lower port numbers.


Displays verbose output. This is useful for debugging.


Reports in quiet mode, opposite of verbose.


Uses compression on the encrypted traffic. This can be useful for extremely slow connections like dial-up, but you better have a powerful processor to do the compression or it will slow you down more than it will speed you up.


Forces SSH to use only SSH protocol version 1. This is not recommended for the reasons mentioned in the -C option, but it may be required if the server you are connecting to isn't upgraded to version 2.


Forces SSH to use SSH protocol version 2 only. This may keep you from connecting to some servers.

    Previous Section  < Day Day Up >  Next Section