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

FD_SETSIZE issues #1857

Open
ziya5635 opened this issue Dec 15, 2019 · 1 comment
Open

FD_SETSIZE issues #1857

ziya5635 opened this issue Dec 15, 2019 · 1 comment
Labels

Comments

@ziya5635
Copy link

@ziya5635 ziya5635 commented Dec 15, 2019

Hi, I am trying to identify some services in an enterprise network, which contains about 5000 live hosts. To achieve this I run the following command:
'nmap -Pn -n -iL hosts/target.txt -p 0-65535 -sV -A -oA services/full-sweep --min-rate 20000 --min-hostgroup 22'
, which gives me the following error:
"Attempt to FD_ISSET fd 1024, which is not less than FD_SETSIZE (1024). Try using a lower parallelism. Aborted (core dumped)"

If I set "min-rate" to about 700, it works just fine but the problem is that for such a big network, it would take forever to complete the work.

It is worth mentioning that I am running it on Ubuntu 18.

Could you please help? Thanks!

@dmiller-nmap

This comment has been minimized.

Copy link

@dmiller-nmap dmiller-nmap commented Jan 2, 2020

Thanks for reporting this. I'm not sure what possibilities there are to more safely limit parallelism to avoid exceeding FD_SETSIZE, you may be able to work around the problem for now by adjusting your scan parameters and splitting your scan into sections.

My first suggestion would be to avoid using -Pn (disable host discovery) unless you absolutely MUST send a probe to every port on every address in your entire network. This is an enormous number of probes, most of which will probably be going to unoccupied addresses. The point of host discovery is to limit the number of probes that must be sent in any case. It also has the benefit of "priming" Nmap's timing algorithms with round-trip latency times that help avoid drastically slow start to the port scan phase.

The next suggestion is to split your scan in order to speed it up. If you do all the port scanning first, you can use very high rates and parallelism, since except for TCP Connect scan (-sT) those do not use regular sockets limited by FD_SETSIZE. Then you can extract all the open port numbers and live IP addresses and re-scan them for OS, service, traceroute, and NSE (the features enabled by the -A option). This scan will often go faster than before because there are fewer probes to send in total and you will be saturating the network less. Timing settings can be tuned separately for each scan, since there are different limitations. You could even split the work of the followup scan among several worker machines in order to get more done in parallel than a single connection might support.

In any case, it would be nice to be able to detect when we're about to exceed FD_SETSIZE and throttle back instead of choking entirely, so I'll leave that as the goal for this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.