3

I am looking to find all the hosts that are online in a set of networks.

I would like to find all hosts that are online in the entire network of 170.10.. (there are ~64K possible hosts). The network I am trying to scan is an internal local network.

I used nmap tool. But it takes about 50 mins, which is way too long. Out of the 64K hosts, there are possible only about 20-40 hosts online. But the problem is they may be in any (or in one or more) network out of the possible 256 networks.

I am looking for a way to quickly figure out this. I don't think using ping command will help either as pinging 64K hosts is not going to be any faster.

I am looking for any alternate solution, perhaps broadcasting ICMP packets directly to all 256 networks or something similar.

Any ideas/suggestions? Thanks.

  • 5
    Seriously, sometimes things take time. I don't know what mechanism nmap uses to determine that a host is live (presumably ARP) but I would suggest looking at whatever nmap options there are for adjusting the number of probes/queries and probe/query timeout. – joeqwerty Feb 5 '15 at 16:56
  • Are you sure that IP range is private? If that is the case, you have just made 65K public IPs unavailable to your private LAN. Anyway, why don't you just take a look at your internal switch's ARP table? Should your hosts be active, the ARP table will be populated with all of your working IPs. – ma.tome Feb 5 '15 at 18:49
  • Lazy man's way fping -agq 172.10.0.0/16 – Dan Feb 5 '15 at 20:08
9

short answer: nmap -sn -T5 --min-parallelism 100 subnet/mask -oG output.file.txt; grep -v Down output.file.txt

explanation: nmap alone should be able to scan much faster. We'll start by limiting nmap to do ping scans with -sP (newer versions replaced -sP with -sn)

From man nmap:

TIMING AND PERFORMANCE:
     Options which take <time> are in seconds, or append 'ms' (milliseconds),
     's' (seconds), 'm' (minutes), or 'h' (hours) to the value (e.g. 30m).
     -T<0-5>: Set timing template (higher is faster)
     --min-hostgroup/max-hostgroup <size>: Parallel host scan group sizes
     --min-parallelism/max-parallelism <numprobes>: Probe parallelization
     --min-rtt-timeout/max-rtt-timeout/initial-rtt-timeout <time>: Specifies
         probe round trip time.
     --max-retries <tries>: Caps number of port scan probe retransmissions.
     --host-timeout <time>: Give up on target after this long
     --scan-delay/--max-scan-delay <time>: Adjust delay between probes
     --min-rate <number>: Send packets no slower than <number> per second
     --max-rate <number>: Send packets no faster than <number> per second

Time for a little experiment with just running more ping scans parallel --max-parallelism and throwing caution about being detected in the wind -T5:

nmap without any options:

% time nmap -sP 192.168.1.0/24 
[...]
nmap -sP 192.168.1.0/24  0.04s user 0.02s system 2% cpu 2.917 total
% time nmap -T5 --max-parallelism=100 -sP 192.168.1.0/23
[...]
nmap -sP 192.168.1.0/23  0.08s user 0.04s system 0% cpu 37.469 total

nmap with timing options:

% time nmap -T5 --max-parallelism=100 -sP 192.168.1.0/24
[...]
nmap -T5 --max-parallelism=100 -sP 192.168.1.0/24  0.03s user 0.03s system 3% cpu 2.016 total
% time nmap -T5 --max-parallelism=100 -sP 192.168.1.0/23
[...]
nmap -T5 --max-parallelism=100 -sP 192.168.1.0/23  0.11s user 0.02s system 2% cpu 4.869 total

Quite the improvement.

For a /16 subnet scan, like OP asked:

Nmap done: 65536 IP addresses (30 hosts up) scanned in 169.43 seconds
nmap -sP -T5 --min-parallelism 100 --max-parallelism 256 192.168.0.0/16  44.67s user 8.45s system 31% cpu 2:49.44 total

To throw @Dan's suggestion in the mix too, I got bored after hitting 5 minutes with fping still running :-)

  • I kind of used -T5 along with -p to specify my target port. It still took 10 mins, but I have kind of reduce the network range in order to bring it down to about 100 secs. Thanks. – P.P. Feb 12 '15 at 14:21
  • @fuero looks like --max-retries options doesn't work along with ping scan, any suggestions? – abhiomkar Nov 8 '15 at 7:03
  • I don't think --max-parallelism is necessary. the manual says it will slow down automatically. however --min-paralllelism 100 help speeding up the start (by default starts slow then increases). note that exceeding 100 gives warning and I also got netfilter conntrack kernel warnings about dropped connections. – Costin Gușă Sep 27 '18 at 7:57
1

More threads. Start 256 nmap scans simultaneously. Hope your host can handle the simultaneous connections.

for i in 172.10.{0..255}.0 ; do nmap $i <arguments> & done;

You might want to make sure that it's writing to a file somewhere, as the terminal output would be atrocious to try and parse with 256 nmaps going at once.

Edit:

You can do the same thing with ping. Just make sure you limit the number. You might want to tweak this:

for i in {0..255} ; do for j in 172.10.$i.{0..255} ; do ping $j -c 2 -W 1 | \
    grep "bytes from" >> aliveips.txt & done ; done
  • 2
    Running multiple nmap commands concurrently doesn't produce reliable output. – P.P. Feb 12 '15 at 14:19
  • 2
    Running multiple nmap commands at once makes them conflict with each other for resources. Nmap already parallelizes scans, and slows down as necessary to avoid congestion. Running multiple commands makes it slow down more. – bonsaiviking Jan 17 '18 at 0:15

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.