When I ran nmap -sn x.x.x.x/24 on a network behind Cisco ASA firewall I get 255 hosts up even though there are only three hosts on that subnet.
If I run nmap -T4 -F x.x.x.x/24 I get all 254 IP addresses coming back with port 53 and 110 filtered
Is this likely the ASA doing something? know that there are only three hosts - a switch and two VMware hosts on this subnet.
You are probably perfectly right: Your firewall is "doing something". This is the role of a firewall. And possibly, one of the reasons to have a firewall might be to prevent port scans, by the way.
You have to ask yourself how nmap decides if a host is "there", "alive" or "up" or not. A naive idea often is to try and ping it, though ping is a specific TCP service which may be implemented and enabled or not and which may be filtered or not. So the rule of thumb here is: If you get a reply to a ping package, it is very likely that the host is up. If you don't get a reply, you simple did not gain a lot of information from that ping.
Having said that, in your examples, -sN (I guess this is what you meant as I think there is no option -sn in nmap) and -T4 -F are not contradicting scan methods, but in your second example, you are leaving it to nmap to decide how to scan, which means it will default to a SYN scan and fall back to a connect scan if it cannot perform a SYN scan. Note that the reason why it may not be able to perform a SYN scan may well be a problem with the client side, i.e. the permissions of the nmap process itself, not about the scan target.
From nmap.org:
[The SNY scan] technique is often referred to as half-open scanning, because you don't open a full TCP connection. You send a SYN packet, as if you are going to open a real connection and then wait for a response. A SYN/ACK indicates the port is listening (open), while a RST (reset) is indicative of a non-listener. If no response is received after several retransmissions, the port is marked as filtered. The port is also marked filtered if an ICMP unreachable error (type 3, code 0, 1, 2, 3, 9, 10, or 13) is received.
In contrast to that, a connect scan does what it says. It's not a half connect but a connect. (Note that a major difference is the fact that a connect is usually seen on the target while a half-connect (SYN scan) is most often undetected.
Your -SN example in contrast performs a so-called null scan. It's called null because it sends packets in which none of three possible flags are set. This goes very deep into TCP implementation and would be a bit hard to explain in all detail in this answer, but here is what nmap.org explains:
These three scan types [...] [of which the Null scan is one of them] exploit a subtle loophole in the TCP RFC to differentiate between open and closed ports. Page 65 of RFC 793 says that “if the [destination] port state is CLOSED .... an incoming segment not containing a RST causes a RST to be sent in response.” Then the next page discusses packets sent to open ports without the SYN, RST, or ACK bits set, stating that: “you are unlikely to get here, but if you do, drop the segment, and return.”
When scanning systems compliant with this RFC text, any packet not containing SYN, RST, or ACK bits will result in a returned RST if the port is closed and no response at all if the port is open. As long as none of those three bits are included, any combination of the other three (FIN, PSH, and URG) are OK.
In other words, while some scans look for positive results, this one will look for negative results.
Now you may wish to consult your firewall's settings to understand how the firewall deals with half connects (i.e. SYN scans) on one hand or Null scans on the other. At least your firewall seems to be doing a good job in hiding the topology behind it.
Assuming that you allowed all ports for the entire subnet through your firewall, try a connect scan:
nmap -sT x.x.x.x/24
If that reports anything more than your three known hosts up, then you have a different problem.
I can understand and agree with most of what is said but the statement that there is no -sn command in NMAP is incorrect, it replaced -sP as a ping sweep or network scan and in the NMAP docs it says this:
This option tells Nmap not to do a port scan after host discovery, and only print out the available hosts that responded to the host discovery probes.
It also gives the following information about what actually takes place:
The default host discovery done with -sn consists of an ICMP echo request, TCP SYN to port 443, TCP ACK to port 80, and an ICMP timestamp request by default
If the ASA is blocking traffic to all addresses in the subnet on the other side except those with allow rules why does NMAP report all hosts active when running the -sn network scan. Does this indicate something amiss with the ASA or have I misunderstood the output
Tks
