Test 10: Using the netstat command and TCPView to Check Port Usage

Test 10: Using the netstat command and TCPView to Check Port Usage

What happens if you can trace a network slowdown to a particular computer, but nobody knows what could be causing it to use so much bandwidth? The device could be running any number of legitimate background updates or services that use an Internet connection. Unfortunately, the same machine could have been compromised by a trojan hourse or virus and now it's relaying tons of spam email or acting as an illegal file sharing service. We need to invesigate what processes are using the ports on your system and how they are using them. (This is when installing a network traffic monitoring tool like Paessler's PRTG Traffic Grapher can be quite helpful since we've narrowed the problem down to a machine [or two].) Luckily, there are some tools and Windows and some nice free tools to help us with this step. The first one we'll mention is the netstat command.

The command "netstat" is short for "network status." It can used to show the configuration and status of the network on the machine on which it is run. It's a good idea to periodically run the netstat command to see what services you have listening for connections. If you see a port listed that is new and unexpected, it is a good idea to do a Google search on that protocol and port. For example, if I look on a Windows XP system that is connected to a few services on the Internet, I might see the following screen.

The "-a" option instructs netstat to display the active network connections. It lists the protocol (either TCP or UDP), Local (IP) Address, Foreign (remote IP) Address, and the connection's state (for TCP connections). Since I am using the Windows XP operating system in this example, I can add "-o" option to display the process ID number or "PID" of the program using that port. (The "-n" option instructs netstat to use raw IP addresses in its results rather than attempting to resolve the IP addresses to their respective domain and host names.)

Generally, it is the remote (foreign) connection information that we want to inspect. Let's assume we decide that having two connections to Internet servers at (the remote) destination port 5190 somewhat suspicious. The process ID associated with that port 2864. Now, we need to find out what process matches this process ID. For that, we can use the windows Task Manager. To bring up the Task Manager, you can either hit Ctrl-Alt-Del (Windows XP only) or right-click (not left-click) on an empty spot in the toolbar at the bottom of the screen as shown here. From the popup menu, choose the Task Manager.

The task manager is shown below. Click on the Processes tab to bring that tab to the front as shown. This lists all the active processes on your system by name, PID, user name (of who started the program), percentage of CPU that task is using, and the amount of memory that task is using. Clicking on the title of any column will sort the entries in ascending order. (Clicking a second time will reverse the sort to descending order.) Click on the title of the PID column to sort the entries in PID order and look for the PID of the suspicious entry (2864).

From the Task Manager window above, I find that the application's name is aim.exe, which is the name of AOL Instant Messenger application. If I didn't know what aim.exe was, I would Google that name along with the either the source or destination port and protocol (e.g., "aim.exe tcp 5190"). If a search using the source port doesn't turn up anything conclusive, try the destination port (or both). If you do find a application listening on a port that turns out to be a known virus or Trojan horse, your fun is just beginning, but at least you're aware of its presence. (Eradicating the problem is left as an exercise for the reader.) In this case, what I've found is AOL's AIM communicating on its default port of 5190. There's nothing to see here. Move along.

The netstat command is a fine tool, but it is command line driven as opposed to having a standard graphical user interface (GUI). It also just runs once unless the command is issued repeatedly. Therefore, it can't show changes in connections as they occur. The upside it that it comes installed on Windows 2000 and above though, so it's pretty much guaranteed to be there. (Although the -o option is only available in Windows XP and above.) However, there are some nice GUI-based tools out there for investigating the traffic on specific computers and on your LAN. We'll start with TCPView from Microsoft's own TechNet site.

TCPView displays a list of the current TCP and UDP connections established with the computer upon which it is run. It's very much the same information that netstat had, but in a nicer viewing format. Additionally, TCPView can be set to recheck the connections at 1, 2 or 5 second intervals and displays the differences from the previous check. Connections that change state from one update to the next are highlighted in yellow; those that are deleted are shown in red, and new connections are shown in green. (TCPView calls the connections to other IPs, "endpoints.") The owning processes name and PID are also shown, which saves looking them up via other means.

Using TCPView, you can look for unexpected connections as before. However, with TCPView, you can immediately see what processes those connections are from/to. Additionally, if any of those connections look questionable, you can close them by right clicking on the connection and choosing "Close Connection" from the popup menu.