Assessing the Risk: which TCP/UDP ports does your favorite application use?

  • Article

In order to determine how to implement security on your Windows system(s) you need to assess and understand the ways in which your individual systems can be compromised. Systems can be very unique depending on the role of each system and the software that is running on each system. Generally speaking, the more roles a system plays and the more software that a system is required to run, the more ways that system can be attacked. One of the first steps in hardening a system is to determine the role that the system is going to play and then turn off and/or uninstall as many unnecessary applications and services as possible.

It is important that you understand how an application is going to behave before you run it on a system attached to a network and/or the Internet. You need to answer some basic questions about your applications:

  • Does the application require TCP/IP in order to install and run? If it does, you need to understand why.
  • Which TCP and/or UDP ports does the application’s author state that the application uses? Some developers document this better than others. The list you get from the author may be exhaustive, but more likely it will be incomplete.
  • Does the application listen on or bind to specific ports while the application is running? If it does, it is prudent to understand what kind of traffic those ports are expecting and from which systems.
  • Can the list of ports that you developed from the questions above be mapped to specific functions within the application? For example, does a specific port get used when you make a specific menu selection within the application? This is probably a very tough question to answer, but worthwhile if you can answer it.

This level of detail may sound like its a little overkill, but attackers are using ever-improving tools and are spending a lot of time reverse engineering software. Even if your systems run behind firewalls or have host-based firewalls installed on them, the applications that the systems run can still be attacked depending on how those applications use the network.

Network monitor and other tools that watch the network traffic that goes to/from a system only report part of the picture. These tools only catch the traffic that a system either puts on the wire or receives from the network. They do not log which ports are listening or are bound to the network interface(s) on a system unless those ports are actually used while the capture is taken.

There are some good tools available to help you determine what ports are in use and which applications are using them. One such tool, for example, is: https://www.sysinternals.com/ntw2k/source/tcpview.shtml

I have also developed some tools which can also help do this, one of which I mentioned in my last blog on Port Reporter and Port Reporter Parser: https://weblogs.asp.net/tim_rains/archive/2004/09/02/224905.aspx

These tools can be useful when trying to “profile” an application’s port usage.

Another popular tool that I developed to help get this type of data is called PortQry. This tool will give you this type of data in near real time as opposed to Port Reporter which is good for supplying data for post-usage analysis over a longer period of time. Most people think of PortQry as a TCP/UDP port scanner - and it is. But, in version 2.0 I added a lot of functionality into PortQry so that it could get data on the local system’s TCP/UDP ports.

Three PortQry options can help gather this type of data:

  • portqry –local
  • portqry –wport
  • portqry –wpid

On a Windows XP or Windows Server 2003 system the command “portqry –local –v “ will provide a “snapshot” of all of the ports and process data currently running on the system. This data is very similar to the type of data you will find a PR-INITIAL-*.log file created by Port Reporter. It shows you each process running, any ports each process is using (including their state and remote IP/port data), and a list of the modules that each process has loaded.

Running “portqry –wport –v” allows you to watch a specific port for activity. This can help determine what process (or processes) uses a particular port and when/how the port gets used. For example, if you see a system using a particular port (say TCP port 4444) in firewall logs, and want to see which application is actually using the port you can watch it by running portqry –wport 4444 –wt 1 –v. The –wt option allows you to specify how often to check for changes (in seconds). The –v option (verbose) will list all the modules that the process has loaded. This output can also be logged to a text log file using the –l option.

Running “portqry –wpid –wt 1 –v” allows you to watch a specific process (process ID) for port activity. This can help determine what ports are used by particular process and when/how the ports get used. I found it really interesting watching applications (some that I supported for years) and which ports they actually use. In some cases this data was merely interesting and in other cases it was an eye opening revelation. Again, the –wt option specifies how often to check for changes (in seconds) and –l can be used to log the output to a text file.

Port Reporter has some advantages over PortQry. Because it runs as a service which in system context, it can provide a more complete, long term picture of port and process usage. It is also much more efficient in the way it monitors ports. But it must be “installed” on a system and it takes more time to analyze the data. PortQry is a small (140 KB) command line utility that can simply be copied onto a system (no installation program, no registry entries) and then deleted afterwards. Keep in mind that neither of these tools is designed to show you all of the traffic coming to and/or leaving a system. You need a network sniffer like Network Monitor to get that type of data.

You can read more about PortQry version 2.0 in this Knowledge Base article: https://support.microsoft.com/default.aspx?scid=kb;en-us;832919

Whether you use a tool that I have mentioned here or other good tools, understanding how your applications use the network is crucial to protecting them. After-all the last question you want to ask during the next big worm attack is equivalent to “SQL Server uses UDP port 1434?” ;>)