|< Day Day Up >|
Performing Network Diagnostics: Network Utility
Unix-based operating systems are inherently networked operating systems from the original design, so they have a rather complete suite of network diagnostic software that comes with the basic operating system by default. We cover interaction with the command-line versions of these tools in several chapters to come. Apple has also provided a convenient GUI tool that functions as a front end to many of the diagnostics that the command-line tools can perform. Although it doesn't provide access to the complete range of options for each of the commands, the Network Utility application (path: /Applications/Utilities/Network Utility) is convenient for those who don't care to remember the syntax of command-line tools. The drawbacks are the need to navigate multiple windows to access the tool and the requirement for a graphical interface, whereas the command-line tools can be accessed to determine the health of your network from any machine with a network connection. The Network Utility application provides access to network diagnostics, which are described in the following sections:
The Interface Information (command-line command ifconfig) diagnostic gives you configuration information about your network interface. Shown in Figure 28.1, this diagnostic provides information regarding the traffic and error rate of the interface, as well as speed, hardware address, and vendor information.
Figure 28.1. The Info pane of Network Utility provides information regarding the network interface and its performance.
The Network Statistics (command-line command netstat) diagnostic gives you statistical information regarding your network. It can provide four types of network information routing tables, by-protocol comprehensive statistics, multicast statistics, and current socket statistics. The information that's provided is extremely terse and dense, but with experience, it can prove invaluable in diagnosing network problems. Figure 28.2 shows the routing information display.
Figure 28.2. Click the Netstat button on the Netstat pane to look up connection information, but don't be surprised if you have to wait a while.
To get this information takes the GUI client some time, and you might have to wait for several minutes before the utility responds. The routing information specifies what your computer knows about how to get information to remote locations. The IPv4 information displayed in Figure 28.2 indicates that the machine knows how to send information to three machines (192.168.1.4, 192.168.1.13, and 192.168.1.18), directly to an entire C-class network (192.168.1.) by one route, directly to an automatically configured B-class network (169.254., a network used by Rendezvous/Zeroconf), and to all other locations (default), by going through 192.168.1.4, which is this machine's default router. The comprehensive network statistics display includes considerably more information than fits in the display in Figure 28.3. Included is a fairly complete listing of every type of network connection and traffic that your machine has engaged in, and any problems or abnormalities that have been observed with the data transmissions for that traffic.
Figure 28.3. A portion of the comprehensive network statistics display of Network Utility.
The multicast information display provides information regarding multicast broadcast network information. If you are using your machine to stream QuickTime video or for other multicast applications, this display might provide useful information. Otherwise, expect it to remain essentially empty, as shown in Figure 28.4.
Figure 28.4. The multicast information display of Network Utility. If you do not use multicast services, expect this display to remain essentially empty.
The socket connection section displays information on all current Internet and local (Unix) domain socket connections. The information displayed in this section is much larger than what is shown in Figure 28.5. The active Internet connections portion shows the local addresses and remote addresses involved in the connections as well as the state of the connection. Common states you'll see are established, closed, and listen. In the local (Unix) domain socket connections portion, the listing includes a connection type of stream or dgram, inode numbers, and occasionally a filename identifier.
Figure 28.5. The active sockets connection information display of Network Utility.
The AppleTalk (various command-line utilities) pane provides information on the AppleTalk network. Four types of information are available: AppleTalk statistics and error counts, saved PRAM AppleTalk information, available AppleTalk zones on the network, and information on a specific AppleTalk node. Of these four, the AppleTalk statistics and error counts display and the available AppleTalk zone information are probably the most interesting.
The AppleTalk statistics and error counts display, shown in Figure 28.6, can provide information on how healthy your AppleTalk network is at the given moment. If you have been having a lot of trouble and discover from this that many errors are occurring, let your network administrator know.
Figure 28.6. The AppleTalk statistics and error counts information display of Network Utility.
Figure 28.7 shows the AppleTalk zones display, which displays the available AppleTalk zones for your network. If you see many more zones than you ought to, let your network administrator know.
Figure 28.7. The AppleTalk zones information display of Network Utility.
The Ping pane provides network connection/traffic testing (command-line program ping), as shown in Figure 9.34. It enables you to ping a remote machine to determine whether it, and the network between your machine and it, are alive. The ping program injects packets destined for a remote machine into the network, destined for a mandatory service that echoes the ping back to the originating machine. Usually, 10 packets are injected into the network at one-second intervals; both the round-trip time and information regarding any packets that don't complete the trip are reported back. You have the option of continuously sending packets to the remote host, but unless you have permission and a good reason to do so, this is usually considered, at the minimum, to be rude. The icmp_seq value increases by one for every packet sent, so if you see a gap in the values displayed, you know that one (or more) packets did not complete their round-trips.
Also displayed is a TTL (Time To Live) value, which starts at 255 and decreases for every machine that reroutes the packet. Usually, all these values will be the same, but if network trouble causes packets to take alternative routes between the machines, differing TTL values might be reflected. To keep errant packets from circling the Internet forever, each packet is restricted to a finite number of machines usually 255 that can touch it before it dies. Packets that get lost in routing loops and never make it to their destination quickly run out of TTL counts and are discarded. Finally, the time each packet took to traverse the network is displayed in milliseconds (thousandths of a second).
A number of modern firewalls optionally reject ping requests. Consequently, you might run into times when a ping request makes it seem like a host is unreachable when it really is not.
Figure 28.8. The Ping pane of Network Utility enables you to determine whether a remote host can be reached and how the network between the machines is performing.
The Lookup (command-line command nslookup [deprecated] or dig) diagnostic enables you to query the DNS (Domain Name Service) information for a machine. This includes information that maps the fully qualified domain name (FQDN), such as www.killernuts.org, to an IP address, and considerable additional information as well. The default operation of the diagnostic is to look up IP addresses for an FQDN, as shown in Figure 28.9.
Figure 28.9. The results of a default search for www.killernuts.org with the Lookup tool of the Network Utility application.
The diagnostic can also look up other types of information out of the DNS, such as what machine handles the email for a host and the canonical names (aliases) by which it might be known. Figure 28.10 shows the range of options for the lookup diagnostic.
Figure 28.10. The Lookup type options for the Lookup tool of the Network Utility application set the amount of data that will be queried from the remote server.
The information that the Lookup tool can provide includes the following:
The Traceroute (command-line program traceroute) diagnostic provides information on the route that a packet must travel between your machine and a remote machine. When the network is working properly, this information will usually be of little interest to you. If you can't reach a remote machine, however, it is sometimes useful to see this information so that you can tell whether the problem is with only a segment of the network, or if it's with the remote machine itself. Figure 28.11 shows the result of a successful Traceroute trace to the host www.tcp.com. Each line of the output indicates a machine through which the traffic to www.tcp.com had to be routed, and the time it took for that particular router to respond. The trace ends at the host www.tcp.com, indicating that the network is successful at transmitting data between the querying host and www.tcp.com.
Figure 28.11. The Traceroute output includes diagnostic information regarding each router that the packet needed to traverse to reach the remote host.
Figure 28.12 shows the result of an attempt to trace the route to a host that is down, on the same subnet as www.tcp.com. The traffic in this case manages to make it almost all the way to its final destination, but cannot reach the requested final host. If we know that the host is not, in fact, the next machine along the network (that is, Traceroute fails somewhere between you and the target, rather than at the target), we can infer that the problem is actually a network problem. Therefore, the routing of traffic between your machine and the remote machine is currently defective.
Figure 28.12. The output from Traceroute showing an unsuccessful attempt to reach a remote host on the same subnet as www.tcp.com.
If a transient failure were occurring in the Internet and the trace stopped well before reaching the target host's subnet, we could determine that problems reaching the host were because of something other than the host itself being down.
The Whois (command-line program whois) program actually has a more flexible use than is presented by this tool. It is designed to talk to remote servers that provide a sort of phone directory function. Apple has pointed the Whois tool of the Network Utility application to a subset of whois servers that provide directory information regarding the ownership and management of hostnames and domains, but you can also specify a whois server that is not already on the list. Figure 28.13 shows the results of trying to use the Whois tool to look up itchysweater.com. The whois server selected, whois.internic.net, machine knows only that another server, whois.godaddy.com, should know the complete information for this host. Figure 28.14 shows a portion of the results of specifying whois.godaddy.com as the whois server and reissuing the whois query for itchysweater.com.
Figure 28.13. The output from whois for itchysweater.com at whois.internic.net.
Figure 28.14. The output from whois for itchysweater.com at whois.godaddy.com. This server knows considerably more about the domain.
You can also use the Whois tool from the Network Utility application to make other types of queries to whois servers. For example, if you point the whois server to osu.edu, you can find out everyone who has "ness" in their name by searching for ness in the domain address box. Figure 28.15 shows a portion of the results of this search. In this case, it's a listing of people and email addresses that the server knows about at the institution that match the query "ness". If there are a lot of results, you will receive partial output and a comment that the sizelimit has been exceeded. This particular Whois server also enables you to get more specific information regarding the people identified and gives instructions at the bottom of the listing of names. Other whois servers can be contacted similarly and can be used to obtain a range of types of information.
Figure 28.15. The output from a "misuse" of the Whois tool of the Network Utility application to query a whois server that doesn't provide domain name information.
The Finger (command-line program finger) tool of the Network Utility application gives you the ability to query the finger server of a host. This server, if enabled, provides information regarding who a user is (full name and so on) and when the user was most recently logged in. It is generally considered to be a minor security risk to run the finger server because it lets crackers know whether it's safe to break into a system. But, if you know of a machine that has the service enabled, you can use this tool to access it. Figure 28.16 shows the results of using the finger tool to finger email@example.com. Notice that the server returns information about all known users with ray in their names. Different finger servers return different information about users. This one is rather sparse, leaving out most of the users' personal information but still indicates whether the users are logged in.
Figure 28.16. The output of a Finger tool lookup of firstname.lastname@example.org.
Port Scan (various command-line programs) examines a host for available opportunities to access it via the network. Conceptually, TCP/IP networking is accomplished by establishing connections between logical constructs, known as ports, created by the networking software of each machine. These ports can be thought of as analogous to a series of numbered sockets into which a network connection can be plugged. The network connection must be plugged into one socket on each communicating machine; hence, it has an originating port and a destination port. Some network services always exist at particular fixed ports and are connected to based on the knowledge that they exist at these known locations. Other applications attempt to generate a small level of security by opening a randomly numbered port and not advertising its presence. Connections then require that a connecting machine know where to look to find them. This isn't a particularly useful way of establishing security, but it does turn out to be a reasonably decent way for a cracker to hide the fact that he or she has broken into your machine. After the system has been compromised, many crackers will install a backdoor on an unknown port so that they can come and go undetected, instead of connecting to the normal known ports, and thereby incurring a noticeable connection to a known service.
The Port Scan tool of the Network Utility application causes your machine to examine all the ports on a remote machine and tell you which of them appear to have software listening to them. If the monitored ports don't correspond to known services, it's possible that there's been a network break-in. Figure 28.17 shows the Port Scan tool results for a machine running FTP and SSH. I can account all the ports shown in the results, but I did not have the patience to wait for the portscan to finish. There could be something else running that I don't know about. Additionally, it is considered to be excruciatingly bad form to portscan someone else's computer. This is exactly the methodology that crackers use to examine a machine for known vulnerabilities. We'd go so far as to say that it is a bit irresponsible of Apple to have put this tool in a user-level GUI application, and we recommend that you not use it, except on your own devices.
Figure 28.17. The output of the Port Scan tool of the Network Utility application.
|< Day Day Up >|