Nmap network security scanner man page
NMAP(1) NMAP(1)
NAME
nmap - Network exploration tool and security scanner
SYNOPSIS
nmap [Scan Type(s)] [Options] <host or net #1 ... [#N]>
DESCRIPTION
Nmap is designed to allow system administrators and curious individuals
to scan large networks to determine which hosts are up and what ser-
vices they are offering. nmap supports a large number of scanning
techniques such as: UDP, TCP connect(), TCP SYN (half open), ftp proxy
(bounce attack), ICMP (ping sweep), FIN, ACK sweep, Xmas Tree, SYN
sweep, IP Protocol, and Null scan. See the Scan Types section for more
details. nmap also offers a number of advanced features such as remote
OS detection via TCP/IP fingerprinting, stealth scanning, dynamic delay
and retransmission calculations, parallel scanning, detection of down
hosts via parallel pings, decoy scanning, port filtering detection,
direct (non-portmapper) RPC scanning, fragmentation scanning, and flex-
ible target and port specification.
Significant effort has been put into decent nmap performance for non-
root users. Unfortunately, many critical kernel interfaces (such as
raw sockets) require root privileges. nmap should be run as root when-
ever possible (not setuid root, of course).
The result of running nmap is usually a list of interesting ports on
the machine(s) being scanned (if any). Nmap always gives the port’s
"well known" service name (if any), number, state, and protocol. The
state is either "open", "closed" "filtered", or "unfiltered". Open
means that the target machine will accept() connections on that port.
Closed ports are not listening for connections (they have no applica-
tion associated with them). Filtered means that a firewall, filter, or
other network obstacle is covering the port and preventing nmap from
determining whether the port is open. Unfiltered means that the port
is known by nmap to be closed and no firewall/filter seems to be inter-
fering with nmap’s attempts to determine this. Unfiltered ports are
the common case and are only shown when most of the scanned ports are
in the filtered state. In some cases, Nmap cannot distinguish between
filtered ports and those that are either open or closed. For example,
a port that does not respond to a FIN Scan could be either open or fil-
tered. In these cases, Nmap lists ports as "open|filtered" or
"closed|filtered".
Depending on options used, nmap may also report the following charac-
teristics of the remote host: OS in use, TCP sequentiality, usernames
running the programs which have bound to each port, the DNS name,
whether the host is a smurf address, and a few others.
OPTIONS
Options that make sense together can generally be combined. Some
options are specific to certain scan modes. nmap tries to catch and
warn the user about psychotic or unsupported option combinations.
If you are impatient, you can skip to the examples section at the end,
which demonstrates common usage. You can also run nmap -h for a quick
reference page listing all the options.
SCAN TYPES
-sS TCP SYN scan: This technique is often referred to as "half-open"
scanning, because you don’t open a full TCP connection. You send
a SYN packet, as if you are going to open a real connection and
you wait for a response. A SYN|ACK indicates the port is listen-
ing. A RST is indicative of a non-listener. If a SYN|ACK is
received, a RST is immediately sent to tear down the connection
(actually our OS kernel does this for us). The primary advantage
to this scanning technique is that fewer sites will log it.
Unfortunately you need root privileges to build these custom SYN
packets. This is the default scan type for privileged users.
-sT TCP connect() scan: This is the most basic form of TCP scanning.
The connect() system call provided by your operating system is
used to open a connection to every interesting port on the
machine. If the port is listening, connect() will succeed, oth-
erwise the port isn’t reachable. One strong advantage to this
technique is that you don’t need any special privileges. Any
user on most UNIX boxes is free to use this call.
This sort of scan is easily detectable as target host logs will
show a bunch of connection and error messages for the services
which accept() the connection just to have it immediately shut-
down. This is the default scan type for unprivileged users.
-sF -sX -sN
Stealth FIN, Xmas Tree, or Null scan modes: There are times when
even SYN scanning isn’t clandestine enough. Some firewalls and
packet filters watch for SYNs to restricted ports, and programs
like Synlogger and Courtney are available to detect these scans.
These advanced scans, on the other hand, may be able to pass
through unmolested.
The idea is that closed ports are required to reply to your
probe packet with an RST, while open ports must ignore the pack-
ets in question (see RFC 793 pp 64). Filered ports also tend to
drop probes without a response, so Nmap considers ports
"open|filtered" when it fails to elicit any response. If you
add version detection (-sV), it will try to verify whether the
ports are actually open and change the state as appropriate.
The FIN scan uses a bare (surprise) FIN packet as the probe,
while the Xmas tree scan turns on the FIN, URG, and PUSH flags.
The Null scan turns off all flags. Unfortunately Microsoft
(like usual) decided to completely ignore the standard and do
things their own way. Thus this scan type will not work against
systems running Windows95/NT. On the positive side, this is a
good way to distinguish between the two platforms. If the scan
finds open ports, you know the machine is not a Windows box. If
a -sF,-sX,or -sN scan shows all ports closed, yet a SYN (-sS)
scan shows ports being opened, you are probably looking at a
Windows box. This is less useful now that nmap has proper OS
detection built in. There are also a few other systems that are
broken in the same way Windows is. They include Cisco, BSDI,
HP/UX, MVS, and IRIX. All of the above send resets from the
open ports when they should just drop the packet.
-sP Ping scanning: Sometimes you only want to know which hosts on a
network are up. Nmap can do this by sending ICMP echo request
packets to every IP address on the networks you specify. Hosts
that respond are up. Unfortunately, some sites such as
microsoft.com block echo request packets. Thus nmap can also
send a TCP ack packet to (by default) port 80. If we get an RST
back, that machine is up. A third technique involves sending a
SYN packet and waiting for a RST or a SYN/ACK. For non-root
users, a connect() method is used.
By default (for root users), nmap uses both the ICMP and ACK
techniques in parallel. You can change these with the -P
options described later.
Note that pinging is done by default anyway, and only hosts that
respond are scanned. Only use this option if you wish to ping
sweep without doing any actual port scans.
-sV Version detection: After TCP and/or UDP ports are discovered
using one of the other scan methods, version detection communi-
cates with those ports to try and determine more about what is
actually running. A file called nmap-service-probes is used to
determine the best probes for detecting various services and the
match strings to expect. Nmap tries to determine the service
protocol (e.g. ftp, ssh, telnet, http), the application name
(e.g. ISC Bind, Apache httpd, Solaris telnetd), the version num-
ber, and sometimes miscellaneous details like whether an X
server is open to connections or the SSH protocol version). If
Nmap was compiled with OpenSSL support, it will connect to SSL
servers to deduce the service listening behind the encryption.
When RPC services are discovered, the Nmap RPC grinder is used
to determine the RPC program and version numbers. Some UDP
ports are left in the "open|filtered" state after a UDP scan is
unable to determine whether the port is open or filtered. Ver-
sion detection will try to elicit a response from these ports
(just as it does with open ports), and change the state to open
if it succeeds. Note that the Nmap -A option also enables this
feature. For a much more detailed description of Nmap service
detection, read our paper at http://www.insecure.org/nmap/ver-
sionscan.html . There is a related --version_trace option which
causes Nmap to print out extensive debugging info about what
version scanning is doing (this is a subset of what you would
get with --packet_trace).
-sU UDP scans: This method is used to determine which UDP (User
Datagram Protocol, RFC 768) ports are open on a host. The tech-
nique is to send 0 byte UDP packets to each port on the target
machine. If we receive an ICMP port unreachable message, then
the port is closed. If a UDP response is received to the probe
(unusual), the port is open. If we get no response at all, the
state is "open|filtered", meaning that the port is either open
or packet filters are blocking the communication. Versions scan
(-sV) can be used to help differentiate the truly open ports
from the filtered ones.
Some people think UDP scanning is pointless. I usually remind
them of the Solaris rpcbind hole. Rpcbind can be found hiding on
an undocumented UDP port somewhere above 32770. So it doesn’t
matter that 111 is blocked by the firewall. But can you find
which of the more than 30,000 high ports it is listening on?
With a UDP scanner you can! There is also the cDc Back Orifice
backdoor program which hides on a configurable UDP port on Win-
dows machines. Not to mention the many commonly vulnerable ser-
vices that utilize UDP such as snmp, tftp, NFS, etc.
Unfortunately UDP scanning is sometimes painfully slow since
most hosts implement a suggestion in RFC 1812 (section 4.3.2.8)
of limiting the ICMP error message rate. For example, the Linux
kernel (in net/ipv4/icmp.h) limits destination unreachable mes-
sage generation to 80 per 4 seconds, with a 1/4 second penalty
if that is exceeded. Solaris has much more strict limits (about
2 messages per second) and thus takes even longer to scan. nmap
detects this rate limiting and slows down accordingly, rather
than flood the network with useless packets that will be ignored
by the target machine.
As is typical, Microsoft ignored the suggestion of the RFC and
does not seem to do any rate limiting at all on Win95 and NT
machines. Thus we can scan all 65K ports of a Windows machine
very quickly. Whoop!
-sO IP protocol scans: This method is used to determine which IP
protocols are supported on a host. The technique is to send raw
IP packets without any further protocol header to each specified
protocol on the target machine. If we receive an ICMP protocol
unreachable message, then the protocol is not in use. Otherwise
we assume it is open. Note that some hosts (AIX, HP-UX, Digital
UNIX) and firewalls may not send protocol unreachable messages.
This causes all of the protocols to appear "open".
Because the implemented technique is very similar to UDP port
scanning, ICMP rate limit might apply too. But the IP protocol
field has only 8 bits, so at most 256 protocols can be probed
which should be possible in reasonable time anyway.
-sI <zombie host[:probeport]>
Idlescan: This advanced scan method allows for a truly blind TCP
port scan of the target (meaning no packets are sent to the tar-
get from your real IP address). Instead, a unique side-channel
attack exploits predictable "IP fragmentation ID" sequence gen-
eration on the zombie host to glean information about the open
ports on the target. IDS systems will display the scan as com-
ing from the zombie machine you specify (which must be up and
meet certain criteria). I wrote an informal paper about this
technique at http://www.insecure.org/nmap/idlescan.html .
Besides being extraordinarily stealthy (due to its blind
nature), this scan type permits mapping out IP-based trust rela-
tionships between machines. The port listing shows open ports
from the perspective of the zombie host. So you can try scan-
ning a target using various zombies that you think might be
trusted (via router/packet filter rules). Obviously this is
crucial information when prioritizing attack targets. Other-
wise, you penetration testers might have to expend considerable
resources "owning" an ins no include Cisco, BSDI,
HP/UX, MVS, and IRIX. All of the above send resets from the
open ports when they should just drop the packet.
-sP Ping scanning: Sometimes you only want to know which hosts on a
network are up. Nmap can do this by sending ICMP echo request
packets to every IP address on the networks you specify. Hosts
that respond are up. Unfortunately, some sites such as
microsoft.com block echo request packets. Thus nmap can also
send a TCP ack packet to (by default) port 80. If we get an RST
back, that machine is up. A third technique involves sending a
SYN packet and waiting for a RST or a SYN/ACK. For non-root
users, a connect() method is used.
By default (for root users), nmap uses both the ICMP and ACK
techniques in parallel. You can change these with the -P
options described later.
Note that pinging is done by default anyway, and only hosts that
respond are scanned. Only use this option if you wish to ping
sweep without doing any actual port scans.
-sV Version detection: After TCP and/or UDP ports are discovered
using one of the other scan methods, version detection communi-
cates with those ports to try and determine more about what is
actually running. A file called nmap-service-probes is used to
determine the best probes for detecting various services and the
match strings to expect. Nmap tries to determine the service
protocol (e.g. ftp, ssh, telnet, http), the application name
(e.g. ISC Bind, Apache httpd, Solaris telnetd), the version num-
ber, and sometimes miscellaneous details like whether an X
server is open to connections or the SSH protocol version). If
Nmap was compiled with OpenSSL support, it will connect to SSL
servers to deduce the service listening behind the encryption.
When RPC services are discovered, the Nmap RPC grinder is used
to determine the RPC program and version numbers. Some UDP
ports are left in the "open|filtered" state after a UDP scan is
unable to determine whether the port is open or filtered. Ver-
sion detection will try to elicit a response from these ports
(just as it does with open ports), and change the state to open
if it succeeds. Note that the Nmap -A option also enables this
feature. For a much more detailed description of Nmap service
detection, read our paper at http://www.insecure.org/nmap/ver-
sionscan.html . There is a related --version_trace option which
causes Nmap to print out extensive debugging info about what
version scanning is doing (this is a subset of what you would
get with --packet_trace).
-sU UDP scans: This method is used to determine which UDP (User
Datagram Protocol, RFC 768) ports are open on a host. The tech-
nique is to send 0 byte UDP packets to each port on the target
machine. If we receive an ICMP port unreachable message, then
the port is closed. If a UDP response is received to the probe
(unusual), the port is open. If we get no response at all, the
state is "open|filtered", meaning that the port is either open
or packet filters are blocking the communication. Versions scan
(-sV) can be used to help differentiate the truly open ports
from the filtered ones.
Some people think UDP scanning is pointless. I usually remind
them of the Solaris rpcbind hole. Rpcbind can be found hiding on
an undocumented UDP port somewhere above 32770. So it doesn’t
matter that 111 is blocked by the firewall. But can you find
which of the more than 30,000 high ports it is listening on?
With a UDP scanner you can! There is also the cDc Back Orifice
backdoor program which hides on a configurable UDP port on Win-
dows machines. Not to mention the many commonly vulnerable ser-
vices that utilize UDP such as snmp, tftp, NFS, etc.
Unfortunately UDP scanning is sometimes painfully slow since
most hosts implement a suggestion in RFC 1812 (section 4.3.2.8)
of limiting the ICMP error message rate. For example, the Linux
kernel (in net/ipv4/icmp.h) limits destination unreachable mes-
sage generation to 80 per 4 seconds, with a 1/4 second penalty
if that is exceeded. Solaris has much more strict limits (about
2 messages per second) and thus takes even longer to scan. nmap
detects this rate limiting and slows down accordingly, rather
than flood the network with useless packets that will be ignored
by the target machine.
As is typical, Microsoft ignored the suggestion of the RFC and
does not seem to do any rate limiting at all on Win95 and NT
machines. Thus we can scan all 65K ports of a Windows machine
very quickly. Whoop!
-sO IP protocol scans: This method is used to determine which IP
protocols are supported on a host. The technique is to send raw
IP packets without any further protocol header to each specified
protocol on the target machine. If we receive an ICMP protocol
unreachable message, then the protocol is not in use. Otherwise
we assume it is open. Note that some hosts (AIX, HP-UX, Digital
UNIX) and firewalls may not send protocol unreachable messages.
This causes all of the protocols to appear "open".
Because the implemented technique is very similar to UDP port
scanning, ICMP rate limit might apply too. But the IP protocol
field has only 8 bits, so at most 256 protocols can be probed
which should be possible in reasonable time anyway.
-sI <zombie host[:probeport]>
Idlescan: This advanced scan method allows for a truly blind TCP
port scan of the target (meaning no packets are sent to the tar-
get from your real IP address). Instead, a unique side-channel
attack exploits predictable "IP fragmentation ID" sequence gen-
eration on the zombie host to glean information about the open
ports on the target. IDS systems will display the scan as com-
ing from the zombie machine you specify (which must be up and
meet certain criteria). I wrote an informal paper about this
technique at http://www.insecure.org/nmap/idlescan.html .
Besides being extraordinarily stealthy (due to its blind
nature), this scan type permits mapping out IP-based trust rela-
tionships between machines. The port listing shows open ports
from the perspective of the zombie host. So you can try scan-
ning a target using various zombies that you think might be
trusted (via router/packet filter rules). Obviously this is
crucial information when prioritizing attack targets. Other-
wise, you penetration testers might have to expend considerable
resources "owning" an ins no include Cisco, BSDI,
HP/UX, MVS, and IRIX. All of the above send resets from the
open ports when they should just drop the packet.
-sP Ping scanning: Sometimes you only want to know which hosts on a
network are up. Nmap can do this by sending ICMP echo request
packets to every IP address on the networks you specify. Hosts
that respond are up. Unfortunately, some sites such as
microsoft.com block echo request packets. Thus nmap can also
send a TCP ack packet to (by default) port 80. If we get an RST
back, that machine is up. A third technique involves sending a
SYN packet and waiting for a RST or a SYN/ACK. For non-root
users, a connect() method is used.
By default (for root users), nmap uses both the ICMP and ACK
techniques in parallel. You can change these with the -P
options described later.
Note that pinging is done by default anyway, and only hosts that
respond are scanned. Only use this option if you wish to ping
sweep without doing any actual port scans.
-sV Version detection: After TCP and/or UDP ports are discovered
using one of the other scan methods, version detection communi-
cates with those ports to try and determine more about what is
actually running. A file called nmap-service-probes is used to
determine the best probes for detecting various services and the
match strings to expect. Nmap tries to determine the service
protocol (e.g. ftp, ssh, telnet, http), the application name
(e.g. ISC Bind, Apache httpd, Solaris telnetd), the version num-
ber, and sometimes miscellaneous details like whether an X
server is open to connections or the SSH protocol version). If
Nmap was compiled with OpenSSL support, it will connect to SSL
servers to deduce the service listening behind the encryption.
When RPC services are discovered, the Nmap RPC grinder is used
to determine the RPC program and version numbers. Some UDP
ports are left in the "open|filtered" state after a UDP scan is
unable to determine whether the port is open or filtered. Ver-
sion detection will try to elicit a response from these ports
(just as it does with open ports), and change the state to open
if it succeeds. Note that the Nmap -A option also enables this
feature. For a much more detailed description of Nmap service
detection, read our paper at http://www.insecure.org/nmap/ver-
sionscan.html . There is a related --version_trace option which
causes Nmap to print out extensive debugging info about what
version scanning is doing (this is a subset of what you would
get with --packet_trace).
-sU UDP scans: This method is used to determine which UDP (User
Datagram Protocol, RFC 768) ports are open on a host. The tech-
nique is to send 0 byte UDP packets to each port on the target
machine. If we receive an ICMP port unreachable message, then
the port is closed. If a UDP response is received to the probe
(unusual), the port is open. If we get no response at all, the
state is "open|filtered", meaning that the port is either open
or packet filters are blocking the communication. Versions scan
(-sV) can be used to help differentiate the truly open ports
from the filtered ones.
Some people think UDP scanning is pointless. I usually remind
them of the Solaris rpcbind hole. Rpcbind can be found hiding on
an undocumented UDP port somewhere above 32770. So it doesn’t
matter that 111 is blocked by the firewall. But can you find
which of the more than 30,000 high ports it is listening on?
With a UDP scanner you can! There is also the cDc Back Orifice
backdoor program which hides on a configurable UDP port on Win-
dows machines. Not to mention the many commonly vulnerable ser-
vices that utilize UDP such as snmp, tftp, NFS, etc.
Unfortunately UDP scanning is sometimes painfully slow since
most hosts implement a suggestion in RFC 1812 (section 4.3.2.8)
of limiting the ICMP error message rate. For example, the Linux
kernel (in net/ipv4/icmp.h) limits destination unreachable mes-
sage generation to 80 per 4 seconds, with a 1/4 second penalty
if that is exceeded. Solaris has much more strict limits (about
2 messages per second) and thus takes even longer to scan. nmap
detects this rate limiting and slows down accordingly, rather
than flood the network with useless packets that will be ignored
by the target machine.
As is typical, Microsoft ignored the suggestion of the RFC and
does not seem to do any rate limiting at all on Win95 and NT
machines. Thus we can scan all 65K ports of a Windows machine
very quickly. Whoop!
-sO IP protocol scans: This method is used to determine which IP
protocols are supported on a host. The technique is to send raw
IP packets without any further protocol header to each specified
protocol on the target machine. If we receive an ICMP protocol
unreachable message, then the protocol is not in use. Otherwise
we assume it is open. Note that some hosts (AIX, HP-UX, Digital
UNIX) and firewalls may not send protocol unreachable messages.
This causes all of the protocols to appear "open".
Because the implemented technique is very similar to UDP port
scanning, ICMP rate limit might apply too. But the IP protocol
field has only 8 bits, so at most 256 protocols can be probed
which should be possible in reasonable time anyway.
-sI <zombie host[:probeport]>
Idlescan: This advanced scan method allows for a truly blind TCP
port scan of the target (meaning no packets are sent to the tar-
get from your real IP address). Instead, a unique side-channel
attack exploits predictable "IP fragmentation ID" sequence gen-
eration on the zombie host to glean information about the open
ports on the target. IDS systems will display the scan as com-
ing from the zombie machine you specify (which must be up and
meet certain criteria). I wrote an informal paper about this
technique at http://www.insecure.org/nmap/idlescan.html .
Besides being extraordinarily stealthy (due to its blind
nature), this scan type permits mapping out IP-based trust rela-
tionships between machines. The port listing shows open ports
from the perspective of the zombie host. So you can try scan-
ning a target using various zombies that you think might be
trusted (via router/packet filter rules). Obviously this is
crucial information when prioritizing attack targets. Other-
wise, you penetration testers might have to expend considerable
resources "owning" an ins no include Cisco, BSDI,
HP/UX, MVS, and IRIX. All of the above send resets from the
open ports when they should just drop the packet.
-sP Ping scanning: Sometimes you only want to know which hosts on a
network are up. Nmap can do this by sending ICMP echo request
packets to every IP address on the networks you specify. Hosts
that respond are up. Unfortunately, some sites such as
microsoft.com block echo request packets. Thus nmap can also
send a TCP ack packet to (by default) port 80. If we get an RST
back, that machine is up. A third technique involves sending a
SYN packet and waiting for a RST or a SYN/ACK. For non-root
users, a connect() method is used.
By default (for root users), nmap uses both the ICMP and ACK
techniques in parallel. You can change these with the -P
options described later.
Note that pinging is done by default anyway, and only hosts that
respond are scanned. Only use this option if you wish to ping
sweep without doing any actual port scans.
-sV Version detection: After TCP and/or UDP ports are discovered
using one of the other scan methods, version detection communi-
cates with those ports to try and determine more about what is
actually running. A file called nmap-service-probes is used to
determine the best probes for detecting various services and the
match strings to expect. Nmap tries to determine the service
protocol (e.g. ftp, ssh, telnet, http), the application name
(e.g. ISC Bind, Apache httpd, Solaris telnetd), the version num-
ber, and sometimes miscellaneous details like whether an X
server is open to connections or the SSH protocol version). If
Nmap was compiled with OpenSSL support, it will connect to SSL
servers to deduce the service listening behind the encryption.
When RPC services are discovered, the Nmap RPC grinder is used
to determine the RPC program and version numbers. Some UDP
ports are left in the "open|filtered" state after a UDP scan is
unable to determine whether the port is open or filtered. Ver-
sion detection will try to elicit a response from these ports
(just as it does with open ports), and change the state to open
if it succeeds. Note that the Nmap -A option also enables this
feature. For a much more detailed description of Nmap service
detection, read our paper at http://www.insecure.org/nmap/ver-
sionscan.html . There is a related --version_trace option which
causes Nmap to print out extensive debugging info about what
version scanning is doing (this is a subset of what you would
get with --packet_trace).
-sU UDP scans: This method is used to determine which UDP (User
Datagram Protocol, RFC 768) ports are open on a host. The tech-
nique is to send 0 byte UDP packets to each port on the target
machine. If we receive an ICMP port unreachable message, then
the port is closed. If a UDP response is received to the probe
(unusual), the port is open. If we get no response at all, the
state is "open|filtered", meaning that the port is either open
or packet filters are blocking the communication. Versions scan
(-sV) can be used to help differentiate the truly open ports
from the filtered ones.
Some people think UDP scanning is pointless. I usually remind
them of the Solaris rpcbind hole. Rpcbind can be found hiding on
an undocumented UDP port somewhere above 32770. So it doesn’t
matter that 111 is blocked by the firewall. But can you find
which of the more than 30,000 high ports it is listening on?
With a UDP scanner you can! There is also the cDc Back Orifice
backdoor program which hides on a configurable UDP port on Win-
dows machines. Not to mention the many commonly vulnerable ser-
vices that utilize UDP such as snmp, tftp, NFS, etc.
Unfortunately UDP scanning is sometimes painfully slow since
most hosts implement a suggestion in RFC 1812 (section 4.3.2.8)
of limiting the ICMP error message rate. For example, the Linux
kernel (in net/ipv4/icmp.h) limits destination unreachable mes-
sage generation to 80 per 4 seconds, with a 1/4 second penalty
if that is exceeded. Solaris has much more strict limits (about
2 messages per second) and thus takes even longer to scan. nmap
detects this rate limiting and slows down accordingly, rather
than flood the network with useless packets that will be ignored
by the target machine.
As is typical, Microsoft ignored the suggestion of the RFC and
does not seem to do any rate limiting at all on Win95 and NT
machines. Thus we can scan all 65K ports of a Windows machine
very quickly. Whoop!
-sO IP protocol scans: This method is used to determine which IP
protocols are supported on a host. The technique is to send raw
IP packets without any further protocol header to each specified
protocol on the target machine. If we receive an ICMP protocol
unreachable message, then the protocol is not in use. Otherwise
we assume it is open. Note that some hosts (AIX, HP-UX, Digital
UNIX) and firewalls may not send protocol unreachable messages.
This causes all of the protocols to appear "open".
Because the implemented technique is very similar to UDP port
scanning, ICMP rate limit might apply too. But the IP protocol
field has only 8 bits, so at most 256 protocols can be probed
which should be possible in reasonable time anyway.
-sI <zombie host[:probeport]>
Idlescan: This advanced scan method allows for a truly blind TCP
port scan of the target (meaning no packets are sent to the tar-
get from your real IP address). Instead, a unique side-channel
attack exploits predictable "IP fragmentation ID" sequence gen-
eration on the zombie host to glean information about the open
ports on the target. IDS systems will display the scan as com-
ing from the zombie machine you specify (which must be up and
meet certain criteria). I wrote an informal paper about this
technique at http://www.insecure.org/nmap/idlescan.html .
Besides being extraordinarily stealthy (due to its blind
nature), this scan type permits mapping out IP-based trust rela-
tionships between machines. The port listing shows open ports
from the perspective of the zombie host. So you can try scan-
ning a target using various zombies that you think might be
trusted (via router/packet filter rules). Obviously this is
crucial information when prioritizing attack targets. Other-
wise, you penetration testers might have to expend considerable
resources "owning" an ins no include Cisco, BSDI,
HP/UX, MVS, and IRIX. All of the above send resets from the
open ports when they should just drop the packet.
-sP Ping scanning: Sometimes you only want to know which hosts on a
network are up. Nmap can do this by sending ICMP echo request
packets to every IP address on the networks you specify. Hosts
that respond are up. Unfortunately, some sites such as
microsoft.com block echo request packets. Thus nmap can also
send a TCP ack packet to (by default) port 80. If we get an RST
back, that machine is up. A third technique involves sending a
SYN packet and waiting for a RST or a SYN/ACK. For non-root
users, a connect() method is used.
By default (for root users), nmap uses both the ICMP and ACK
techniques in parallel. You can change these with the -P
options described later.
Note that pinging is done by default anyway, and only hosts that
respond are scanned. Only use this option if you wish to ping
sweep without doing any actual port scans.
-sV Version detection: After TCP and/or UDP ports are discovered
using one of the other scan methods, version detection communi-
cates with those ports to try and determine more about what is
actually running. A file called nmap-service-probes is used to
determine the best probes for detecting various services and the
match strings to expect. Nmap tries to determine the service
protocol (e.g. ftp, ssh, telnet, http), the application name
(e.g. ISC Bind, Apache httpd, Solaris telnetd), the version num-
ber, and sometimes miscellaneous details like whether an X
server is open to connections or the SSH protocol version). If
Nmap was compiled with OpenSSL support, it will connect to SSL
servers to deduce the service listening behind the encryption.
When RPC services are discovered, the Nmap RPC grinder is used
to determine the RPC program and version numbers. Some UDP
ports are left in the "open|filtered" state after a UDP scan is
unable to determine whether the port is open or filtered. Ver-
sion detection will try to elicit a response from these ports
(just as it does with open ports), and change the state to open
if it succeeds. Note that the Nmap -A option also enables this
feature. For a much more detailed description of Nmap service
detection, read our paper at http://www.insecure.org/nmap/ver-
sionscan.html . There is a related --version_trace option which
causes Nmap to print out extensive debugging info about what
version scanning is doing (this is a subset of what you would
get with --packet_trace).
-sU UDP scans: This method is used to determine which UDP (User
Datagram Protocol, RFC 768) ports are open on a host. The tech-
nique is to send 0 byte UDP packets to each port on the target
machine. If we receive an ICMP port unreachable message, then
the port is closed. If a UDP response is received to the probe
(unusual), the port is open. If we get no response at all, the
state is "open|filtered", meaning that the port is either open
or packet filters are blocking the communication. Versions scan
(-sV) can be used to help differentiate the truly open ports
from the filtered ones.
Some people think UDP scanning is pointless. I usually remind
them of the Solaris rpcbind hole. Rpcbind can be found hiding on
an undocumented UDP port somewhere above 32770. So it doesn’t
matter that 111 is blocked by the firewall. But can you find
which of the more than 30,000 high ports it is listening on?
With a UDP scanner you can! There is also the cDc Back Orifice
backdoor program which hides on a configurable UDP port on Win-
dows machines. Not to mention the many commonly vulnerable ser-
vices that utilize UDP such as snmp, tftp, NFS, etc.
Unfortunately UDP scanning is sometimes painfully slow since
most hosts implement a suggestion in RFC 1812 (section 4.3.2.8)
of limiting the ICMP error message rate. For example, the Linux
kernel (in net/ipv4/icmp.h) limits destination unreachable mes-
sage generation to 80 per 4 seconds, with a 1/4 second penalty
if that is exceeded. Solaris has much more strict limits (about
2 messages per second) and thus takes even longer to scan. nmap
detects this rate limiting and slows down accordingly, rather
than flood the network with useless packets that will be ignored
by the target machine.
As is typical, Microsoft ignored the suggestion of the RFC and
does not seem to do any rate limiting at all on Win95 and NT
machines. Thus we can scan all 65K ports of a Windows machine
very quickly. Whoop!
-sO IP protocol scans: This method is used to determine which IP
protocols are supported on a host. The technique is to send raw
IP packets without any further protocol header to each specified
protocol on the target machine. If we receive an ICMP protocol
unreachable message, then the protocol is not in use. Otherwise
we assume it is open. Note that some hosts (AIX, HP-UX, Digital
UNIX) and firewalls may not send protocol unreachable messages.
This causes all of the protocols to appear "open".
Because the implemented technique is very similar to UDP port
scanning, ICMP rate limit might apply too. But the IP protocol
field has only 8 bits, so at most 256 protocols can be probed
which should be possible in reasonable time anyway.
-sI <zombie host[:probeport]>
Idlescan: This advanced scan method allows for a truly blind TCP
port scan of the target (meaning no packets are sent to the tar-
get from your real IP address). Instead, a unique side-channel
attack exploits predictable "IP fragmentation ID" sequence gen-
eration on the zombie host to glean information about the open
ports on the target. IDS systems will display the scan as com-
ing from the zombie machine you specify (which must be up and
meet certain criteria). I wrote an informal paper about this
technique at http://www.insecure.org/nmap/idlescan.html .
Besides being extraordinarily stealthy (due to its blind
nature), this scan type permits mapping out IP-based trust rela-
tionships between machines. The port listing shows open ports
from the perspective of the zombie host. So you can try scan-
ning a target using various zombies that you think might be
trusted (via router/packet filter rules). Obviously this is
crucial information when prioritizing attack targets. Other-
wise, you penetration testers might have to expend considerable
resources "owning" an ins no include Cisco, BSDI,
HP/UX, MVS, and IRIX. All of the above send resets from the
open ports when they should just drop the packet.
-sP Ping scanning: Sometimes you only want to know which hosts on a
network are up. Nmap can do this by sending ICMP echo request
packets to every IP address on the networks you specify. Hosts
that respond are up. Unfortunately, some sites such as
microsoft.com block echo request packets. Thus nmap can also
send a TCP ack packet to (by default) port 80. If we get an RST
back, that machine is up. A third technique involves sending a
SYN packet and waiting for a RST or a SYN/ACK. For non-root
users, a connect() method is used.
By default (for root users), nmap uses both the ICMP and ACK
techniques in parallel. You can change these with the -P
options described later.
Note that pinging is done by default anyway, and only hosts that
respond are scanned. Only use this option if you wish to ping
sweep without doing any actual port scans.
-sV Version detection: After TCP and/or UDP ports are discovered
using one of the other scan methods, version detection communi-
cates with those ports to try and determine more about what is
actually running. A file called nmap-service-probes is used to
determine the best probes for detecting various services and the
match strings to expect. Nmap tries to determine the service
protocol (e.g. ftp, ssh, telnet, http), the application name
(e.g. ISC Bind, Apache httpd, Solaris telnetd), the version num-
ber, and sometimes miscellaneous details like whether an X
server is open to connections or the SSH protocol version). If
Nmap was compiled with OpenSSL support, it will connect to SSL
servers to deduce the service listening behind the encryption.
When RPC services are discovered, the Nmap RPC grinder is used
to determine the RPC program and version numbers. Some UDP
ports are left in the "open|filtered" state after a UDP scan is
unable to determine whether the port is open or filtered. Ver-
sion detection will try to elicit a response from these ports
(just as it does with open ports), and change the state to open
if it succeeds. Note that the Nmap -A option also enables this
feature. For a much more detailed description of Nmap service
detection, read our paper at http://www.insecure.org/nmap/ver-
sionscan.html . There is a related --version_trace option which
causes Nmap to print out extensive debugging info about what
version scanning is doing (this is a subset of what you would
get with --packet_trace).
-sU UDP scans: This method is used to determine which UDP (User
Datagram Protocol, RFC 768) ports are open on a host. The tech-
nique is to send 0 byte UDP packets to each port on the target
machine. If we receive an ICMP port unreachable message, then
the port is closed. If a UDP response is received to the probe
(unusual), the port is open. If we get no response at all, the
state is "open|filtered", meaning that the port is either open
or packet filters are blocking the communication. Versions scan
(-sV) can be used to help differentiate the truly open ports
from the filtered ones.
Some people think UDP scanning is pointless. I usually remind
them of the Solaris rpcbind hole. Rpcbind can be found hiding on
an undocumented UDP port somewhere above 32770. So it doesn’t
matter that 111 is blocked by the firewall. But can you find
which of the more than 30,000 high ports it is listening on?
With a UDP scanner you can! There is also the cDc Back Orifice
backdoor program which hides on a configurable UDP port on Win-
dows machines. Not to mention the many commonly vulnerable ser-
vices that utilize UDP such as snmp, tftp, NFS, etc.
Unfortunately UDP scanning is sometimes painfully slow since
most hosts implement a suggestion in RFC 1812 (section 4.3.2.8)
of limiting the ICMP error message rate. For example, the Linux
kernel (in net/ipv4/icmp.h) limits destination unreachable mes-
sage generation to 80 per 4 seconds, with a 1/4 second penalty
if that is exceeded. Solaris has much more strict limits (about
2 messages per second) and thus takes even longer to scan. nmap
detects this rate limiting and slows down accordingly, rather
than flood the network with useless packets that will be ignored
by the target machine.
As is typical, Microsoft ignored the suggestion of the RFC and
does not seem to do any rate limiting at all on Win95 and NT
machines. Thus we can scan all 65K ports of a Windows machine
very quickly. Whoop!
-sO IP protocol scans: This method is used to determine which IP
protocols are supported on a host. The technique is to send raw
IP packets without any further protocol header to each specified
protocol on the target machine. If we receive an ICMP protocol
unreachable message, then the protocol is not in use. Otherwise
we assume it is open. Note that some hosts (AIX, HP-UX, Digital
UNIX) and firewalls may not send protocol unreachable messages.
This causes all of the protocols to appear "open".
Because the implemented technique is very similar to UDP port
scanning, ICMP rate limit might apply too. But the IP protocol
field has only 8 bits, so at most 256 protocols can be probed
which should be possible in reasonable time anyway.
-sI <zombie host[:probeport]>
Idlescan: This advanced scan method allows for a truly blind TCP
port scan of the target (meaning no packets are sent to the tar-
get from your real IP address). Instead, a unique side-channel
attack exploits predictable "IP fragmentation ID" sequence gen-
eration on the zombie host to glean information about the open
ports on the target. IDS systems will display the scan as com-
ing from the zombie machine you specify (which must be up and
meet certain criteria). I wrote an informal paper about this
technique at http://www.insecure.org/nmap/idlescan.html .
Besides being extraordinarily stealthy (due to its blind
nature), this scan type permits mapping out IP-based trust rela-
tionships between machines. The port listing shows open ports
from the perspective of the zombie host. So you can try scan-
ning a target using various zombies that you think might be
trusted (via router/packet filter rules). Obviously this is
crucial information when prioritizing attack targets. Other-
wise, you penetration testers might have to expend considerable
resources "owning" an ins no include Cisco, BSDI,
HP/UX, MVS, and IRIX. All of the above send resets from the
open ports when they should just drop the packet.
-sP Ping scanning: Sometimes you only want to know which hosts on a
network are up. Nmap can do this by sending ICMP echo request
packets to every IP address on the networks you specify. Hosts
that respond are up. Unfortunately, some sites such as
microsoft.com block echo request packets. Thus nmap can also
send a TCP ack packet to (by default) port 80. If we get an RST
back, that machine is up. A third technique involves sending a
SYN packet and waiting for a RST or a SYN/ACK. For non-root
users, a connect() method is used.
By default (for root users), nmap uses both the ICMP and ACK
techniques in parallel. You can change these with the -P
options described later.
Note that pinging is done by default anyway, and only hosts that
respond are scanned. Only use this option if you wish to ping
sweep without doing any actual port scans.
-sV Version detection: After TCP and/or UDP ports are discovered
using one of the other scan methods, version detection communi-
cates with those ports to try and determine more about what is
actually running. A file called nmap-service-probes is used to
determine the best probes for detecting various services and the
match strings to expect. Nmap tries to determine the service
protocol (e.g. ftp, ssh, telnet, http), the application name
(e.g. ISC Bind, Apache httpd, Solaris telnetd), the version num-
ber, and sometimes miscellaneous details like whether an X
server is open to connections or the SSH protocol version). If
Nmap was compiled with OpenSSL support, it will connect to SSL
servers to deduce the service listening behind the encryption.
When RPC services are discovered, the Nmap RPC grinder is used
to determine the RPC program and version numbers. Some UDP
ports are left in the "open|filtered" state after a UDP scan is
unable to determine whether the port is open or filtered. Ver-
sion detection will try to elicit a response from these ports
(just as it does with open ports), and change the state to open
if it succeeds. Note that the Nmap -A option also enables this
feature. For a much more detailed description of Nmap service
detection, read our paper at http://www.insecure.org/nmap/ver-
sionscan.html . There is a related --version_trace option which
causes Nmap to print out extensive debugging info about what
version scanning is doing (this is a subset of what you would
get with --packet_trace).
-sU UDP scans: This method is used to determine which UDP (User
Datagram Protocol, RFC 768) ports are open on a host. The tech-
nique is to send 0 byte UDP packets to each port on the target
machine. If we receive an ICMP port unreachable message, then
the port is closed. If a UDP response is received to the probe
(unusual), the port is open. If we get no response at all, the
state is "open|filtered", meaning that the port is either open
or packet filters are blocking the communication. Versions scan
(-sV) can be used to help differentiate the truly open ports
from the filtered ones.
Some people think UDP scanning is pointless. I usually remind
them of the Solaris rpcbind hole. Rpcbind can be found hiding on
an undocumented UDP port somewhere above 32770. So it doesn’t
matter that 111 is blocked by the firewall. But can you find
which of the more than 30,000 high ports it is listening on?
With a UDP scanner you can! There is also the cDc Back Orifice
backdoor program which hides on a configurable UDP port on Win-
dows machines. Not to mention the many commonly vulnerable ser-
vices that utilize UDP such as snmp, tftp, NFS, etc.
Unfortunately UDP scanning is sometimes painfully slow since
most hosts implement a suggestion in RFC 1812 (section 4.3.2.8)
of limiting the ICMP error message rate. For example, the Linux
kernel (in net/ipv4/icmp.h) limits destination unreachable mes-
sage generation to 80 per 4 seconds, with a 1/4 second penalty
if that is exceeded. Solaris has much more strict limits (about
2 messages per second) and thus takes even longer to scan. nmap
detects this rate limiting and slows down accordingly, rather
than flood the network with useless packets that will be ignored
by the target machine.
As is typical, Microsoft ignored the suggestion of the RFC and
does not seem to do any rate limiting at all on Win95 and NT
machines. Thus we can scan all 65K ports of a Windows machine
very quickly. Whoop!
-sO IP protocol scans: This method is used to determine which IP
protocols are supported on a host. The technique is to send raw
IP packets without any further protocol header to each specified
protocol on the target machine. If we receive an ICMP protocol
unreachable message, then the protocol is not in use. Otherwise
we assume it is open. Note that some hosts (AIX, HP-UX, Digital
UNIX) and firewalls may not send protocol unreachable messages.
This causes all of the protocols to appear "open".
Because the implemented technique is very similar to UDP port
scanning, ICMP rate limit might apply too. But the IP protocol
field has only 8 bits, so at most 256 protocols can be probed
which should be possible in reasonable time anyway.
-sI <zombie host[:probeport]>
Idlescan: This advanced scan method allows for a truly blind TCP
port scan of the target (meaning no packets are sent to the tar-
get from your real IP address). Instead, a unique side-channel
attack exploits predictable "IP fragmentation ID" sequence gen-
eration on the zombie host to glean information about the open
ports on the target. IDS systems will display the scan as com-
ing from the zombie machine you specify (which must be up and
meet certain criteria). I wrote an informal paper about this
technique at http://www.insecure.org/nmap/idlescan.html .
Besides being extraordinarily stealthy (due to its blind
nature), this scan type permits mapping out IP-based trust rela-
tionships between machines. The port listing shows open ports
from the perspective of the zombie host. So you can try scan-
ning a target using various zombies that you think might be
trusted (via router/packet filter rules). Obviously this is
crucial information when prioritizing attack targets. Other-
wise, you penetration testers might have to expend considerable
resources "owning" an ins no include Cisco, BSDI,
HP/UX, MVS, and IRIX. All of the above send resets from the
open ports when they should just drop the packet.
-sP Ping scanning: Sometimes you only want to know which hosts on a
network are up. Nmap can do this by sending ICMP echo request
packets to every IP address on the networks you specify. Hosts
that respond are up. Unfortunately, some sites such as
microsoft.com block echo request packets. Thus nmap can also
send a TCP ack packet to (by default) port 80. If we get an RST
back, that machine is up. A third technique involves sending a
SYN packet and waiting for a RST or a SYN/ACK. For non-root
users, a connect() method is used.
By default (for root users), nmap uses both the ICMP and ACK
techniques in parallel. You can change these with the -P
options described later.
Note that pinging is done by default anyway, and only hosts that
respond are scanned. Only use this option if you wish to ping
sweep without doing any actual port scans.
-sV Version detection: After TCP and/or UDP ports are discovered
using one of the other scan methods, version detection communi-
cates with those ports to try and determine more about what is
actually running. A file called nmap-service-probes is used to
determine the best probes for detecting various services and the
match strings to expect. Nmap tries to determine the service
protocol (e.g. ftp, ssh, telnet, http), the application name
(e.g. ISC Bind, Apache httpd, Solaris telnetd), the version num-
ber, and sometimes miscellaneous details like whether an X
server is open to connections or the SSH protocol version). If
Nmap was compiled with OpenSSL support, it will connect to SSL
servers to deduce the service listening behind the encryption.
When RPC services are discovered, the Nmap RPC grinder is used
to determine the RPC program and version numbers. Some UDP
ports are left in the "open|filtered" state after a UDP scan is
unable to determine whether the port is open or filtered. Ver-
sion detection will try to elicit a response from these ports
(just as it does with open ports), and change the state to open
if it succeeds. Note that the Nmap -A option also enables this
feature. For a much more detailed description of Nmap service
detection, read our paper at http://www.insecure.org/nmap/ver-
sionscan.html . There is a related --version_trace option which
causes Nmap to print out extensive debugging info about what
version scanning is doing (this is a subset of what you would
get with --packet_trace).
-sU UDP scans: This method is used to determine which UDP (User
Datagram Protocol, RFC 768) ports are open on a host. The tech-
nique is to send 0 byte UDP packets to each port on the target
machine. If we receive an ICMP port unreachable message, then
the port is closed. If a UDP response is received to the probe
(unusual), the port is open. If we get no response at all, the
state is "open|filtered", meaning that the port is either open
or packet filters are blocking the communication. Versions scan
(-sV) can be used to help differentiate the truly open ports
from the filtered ones.
Some people think UDP scanning is pointless. I usually remind
them of the Solaris rpcbind hole. Rpcbind can be found hiding on
an undocumented UDP port somewhere above 32770. So it doesn’t
matter that 111 is blocked by the firewall. But can you find
which of the more than 30,000 high ports it is listening on?
With a UDP scanner you can! There is also the cDc Back Orifice
backdoor program which hides on a configurable UDP port on Win-
dows machines. Not to mention the many commonly vulnerable ser-
vices that utilize UDP such as snmp, tftp, NFS, etc.
Unfortunately UDP scanning is sometimes painfully slow since
most hosts implement a suggestion in RFC 1812 (section 4.3.2.8)
of limiting the ICMP error message rate. For example, the Linux
kernel (in net/ipv4/icmp.h) limits destination unreachable mes-
sage generation to 80 per 4 seconds, with a 1/4 second penalty
if that is exceeded. Solaris has much more strict limits (about
2 messages per second) and thus takes even longer to scan. nmap
detects this rate limiting and slows down accordingly, rather
than flood the network with useless packets that will be ignored
by the target machine.
As is typical, Microsoft ignored the suggestion of the RFC and
does not seem to do any rate limiting at all on Win95 and NT
machines. Thus we can scan all 65K ports of a Windows machine
very quickly. Whoop!
-sO IP protocol scans: This method is used to determine which IP
protocols are supported on a host. The technique is to send raw
IP packets without any further protocol header to each specified
protocol on the target machine. If we receive an ICMP protocol
unreachable message, then the protocol is not in use. Otherwise
we assume it is open. Note that some hosts (AIX, HP-UX, Digital
UNIX) and firewalls may not send protocol unreachable messages.
This causes all of the protocols to appear "open".
Because the implemented technique is very similar to UDP port
scanning, ICMP rate limit might apply too. But the IP protocol
field has only 8 bits, so at most 256 protocols can be probed
which should be possible in reasonable time anyway.
-sI <zombie host[:probeport]>
Idlescan: This advanced scan method allows for a truly blind TCP
port scan of the target (meaning no packets are sent to the tar-
get from your real IP address). Instead, a unique side-channel
attack exploits predictable "IP fragmentation ID" sequence gen-
eration on the zombie host to glean information about the open
ports on the target. IDS systems will display the scan as com-
ing from the zombie machine you specify (which must be up and
meet certain criteria). I wrote an informal paper about this
technique at http://www.insecure.org/nmap/idlescan.html .
Besides being extraordinarily stealthy (due to its blind
nature), this scan type permits mapping out IP-based trust rela-
tionships between machines. The port listing shows open ports
from the perspective of the zombie host. So you can try scan-
ning a target using various zombies that you think might be
trusted (via router/packet filter rules). Obviously this is
crucial information when prioritizing attack targets. Other-
wise, you penetration testers might have to expend considerable
resources "owning" an ins no include Cisco, BSDI,
HP/UX, MVS, and IRIX. All of the above send resets from the
open ports when they should just drop the packet.
-sP Ping scanning: Sometimes you only want to know which hosts on a
network are up. Nmap can do this by sending ICMP echo request
packets to every IP address on the networks you specify. Hosts
that respond are up. Unfortunately, some sites such as
microsoft.com