I have noticed during some assesments when doing a TCP port scan, Nmap will report almost every port as open for a machine.
Using for example nmap -sS -PN -T4 target -p0-65535, over 20,000 ports will be returned as open. On further investigation, most of these ports are not open or even filtered.
What is causing Nmap to consider the ports open, and is there a different type of scan that can counter this and give more accurate results?
You're most likely hitting a well-configured IDS/IPS appliance.
snort can easily detect your port scan in progress with the sfPortscan filter (the -sS is practically a "portscan in progress" signature), and in addition to logging your attack, it can be configured to perform an active response. These responses can be as simple as sending you an RST, or as rich as the "react" rule. The "react" response's default behavior is to respond with an HTTP 403 Forbidden message, but they can also configure it to send any arbitrary data desired. The reaction behavior is not limited to port 80 requests, either. snort will send the reply regardless of port number.
To test this theory, while undertaking a portscan of the target, from the same machine that's doing the scanning, try opening any old port on that target with a browser or netcat. If you receive the HTTP 403 Forbidden response from a non HTTP port, that's likely what's happening.
I am guessing that nmap doesn't interpret the response, it only reports that the socket connection was established, therefore it is reporting it to you as an open port. Rather than guessing, however, you could set the --packet-trace option on nmap to see what you're actually getting back.
You can read the snort manual here.
You have a few options. My first thought would be that there may be an intermediate system that is responding with SYN/ACK packets to prohibited (firewalled) ports. If this is the case, you may be able to distinguish truly-open ports by the TTL of the response. If you saved the XML output of your scan (-oX or -oA), you can check the //port/state/@reason_ttl attribute. This is similar to the technique of "firewalking." You can find some related info here: Firewalking with nmap.
Another alternative would be to use a different scan type. Nmap's SYN scan (-sS or default when scanning as root) can be detected by the TCP options, MSS, and window size, so an IDS/IPS could be responding to that. Try using the TCP Connect scan (-sT) instead. Other scan types (ACK, FIN, Maimon, etc) could be used to filter your results; they won't show open ports by themselves, but they could flag some of these "open" ports as firewalled, or at least show that they behave differently. Use caution here, though, since these send very noticeable "bad" packets, and rely on behaviors that aren't often present in modern OSs.
Finally, you can use Nmap's service version detection (-sV) to identify the services behind the "open" ports. It is likely that the false-positives will simply time-out or send a RST to close the connection soon after opening it. This will slow your scan down a lot, but sometimes it's important to be accurate. I would recommend starting with --version-intensity 0, which will simply do a banner grab and possibly any probes that are tagged to the specific port being scanned, as opposed to the default, which does this and up to 8 other tests.
There is an obfuscation technique where a server simulates nearly all ports to be opened, ideally simulating valid service signature on most of these ports.
Portspoof, for instance, implements this approach and handles more than 8000 service signatures.
I had the same thing happen to me. It was Snort causing it. Adding the -f and --badsum switches to nmap allowed me to by pass the IDS/IPS. The full command was as follows:
nmap -sS -p 1-65535 -f --badsum -vv -Pn -oA target_nmap target
I faced the same problem as you. In my case the IDS/IPS would send a SYN,ACK for all ports, which caused nmap to conclude that all ports were open.
However, while packets should be retransmitted when they are not acknowledged according to the TCP specification, the IDS/IPS did NOT retransmit any packets that were not acknowledged (which is the case in an TCP SYN scan), .
Therefore I was able to distinguish open ports from inaccessible ones by looking at retransmitted packets in wireshark. If a SYN,ACK was retransmitted, it meant that the port was open.
The wireshark filter you can use for this is:
tcp.analysis.retransmission
I've had strange things happen with nmap in the past when I'm trying to scan too quickly, and -T4 is after all defined as "aggressive". Try turning your scan speed to 3 and see if you get the same results.
You may also be running into OS or nmap bugs or interoperability problems of some kind. If you have another system try running it off of that and see if you get the same result.
There may be some firewall technology which is messing with your traffic, see if you can eliminate anything in the way.
There could be a number of things going on here.
John mentioned snort or another type of IDS/IPS being a potential pitfall that's catching your syn scan. You can try switching -sS to -sT and specifying a period of time to wait before attempting to scan another port -- sfportscan is time-driven, if it's enabled at all. (Source: former Sourcefire employee)
Other possibilities include stateful inspection firewalls. I've seen cases where if there's a firewall/NAT/filtering device between you and your scan target, the firewall may return a SYN/ACK, when in fact the port to your actual target may not be accessible. Again, try a -sT scan, and tone done how many ports your attempting to scan at once.
The caveat to using -sT as opposed to -sS or other scan types is that, if a service is listening on a port, and you do get a response, there's a good chance you'll end up getting logged. For an example of this, throw an -sT scan to any ssh daemon and check /var/log/secure afterwards.
