I am going to try explaining my question in the simplest way possible.
I have a script which uses nmap to scan for open ports and save the result in a file. The next time it scans a host it moves the old saved nmap report and creates a new one, lastly it compares these 2 reports to see what ports have been changed. That is, if a machine had a port say (80/tcp , 22tcp) open in previous scan result; and if the new scan result consists of only (80/tcp) then the script notifies a slack channel as :

CHANGE OCCURED FROM (80/tcp , 22tcp)   ===>   (80/tcp) 

so lately I have been having too many notifications from some of the machines, it keeps on changing port i.e from OPEN to CLOSE and CLOSE to OPEN. Now this script runs every 15 mins and I am really not sure why for some of the machines this keeps happening since I have seen that the ports do not change by manually logging in the machines.

There are no IDS on the machines which show this behavior. Is it possible that the machines are dropping NMAP traffic?

  • Which port? <1024 or >1024? Jul 19, 2016 at 11:38
  • i have a range of ports 80,22,8080,3306 etc Jul 19, 2016 at 11:59
  • Using Linux before 3.19 and libpcap 1.5 or later? Could be dropping packets due to a bug in the kernel. Build Nmap yourself, being sure to ./configure --with-libpcap=included Jul 19, 2016 at 12:42
  • @bonsaiviking well i am actually using libnmap , the python Library for nmap for performing the scans Jul 20, 2016 at 4:14
  • I ran across this question while searching for a way to do a diff of nmap scans. For some reason Google had it indexed well above the more official solution: nmap.org/ndiff so I'll drop this note here to provide a redirect to others. Feb 16, 2018 at 16:26

1 Answer 1


1) Nmap Timeout

I do not know how Nmap determines that but I'm fairly sure that it takes respond time into account while deciding if the target port is open or not. Depending on various factors, a port may not be able to respond immediately so maybe Nmap decides that the port is closed. Lets say that the threshold is 100ms. At first Nmap gets a response in 89ms and at second try it gets a response in 105ms. In both situations the target port is actually open but fails to respond in time.

2) Firewall Rules

The target machine does not need to have a full blown IDS in front of it, port scan is a really simple threat to detect. Limiting packet number over time from a single IP can disable your scans for a while. The funny thing is, since Nmap governs asynchronous scans it may scramble the order. That means Nmap might exceed the threshold while scanning port 8080 on one thread, and it might not have been scanned the port 50 yet. It could give you weird results.

My Recommendations

  • Use the "-T" flag of the Nmap. For example, use -T3 instead of -T5 so the scan will be slower but more docile.
  • There are flags for timeouts such as "--max-rtt-timeout" and "--max-scan-delay", take advantage of them for slower hosts.
  • Implement a better change detection algorithm. Instead of just checking the current result with a previous one, compare how many "CLOSED" or "OPEN" results you've got in a certain time. There are many false positive and false negative detection algorithms you can find on the internet. (SANS explains False Negatives security wise, here)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .