18

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?

schroeder
  • 123,438
  • 55
  • 284
  • 319
Sonny Ordell
  • 3,476
  • 9
  • 33
  • 56
  • 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 Nov 15 '13 at 15:38
  • @Nasrus I used the word target in place of an actual target in my example....no I'm not scanning my self. – Sonny Ordell Nov 15 '13 at 15:39
  • 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 Nov 15 '13 at 17:15
  • @gowenfawr not all consecutive, and yeah I figure it isn't true, but it kind of makes nmap useless when scanning against such hosts... – Sonny Ordell Nov 15 '13 at 17:41
  • I know it's slower, but do you get the same results with -sT instead of -sS – RSchulze Nov 15 '13 at 18:10
  • @RSchulze I will test and see. – Sonny Ordell Nov 15 '13 at 18:49
  • @RSchulze yes, I get exactly the same results using -sT – Sonny Ordell Nov 20 '13 at 00:03
  • 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 – Angelo Schilling Jul 20 '18 at 20:29
  • also, that -T4 is not great. Using -T2 or leaving the option out (which equates to T3) is safer if you're avoiding an IDS/IPS – Angelo Schilling Jul 20 '18 at 20:32

7 Answers7

22

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.

John Deters
  • 33,650
  • 3
  • 57
  • 110
  • So I have had a chance to test. Connecting with telnet or netcat on one of the ports said to be open simply returns nothing...nothing at all. --packet-trace seems to just indicate connect success. This happens with -ST as well. – Sonny Ordell Nov 20 '13 at 00:03
12

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.

bonsaiviking
  • 11,316
  • 1
  • 27
  • 50
5

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.

WhiteWinterWolf
  • 19,082
  • 4
  • 58
  • 104
  • Is there any way to counter this and get accurate results? The ports detected have no service signatures and are just considered open. – Sonny Ordell Nov 15 '13 at 16:29
  • 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. – WhiteWinterWolf Nov 15 '13 at 16:39
  • it is only triggered by a port scan. What other scanning techniques would you suggest? – Sonny Ordell Nov 15 '13 at 16:52
  • @SonnyOrdell - First thing, perhaps would be a telnet against any one of such ports. – Lex Nov 15 '13 at 17:27
  • @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. – Sonny Ordell Nov 15 '13 at 17:40
  • 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. – WhiteWinterWolf Nov 15 '13 at 18:08
3

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

dprofancik
  • 31
  • 1
2

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
Community
  • 1
Onderbetaald
  • 141
  • 2
1

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.

GdD
  • 17,291
  • 2
  • 41
  • 63
  • 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. – Sonny Ordell Nov 15 '13 at 15:56
  • 1
    If memory serves Nessus uses nmap for port scanning, so using nessus port scan is just a lengthly way of running nmap. – GdD Nov 15 '13 at 16:07
  • Oh...I did not know that. Good to know. – Sonny Ordell Nov 15 '13 at 16:13
1

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.

some_noob
  • 131
  • 1