Take the mystery out of network-traffic analysis
|
By
Ryan Russell
The free TCPView utility shows which programs are responsible for which network connections. Free up bandwidth and stay safe by identifying the network links that you don't need or that jeopardize your security. |
Identify the apps that are reaching out
In my Apr. 24 column, I mentioned in passing Microsoft's free TCPView utility (developed by Sysinternals), which displays all the network connections made to and from your computer and identifies the program responsible for each connection.
Suppose you find some interesting network traffic by using Wireshark, the packet-monitoring utility I described in the previous column, and you wonder which program is responsible for the transmission. Since Wireshark works at the network-driver level, the monitor has no idea which program is generating which packets.
In some cases, the source will be obvious from the traffic. For example, many ports are assigned to specific purposes. If a computer has connected to yours at port 1433, it's a fairly safe bet that SQL Server is responsible for the connection, since the program is assigned to that port.
However, you probably have dozens of programs installed on your computer that are HTTP clients and thus use port 80. These include not only the obvious Web browsers but also any self-updating programs such as media players, games, and many Office-type applications. How do you know which program initiated the network session? TCPView can show you.
Link a program to its network connections
Unlike most other network-monitoring utilities, TCPView is simple and single-purpose. The program displays everything you need to see in one window, and you probably won't need to change the utility's default settings (see Figure 1).
Figure 1. TCPView shows you the program behind the network link.
The Process column tells you the name of the program initiating the connection, which is the information you're after most of the time. If you see suspicious traffic in Wireshark or another packet-monitoring program, note its IP addresses, port numbers, and protocol. Open TCPView and use the information from the packet monitor to identify the program.
About 95% of the time I use TCPView to track down the app behind a connection, I think to myself, "Well, that explains it" and leave things as is. The rest of the time, I decide that the program in question doesn't need to be dialing out and shut it off. On rare occasions I find something really wrong, such as an active piece of malware that needs to be removed from the computer.
The program's network-monitoring blind spots
TCPView is live-view-style, which means the information displayed by the utility eventually vanishes from the screen. If you don't act fast, you may not see your active network ports listed. TCP connections stick around in a waiting state for a short period of time after they close, so you usually have a minute or two to identify them.
Also, the program seems to monitor only TCP and UDP connections. If you open a command prompt and ping an IP address, the connection will not show in TCPView's window. This is usually a problem only if something really stealthy is communicating via a custom protocol.
One final bit of strangeness: on my XP system, a number of outbound HTTP connections claimed to be coming from [System Process]:0. This worried me a little bit.
However, by monitoring traffic and applying the process of elimination, I discovered that the links were established by the iGridd Java applet for solving Griddlers logic puzzles. Griddlers are an entertaining — and harmless — waste of time. It would appear that Java does something a little funny with its network communications.
The Perimeter Scan column gives you the facts you need to test your systems to prevent weaknesses. Ryan Russell is quality assurance manager at BigFix Inc., a configuration management company. He moderated the vuln-dev mailing list for three years under the alias "Blue Boar." He was the lead author of Hack-Proofing Your Network, 2nd Ed., and the technical editor of the Stealing the Network book series.
Digg
Del.icio.us
Reddit
StumbleUpon
Other
Permalink
