Network Utilities

To realize the full benefits of a networked environment, it made sense to extend certain tools, some of which have already been described. The advent of networks also created a need for new utilities to control and monitor them, spurring the development of new tools that took advantage of network speed and connectivity. This section describes concepts and utilities for systems attached to a network.

Trusted Hosts

Some commands, such as rcp and rsh, work only if the remote system trusts your local computer (that is, if the remote system knows your local computer and believes that it is not pretending to be another system). The /etc/hosts.equiv file lists trusted systems. For reasons of security, the Superuser account does not rely on this file to identify trusted Superusers from other systems.

Host-based trust is largely obsolete. Because there are many ways to circumvent trusted host security, including subverting DNS systems and IP spoofing (page 1038), authentication based on IP address is widely regarded as insecure and obsolete. In a small homogeneous network of machines with local DNS control, it can be "good enough." Its greater ease of use in these situations may outweigh the security concerns.

Security: Do not share your login account

You can use a .rhosts file to allow another user to log in as you from a remote system without knowing your password. This setup is not recommended. Do not compromise the security of your files or the entire system by sharing your login account. Use ssh and scp instead of rsh and rcp whenever possible.

OpenSSH Tools

The OpenSSH project provides a set of tools that replace rcp, rsh, and others with secure equivalents. These tools are installed by default in Red Hat Linux and can be used as drop-in replacements for their insecure counterparts. The OpenSSH tool suite is covered in detail in Chapter 18.

telnet: Logs In on a Remote System

You can use the TELNET protocol to interact with a remote computer. The telnet utility, a user interface to this protocol, is older than ssh and is not secure. Nevertheless, it may work where ssh (page 585) is not available (there is more non-UNIX support for TELNET access than for ssh access). In addition, many legacy devices, such as terminal servers and network devices, do not support ssh.

[bravo]$ telnet kudos Trying 172.19.52.2... Connected to kudos.example.com Escape character is '^]'. Welcome to SuSE Linux 7.3 (i386) - Kernel 2.4.10-4GB (2). kudos login: watson Password: You have old mail in /var/mail/watson. Last login: Mon Feb 27 14:46:55 from bravo.example.com watson@kudos:~> ... watson@kudos:~> logout Connection closed by foreign host. [bravo]$

telnet versus ssh

When you connect to a remote UNIX or Linux system using telnet, you are presented with a regular, textual login: prompt. Unless you specify differently, the ssh utility assumes that your username on the remote system matches that on the local system. Because telnet is designed to work with non-UNIX and non-Linux systems, it makes no such assumptions.

Security: telnet is not secure

Whenever you enter sensitive information, such as your password, while you are using telnet, it is transmitted in cleartext and can be read by someone who is listening in on the session.

Another difference between these two utilities is that telnet allows you to configure many special parameters, such as how RETURNs or interrupts are processed. When using telnet between UNIX and/or Linux systems, you rarely need to change any parameters.

When you do not specify the name of a remote host on the command line, telnet runs in an interactive mode. The following example is equivalent to the previous telnet example:

[bravo]$ telnet telnet> open kudos Trying 172.19.52.2... Connected to kudos.example.com Escape character is '^]'. ...

Before connecting you to a remote system, telnet tells you what the escape character is; in most cases, it is ^] (where ^ represents the CONTROL key). When you press CONTROL-], you escape to telnet's interactive mode. Continuing the preceding example:

[kudos]$ CONTROL-] telnet> ?

(displays help information)

telnet> close Connection closed. [bravo]$

When you enter a question mark in response to the telnet> prompt, telnet lists its commands. The close command ends the current telnet session, returning you to the local system. To get out of telnet's interactive mode and resume communication with the remote system, press RETURN in response to a prompt.

You can use telnet to access special remote services at sites that have chosen to make such services available. However, many of these services, such as the U.S. Library of Congress Information System (LOCIS), have moved to the Web. As a consequence, you can now obtain the same information using a Web browser.

Using telnet to Connect to Other Ports

By default telnet connects to port 23, which is used for remote logins. However, you can use telnet to connect to other services by specifying a port number. In addition to standard services, many of the special remote services available on the Internet use unallocated port numbers. For example, you can access some multiplayer text games, called MUDs (Multi-User Dungeons, or Dimensions), using telnet to connect to a specified port, such as 4000 or 8888. Unlike the port numbers for standard protocols, these port numbers can be picked arbitrarily by the administrator of the game.

While telnet is no longer commonly employed to log in on remote systems, it is still used extensively as a debugging tool. This utility allows you to communicate directly with a TCP server. Some standard protocols are simple enough that an experienced user can debug problems by connecting to a remote service directly using telnet. If you are having a problem with a network server, a good first step is to try to connect to it using telnet.

In the following example, a system administrator who is debugging a problem with email delivery uses telnet to connect to the SMTP port (port 25) on a the server at example.com to see why it is bouncing mail from the spammer.com domain. The first line of output indicates which IP address telnet is trying to connect to. After telnet displays the Connected to smtpsrv.example.com message, the user emulates an SMTP dialog, following the standard SMTP protocol. The first line, which starts with helo, begins the session and identifies the local system. After the SMTP server responds, the user enters a line that identifies the mail sender as [e-mail]. The SMTP server's response explains why the message is bouncing, so the user ends the session with quit.

$ telnet smtpsrv 25 Trying 192.168.1.1... Connected to smtpsrv.example.com. Escape character is '^]'. helo example.com 220 smtpsrv.example.com ESMTP Sendmail 8.13.1/8.13.1; Wed, 4 May 2005 00:13:43 -0500 (CDT) 250 smtpsrv.example.com Hello desktop.example.com [192.168.1.97], pleased to meet you mail from:[e-mail] 571 5.0.0 Domain banned for spamming quit 221 2.0.0 smtpsrv.example.com closing connection

The telnet utility allows you to use any protocol you want, as long as you know it well enough to type commands manually.

ftp: Transfers Files Over a Network

The File Transfer Protocol (FTP) is a method of downloading files from and uploading files to another system using TCP/IP over a network. FTP is not a secure protocol; use it only for downloading public information from a public server. Most Web browsers can download files from FTP servers. Chapter 19 covers FTP clients and servers.

ping: Tests a Network Connection

The ping^[15] utility (http://ftp.arl.mil/~mike/ping.html) sends an ECHO_REQUEST packet to a remote computer. This packet causes the remote system to send back a reply. This exchange is a quick way to verify that a remote system is available and to check how well the network is operating, such as how fast it is or whether it is dropping data packets. The ping utility uses the ICMP (Internet Control Message Protocol) protocol. Without any options, ping tests the connection once per second until you abort execution with CONTROL-C.

^[15] The name ping mimics the sound of a sonar burst used by submarines to identify and communicate with each other. The word ping also expands to packet internet groper.

$ ping tsx-11.mit.edu PING tsx-11.mit.edu (18.7.14.121) 56(84) bytes of data. 64 bytes from TSX-11.MIT.EDU (18.7.14.121): icmp_seq=0 ttl=45 time=97.2 ms 64 bytes from TSX-11.MIT.EDU (18.7.14.121): icmp_seq=1 ttl=45 time=96.1 ms 64 bytes from TSX-11.MIT.EDU (18.7.14.121): icmp_seq=2 ttl=45 time=95.7 ms 64 bytes from TSX-11.MIT.EDU (18.7.14.121): icmp_seq=3 ttl=45 time=96.3 ms CONTROL-C --- tsx-11.mit.edu ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3001ms rtt min/avg/max/mdev = 95.755/96.361/97.202/0.653 ms

This example shows that the remote system named tsx-11.mit.edu is up and available over the network.

By default ping sends packets containing 64 bytes (56 data bytes and 8 bytes of protocol header information). In the preceding example, four packets were sent to the system tsx-11.mit.edu before the user interrupted ping by pressing CONTROL-C. The four-part number in parentheses on each line is the remote system's IP address. A packet sequence number (called icmp_seq) is also given. If a packet is dropped, a gap occurs in the sequence numbers. The round-trip time is listed last; it represents the time (in milliseconds) that elapsed from when the packet was sent from the local system to the remote system until the reply from the remote system was received by the local system. This time is affected by the distance between the two systems, network traffic, and the load on both computers. Before it terminates, ping summarizes the results, indicating how many packets were sent and received as well as the minimum, average, maximum, and mean deviation round-trip times it measured. Use ping6 to test IPv6 networks.

Tip: When ping cannot connect

If it is unable to contact the remote system, ping continues trying until you interrupt it with CONTROL-C. A system may not answer for any of several reasons: The remote computer may be down, the network interface or some part of the network between the systems may be broken, a software failure may have occurred, or the remote machine may be set up, for reasons of security, not to return pings (try pinging www.microsoft.com or www.ibm.com).

traceroute: Traces a Route Over the Internet

The traceroute utility traces the route that an IP packet follows, including all intermediary points traversed (called network hops), to its destination (the argument to traceroutean Internet host). It displays a numbered list of hostnames, if available, and IP addresses, together with the round-trip time it took for a packet to reach each router along the way and an acknowledgment to get back. You can put this information to good use when you are trying to identify the location of a network bottleneck.

The traceroute utility has no concept of the path from one host to the next; instead, it simply sends out packets with increasing TTL (time to live) values. TTL is an IP header field that indicates how many more hops the packet should be allowed to make before being discarded or returned. In the case of a traceroute packet, the packet is returned by the host that has the packet when the TTL value is zero. The result is a list of hosts that the packet traveled through to get to its destination.

The traceroute utility can help you solve routing configuration problems and locate routing path failures. When you cannot reach a host, use traceroute to discover what path the packet follows, how far it gets, and what the delay is.

The next example shows the output of traceroute when it follows a route from a local computer to www.linux.org. The first line indicates the IP address of the target, the maximum number of hops that will be traced, and the size of the packets that will be used. Each numbered line contains the name and IP address of the intermediate destination, followed by the time it takes a packet to make a trip to that destination and back again. The traceroute utility sends three packets to each destination; thus three times appear on each line. Line 1 shows the statistics when a packet is sent to the local gateway (less than 3 milliseconds). Lines 46 show the packet bouncing around Mountain View (California) before it goes to San Jose. Between hops 13 and 14 the packet travels across the United States (San Francisco to somewhere in the East). By hop 18 the packet has found www.linux.org. The traceroute utility displays asterisks when it does not receive a response. Each asterisk indicates that traceroute has waited three seconds. Use traceroute6 to test IPv6 networks.

$ /usr/sbin/traceroute www.linux.org traceroute to www.linux.org (198.182.196.56), 30 hops max, 38 byte packets  1 gw.localco.com. (204.94.139.65) 2.904 ms 2.425 ms 2.783 ms  2 covad-gw2.meer.net (209.157.140.1) 19.727 ms 23.287 ms 24.783 ms  3 gw-mv1.meer.net (140.174.164.1) 18.795 ms 24.973 ms 19.207 ms  4 d1-4-2.a02.mtvwca01.us.ra.verio.net (206.184.210.241) 59.091 ms d1-10-0-0-200.a03.      mtvwca01.us.ra.verio.net (206.86.28.5) 54.948 ms 39.485 ms  5 fa-11-0-0.a01.mtvwca01.us.ra.verio.net (206.184.188.1) 40.182 ms 44.405 ms 49.362 ms  6 p1-1-0-0.a09.mtvwca01.us.ra.verio.net (205.149.170.66) 78.688 ms 66.266 ms 28.003 ms  7 p1-12-0-0.a01.snjsca01.us.ra.verio.net (209.157.181.166) 32.424 ms 94.337 ms 54.946 ms  8 f4-1-0.sjc0.verio.net (129.250.31.81) 38.952 ms 63.111 ms 49.083 ms  9 sjc0.nuq0.verio.net (129.250.3.98) 45.031 ms 43.496 ms 44.925 ms 10 mae-west1.US.CRL.NET (198.32.136.10) 48.525 ms 66.296 ms 38.996 ms 11 t3-ames.3.sfo.us.crl.net (165.113.0.249) 138.808 ms 78.579 ms 68.699 ms 12 E0-CRL-SFO-02-E0X0.US.CRL.NET (165.113.55.2) 43.023 ms 51.910 ms 42.967 ms 13 sfo2-vva1.ATM.us.crl.net (165.113.0.254) 135.551 ms 154.606 ms 178.632 ms 14 mae-east-02.ix.ai.net (192.41.177.202) 158.351 ms 201.811 ms 204.560 ms 15 oc12-3-0-0.mae-east.ix.ai.net (205.134.161.2) 202.851 ms 155.667 ms 219.116 ms 16 border-ai.invlogic.com (205.134.175.254) 214.622 ms * 190.423 ms 17 router.invlogic.com (198.182.196.1) 224.378 ms 235.427 ms 228.856 ms 18 www.linux.org (198.182.196.56) 207.964 ms 178.683 ms 179.483 ms

host and dig: Query Internet Nameservers

The host utility looks up an IP address given a name, or vice versa. The following example shows how to use host to look up the domain name of a machine, given an IP address:

$ host 140.174.164.2 2.164.174.140.in-addr.arpa. domain name pointer ns.meer.net.

You can also use host to determine the IP address of a domain name:

$ host ns.meer.net ns.meer.net. has address 140.174.164.2

The dig (domain information groper) utility queries DNS servers and individual machines for information about a domain. A powerful utility, dig has many features that you may never use. It is more complex than host.

Chapter 24 on DNS has many examples of the use of host and dig.

jwhois: Looks Up Information About an Internet Site

The jwhois utility replaces whois and queries a whois server for information about an Internet site. This utility returns site contact and InterNIC or other registry information that can help you track down the person who is responsible for a site: Perhaps that person is sending you or your company spam (page 1056). Many sites on the Internet are easier to use and faster than jwhois. Use a browser and search engine to search on whois or go to www.networksolutions.com/whois or www.ripe.net/perl/whois to get started.

When you do not specify a whois server, jwhois defaults to whois.internic.net. Use the h option to jwhois to specify a different whois server. See the jwhois info page for more options and setup information.

To obtain information on a domain name, specify the complete domain name, as in the following example:

$ jwhois sobell.com [Querying whois.internic.net] [Redirected to whois.godaddy.com] [Querying whois.godaddy.com] [whois.godaddy.com] The data contained in Go Daddy Software, Inc.'s WhoIs database, ... Registrant:   Sobell Associates Inc   POBox 460068   San Francisco, California 94146-0068   United States

Registered through: GoDaddy.com Domain Name: SOBELL.COM    Created on: 07-Apr-95    Expires on: 08-Apr-13    Last Updated on: 16-Jan-04 Administrative Contact:    Sobell, Mark [e-mail]    Sobell Associates Inc    PO BOX 460068    SAN FRANCISCO, California 94146-0068    United States    9999999999 Fax -- 9999999999 Technical Contact:    ,   [e-mail]    meer.net    po box 390804    Mountain View, California 94039    United States    18888446337 Fax -- 18888446337 Domain servers in listed order:    NS.MEER.NET    NS2.MEER.NET

Several top-level registries serve various regions of the world. You are most likely to use the following ones:

North American registry	whois.arin.net
European registry	www.ripe.net
Asia-Pacific registry	www.apnic.net
U.S. military	whois.nic.mil
U.S. government	www.nic.gov