|< Day Day Up >|
traceroute (UNIX) or tracert (Windows): Network Diagnostic Tools
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 www.example.com over a maximum of 30 hops: 1 <10 ms <10 ms <10 ms 192.168.200.1 2 40 ms 60 ms 160 ms 10.200.40.1 3 30ms 40ms 100ms gateway.smallisp.net 4 100 ms 120 ms 100 ms iah-core-03.inet.genericisp.net [10.1.1.1] 5 70 ms 100 ms 70 ms dal-core-03.inet.genericisp.net [10.1.1.2] 6 61 ms 140 ms 70 ms dal-core-02.inet.genericisp.net [10.1.1.3] 7 70 ms 71 ms 150 ms dal-brdr-02.inet.genericisp.net [10.1.1.4] 8 60 ms 60 ms 91 ms 192.168.1.1 9 70 ms 140 ms 100 ms sprintds1cust123.hou-pop.sprint.com [192.168.1.2] 10 101 ms 130 ms 200 ms core-cr7500.example.com [22.214.171.124] 11 180 ms 190 ms 70 ms acmefirewall-hou.example.com [126.96.36.199] 12 110 ms 110 ms 100 ms www.example.com [188.8.131.52] 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 hou-pop.sprint.com is a Sprint router in Houston.
Listing 2.2. traceroute Example 2
Tracing route to resnet169-136.plymouth.edu [184.108.40.206] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 192.168.200.1 2 12 ms 7 ms 8 ms 10.200.40.1 3 26 ms 28 ms 11 ms iah-edge-04.inet.qwest.net [220.127.116.11] 4 37 ms 15 ms 12 ms iah-core-01.inet.qwest.net [18.104.22.168] 5 51 ms 49 ms 47 ms dca-core-03.inet.qwest.net [22.214.171.124] 6 52 ms 55 ms 65 ms jfk-core-03.inet.qwest.net [126.96.36.199] 7 73 ms 63 ms 58 ms jfk-core-01.inet.qwest.net [188.8.131.52] 8 94 ms 67 ms 55 ms bos-core-02.inet.qwest.net [184.108.40.206] 9 56 ms 56 ms 60 ms bos-brdr-01.ip.qwest.net [220.127.116.11] 10 64 ms 63 ms 61 ms 18.104.22.168 10 67 ms 59 ms 55 ms so-7-0-0-0.core-rtr1.bos.verizon-gni.net [22.214.171.124] 11 56 ms 61 ms 62 ms so-0-0-1-0.core-rtr1.man.verizon-gni.net [126.96.36.199] 12 58 ms 59 ms 57 ms so-0-0-0-0.core-rtr2.man.verizon-gni.net [188.8.131.52] 13 59 ms 57 ms 64 ms a5-0-0-732.g-rtr1.man.verizon-gni.net [184.108.40.206] 15 74 ms 62 ms 61 ms 220.127.116.11 16 68 ms 67 ms 68 ms usnh-atm-inet.plymouth.edu [18.104.22.168] 17 80 ms 2968 ms 222 ms xhyd04-3.plymouth.edu [22.214.171.124] 18 75 ms 2337 ms 227 ms xspe04-2.plymouth.edu [126.96.36.199] 19 74 ms 65 ms 72 ms resnet169-136.plymouth.edu [188.8.131.52] 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 plymouth.edu. The .edu means that it's a university. This was an educated guess, but you can verify it by going to the plymouth.edu 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.
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 domain-name.com 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
Registrant: Example Corp (EXAMPLE.DOM) 123 Elm, Suite 123 New York, NY 10000 US 212-123-4567 Domain Name: EXAMPLE.COM Administrative Contact: Jones, Jane (JJ189) email@example.com 123 Elm, Ste 123 New York, NY 10000 212-123-4567 Technical Contact: John Smith (JS189) firstname.lastname@example.org 123 Elm, Ste 123 New York, NY 10000 212-123-4567 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: NS.EXAMPLE.COM 10.1.1.1 NS2.EXAMPLE.COM 10.1.1.2
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:
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.
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 @ns.example.com AXFR
; <<>> DiG 9.2.1 <<>> @ns.example.com.com example.com 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 ;; QUESTION SECTION: ;example.com IN ANY ;; ANSWER SECTION: example.com. 86400 IN MX 10 mail.example.com. example.com. 2560 IN SOA ns.example.com hostmaster.example.com. 1070057380 16384 2048 1048576 2560 example.com. 259200 IN NS ns.example.com. example.com. 259200 IN NS ns2.example.com. example.com. 86400 IN A 10.1.1.1 ;; ADDITIONAL SECTION: nat1.example.com. 86400 IN A 10.1.1.2 ns.example.com. 86400 IN 10.1.1.3 ns2.example.com. 86400 IN A 10.1.1.4 sql.example.com 86400 IN A 10.1.1.5 www.example.com 86400 IN A 10.1.1.6 ;; Query time: 107 msec ;; SERVER: 184.108.40.206#53(ns.example.com) ;; WHEN: Wed Dec 31 18:39:24 2003 ;; MSG SIZE rcvd: 247
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 hostname.example.com 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 server1.example.com.
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 example.com. 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 @hostname.example.com generates a full finger query on every user logged in at that moment.
Listing 2.6. finger –l with No Username
[hostname.example.com] User Real Name What Idle TTY Host Console Location bsmith Bob Smith 2 lab1-30 (cs.example.edu) ajohnson Andrew Johnson 2 lab1-10 (dialup.genericisp.com) 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
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.
Listing 2.7 shows the output from a ps command with the -aux switch.
Listing 2.7. ps -aux Output
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.1 0.7 1288 484 ? S 18:00 0:04 init  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.
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.
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:
So, to log onto the Web server called web.example.com using my login of tony, I would type
I can also use ssh –l tony web.example.com to log into the server using SSH. If you simply type ssh web.example.com, the server will assume the same user name as your system login.
Table 2.4 lists some more SSH options.
|< Day Day Up >|