Nmap reporting almost every port as open
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?
Did you specify a scan target? From your provided example you do not seem to provide a target, so Nmap might instead be scanning localhost (ie. yourself). As there are many services that use local ports without listening to comms outside your computer, that may be the reason.
@Nasrus I used the word target in place of an actual target in my example....no I'm not scanning my self.
I've seen that happen *intermittently* with nmap. Are those ports consecutive? Two rules of thumb: 1) If it looks too crazy to be true, it probably isn't true. 2) Verify your tool output - it's a good habit.
@gowenfawr not all consecutive, and yeah I figure it isn't true, but it kind of makes nmap useless when scanning against such hosts...
you can give -f (fragmentation) a try. I've used it to bypass Vectra detections for nmap scans, and I assume it will work on other IDS/IPSes as well
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 Forbiddenmessage, 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-traceoption 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 (
-oA), you can check the
//port/state/@reason_ttlattribute. 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 (
-sSor 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.
Is there any way to counter this and get accurate results? The ports detected have no service signatures and are just considered open.
Maybe firstly check if this system is triggered only when a port-scan is detected: when you check some of this ports manually (if possible from a different source IP address), do these port still appear as "open" ? You may also try to use different nmap scanning techniques.
it is only triggered by a port scan. What other scanning techniques would you suggest?
@Lex, that doesn't help. I already verify that the ports are closed, what I want to do is be able to scan and not have to verify each of the 20,000 ports or so.
You say it is triggered by a port scan. Executing a slowest scan (option -T in your command) may avoid to trigger this protection. Otherwise, a Null scan (-sN) for instance might help: nmap sends a data packet to the target, either there is really a service listening on this port, he will take the packet and drop it (since unrelated to any connection), and if there is no service on this port the server should send a TCP RST.
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:
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.
I don't know that it is purely an nmap problem...even using the portscanner in Nessus gives the same results, as does -T2. It seems to be some weird firewall technology that I'm not sure how to counter.
If memory serves Nessus uses nmap for port scanning, so using nessus port scan is just a lengthly way of running nmap.
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.