Tip

Using NetStat commands and Microsoft Port Reporter tool to find network connections

SearchMidmarketSecurity.com reader: How can I know what programs are connecting to the Internet or other systems on my network?

    Requires Free Membership to View

Tom Chmielarski: There are several ways to enumerate the network connections your system makes. If your system has an active host-based firewall, and it probably should, then those logs might be the best place to look. If you want a point-in-time answer, then the utility NetStat, which comes bundled with all versions of Windows), is a simple solution.

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.

Active Connections
Table ProtocolLocal AddressForeign AddressState
TCP127.0.0.1:1050127.0.0.1:27015Established
TCP127.0.0.1:1064127.0.0.1:1065Established
TCP127.0.0.1:1065127.0.0.1:1064Established
TCP127.0.0.1:1091127.0.0.1:1092Established
TCP127.0.0.1:1092127.0.0.1:1091Established

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
netstat view 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.

Table 3 - Port Reporter Parser

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."

Table 4 - Port Reporter Parser Reports

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.

This was first published in September 2010

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.