Your computer systems probably use TCP and UDP for most of their communication, and all versions of Windows open many ports that provide useful functionality such as file sharing and remote procedure call (RPC). However, malicious programs such as Trojan horses can use ports nefariously to open a back door for attackers into your computer system. Whether you need to troubleshoot a necessary network service or detect unwanted programs, you need to be able to understand and manage the traffic between computers on your network. A basic step toward doing so is determining which programs are listening on your computer systems' network ports.
A network port scanner, such as Nmap, can help you determine whether an application or network service is installed and listening on a computer. For example, if you scan a Web server, you'll see that ports 80 and 443 are open. Some port scanners let you query an open port for information about the listening application. Typically, such a query requests a text banner, which should contain information about the application. However, the banner might be wrong or purposely misleading. For example, through a banner grab, a port scanner might report that the application listening on port 80 is Apache. If you run only Microsoft IIS, that report should make you suspicious that some other program might be masquerading as Apache. Depending on the results, you might need to actually log on to the computer and directly determine the application that's listening on that port.
Windows Server 2003 and Windows XP let you correlate process identifiers (PIDs) with open network ports. With the release of XP, Microsoft upgraded Netstat to support PID-to-network correlation, but Netstat still falls short in some areas. For example, Netstat shows only a process's PID, not its name; to find the process name, you need to use a tool such as Task Manager to resolve the PID to the name.
A less-well-known tool can assist with such network reconnaissance or forensic activity. That tool is PortQry, a Microsoft-focused network port scanner with local-host-monitoring features.
PortQry Overview
PortQry 2.0 runs on Windows 2003, XP, and Windows 2000 and displays the state of TCP and UDP ports on a local or remote system. PortQry isn't as feature-rich as most other network port scanners, such as Nmap or Foundstone's free SuperScan 4.0 and ScanLine. But when you run PortQry in its local mode on Windows 2003 or XP, it can map open ports to the names of the listening network applications all the way down to the DLL level. In addition, PortQry's reports are richer than Netstat-generated output.
When run in remote mode, PortQry shows you whether a port is open or closed. For some ports, such as the Lightweight Directory Access Protocol (LDAP) and RPC ports, PortQry returns additional information about the listening service. For example, when querying LDAP port UDP 389, PortQry returns useful information about the LDAP service, including its schema, configuration, and root-domain-naming contexts; LDAP version; and DNS host name.
PortQry is a command-line tool. However, the separately available PortQueryUI program, which I discuss later, provides a GUI for PortQry and includes several features that can make PortQry easier to use.
Using PortQry Remotely
To download PortQryV2.exe, go to http://www.microsoft.com/down loads/details.aspx?familyid=89811747-C74B-4638-A2D5-AC828BDC6983&dis playlang=en. After you download the scanner, run the self-extracting executable to uncompress the files to a directory of your choice. Portqry.exe is a very small (140KB) executable. From a command prompt, change to the directory in which you installed the utility and run portqry.exe to display all the run parameters. PortQry can scan remote systems, but it's slow and unsophisticated compared with other port scanners. For example, unlike Nmap, PortQry doesn't let you perform scans that use specified packet flags (e.g., SYN, FIN).
To determine whether a Web server is installed on TCP port 80 of a remote system whose IP address is 192 .168.0.8, you'd run the command
portqry -n 192.168.0.8 -e 80
The -n switch specifies the system name or IP address. The -e switch specifies the destination port, or end point, and precedes the port number. By default, PortQry scans use TCP, but you can specify a different protocol, as I explain later. If a Web server is active on the system, PortQry returns the output
TCP Port 80 (http service): LISTENING
Other switches let you customize PortQry's behavior. The -r and -o switches let you scan a range of consecutive ports or specify a list of individual ports, respectively:
portqry -r 10:100
portqry -o 53,80,443
Use the -sp switch followed by the port number to specify the source port. To change the default protocol, use the -p switch followed by UDP or BOTH. If you're scanning UDP packets across a slow link, use the -sl switch to specify a slow-link delay and instruct PortQry to wait longer for UDP replies from remote systems.
To scan an SNMP port, use the -cn switch followed by the SNMP community string delimited by exclamation marks:
portqry -cn !community_string!
where community_string is the SNMP community string. If you don't specify the correct community string, PortQry returns the result Filtered instead of telling you whether the port is open. PortQry gives you a quick way to check that all your systems are properly configured for your organization's community string—or to determine whether any system is listening on the well known Public community string.
PortQry also returns useful information from certain ports. For example, if you query the RPC endpoint mapper port (TCP port 135), PortQry returns information about all the services that are listening on that port.
Using PortQry Locally
What PortQry lacks in remote scanning features it makes up for with its unique local-machine capabilities. To enable local mode, run PortQry with the -local switch. When -local is the only switch used, PortQry enumerates all local port usage and port-to-PID mapping. Instead of sorting the data by open port, PortQry lists it according to PID, letting you quickly see which applications have open network connections.
PortQry lets you watch a specific local port or PID for state changes. To watch port 80, you'd run the command
portqry -local -wport 80
and PortQry would list all applications listening on port 80. For example, if you're running Microsoft IIS, PortQry reports that the W3SVC service is in the Listening state and lists other ports that the W3SVC service is using, such as port 443 for HTTP Secure (HTTPS). In addition, PortQry continues to run in the command shell and outputs all changes to activity on the port. Thus, if you subsequently open a Web browser and surf to the server that's running IIS, PortQry outputs that activity and reports the new Established connections, as Figure 1 shows.
To watch a specific application, run PortQry with the -wpid switch:
portqry -local -wpid PID
where PID is the application's PID. Watching a PID lets you easily monitor the network activity of a new application. Say you want to determine what ports Windows Messenger uses. You know that the program's executable is named msmsgs.exe, and you've seen it running in Task Manager. Start the executable msmsgs.exe (or verify that the Windows Messenger icon is in your system tray), then launch Task Manager. Click Task Manager's Processes tab and make sure that the PID column is displayed. If the column doesn't appear, click View, Select Columns, then select the check box next to PID (Process Identifier). Find the msmsgs .exe process and note its PID, then open another command prompt and launch PortQry with the -wpid switch and that PID.
As the truncated output in Figure 2 shows, the process whose PID is 2400 is waiting on UDP port 1127. If you remain in watch mode, PortQry displays this information until the utility detects a change. (PortQry checks for changes every minute.) For example, if you log in to Windows Messenger, PortQry automatically outputs a summary of the new activity to the command shell, as Figure 3 shows.
Now we know that Windows Messenger listens on port UDP 1127 and uses the destination port TCP 1863 for communication associated with logging in to the application. Also notice that Windows Messenger has initiated this connection with a remote IP address, 207.46.107.118, which corresponds to an IP address associated with msgr.hotmail.com, a part of the Windows Messenger network.
If you send an instant message, you'll see something more interesting. PortQry reports two new opened sockets. (A socket is the combination of a port and the remote IP address.) The new sockets are another port with destination TCP 1863 and a new port to destination TCP 80, as Figure 4, page 4, shows. TCP port 80 is used for HTTP and indicates that Windows Messenger accesses a remote Web server when sending an instant message. After a few minutes of inactivity, the TCP sessions end, the ports close, and PortQry reports that only the original two ports remain open.
This fairly trivial example demonstrates some of PortQry's value. Using Task Manager and PortQry, you can watch the activity of a specific application and discern the ports it uses. You probably knew that Windows Messenger uses TCP port 1863 but not that it also uses port 80 for HTTP. Also, watching a particular application would be difficult using a traditional network sniffer that records TCP/IP traffic. Netstat returns similar information about open ports, but it doesn't let you focus on a single PID or report only changes associated with new network activity.
PortQryUI
Microsoft offers a graphical front end, called portqryui.exe, to PortQry. You can download Port-QryUI at http://download
.microsoft.com/download/3/f/4/3f4c6a54-65f0-4164-bdec-a3411ba24d3a/PortQryUI.exe. PortQry-UI includes a version of portqry.exe and some predefined services, which consist simply of groups of ports to scan. These services are Domains and Trusts, IP Security (IPSec), Networking, SQL Service, Web Service, Ex-change Server, NetMeeting, and Miscellaneous. Web Table 1 (http://www .windowsitpro.com, In-stantDoc ID 44411) lists the individual ports and protocols that make up these services. You can specify your own groups of ports to scan by creating a custom XML configuration file.
When you use a predefined service for a scan, PortQryUI chains together multiple runs of PortQry, then displays the re-sults. For example, if you query Domains and Trusts, the front end initiates a series of PortQry scans of all Active Directory (AD)related ports (e.g., NetBIOS, DNS, Kerberos, LDAP, RPC).
One drawback to PortQryUI is that it doesn't support local mode, so you can't use it to watch PIDs or ports. And because PortQryUI initiates separate PortQry runs for each port, the output contains a lot of clutter, such as repeatedly listing when the scan starts. You can get cleaner results by simply running the command tool and specifying the particular ports. For example, the command
portqry -n 192.168.0.8 -o 135, 389,636,3268,3269,53,88,445, 137,138,139,42 -p both
returns a condensed version of Port-QryUI's results for a Domains and Trusts service scan. (You must type the command on one line and without inserting spaces between port numbers.)
Better Visibility
PortQry illuminates the network activity on your Windows systems. This small-footprint, easy-to-use scanner really shines when you use it in local mode. Make a place for it in your security toolkit—you'll be glad you did.
