Portqry Remarks

Article
10/08/2009

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

PortQry Remarks

Special Features

PortQry improves on typical port scanning utilities by giving additional UDP-port status detail, and by providing protocol-specific support.

Determining the status of UDP ports depends on a response from the process that is listening on each UDP port. If an unformatted zero-length or fixed-length message is sent to a target UDP port, the port may not respond.

If the target port does respond, it is characterized as listening. If an "ICMP destination unreachable" message is returned from the port, the port is characterized as not listening. However, some port scanning utilities report that the port is listening simply if an "ICMP destination unreachable" message is not returned from a target port. This may, in fact, be inaccurate, because no response to a directed datagram may also indicate that the target port is being filtered. Usually only a properly-formatted message using the session layer or application layer protocol that the listening service or application understands, elicits a response from the target port.

When you are troubleshooting a connectivity problem, especially in an environment with firewalls, it is useful to know whether a port is first being filtered, or if it is actually listening. PortQry pinpoints this distinction on selected ports.

If there is no response from a target UDP port, PortQry reports that the port is "Listening or Filtered." Then, PortQry sends a properly-formatted message, using the session layer or application layer protocol that the listening service or application understands, to determine if the port is in fact listening.

PortQry supports the following session/application layer protocols

NetBIOS Name Service

By default, this service listens on UDP port 137. If PortQry receives no response from port 137, it reports that the port is "Listening or Filtered," and then determines whether the port is actually listening. If NetBIOS is available on the computer that is running PortQry, PortQry sends a NetBIOS adapter status query to the target computer. If the target computer responds to the query, PortQry reports the port status as Listening and returns the target computer's Media Access Control (MAC) address to the user.

DNS

PortQry can also send a properly formatted DNS query, by using UDP and TCP. PortQry first sends a DNS query, then waits for a response from the server. Whether the DNS response to the query is negative or positive is irrelevant, because any response indicates to PortQry that the port is listening.

RPC

PortQry can send a query to the RPC endpoint mapper (by using UDP and TCP) and interpret the response. This query dumps all of the endpoints that are currently registered with the RPC endpoint mapper. The response from the endpoint mapper is parsed, formatted, and returned to the user. Portqry Examples.

LDAP

PortQry can send an LDAP query (by using UDP and TCP) and interpret an LDAP server's response to the query. The response from the LDAP server is parsed, formatted, and returned to the user.

To query LDAP, PortQry automatically resolves UDP port 389 by using the %SystemRoot%\System32\Drivers\Etc\Services file that every Windows Server 2003, Windows XP, and Windows 2000-based computer has by default. If PortQry resolves the port to the LDAP service, it sends an unformatted user datagram to UDP port 389 on the target computer. However, PortQry does not receive a response from the port because the LDAP service responds only to a properly-formatted LDAP query. So, again, PortQry initially reports that the port is "Listening or Filtered."

PortQry then sends a properly-formatted LDAP query to UDP port 389. If PortQry receives a response to this query, it returns the entire response to the user, and reports that the port is Listening. If PortQry does not receive a response to the query, it reports that the port is Filtered. Portqry Examples.

Port Status Reporting

PortQry characterizes port status as one of the following three states:

Listening

A process is listening on the target port. PortQry received a response from the port.
Not Listening

No process is listening on the target port. PortQry received an Internet Control Message Protocol (ICMP) "Destination Unreachable - Port Unreachable" message back from the target UDP port. Or, if the target port is a TCP port, PortQry received a TCP Acknowledgement packet with the Reset flag set.
Filtered

The target port on the target computer is being filtered. PortQry dides not receive a response from the target port. A process may or may not be listening on the port. By default, TCP ports are queried three times; UDP ports are queried once before reporting that the target port is Filtered.

While PortQry supports querying a range of ports, its performance has not been optimized for security assessment. In particular, querying large ranges of TCP ports can be time-consuming and is not recommended.

PortQry Errorlevels

When using the /q parameter with PortQry from within a batch file, PortQry returns errorlevels based on the status of the target port. PortQry returns an errorlevel 0 if the port is Listening, 1 if the port is Not Listening, and 2 if the port is Listening or Filtered.

The Services File

In order to send protocol-specific queries, PortQry must first determine what protocol to use. On computers running Windows 2000 or later, this information is stored in the Services file, located in the %SystemRoot%\system32\drivers\etc directory. PortQry also uses the Services file to resolve the port name.

Using PortQry in a Batch File

You can use the /q parameter when running PortQry from a batch file, to report errorlevels based the status of the target port. PortQry returns an errorlevel 0 if the port is listening, 1 if the port is not listening, and 2 if the port is listening or filtered.

Querying Filtered TCP Ports

PortQry was developed as a trouble-shooting tool, rather than a security assessment tool. While PortQry supports querying a range of ports (by using the /r parameter), its performance has not been optimized to handle querying large ranges of TCP ports that may be filtered.

Share via