Ports Showing Closed/Filtered in Nmap Scans

Question

hopefully this isn't a stupid question.. I am running some nmap scans and I get a list of ports that show closed. Why would they even show in the scan report? Can these be exploited further with other nmap switches such as zombie scans etc? I specified all ports in my scan using -p- .My thought is that it would show a large list of all closed ports on my system not just those?

Here is the command I ran: nmap -iL axisips.txt -A -sV -p- > axisnmapresults2.txt

Host is up (0.062s latency). Not shown: 65525 filtered ports PORT STATE SERVICE VERSION 17/tcp closed qotd 19/tcp closed chargen 25/tcp closed smtp 111/tcp closed rpcbind 136/tcp closed profile 137/tcp closed netbios-ns 138/tcp closed netbios-dgm 139/tcp closed netbios-ssn 443/tcp open ssl/http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) |_http-server-header: Microsoft-HTTPAPI/2.0

Answer 1

To avoid 65K+ lines of mostly-useless output, Nmap collapses most "uninteresting" results into a line that says something like "Not shown: 65530 filtered ports." Open ports are never collapsed this way, but closed (TCP RST) and filtered (no response or ICMP admin-prohibited) ports are only shown if there are fewer than a certain number.

In your case, I would guess that most of the ports are "filtered" but a few are "closed" instead. There are many reasons this might be the case, but the most likely are:

1. Something between you and the target is blocking access to those ports by spoofing RST replies. This is common with residential ISPs blocking ports 137, 139, and 445, among others.
2. The target's firewall is allowing those ports, but there is no service running on them.

EDITED TO ADD: Based on the actual port output, I'm pretty sure this is ISP filtering (spoofing closed-port responses). Ports 17 and 19 are commonly used as DDoS amplifiers (though UDP, not TCP). Ports 137-139 and 445 have been exploited on Windows by network worms. Port 25 is for email servers, so ISPs block it unless you buy a business-class connection. I'm not sure about 111 and 136; those could be legitimately closed, or they could be blocked for some other reason. Add the --reason option to your scan to see details about IP Time-to-Live (TTL) in the response; abnormally high TTL values can indicate ISP blocking, especially if the TTL value for open ports is several hops lower (usually between 5 and 15 hops different or so).