Out of curiosity, why do you want to scan all the ports? I understand trying to be thorough, but there are only so many exploits out there, and when you boil it down, there aren't that many "interesting" ports. Chances are, you'll hit a vulnerability on the well known ports long before you find some hidden application running on some high-end port... plus you might get false positives anyway as different apps use different high numbered ports for dedicated communication.

It's not uncommon for people to run network services on non-standard ports. People still practice security by obscurity so scanning the full range is fine.

Look at the timing and perf options for nmap and let that sucker run all night. If you're trying to evade an IDS, go on a vacation while you wait!
http://nmap.org/book/man-performance.html

If you're going to do a scan like this, you HAVE to use Linux due to you can use true raw sockets on this. You can even set some custom firewall rules (if possible at the target host) to speed up the scanning process, and if you use the throttling flag, your scans will be even faster.

If you're doing a scan over the Internet, use a -T4 setting but if you're on an internal lan, you can actually set it to -T5 if you don't have to be stealthy at all.

Besides that, use the Syn Scan (-sS), NOT the OS Connect() (3-way handshake scan), and if you're scanning UDP ports, I suggest you do that in a separate scan as scanning UDP ports can often take a longer time, especially if packets are dropped. (Timeout is 1 second I think.)

Scanning a host that sends RST packets when you're doing a Syn Scan, instead of just dropping the packets will increase the scanning speed drastically. (This has to be configured on the remote hosts of course.)

Almost the same with UDP, except that it's not RST packets being sent back.

So, how can you speed up your scan too? By using a scanner that has separate sending and receiving modules. Randscan has this feature, which makes it a very fast port scanner, faster than nmap.

When you're doing large scans like this, I also suggest you keep usage of flags to a minimum, so avoid using -A, and perhaps -O as the last is just guessing / probability. You can use -sV, but this will take A LOT more time to complete, so I'd rather suggest you only use it on hosts that some interesting ports open that might be exploitable.


However before you continue with nmap, test out randscan. There's some info about how it works here including how to detect it: http://www.sans.org/security-resources/idfaq/scanrand.php

Update: I was going through some notes for a certification I once took, and just remembered that a NMAP UDP scan, is limited to sending 1 packet per second on Linux, which is also why you should separate your TCP and UDP on large networks.

If you configure the firewall on the target device to send ICMP Port Unreachable the UDP scan will of course be faster.

If you can use fewer ports to scan, it's a good idea too, and if possible, use several scanning machines. If you're on a wireless network, move closer to the router as this will also increase the scanning speed. (On a wired network, be close to the high-bandwidth backbone.)


That's pretty much some of the best advice I can give at the moment  


No problem, however, you do NOT use step 1 and 3, because different computers, has different ports open. So either you scan for the most commonly used ports or services you want to find, such as telnet, snmp, etc., or you scan all ports on all hosts.

Scanning one host and then applying this to all other hosts, will not give you a realistic picture, as a Windows machine may have port 135, and 445 open, while Linux will not unless Samba is installed. On a lot of linux equipment on the other hand, you may find port 22 and 80 open, while on Windows equipment, often but not always 3389 (RDP). Therefore you cannot just scan one host and repeat the same process for all hosts  

You can run -sV selectively, for example on targets that appears to be servers as they're often more critical to the business than clients containing no valuable data, e.g. they may not pose a huge risk compared to a full database full of classified information stored on a server. During each pentest, you should always try to identify where the highest risk is for the company, and attack that. If you were the company, would you loose money if one regular and low privileged client is compromised, compared to a highly-privileged client or a server?   Therefore you must prioritize if you're doing this all by yourself and you don't have infinite time.

If you're just doing an assessment and you're not going to exploit  any services (aka pentest the network), then you should scan all hosts to identify the blacksheeps. The scanning will of course take a lot longer time, but since your goal is not to get 100 shells most likely, then you'll be fine. However, wherever you're planning this scan, find out whether you're going to break into the services, or just map the network and its services for e.g. a vulnerability assessment.

You can output it into various formats, including grepable format, xml format, normal output and even a few more. There are a few tools that will create reports for you as well, that you may feel trying out.

If you're going to scan the open services later on, find out which formats e.g. Nessus or Nexpose supports, so you can export the results from NMAP into that, and import it directly into those vulnerability scanners.

You can also go through it manually, which I've done on networks between ~30-60 hosts. The more hosts, the longer time, even though you'll quickly be able to spot anomalies that shouldn't be there, but if you're good with regex and grep, use that  

Valuable addition  I didn't think about that immediately, but you're right, a non- or slow responsive nameserver will definitely slow most scans down if you're doing reverse IP lookups. (Which you can afterward anyway.) Thanks for reminding me