traceroute (UNIX) or tracert (Windows) | Author/primary contact: | Unknown | | Web sites: | www.traceroute.org www.tracert.com | | Platforms: | Most UNIX and all Windows platforms | | Licenses: | Various | | 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 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 [216.34.160.36] 11 180 ms 190 ms 70 ms acmefirewall-hou.example.com [216.32.132.149] 12 110 ms 110 ms 100 ms www.example.com [64.58.76.229] 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 [158.136.169.136] 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 [63.237.97.81] 4 37 ms 15 ms 12 ms iah-core-01.inet.qwest.net [205.171.31.21] 5 51 ms 49 ms 47 ms dca-core-03.inet.qwest.net [205.171.5.185] 6 52 ms 55 ms 65 ms jfk-core-03.inet.qwest.net [205.171.8.217] 7 73 ms 63 ms 58 ms jfk-core-01.inet.qwest.net [205.171.230.5] 8 94 ms 67 ms 55 ms bos-core-02.inet.qwest.net [205.171.8.17] 9 56 ms 56 ms 60 ms bos-brdr-01.ip.qwest.net [205.171.28.34] 10 64 ms 63 ms 61 ms 63.239.32.230 10 67 ms 59 ms 55 ms so-7-0-0-0.core-rtr1.bos.verizon-gni.net [130.81.4.181] 11 56 ms 61 ms 62 ms so-0-0-1-0.core-rtr1.man.verizon-gni.net [130.81.4.198] 12 58 ms 59 ms 57 ms so-0-0-0-0.core-rtr2.man.verizon-gni.net [130.81.4.206] 13 59 ms 57 ms 64 ms a5-0-0-732.g-rtr1.man.verizon-gni.net [130.81.5.126] 15 74 ms 62 ms 61 ms 64.223.133.166 16 68 ms 67 ms 68 ms usnh-atm-inet.plymouth.edu [158.136.12.2] 17 80 ms 2968 ms 222 ms xhyd04-3.plymouth.edu [158.136.3.1] 18 75 ms 2337 ms 227 ms xspe04-2.plymouth.edu [158.136.2.2] 19 74 ms 65 ms 72 ms resnet169-136.plymouth.edu [158.136.169.136] 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. whois: A DNS Query Tool | whois | | Author/Primary contact: | N/A | | Web site: | N/A | | Platforms: | Most UNIX platforms | | Licenses: | Various | | 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:
whois domain-name.com
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) jane.jones@example.com 123 Elm, Ste 123 New York, NY 10000 212-123-4567 Technical Contact: John Smith (JS189) john.smith@example.com 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: www.networksolutions.com/cgi-bin/whois/whois  | 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 dnsmaster@example.com or admin@example.com . 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 | dig | | Author/primary contact: | Andrew Scherpbeir | | Web site: http://www-search.ucl.ac.uk/htdig-docs/author.html | | Platforms: | Most UNIX Platforms | | Licenses: | Various | | 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 | Options | Descriptions | | AXFR | 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. | | A | Returns any "A" records. "A" records are individual host names on the network, such as webserver .example.com and firewall1.example.com. | | MX | Returns the registered mail host name for that domain. This is useful if you want to contact an administrator (try administrator@mailhost.example.com or root@mailhost.example.com). | | CNAME | Returns any CNAMED hosts , also known as aliases. For example: fido.example.com = www.example.com. | | ANY | 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 @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: 64.115.0.245#53(ns.example.com) ;; WHEN: Wed Dec 31 18:39:24 2003 ;; MSG SIZE rcvd: 247
finger: A User Information Service | finger | | Author/primary contact: | Unknown | | Web site: | Various including: www.infonet.st-johns.nf.ca/adm/finger.html www.developer.com/net/cplus/article.php/627661 | | Platforms: | Most UNIX and Windows platforms | | Licenses: | Various | | 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:
finger user@hostname.example.com
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
ps: A UNIX Process Query Command | ps | | Author/primary contact: | Unknown | | Web sites: | Various, including www.nevis. columbia .edu/cgi-bin/man/sh?man=ps | | Platforms: | Most UNIX platforms | | Licenses: | Various | | 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 | Switches | Descriptions | | A | Shows all users' processes. | | a | Shows users' processes for all processes with a tty. | | u | Shows the name of the process user. | | x | 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 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 [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 www.ssh.com 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 web.example.com using my login of tony, I would type
ssh tony@web.example.com
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. Table 2.4. More SSH Options | Options | Descriptions | | -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. | | -v | Displays verbose output. This is useful for debugging. | | -q | Reports in quiet mode, opposite of verbose. | | -C | 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. | | -1 | 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. | | -2 | Forces SSH to use SSH protocol version 2 only. This may keep you from connecting to some servers. |
| 