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.
Prev. page
[1]
2
next page 
