Provide Feedback on this Broadcast

Note This document is based on the original spoken WebCast transcript. It has been edited for clarity.

Tim Rains: Hello. My name is Tim Rains, and I will be discussing a tool that I developed recently, named Port Reporter.

(Slide 2) During this presentation I will give you an introduction to the tool, I will tell you how to install it, and I will discuss its functionality.

(Slide 3) First, let me tell you what Port Reporter does. It is an application that runs as a service. This service logs TCP and UDP port usage data. This data is detailed enough so that you can use it for a variety of reasons, including troubleshooting, security audits, application development, and profiling an application's port usage.

(Slide 4) Port Reporter runs on Microsoft® Windows® 2000, Windows XP, and Windows Server™ 2003. Windows XP and Windows Server 2003 systems have APIs that allow Port Reporter to log ports that are used and the time that they are used, processes that use the ports, whether a process is a service, all the modules that each process has loaded, and the user account that each process runs under.

(Slide 5) Windows 2000 systems do not have the same APIs as Windows XP and Windows Server 2003. This makes it more difficult to map a process to the ports that it is using.

Currently, Port Reporter is limited to reporting ports that are in use and the time that they are used on Windows 2000 systems.

At some point, Port Reporter and/or Windows 2000 may be updated so that Port Reporter can log process-to-port mappings, just like it does for Windows XP and Windows Server 2003 systems.

(Slide 6) I developed a tool called PortQry. Originally this tool was used as a TCP/IP connectivity-testing tool. Recently I added functionality to this tool so that it could give us detailed information on the local ports used by a system.

(Slide 7) PortQry 2.0 allows you to dump all of the ports currently used by the local system, to watch a specified port for activity, or to watch all of the ports used by a specified process for activity. On Windows XP and Windows Server 2003, this data includes process-to-port mappings.

(Slide 8) The following slides show you some example output from the PortQry -local command. Below you can see the process ID that is mapped to each TCP and UDP port in use in the list. You can see the state TCP connections, the remote ports, and remote IP addresses involved in communicating with the system.

(Slide 9) PortQry then gives you data on the services and the ports they are using. In this example, you can see that four services are sharing this process, and you can see the various ports that are in use by the services.

(Slide 10) Finally, PortQry shows you all of the modules that are loaded by the process.

(Slide 11) I wanted to develop a service that provides the same type of data as PortQry. The advantage of a service is that it can start when the system starts up, and it can run under the System account so that it can access more information.

(Slide 12) Installing Port Reporter is easy. Just run pr-setup.exe, and it will create a Port Reporter directory under your system's Program Files directory. The installer will do all the work necessary to run Port Reporter.

(Slide 13) If you want to install Port Reporter in a different directory, you will have to manually create the install directory, manually copy Portreporter.exe into that directory, and ensure that the directory has appropriate security. It is important that you set the access control list on the installation directory to only allow Administrator and System account access. Otherwise other users may get access to this service, which runs under the System account, and which could turn into a security problem.

(Slide 14) To start Port Reporter, you need to go to the Control Panel, double-click Administrative Tools, and then double-click Services. In the Services snap-in, you can start the service by clicking Start in the Port Reporter service properties. From this location, you can also configure this service to start automatically when your system starts by changing the service start-up type.

(Slide 15) I have updated the original installer that I built so that it will automatically start the service for you, and it will configure the startup type to automatic as well. To do this, use the -a option when you are installing Port Reporter.

(Slide 16) When Port Reporter starts, it will create a PortReporter directory under the %systemroot%\System32\LogFiles directory. It will create log files in this directory. The name of each log file follows a format so that you can tell when it was created.

Each time Port Reporter is started, three logs are created: PR-INITIAL, PR-PORTS, and PR-PIDS. It will also create new logs at midnight each day or as the size of the log exceeds 5 MB.

(Slide 17) Let's talk about each one of these logs. The PR-INITIAL log file contains data that's essentially the same as PortQry -local. It dumps all of the ports, services, and modules that a system is using.

The user context that each process is running under is also logged. On a Windows 2000 system, this log will be empty, because the port-to-process mapping is unavailable.

So the idea behind the PR-INITIAL log file is that it is an initial snapshot of the condition of the machine when the Port Reporter service starts up.

(Slide 18) Then, port usage is logged to the PR-PORTS log file. This log file will contain a summary about the TCP and UDP port activity on the local system. This data is logged in a comma-separated value format, and you can see the format here on this slide. The details include the date, the time, the protocol used, the local port that was used, the local IP address that the port was bound to, remote port, the remote IP address that may be communicating with that port, the process ID, the name of the module, and the user context that the module is running under.

On Windows 2000 systems, again, this output is currently limited to the date, time, protocol, local port, local IP, remote port, and remote IP address. So what we're missing on the Windows 2000 system log is the PID, the module, and the user context.

(Slide 19) Here is an example of what a PR-PORTS log file looks like. Again, you can see the time and date; the protocol used; the port, both remote and local; the IP addresses involved, both remote and local; the PID and the module that the PID actually maps to; and the user context at the very end of each line, identifying the account that the process is running under.

(Slide 20) Each time a line is logged into that log, that indicates that there has been a change on the system. Port Reporter only logs changes after it starts. It watches for port usage — so connections to a TCP port, for example, or a new UDP port starting up.

Changes may include an increase or a decrease in the number of connections on a port, or a change in connection states of existing connections. And Port Reporter monitors these types of changes.

(Slide 21) To give you an example, Port Reporter will make a log entry when the state of a TCP connection changes. An example of this is when we have an established connection to TCP port 25. That connection goes from established to the Close_Wait state. Port Reporter will log that change. It will actually show that there is now a port in the Close_Wait state and all of the details of that connection.

On this slide, you can see the different types of TCP connection states that Port Reporter is capable of seeing.

(Slide 22) It is also capable of logging changes to UDP port status. It doesn't log when UDP packets are sent to the system. That would be more of a function of a firewall or some sort of a filter running between the TCP/IP stack and the wire.

Port Reporter is not a filter. It runs above the TCP/IP stack. So essentially it gets all of its data from the TCP/IP stack itself. Its purpose is not to log packets to or from a machine; its purpose is to log TCP and UDP port activity that the TCP/IP stack tracks.

I'll give you an example here. Let's say a Trivial File Transfer Protocol (TFTP) server started up on the local system and bound to UDP port 69; Port Reporter would log that this service bound to UDP port 69 on the local system. It would tell you about the modules that service has loaded. It would tell you the user accounts that that service is running under. And it would show you all of the ports that this service was using.

(Slide 23) The third log file that the Port Reporter service creates is called the PR-PIDS log file. The PR-PIDS log file contains detailed information about ports, processes, related modules, and user account processes running on the system.

Each line in the PR-PORTS log that we looked at, two or three slides ago, has a corresponding entry in the PR-PIDS log. Essentially, the PR-PORTS log is summary information. And to get the detailed information for each summary line in that log, you would look for the corresponding entry in the PR-PIDS log file.

(Slide 24) Here is an example of the PR-PIDS log file. You can see the time and date that the log file entry was made. Essentially you can take the time and date stamp that's on the log entry in the PR-PORTS log file and match that time and date to the entry in the PR-PIDS log file, so that you can see the detail for each line in the PR-PORTS log file.

Here you can see the detail includes the process ID and the name of the process using the port, the user context, whether the actual process is a service or not, a listing of all of the ports and their various states that the process is using, some statistics on the process, the port usage, and then a listing of all the modules that that particular process has loaded.

Essentially, the three log files that we discussed — PR-INITIAL, PR-PORTS, and PR-PIDS — give you a snapshot of the port usage when the service starts. They give you summary data on the ongoing port usage of the system, and then detailed data on the ongoing port usage of the system.

Essentially, the snapshot is the PR-INITIAL log file; the summary data is the PR-PORTS log file; and the detail data is the PR-PORTS log file.

(Slide 26) Currently I'm working on a Port Reporter Parser. This parser will be a tool with a user interface that makes it much easier to look at these log files. So currently you can open up the log files in Notepad, Word, or whatever text editor you have, and you can go through the log files and look for the data.

The idea behind the parser is to give you a tool that will open the log files and display the data in an easy-to-read format, and give you some ability to do some analysis on the ports and the port usage that's logged within the log files.

I hope to have the parser available in the near future. When it is available, you'll be able to download it off a link in the Port Reporter KB article.

(Slide 27) What is the Port Reporter KB article? Well, it's 837243, and within that article you can download the Port Reporter service. Again, if and when I have the Port Reporter Parser done, a link will also be in that article for that tool.

I've included a few more references on PortQry, 832919 and so on (310099, 310456, and 310298). And PortQry is available for download from the download center as well, and from links within each one of these articles.

Thank you for joining me for this presentation today.