Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to give up on host after too many open ports (e.g. IPS) #1904

Open
djcater opened this issue Feb 2, 2020 · 1 comment
Open

Add option to give up on host after too many open ports (e.g. IPS) #1904

djcater opened this issue Feb 2, 2020 · 1 comment

Comments

@djcater
Copy link

@djcater djcater commented Feb 2, 2020

When scanning some IP addresses, after a certain number of ports are scanned, the device (or a device in between Nmap and the target) starts responding with SYN-ACK to every port.

This seems to be an IPS (Intrusion Prevention System), or similar active defence system, which responds in this way to slow down / tarpit port scans.

It works annoyingly well, as the scans slow down, and then service detection takes forever because there are so many "open" services.

Could we add an option to abandon a host after a certain threshold of "open" ports?

Something like --max-open-tcp-ports=200. After that, the port scanning phase stops looking for more open ports on that host.

@dmiller-nmap

This comment has been minimized.

Copy link

@dmiller-nmap dmiller-nmap commented Feb 3, 2020

This is an interesting idea, and we actually got as far as a proof-of-concept patch back in 2014 by @jaybosamiya. The option was called --ignore-after and supported both a number and a percentage of open ports tested as conditions for dropping the target. Development stalled out partly because we didn't have a good way to categorize the results, since the target is neither "timed out" or completed. But recent changes (6ed754b) have added an interesting XML element, hosthint, that I have proposed for recording timed-out targets. I am planning on committing that proposal this week, after which I think I'll look at Jay's --ignore-after branch again to see if it can be adapted and merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.