First off, I know nmap's documentation is very powerful and I have been reading through it rather extensively.

I will be scanning externally, with permission, to determine ports & services that might be left open on publicly facing assets.

I have about 750 hosts, a lot of them on different subnets. I have the individual IPs listed out in a CSV. I know that nmap can scan based on CIDR ranges to combine many of the IPs within the same subnet, but I didn't see it as necessary if nmap can just pick up each individual IP from my list.

My reasoning behind the SYN scan would be that I don't think I need to establish the full handshake to determine open ports/services. Assuming I want to test all of these hosts to determine open ports, would this syntax be sufficient for my scan? Also, does anyone know of a rough estimate for how long it may take for nmap to perform the following scan on 750 unique hosts? Any other advice?

nmap -sS -iL /user/Desktop/IPlist.csv > /user/Desktop/scanlog.txt

  • 1
    the reason a CIDR range might be good is to discover additional IP addresses that are outward facing but not on your list.
    – mcgyver5
    Jul 14, 2015 at 15:28
  • Thanks mcgyver. Assuming I pulled all of the IPs from all of the authoritative DNS zone files, would it still be recommended to use CIDR range or can I leave as individual IPs?
    – shift_tab
    Jul 14, 2015 at 15:37
  • 1
    What if an IP address is reachable but not in one of the zone files?
    – mcgyver5
    Jul 14, 2015 at 16:00
  • Fair enough. Perhaps I should use the CIDR range then instead of individual IPs.
    – shift_tab
    Jul 14, 2015 at 16:09
  • Or just do a host discovery against the CIDR range(s) and do a more complete scan of the known hosts on your list.
    – mcgyver5
    Jul 14, 2015 at 16:18

2 Answers 2


Do your own host discovery first. Like I said in a comment, use CIDR range instead of or in addition to your list of specific IP addresses. Maybe one scan from your list and a separate scan for host discovery. As the docs on host discovery say,

One of the very first steps in any network reconnaissance mission is to reduce a (sometimes huge) set of IP ranges into a list of active or interesting hosts. Scanning every port of every single IP address is slow and usually unnecessary.

The advantage of -sS is that it is quick and not noisy. It may be a good place to start as it will identify "low hanging fruit".

I would encourage you to broaden this.

If I were doing it, I would want UDP and other IP protocols as well as the TCP that you specify when you use -sS:

include -sU so that you look at UDP ports. as the docs say :

"Because UDP scanning is generally slower and more difficult than TCP, some security auditors ignore these ports. This is a mistake, as exploitable UDP services are quite common and attackers certainly don't ignore the whole protocol."

include -sO so that any IP functionality is discovered.

Collect other nmap features that make sense for your situation. (For example, do you want version detection of the services you find so you can identify vulnerable versions? If so, look at http://nmap.org/book/man-version-detection.html)


It's going to take a long time. There are options to vary the speed, the number of ports, and the amount of parallelism. Adjust them all for your use.

Take a look at the defaults in nmap, and you'll see options that you might want to tweak. For instance, UDP scans take forever.

From my experience, I would split up the scan into sections. Perform a quick top ports TCP scan in order to find the quick wins, then expand from there into lesser used ports and UDP. When doing pentests, I use nmap this way to get the initial results, then when I get those, I launch multiple parallel scans looking for different things, while using the initial results to start my first tests.

You can also look at other scanning tools designed for speed (e.g. unicornscan) to help you narrow in to the meat of what you are looking for.

You must log in to answer this question.

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