Test port reachability from a remote host even though the port is not bound to a service?

Question

I need to check whether a remote host is able to reach a specific port. At the time of test the service bound to that port will be down.

The possible issues that the test would address would be :

• The network allows the remote host to reach the port.
• The firewall on the host ( receiver ) allows the remote host to connect to that port.

I've tried telnet. However telnet returns non-zero exit code if a service is not bound to that port. What could be the possible options?

UPDATE :

Can't we have an nmap way to do this? Any output with the filtered state should mean a red flag.

Sample command: $ nmap -v 120.114.24.56 -P0 -p 8080

Ref: http://nmap.org/book/man-port-scanning-basics.html

The six port states recognized by Nmap – ( the ones marked in red should ideally be a red flag to us )

open

An application is actively accepting TCP connections, UDP datagrams or SCTP associations on this port. Finding these is often the primary goal of port scanning. Security-minded people know that each open port is an avenue for attack. Attackers and pen-testers want to exploit the open ports, while administrators try to close or protect them with firewalls without thwarting legitimate users. Open ports are also interesting for non-security scans because they show services available for use on the network.

closed

A closed port is accessible (it receives and responds to Nmap probe packets), but there is no application listening on it. They can be helpful in showing that a host is up on an IP address (host discovery, or ping scanning), and as part of OS detection. Because closed ports are reachable, it may be worth scanning later in case some open up. Administrators may want to consider blocking such ports with a firewall. Then they would appear in the filtered state, discussed next.

filtered

Nmap cannot determine whether the port is open because packet filtering prevents its probes from reaching the port. The filtering could be from a dedicated firewall device, router rules, or host-based firewall software. These ports frustrate attackers because they provide so little information. Sometimes they respond with ICMP error messages such as type 3 code 13 (destination unreachable: communication administratively prohibited), but filters that simply drop probes without responding are far more common. This forces Nmap to retry several times just in case the probe was dropped due to network congestion rather than filtering. This slows down the scan dramatically.

unfiltered

The unfiltered state means that a port is accessible, but Nmap is unable to determine whether it is open or closed. Only the ACK scan, which is used to map firewall rulesets, classifies ports into this state. Scanning unfiltered ports with other scan types such as Window scan, SYN scan, or FIN scan, may help resolve whether the port is open.

open|filtered

Nmap places ports in this state when it is unable to determine whether a port is open or filtered. This occurs for scan types in which open ports give no response. The lack of response could also mean that a packet filter dropped the probe or any response it elicited. So Nmap does not know for sure whether the port is open or being filtered. The UDP, IP protocol, FIN, NULL, and Xmas scans classify ports this way.

closed|filtered

This state is used when Nmap is unable to determine whether a port is closed or filtered. It is only used for the IP ID idle scan.

Answer 1

This is difficult (if not impossible) to do depending on your access to resources.

If its a Unix based server I'd run tcpdump on the server (in such a way that it only listens to the traffic on the port you are interested in), and then try and connect to it via Telnet. Telnet will, of-course fail, but at least you should see the incoming server attempt through tcpdump [ even though only the incoming traffic as there is nothing to respond ]. This would mean the traffic is getting to the box - it does not mean there is not a firewall on the box preventing a program from working of-course.

Answer 2

If nothing is listening on the server already, then I usually simply start a service on the port. Modern firewalls may use packet inspection though, so it's no guarantee that what you aim to have listening on the port is going to work.

You can do this with nc like (for example for TCP on port 6667)

nc -l 6667

Then try telnet or nc on the sending end. If you don't have nc, you can craft a simple socket listener with perl and for example IO::Socket::Inet, or with python or powershell, depending on the platform.

For UDP you can use nc with the -u flag, but this you can't verify with telnet, but nc works in the sending end aswell.