"For a complete guide to security, check out ''Security+ Study Guide and DVD Training System'' from Amazon.com"

Using PortQry

If you did not read part one of this article, I suggest viewing my library and checking it out. It covers the fundamental usage of using the PortQry command line tool in normal and interactive modes. This article assumes that you have read part one of the set. In this section we will cover the scanning of other protocols. Let’s start with LDAP on Windows Hosts.

Scanning for LDAP

So, how would you determine whether LDAP is available on a node or not? You can use PortQry to test it. As was discussed in part 1, telnet doesn’t provide a good test for UDP-based ports, for example, lets say, you wanted to verify that your Windows client could verify connectivity to an Active Directory DC? How could you do this with telnet?

Here is an example where I scanned a Windows 2000 Domain Controller:

C:\WINDOWS\SYSTEM32>PortQry -n 10.1.1.2 -p udp -e 389

Querying target system called:

10.1.1.2

Attempting to resolve IP address to a name...

IP address resolved to DC2

querying...

UDP port 389 (unknown service): LISTENING or FILTERED

Using ephemeral source port
Sending LDAP query to UDP port 389...

LDAP query response:
currentdate: 11/1/2004 16:20:13 (unadjusted GMT)
subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=1,DC=com
dsServiceName: CN=NTDS Settings,CN= DC2,CN=Servers,CN=Default-First-Site-Name,CN=com
Sites,CN=Configuration,DC=1,DC=com
namingContexts: CN=Schema,CN=Configuration,DC=1,DC=com
defaultNamingContext: DC=1,DC=com
schemaNamingContext: CN=Schema,CN=Configuration,DC=1,DC=com
configurationNamingContext: CN=Configuration,DC=1,DC=com
rootDomainNamingContext: DC=1,DC=com
supportedControl: 1.2.840.113556.1.4.319
supportedLDAPVersion: 3
supportedLDAPPolicies: MaxPoolThreads
highestCommittedUSN: 241215
supportedSASLMechanisms: GSSAPI
dnsHostName: dc2.1.COM
ldapServiceName: 1.COM: dc2$@1.COM
serverName: CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configurati
on,DC=1,DC=com
supportedCapabilities: 1.2.840.113556.1.4.800
isSynchronized: TRUE
isGlobalCatalogReady: TRUE

======== End of LDAP query response ========

UDP port 389 is LISTENING

So this looks familiar to the example in part 1 correct? The only difference is the output, because it is listening as you can see from the last statement in the output.

To quickly remind you of the syntax used:

• the –n identifies your server, which is 10.1.1.2
• the –p identifies your protocol (in this case, UDP),
• the –e signifies an endpoint or the port you specifically want to query such as LDAP, in this example, listening on port 389

Installing and using the PortQryUI

Port Query UI tool (portqueryui.exe) is a tool to query open ports on a machine. This tool makes use of command line version port query tool (portqry.exe) and provides an interface that can be viewed.

To get the tool from Microsoft.com, click here: PortQryUI

Once you download it, it can be launched by opening up the source folder and clicking on the portqryui.exe file.

Once you open it you will have many new (and cool) options. One of which is the automated predefined profiles for scanning as seen above. You can now pick a ‘class’ of what you want to scan and the UI will scan all the relevant services and then show you the output on the bottom of the Port Query UI tool.

With just a basic scan of ‘Domains and Trusts’, you can see that the output is in the ‘Query Result” Window on the bottom of the tool. Port 129 is not listening because it’s simply disabled. It doesn’t work. Try getting this much information with telnet.

Note:
You may want to run this tool against your won system (like I just showed you here with a lab system), the loopback address or IP that the system currently has will show you open ports on your own system! This tool can show you quickly what ports are open on your system. You can also get this information with Netstat:

Tweaking PortQry

While researching PortQry and what it could do, I found out that the tool actually uses a file in your %systemroot%\system32\drivers\etc directory called “Services”.

PortQry.exe uses this file to resolve the port numbers so it’s really important that you know this… if you change port numbers (like 80 to 8080 for example), you will have to change it in this file as well. If you need to change it back, then you can either have made a copy of it in this directory and named it ServicesBU or something, or you can visit the protocol number registry to get the standard port assignment back. The link is located at the end of this article.

Summary

In this article we covered some advanced uses of PortQry, a Microsoft developed tool that can help you to troubleshoot connectivity problems that you may encounter, much like the email issue shown in this article. PortQry is a great little tool to have in your tool belt when you need to verify if a port is open, closed, or being filtered somehow. Make sure you read the first part too! Stay tuned for more command line troubleshooting tips, you never know when these may get you out of a jam!

Links and Reference Material

PortQry Command Line Port Scanner Version 2.0

IANA – Port Assignments
http://www.iana.org/assignments/port-numbers

Read Part 1
http://www.WindowSecurity.com/articles/Mastering-PortQryexe-Part1.html