Hi all,
As system administrators, especially when working with Microsoft based endpoints, you will very often reach a conclusion that “the specified port is most likely not open” or something very similar.
Now, it might be easy to pass the responsibility to others, and ask them to check, but sometimes it comes in handy to have some supporting information, to sustain your statement.
Of course, most people will be using telnet from a Command Line, or even the “a bit more evolved” Powershell command, Test-NetConnection, by the following syntax:Test-NetConnection -ComputerName MachineName -Port 25
These are good, but to be honest, what most won’t probably know, is that the results will be return only referring TCP (Transmission Control Protocol) connections. That means that UDP (User Datagram Protocol) connections will be ignored, or more correctly said, won’t be tested.
Here is where PortQry comes in. PortQry is a Microsoft developed tool, that used to be part of the Windows 2003 Support Tools suite. Since then, in order to work on newer Microsoft operating systems, it has evolved to PortQryV2 . It can be downloaded from here : https://www.microsoft.com/en-us/download/details.aspx?id=17148
The PortQryV2 tool can be used in three modes, the most common one being the Command-Line Mode. Please see in the below image, the help listed for the Command-Line Mode:
The most common parameters you can use in Command Line Mode are listed below:
Command line mode options:
-n [name_to_query] IP address or name of system to query
-p [protocol] TCP or UDP or BOTH (default is TCP)
-e [endpoint] Single Port to query (valid range: 1-65535)
-r [end point range] Range of ports to query (start:end)
-o [end point order] Range of ports to query in an order (x,y,z)
-l [logfile] Output a log file
-sl 'slow link delay' Wait longer for UDP replies from remote systems
The second mode that can be used, which is an alternative to the Command Line Mode, is the interactive mode. To access the interactive mode, you should run in CMD :portqry.exe -i
Then you can type in help to explore the available options
The third option, is Local Mode, in which you can analyze the opened ports and protocols on the computer you are working from (local). To use this, type in the command line prompt:portqry.exe -local
Now, as working examples, let’s assume we want to analyze if the 80 port is open, for both TCP and UDP, on a domain controller. We will execute the command:PortQry.exe -n DomainController -e 80 -p both
And the results will be :TCP port 80 (http service): NOT LISTENING
UDP port 80 (unknown service): NOT LISTENING
But if we analyze the 53 (DNS) port on the same domain controller, we will have the following result because the 53 port works on both TCP and UDP.PortQry.exe -n DomainController -e 53 -p both
TCP port 53 (domain service): LISTENING
UDP port 53 (domain service): LISTENING
One thing that you need to be aware of, is the 3 possible responses you can get from the PortQry Tool:
- LISTENING – A process is listening on the port on the computer that you selected. Portqry.exe received a response from the port.
- NOT LISTENING – No process is listening on the target port on the target system.
- FILTERED – The port on the computer that you selected is being filtered. Portqry.exe did not receive a response from the port. A process may or may not be listening on the port. By default, TCP ports are queried three times, and UDP ports are queried one time before a report indicates that the port is filtered. This might mean there is a firewall in place, that can block the traffic.
Also, for the really lazy ones 🙂 , there is a GUI-based alternative, that can be downloaded from here: http://download.microsoft.com/download/3/f/4/3f4c6a54-65f0-4164-bdec-a3411ba24d3a/portqryui.exe
The interface is very simple to use and will allow you select services from a drop down list, or enter ports manually.
