Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is it possible with nmap to check only the state of a port whether- open, closed or filtered and NOT the services behind it?

The aim is to speed up scan results. Since UDP scan is also involved it is taking forever to complete.

That aside what could be done to speed up nmap UDP scans? The one I'm using is:

nmap -n -sS -sU -p1-65535 -oN scan_out -iL hosts

share|improve this question
is there any reason you unaccepted my answer? Do you need more information? – bonsaiviking Jan 7 '13 at 21:55
@bonsaiviking I'm sorry I had to get my way around with the functionalities of site. well I tried accepting both answers since it both helped! but it seems only 1 can be given.Thanks for your help and it was all I needed. :) – user492160 Jan 8 '13 at 16:18
up vote 1 down vote accepted

With the command you posted, the only service information is generated with a simple lookup of the port number. There's really no perceptible delay there, and so it cannot be disabled.

I would suggest splitting this into two scans: one for TCP and one for UDP. That way you can get the TCP results without delay while the UDP scan runs. This can also help Nmap with its internal timing calculations.

For speeding up UDP scans, you'll likely have to sacrifice some accuracy for speed. Some options that may help include the using the gross timing options -T<digit> (3 is default, use 4 or 5 to speed things up), setting --max-retries to a low value (less than 3), setting a --max-rtt-timeout using the instructions in the man page, and reducing the number of ports scanned. A scan of 65535 ports is going to take a long time no matter what (and did you know that port 0 is a valid port?). Pay attention to be sure hosts with open ports are not timing out (set the --host-timeout option to a high value if so.)

If you still are unsatisfied with the speed of Nmap for UDP scans, you'll probably have to look at an asynchronous scanner like unicornscan.

share|improve this answer
-PN disables ping I guess? So it should speed up things right? – user492160 Dec 6 '12 at 3:03
@user492160 -Pn disables the host discovery phase (or "ping." -PN and -P0 are synonyms). This will not speed things up, though. It would eliminate a fast step (host discovery involves at most 4 probes per address) and make the slow step (65535 UDP ports times some number of retries) even slower because you are now scanning addresses that are vacant. Host discovery makes your scans faster by avoiding useless scanning. – bonsaiviking Dec 6 '12 at 12:28

there is no service discovery in your nmap command. the service name in the output is based on the well known port definition and is not responsible for a slow scan. Try the option -T5. --min-rate is good to increase performance too. Be careful too fast may result bad scans. have a look at nmap --help:

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

and at:

share|improve this answer
Using -P0 (-Pn is the preferred syntax) will slow down the scan by scanning addresses that are not assigned to a host. – bonsaiviking Dec 5 '12 at 13:46
you are rigth i didn't thought about this. i will edit my answer – user1008764 Dec 5 '12 at 13:56
thanks for responses – user492160 Dec 6 '12 at 3:02

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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