By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Using NetStat commands is one way to see information about every network connection active at the time the tool is run; it does not keep track of any historical connectivity.
By default, NetStat will display a list of every local and remote IP address and port. This includes applications that are communicating locally on that host, not actually using the network as we normally think of it. Usually you also want to see ports that are listening, so you'll want to use the command-line argument "-a", which displays all connections and listening ports. By adding " -n", "netstat –an" name resolution will not occur, so we'll only see IP addresses and not fully qualified names.
|Table Protocol||Local Address||Foreign Address||State|
The above output is helpful, but it has two obvious limitations: It's not historical and it does not show what process is responsible. The first is a limitation of NetStat and the second is easily corrected using the argument "-b" or "dash" for a more verbose version. We can now see the processes responsible for the communication and the DLLs each process is using. The following screen shows Skype (VOIP and IM client) using process ID 1776, listing my local IP (192.168.3.50), connecting to an IP ending in .135.183, the ports involved on both sides of the connection, and the application responsible (skype.exe).
Table 2 - Netstat view of a process
If we want a more complete network activity log we could script NetStat to run regularly and log the output, but a better option would be a tool that stores data historically. There are many options for this, but I'm going to stick to free Microsoft utilities for the scope of this answer. One option is the Microsoft (formerly Sysinternals) TCPView tool. An alternate option, which I'll focus on, is Microsoft's Port Reporter tool. After downloading Microsoft Port Reporter, extracting it to a folder, and running the application "pr-setup.exe," you will have a new Windows service called Port Reporter, which is set to manual start. When you start this service all network activity will be logged to a set of files in: %windir%\system32\LogFiles\PortReporter. The logs are explained in detail in Microsoft KB article 837243. The logs are much more verbose than the output of NetStat and will give a substantially more complete view of the network activity than provided by NetStat. By default, the logs will roll over at 5MB, which, on a system with a lot of network activity, may be insufficient. The "-ls" command adjusts the log size and the "–ld" option controls the log directory. You may want to use these options in the service's start parameters as required by your specific needs. Microsoft provides an additional tool, as a separate download, called Port Reporter Parser. This application loads the PR-PORTS log file (which is not the only log file) and provides a convenient interactive view of the network activity.
The tools option shows several report views of the data including "Process Usage," "User Context Usage," "Port Usage by Hour" and "Report IP Address Usage."
Since Microsoft Port Reporter requires installation and modifies the system you are working on, it makes changes to the system you are collecting data from. If you are collecting information as part of an incident response situation you need to be aware that you are installing software and creating log files (overwriting unallocated disk sectors), adding new software in memory (that could contain artifacts related to your incident), and modifying the Windows registry. When responding to an incident, these steps might be perfectly acceptable to improve your knowledge of the incident, but the risks should be considered and the actions well documented as you do them.
Lastly, note that the tool and techniques I've described here do not monitor the content of network activity. These tools also depend on the underlying operating system to collect this information. If that operating system has been compromised then the data provided to, and then reported by, the applications may be faulty. During incident response efforts, data from non-affected devices, such as firewalls, routers, and other devices, should be used where possible.
Tom Chmielarski is a senior consultant with GlassHouse Technologies, Inc.
Send Tom your security questions.
Join us on LinkedIn.