Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
NMAP(1)			    General Commands Manual		       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),	Reverse-ident, ICMP (ping sweep), FIN, ACK sweep, Xmas
       Tree, SYN sweep,	IP Protocol, and Null scan.  See the Scan  Types  sec-
       tion  for more details.	nmap also offers a number of advanced features
       such as remote OS detection via TCP/IP  fingerprinting,	stealth	 scan-
       ning, dynamic delay and retransmission calculations, parallel scanning,
       detection of down hosts via parallel pings, decoy scanning,  port  fil-
       tering  detection,  direct (non-portmapper) RPC scanning, fragmentation
       scanning, and flexible 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", "filtered", or "unfiltered".  Open  means  that
       the  target  machine  will accept() connections on that port.  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 interfering	with nmap's attempts to	deter-
       mine this.  Unfiltered ports are	the common case	 and  are  only	 shown
       when most of the	scanned	ports are in the filtered state.

       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  op-
       tions 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 re-
	      ceived,  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.  Un-
	      fortunately 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 ma-
	      chine. If	the port is listening, connect() will succeed,	other-
	      wise  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).  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 com-
	      pletely  ignore  the standard and	do things their	own way.  Thus
	      this scan	type  will  not	 work  against	systems	 running  Win-
	      dows95/NT.   On the positive side, this is a good	way to distin-
	      guish 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	micro-
	      soft.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 the -P option 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: Afer TCP and/or UDP ports are discovered  us-
	      ing  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.	 Note that the
	      Nmap -A option also enables this feature.	 For a much  more  de-
	      tailed  description of Nmap service detection, read our paper at
	      http://www.insecure.org/nmap/versionscan.html .  There is	a  re-
	      lated  --version_trace option which causes Nmap to print out ex-
	      tensive 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.  Otherwise we assume it is open.  Unfortu-
	      nately, firewalls	often block  the  port	unreachable  messages,
	      causing  the  port  to appear open.  Sometimes an	ISP will block
	      only a few specific dangerous ports such as 31337	(back orifice)
	      and  139 (Windows	NetBIOS), making it look like these vulnerable
	      ports are	open.  So don't	panic immediately.  Unfortunately,  it
	      isn't  always  trivial  to  differentiate	 between real open UDP
	      ports and	these filtered false-positives.

	      Some people think	UDP scanning is	pointless.  I  usually	remind
	      them  of	the  recent Solaris rcpbind 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 Ori-
	      fice backdoor program which hides	on a configurable UDP port  on
	      Windows  machines.   Not to mention the many commonly vulnerable
	      services 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 ma-
	      chines.	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  na-
	      ture),  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 intermediate system, only to find out that
	      its IP isn't even	trusted	by the target host/network you are ul-
	      timately after.

	      You can add a colon followed by a	port number  if	 you  wish  to
	      probe  a	particular  port  on the zombie	host for IPID changes.
	      Otherwise	Nmap will use the port it uses	by  default  for  "tcp
	      pings".

       -sA    ACK  scan: This advanced method is usually used to map out fire-
	      wall rulesets.  In particular, it	can help determine  whether  a
	      firewall	is stateful or just a simple packet filter that	blocks
	      incoming SYN packets.

	      This scan	type sends an ACK packet (with random looking acknowl-
	      edgment/sequence	numbers)  to  the  ports  specified.  If a RST
	      comes back, the ports is classified as "unfiltered".  If nothing
	      comes  back (or if an ICMP unreachable is	returned), the port is
	      classified as "filtered".	 Note that nmap	usually	doesn't	 print
	      "unfiltered"  ports,  so getting no ports	shown in the output is
	      usually a	sign that all the probes  got  through	(and  returned
	      RSTs).  This  scan will obviously	never show ports in the	"open"
	      state.

       -sW    Window scan: This	advanced scan is very similar to the ACK scan,
	      except  that  it can sometimes detect open ports as well as fil-
	      tered/unfiltered due to an anomaly in the	TCP  window  size  re-
	      porting  by  some	operating systems.  Systems vulnerable to this
	      include at least some versions of	AIX, Amiga, BeOS, BSDI,	 Cray,
	      Tru64  UNIX, DG/UX, OpenVMS, Digital UNIX, FreeBSD, HP-UX, OS/2,
	      IRIX, MacOS, NetBSD, OpenBSD,  OpenStep,	QNX,  Rhapsody,	 SunOS
	      4.X,  Ultrix,  VAX,  and	VxWorks.  See the nmap-hackers mailing
	      list archive for a full list.

       -sR    RPC scan.	 This method works in  combination  with  the  various
	      port scan	methods	of Nmap.  It takes all the TCP/UDP ports found
	      open and then floods them	with SunRPC program NULL  commands  in
	      an  attempt  to determine	whether	they are RPC ports, and	if so,
	      what program and version number they serve up.  Thus you can ef-
	      fectively	 obtain	the same info as "rpcinfo -p" even if the tar-
	      get's portmapper is behind a firewall (or	protected by TCP wrap-
	      pers).   Decoys  do  not	currently  work	with RPC scan, at some
	      point I may add decoy support for	UDP RPC	scans.

       -sL    List scan.  This method simply generates and prints  a  list  of
	      IPs/Names	 without  actually pinging or port scanning them.  DNS
	      name resolution will be performed	unless you use -n.

       -b <ftp relay host>
	      FTP bounce attack: An interesting	"feature" of the ftp  protocol
	      (RFC  959)  is  support  for  "proxy"  ftp connections. In other
	      words, I should be able to connect  from	evil.com  to  the  FTP
	      server  of  target.com  and  request that	the server send	a file
	      ANYWHERE on the Internet!	 Now this may have worked well in 1985
	      when the RFC was written.	But in today's Internet, we can't have
	      people hijacking ftp servers and requesting that	data  be  spit
	      out  to arbitrary	points on the Internet.	As *Hobbit* wrote back
	      in 1995, this protocol flaw "can be used to post	virtually  un-
	      traceable	 mail  and  news,  hammer on servers at	various	sites,
	      fill up disks, try to hop	firewalls, and generally  be  annoying
	      and  hard	 to track down at the same time." What we will exploit
	      this for is to  (surprise,  surprise)  scan  TCP	ports  from  a
	      "proxy"  ftp server. Thus	you could connect to an	ftp server be-
	      hind a firewall, and then	scan ports that	are more likely	to  be
	      blocked  (139  is	 a good	one). If the ftp server	allows reading
	      from and writing to some directory (such as /incoming), you  can
	      send arbitrary data to ports that	you do find open (nmap doesn't
	      do this for you though).

	      The argument passed to the "b" option is the host	 you  want  to
	      use  as a	proxy, in standard URL notation.  The format is: user-
	      name:password@server:port.  Everything but server	 is  optional.
	      To determine what	servers	are vulnerable to this attack, you can
	      see my article in	Phrack 51.  And	updated	version	 is  available
	      at the nmap URL (http://www.insecure.org/nmap).

       GENERAL OPTIONS
	      None  of	these are required but some can	be quite useful.  Note
	      that the -P options can now be combined -- you can increase your
	      odds of penetrating strict firewalls by sending many probe types
	      using different TCP ports/flags and ICMP codes.

       -P0    Do not try and ping hosts	at all before scanning them.  This al-
	      lows  the	 scanning  of  networks	that don't allow ICMP echo re-
	      quests (or responses) through their firewall.  microsoft.com  is
	      an example of such a network, and	thus you should	always use -P0
	      or -PT80 when portscanning microsoft.com.	 Note  tht  "ping"  in
	      this contect may involve more than the traditional ICMP echo re-
	      quest packet.  Nmap supports many	such probes,  including	 arbi-
	      trary  combinations  of  TCP, UDP, and ICMP probes.  By default,
	      Nmap sends an ICMP echo request and a TCP	ACK packet to port 80.

       -PT [portlist]
	      Use TCP "ping" to	determine what hosts are up.  Instead of send-
	      ing  ICMP	 echo  request	packets	and waiting for	a response, we
	      spew out TCP ACK packets throughout the target network (or to  a
	      single  machine)	and  then  wait	for responses to trickle back.
	      Hosts that are up	should respond with a RST.  This  option  pre-
	      serves  the  efficiency of only scanning hosts that are up while
	      still allowing you to scan networks/hosts	that block ping	 pack-
	      ets.  For	non root users,	we use connect().  To set the destina-
	      tion ports of the	 probe	packets	 use  -PT<port1>[,port2][...].
	      The  default  port  is 80, since this port is often not filtered
	      out.  Note that this option now  accepts	multiple,  comma-sepa-
	      rated port numbers.

       -PS [portlist]
	      This option uses SYN (connection request)	packets	instead	of ACK
	      packets for root users.  Hosts that are up should	respond	with a
	      RST  (or,	rarely,	a SYN|ACK).  You can set the destination ports
	      in the same manner as -PT	above.

       -PU [portlist]
	      This option sends	UDP probes to the specified  hosts,  expecting
	      an  ICMP	port unreachable packet	(or possibly a UDP response if
	      the port is open)	if the host is up.  Since  many	 UDP  services
	      won't  reply  to an empty	packet,	your best bet might be to send
	      this to expected-closed ports rather than	open ones.

       -PE    This option uses a true ping (ICMP  echo	request)  packet.   It
	      finds  hosts  that  are  up  and	also looks for subnet-directed
	      broadcast	addresses on your network.   These  are	 IP  addresses
	      which  are  externally reachable and translate to	a broadcast of
	      incoming IP packets to a subnet of computers.  These  should  be
	      eliminated if found as they allow	for numerous denial of service
	      attacks (Smurf is	the most common).

       -PP    Uses an ICMP timestamp request (code 13) packet to find  listen-
	      ing hosts.

       -PM    Same  as	-PE  and  -PP except uses a netmask request (ICMP code
	      17).

       -PB    This is the default ping type.  It uses both the ACK ( -PT ) and
	      ICMP  echo request ( -PE ) sweeps	in parallel.  This way you can
	      get firewalls that filter	either one (but	not  both).   The  TCP
	      probe destination	port can be set	in the same manner as with -PT
	      above.  Note that	this flag is now deprecated as pingtype	 flags
	      can now be used in combination.  So you should use both "PE" and
	      "PT" to achieve this same	effect.

       -O     This option activates remote host	identification via TCP/IP fin-
	      gerprinting.   In	 other words, it uses a	bunch of techniques to
	      detect subtleties	in the	underlying  operating  system  network
	      stack  of	the computers you are scanning.	 It uses this informa-
	      tion to create a "fingerprint" which it compares with its	 data-
	      base of known OS fingerprints (the nmap-os-fingerprints file) to
	      decide what type of system you are scanning.

	      If Nmap is unable	to guess the OS	of a machine,  and  conditions
	      are  good	(e.g. at least one open	port), Nmap will provide a URL
	      you can use to submit the	fingerprint if you know	(for sure) the
	      OS  running on the machine.  By doing this you contribute	to the
	      pool of operating	systems	known to nmap and thus it will be more
	      accurate	for everyone.  Note that if you	leave an IP address on
	      the form,	the machine may	be scanned when	we add the fingerprint
	      (to validate that	it works).

	      The -O option also enables several other tests.  One is the "Up-
	      time" measurement, which uses  the  TCP  timestamp  option  (RFC
	      1323)  to	 guess when a machine was last rebooted.  This is only
	      reported for machines which provide this information.

	      Another test enabled by -O is TCP	Sequence Predictability	 Clas-
	      sification.   This is a measure that describes approximately how
	      hard it is to establish a	forged TCP connection against the  re-
	      mote  host.  This	is useful for exploiting source-IP based trust
	      relationships (rlogin, firewall filters, etc) or for hiding  the
	      source  of  an attack.  The actual difficulty number is based on
	      statistical sampling and may fluctuate.  It is generally	better
	      to  use the English classification such as "worthy challenge" or
	      "trivial joke".  This is only reported in	normal output with -v.

	      When verbose mode	(-v) is	on with	-O, IPID  Sequence  Generation
	      is also reported.	 Most machines are in the "incremental"	class,
	      which means that they increment the "ID" field in	the IP	header
	      for  each	 packet	they send.  This makes them vulnerable to sev-
	      eral advanced information	gathering and spoofing attacks.

       -A     This option enables _a_dditional _a_dvanced and _a_ggressive op-
	      tions.   I  haven't  decided exactly which it stands for yet :).
	      Presently	this enables OS	Detection (-O)	and  version  scanning
	      (-sV).   More features may be added in the future.  The point is
	      to enable	a comprehensive	set of	scan  options  without	people
	      having  to  remember a large set of flags.  This option only en-
	      ables features, and not timing options (such  as	-T4)  or  ver-
	      bosity options (-v) that you might wan't as well.

       -6     This  options enables IPv6 support.  All targets must be IPv6 if
	      this option is used, and they can	be specified  via  normal  DNS
	      name   (AAAA  record)  or	 as  a	literal	 IP  address  such  as
	      3ffe:501:4819:2000:210:f3ff:fe03:4d0 .  Currently, connect() TCP
	      scan and TCP connect() Ping scan are supported.  If you need UDP
	      or  other	 scan  types,  have  a	look  at  http://nmap6.source-
	      forge.net/ .

       -I     This turns on TCP	reverse	ident scanning.	As noted by Dave Gold-
	      smith in a 1996 Bugtraq post, the	ident protocol (RFC 1413)  al-
	      lows  for	 the  disclosure of the	username that owns any process
	      connected	via TCP, even if that process didn't initiate the con-
	      nection.	So  you	can, for example, connect to the http port and
	      then use identd to find out whether the  server  is  running  as
	      root.  This  can	only be	done with a full TCP connection	to the
	      target port (i.e.	the -sT	scanning option).  When	 -I  is	 used,
	      the  remote  host's  identd is queried for each open port	found.
	      Obviously	this won't work	if the host is not running identd.

       -f     This option causes the requested SYN, FIN, XMAS, or NULL scan to
	      use tiny fragmented IP packets.  The idea	is to split up the TCP
	      header over several packets to make it harder  for  packet  fil-
	      ters,  intrusion	detection systems, and other annoyances	to de-
	      tect what	you are	doing. Be careful  with	 this!	Some  programs
	      have  trouble  handling  these tiny packets. My favorite sniffer
	      segmentation  faulted  immediately  upon	receiving  the	 first
	      36-byte  fragment.  After	 that  comes a 24 byte one! While this
	      method won't get by packet filters and firewalls that queue  all
	      IP  fragments  (like  the	 CONFIG_IP_ALWAYS_DEFRAG option	in the
	      Linux kernel), some networks can't afford	 the  performance  hit
	      this causes and thus leave it disabled.

	      Note  that I do not yet have this	option working on all systems.
	      It works fine for	my Linux, FreeBSD, and OpenBSD boxes and  some
	      people have reported success with	other *NIX variants.

       -v     Verbose  mode.  This is a	highly recommended option and it gives
	      out more information about what is going on.   You  can  use  it
	      twice  for  greater  effect.  You	can also use -d	a few times if
	      you really want to get crazy with	scrolling the screen!

       -h     This handy option	display	a quick	reference screen of nmap usage
	      options.	 As you	may have noticed, this man page	is not exactly
	      a	"quick reference" :)

       -oN <logfilename>
	      This logs	the results of your scans in a normal  human  readable
	      form into	the file you specify as	an argument.

       -oX <logfilename>
	      This  logs  the  results of your scans in	XML form into the file
	      you specify as an	argument.  This	allows programs	to easily cap-
	      ture  and	interpret Nmap results.	 You can give the argument "-"
	      (without quotes) to shoot	output into stdout  (for  shell	 pipe-
	      lines,  etc).   In  this	case normal output will	be suppressed.
	      Watch out	for error messages if you use this (they will still go
	      to  stderr).   Also note that "-v" may cause some	extra informa-
	      tion to be printed.  The Document	Type Definition	(DTD) defining
	      the  XML	output	structure  is  available  at  http://www.inse-
	      cure.org/nmap/nmap.dtd .

       -oG <logfilename>
	      This logs	the results of your scans in a grepable	form into  the
	      file  you	 specify  as an	argument.  This	simple format provides
	      all the information on one line (so you can easily grep for port
	      or OS information	and see	all the	IPs.  This used	to be the pre-
	      ferred mechanism for programs to interact	with Nmap, but now  we
	      recommend	 XML output (-oX instead).  This simple	format may not
	      contain as much information as the other formats.	 You can  give
	      the  argument  "-"  (without quotes) to shoot output into	stdout
	      (for shell pipelines, etc).  In this case	normal output will  be
	      suppressed.   Watch out for error	messages if you	use this (they
	      will still go to stderr).	 Also note that	"-v" will  cause  some
	      extra information	to be printed.

       -oA <basefilename>
	      This  tells  Nmap	 to  log  in  ALL  the	major formats (normal,
	      grepable,	and XML).  You give a base for the filename,  and  the
	      output files will	be base.nmap, base.gnmap, and base.xml.

       -oS <logfilename>
	      thIs l0gz	th3 r3suLtS of YouR ScanZ iN a s|<ipT kiDd|3 f0rM iNto
	      THe fiL3 U sPecfy	4s an arGuMEnT!	 U kAn gIv3 the	 4rgument  "-"
	      (wItHOUt qUOteZ) to sh00t	output iNT0 stDouT!@!!

       --resume	<logfilename>
	      A	 network  scan that is canceled	due to control-C, network out-
	      age, etc.	can be resumed using  this  option.   The  logfilename
	      must  be	either	a  normal (-oN)	or grepable (-oG) log from the
	      aborted scan.  No	other options can be given (they will  be  the
	      same as the aborted scan).  Nmap will start on the machine after
	      the last one successfully	scanned	in the log file.

       --append_output
	      Tells Nmap to append scan	results	to any output files  you  have
	      specified	rather than overwriting	those files.

       -iL <inputfilename>
	      Reads  target specifications from	the file specified RATHER than
	      from the command line.  The file should contain a	list  of  host
	      or  network  expressions separated by spaces, tabs, or newlines.
	      Use a hyphen (-) as inputfilename	if you want nmap to read  host
	      expressions  from	 stdin	(like  at the end of a pipe).  See the
	      section target specification for more information	on the expres-
	      sions you	fill the file with.

       -iR <num	hosts>
	      This option tells	Nmap to	generate its own hosts to scan by sim-
	      ply picking random numbers :).  It  will	never  end  after  the
	      given number of IPs has been scanned -- use 0 for	a never-ending
	      scan.  This option can be	useful for statistical sampling	of the
	      Internet	to  estimate  various  things.	If you are ever	really
	      bored, try nmap -sS -PS80	-iR 0 -p 80 to find some  web  servers
	      to look at.

       -p <port	ranges>
	      This  option specifies what ports	you want to specify. For exam-
	      ple "-p 23" will only try	port 23	of the	target	host(s).   "-p
	      20-30,139,60000-"	 scans	ports between 20 and 30, port 139, and
	      all ports	greater	than 60000.  The default is to scan all	 ports
	      between  1  and 1024 as well as any ports	listed in the services
	      file which comes with nmap.  For	IP  protocol  scanning	(-sO),
	      this specifies the protocol number you wish to scan for (0-255).

	      When scanning both TCP and UDP ports, you	can specify a particu-
	      lar protocol by preceding	the port numbers by "T:" or "U:".  The
	      qualifier	 lasts until you specify another qualifier.  For exam-
	      ple, the argument	 "-p  U:53,111,137,T:21-25,80,139,8080"	 would
	      scan  UDP	ports 53,111,and 137, as well as the listed TCP	ports.
	      Note that	to scan	both UDP & TCP,	you have to specify -sU	and at
	      least  one TCP scan type (such as	-sS, -sF, or -sT).  If no pro-
	      tocol qualifier is given,	the port numbers are added to all pro-
	      tocol lists.

       -F Fast scan mode.
	      Specifies	 that  you  only  wish to scan for ports listed	in the
	      services file which comes	with nmap (or the protocols  file  for
	      -sO).   This  is	obviously  much	faster than scanning all 65535
	      ports on a host.

       -D <decoy1 [,decoy2][,ME],...>
	      Causes a decoy scan to be	performed which	makes it appear	to the
	      remote  host that	the host(s) you	specify	as decoys are scanning
	      the target network too.  Thus their IDS might report  5-10  port
	      scans from unique	IP addresses, but they won't know which	IP was
	      scanning them and	which were innocent decoys.  While this	can be
	      defeated	through	 router	 path  tracing,	response-dropping, and
	      other "active" mechanisms, it is generally an  extremely	effec-
	      tive technique for hiding	your IP	address.

	      Separate each decoy host with commas, and	you can	optionally use
	      "ME" as one of the decoys	to represent  the  position  you  want
	      your IP address to be used.  If you put "ME" in the 6th position
	      or later,	some common port scan detectors	 (such	as  Solar  De-
	      signer's	excellent  scanlogd)  are unlikely to show your	IP ad-
	      dress at all.  If	you don't use "ME", nmap will  put  you	 in  a
	      random position.

	      Note  that the hosts you use as decoys should be up or you might
	      accidentally SYN flood your targets.  Also  it  will  be	pretty
	      easy to determine	which host is scanning if only one is actually
	      up on the	network.  You might want to use	IP  addresses  instead
	      of  names	 (so  the  decoy networks don't	see you	in their name-
	      server logs).

	      Also note	that some (stupid) "port scan  detectors"  will	 fire-
	      wall/deny	 routing  to  hosts that attempt port scans.  Thus you
	      might inadvertently cause	the machine you	scan to	 lose  connec-
	      tivity  with the decoy machines you are using.  This could cause
	      the target machines major	problems if the	decoy is, say, its In-
	      ternet  gateway  or even "localhost".  Thus you might want to be
	      careful of this option.  The real	moral of the story is that de-
	      tectors  of  spoofable port scans	should not take	action against
	      the machine that seems like it is	port scanning them.  It	 could
	      just be a	decoy!

	      Decoys  are used both in the initial ping	scan (using ICMP, SYN,
	      ACK, or whatever)	and during the	actual	port  scanning	phase.
	      Decoys are also used during remote OS detection (	-O ).

	      It is worth noting that using too	many decoys may	slow your scan
	      and potentially even make	it less	 accurate.   Also,  some  ISPs
	      will  filter  out	your spoofed packets, although many (currently
	      most) do not restrict spoofed IP packets at all.

       -S <IP_Address>
	      In some circumstances, nmap may not be able  to  determine  your
	      source  address  (  nmap will tell you if	this is	the case).  In
	      this situation, use -S with your IP address  (of	the  interface
	      you wish to send packets through).

	      Another  possible	 use of	this flag is to	spoof the scan to make
	      the targets think	that someone else is scanning them.  Imagine a
	      company  being repeatedly	port scanned by	a competitor!  This is
	      not a supported usage (or	the main purpose)  of  this  flag.   I
	      just  think  it  raises  an  interesting possibility that	people
	      should be	aware of before	they go	accusing others	of port	 scan-
	      ning  them.  -e would generally be required for this sort	of us-
	      age.

       -e <interface>
	      Tells nmap what interface	to send	and receive packets on.	  Nmap
	      should be	able to	detect this but	it will	tell you if it cannot.

       -g <portnumber>
	      Sets  the	source port number used	in scans.  Many	naive firewall
	      and packet filter	installations make an exception	in their rule-
	      set  to  allow DNS (53) or FTP-DATA (20) packets to come through
	      and establish a connection.  Obviously this completely  subverts
	      the security advantages of the firewall since intruders can just
	      masquerade as FTP	or DNS by modifying their source port.	 Obvi-
	      ously  for  a  UDP  scan	you  should try	53 first and TCP scans
	      should try 20 before 53.	Note that this is only	a  request  --
	      nmap will	honor it only if and when it is	able to.  For example,
	      you can't	do TCP ISN sampling all	 from  one  host:port  to  one
	      host:port, so nmap changes the source port even if you used -g.

	      Be aware that there is a small performance penalty on some scans
	      for using	this option, because I sometimes store useful informa-
	      tion in the source port number.

       --data_length <number>
	      Normally	Nmap  sends  minimalistic  packets that	only contain a
	      header.  So its TCP packets are generally	40 bytes and ICMP echo
	      requests	are  just  28.	 This  option tells Nmap to append the
	      given number of random bytes to most of the  packets  it	sends.
	      OS detection (-O)	packets	are not	affected, but most pinging and
	      portscan packets are.   This  slows  things  down,  but  can  be
	      slightly less conspicuous.

       -n     Tells  Nmap  to NEVER do reverse DNS resolution on the active IP
	      addresses	it finds.  Since DNS is	 often	slow,  this  can  help
	      speed things up.

       -R     Tells  Nmap to ALWAYS do reverse DNS resolution on the target IP
	      addresses.  Normally this	is only	done when a machine  is	 found
	      to be alive.

       -r     Tells  Nmap  NOT	to  randomize  the  order  in  which ports are
	      scanned.

       -ttl <value>
	      Sets the IPv4 time to live field in sent packets	to  the	 given
	      value.

       --randomize_hosts
	      Tells  Nmap  to shuffle each group of up to 2048 hosts before it
	      scans them.  This	can make the scans  less  obvious  to  various
	      network  monitoring systems, especially when you combine it with
	      slow timing options (see below).

       -M <max sockets>
	      Sets the maximum number of sockets that will be used in parallel
	      for  a TCP connect() scan	(the default).	This is	useful to slow
	      down the scan a little bit and avoid crashing  remote  machines.
	      Another  approach	 is  to	use -sS, which is generally easier for
	      machines to handle.

       --packet_trace
	      Tells Nmap to show all the packets it sends and  receives	 in  a
	      tcpdump-like format.  This can be	tremendously useful for	debug-
	      ging, and	is also	a good learning	tool.

       --datadir [directoryname]
	      Nmap obtains some	special	data at	runtime	in files  named	 nmap-
	      services,	 nmap-protocols,  nmap-rpc,  and nmap-os-fingerprints.
	      Nmap first searches these	 files	in  the	 directory  option  to
	      --nmapdir.   Any	files not found	there, are searched for	in the
	      directory	specified by the NMAPDIR environmental variable.  Next
	      comes   ~/nmap,	and   then  a  compiled-in  location  such  as
	      /usr/share/nmap .	 As a last resort, Nmap	will look in the  cur-
	      rent directory.

       TIMING OPTIONS
	      Generally	 Nmap does a good job at adjusting for Network charac-
	      teristics	at runtime and scanning	as fast	as possible while min-
	      imizing  that chances of hosts/ports going undetected.  However,
	      there are	same cases where Nmap's	default	timing policy may  not
	      meet  your  objectives.	The  following	options	provide	a fine
	      level of control over the	scan timing:

       -T <Paranoid|Sneaky|Polite|Normal|Aggressive|Insane>
	      These are	canned timing  policies	 for  conveniently  expressing
	      your priorities to Nmap.	Paranoid mode scans very slowly	in the
	      hopes of avoiding	detection by IDS systems.  It  serializes  all
	      scans (no	parallel scanning) and generally waits at least	5 min-
	      utes between sending packets.  Sneaky is similar,	except it only
	      waits  15	 seconds  between sending packets.  Polite is meant to
	      ease load	on the network and reduce the chances of crashing  ma-
	      chines.  It serializes the probes	and waits at least 0.4 seconds
	      between them.  Note that this is generally at least an order  of
	      magnitude	 slower	 than  default	scans, so only use it when you
	      need to.	Normal is the default Nmap behavior,  which  tries  to
	      run  as  quickly	as possible without overloading	the network or
	      missing hosts/ports.  Aggressive This option  can	 make  certain
	      scans (especially	SYN scans against heavily filtered hosts) much
	      faster.  It is recommended for impatient folks with a  fast  net
	      connection.   Insane  is only suitable for very fast networks or
	      where you	don't mind losing  some	 information.	It  times  out
	      hosts in 15 minutes and won't wait more than 0.3 seconds for in-
	      dividual probes.	It does	allow for very	quick  network	sweeps
	      though :).

	      You  can	also  reference	 these	by number (0-5).  For example,
	      "-T0" gives you Paranoid mode and	"-T5" is Insane	mode.

       --host_timeout <milliseconds>
	      Specifies	the amount of time Nmap	is allowed to spend scanning a
	      single  host  before  giving  up on that IP.  The	default	timing
	      mode has no host timeout.

       --max_rtt_timeout <milliseconds>
	      Specifies	the maximum amount of time Nmap	is allowed to wait for
	      a	 probe	response before	retransmitting or timing out that par-
	      ticular probe.  The default mode sets this to about 9000.

       --min_rtt_timeout <milliseconds>
	      When the target hosts start to establish a pattern of responding
	      very  quickly,  Nmap  will  shrink  the amount of	time given per
	      probe.  This speeds up the scan, but can lead to missed  packets
	      when  a  response	 takes longer than usual.  With	this parameter
	      you can guarantee	that Nmap will wait at least the given	amount
	      of time before giving up on a probe.

       --initial_rtt_timeout <milliseconds>
	      Specifies	 the  initial  probe  timeout.	This is	generally only
	      useful when scanning firewalled hosts with -P0.	Normally  Nmap
	      can  obtain  good	 RTT estimates from the	ping and the first few
	      probes.  The default mode	uses 6000.

       --max_parallelism <number>
	      Specifies	the maximum number of scans Nmap is allowed to perform
	      in  parallel.   Setting this to one means	Nmap will never	try to
	      scan more	than 1 port at a time.	It also	effects	other parallel
	      scans such as ping sweep,	RPC scan, etc.

       --min_parallelism <number>
	      Tells  Nmap to scan at least the given number of ports in	paral-
	      lel.  This can speed up scans against certain  firewalled	 hosts
	      by an order of magnitude.	 But be	careful	-- results will	become
	      unreliable if you	push it	too far.

       --scan_delay <milliseconds>
	      Specifies	the minimum amount of  time  Nmap  must	 wait  between
	      probes.  This is mostly useful to	reduce network load or to slow
	      the scan way down	to sneak under IDS thresholds.

       TARGET SPECIFICATION
	      Everything that isn't an option (or option argument) in nmap  is
	      treated  as  a  target host specification.  The simplest case is
	      listing single hostnames or IP addresses on  the	command	 line.
	      If  you  want  to	 scan a	subnet of IP addresses,	you can	append
	      /mask to the hostname or IP address.  mask  must	be  between  0
	      (scan  the  whole	 Internet) and 32 (scan	the single host	speci-
	      fied).  Use /24 to scan a	class "C" address and /16 for a	 class
	      "B".

	      Nmap also	has a more powerful notation which lets	you specify an
	      IP address using lists/ranges for	each element.	Thus  you  can
	      scan  the	 whole	class  "B"  network  192.168.*.* by specifying
	      "192.168.*.*"	or     "192.168.0-255.0-255"	  or	  even
	      "192.168.1-50,51-255.1,2,3,4,5-255".   And of course you can use
	      the mask notation: "192.168.0.0/16".  These are all  equivalent.
	      If  you  use  asterisks ("*"), remember that most	shells require
	      you to escape them  with	back  slashes  or  protect  them  with
	      quotes.

	      Another  interesting thing to do is slice	the Internet the other
	      way.  Instead of scanning	all the	hosts in  a  class  "B",  scan
	      "*.*.5.6-7"  to  scan  every  IP address that ends in specifying
	      hosts to scan, see the examples section.

EXAMPLES
       Here are	some examples of using nmap, from simple and normal to a  lit-
       tle  more  complex/esoteric.   Note that	actual numbers and some	actual
       domain names are	used to	make things more concrete.  In their place you
       should  substitute  addresses/names  from  your	own network.  I	do not
       think portscanning other	networks is illegal; nor should	 portscans  be
       construed by others as an attack.  I have scanned hundreds of thousands
       of machines and have received only one  complaint.   But	 I  am	not  a
       lawyer  and some	(anal) people may be annoyed by	nmap probes.  Get per-
       mission first or	use at your own	risk.

       nmap -v target.example.com

       This option scans all reserved TCP ports	on  the	 machine  target.exam-
       ple.com .  The -v means turn on verbose mode.

       nmap -sS	-O target.example.com/24

       Launches	 a stealth SYN scan against each machine that is up out	of the
       255 machines on class "C" where target.example.com  resides.   It  also
       tries  to  determine what operating system is running on	each host that
       is up and running.  This	requires root privileges because  of  the  SYN
       scan and	the OS detection.

       nmap -sX	-p 22,53,110,143,4564 198.116.*.1-127

       Sends an	Xmas tree scan to the first half of each of the	255 possible 8
       bit subnets in the 198.116 class	"B" address  space.   We  are  testing
       whether	the  systems  run sshd,	DNS, pop3d, imapd, or port 4564.  Note
       that Xmas scan doesn't work on Microsoft	boxes due to  their  deficient
       TCP stack.  Same	goes with CISCO, IRIX, HP/UX, and BSDI boxes.

       nmap -v --randomize_hosts -p 80 *.*.2.3-5

       Rather  than  focus on a	specific IP range, it is sometimes interesting
       to slice	up the entire Internet and  scan  a  small  sample  from  each
       slice.	This  command  finds  all  web servers on machines with	IP ad-
       dresses ending in .2.3, .2.4, or	.2.5 find  more	 interesting  machines
       starting	 at  127.  so  you  might want to use "127-222"	instead	of the
       first asterisks because that section has	a greater density of interest-
       ing machines (IMHO).

       host -l company.com | cut  -d  -f 4 | ./nmap -v -iL -

       Do  a  DNS zone transfer	to find	the hosts in company.com and then feed
       the IP addresses	to nmap.  The above commands are for my	GNU/Linux box.
       You may need different commands/options on other	operating systems.

BUGS
       Bugs?   What bugs?  Send	me any that you	find.  Patches are nice	too :)
       Remember	to also	send in	new OS fingerprints so we can grow  the	 data-
       base.   Nmap will give you a submission URL when	an appropriate finger-
       print is	found.

AUTHOR
       Fyodor _fyodor@insecure.org_

DISTRIBUTION
       The newest version  of  nmap  can  be  obtained	from  http://www.inse-
       cure.org/nmap/

       nmap is (C) 1995-2003 by	Insecure.Com LLC

       The  Nmap Security Scanner is (C) 1995-2003 Insecure.Com	LLC. This pro-
       gram is free software; you may redistribute and/or modify it under  the
       terms  of the GNU General Public	License	as published by	the Free Soft-
       ware Foundation;	Version	2.  This guarantees your right to use, modify,
       and  redistribute  this software	under certain conditions.  If you wish
       to embed	Nmap technology	into proprietary software, we may  be  willing
       to  sell	alternative licenses (contact sales@insecure.com).  Many secu-
       rity scanner vendors already license Nmap technology such as our	remote
       OS fingerprinting database and code.

       Note that we consider aggregation/inclusion/integration of Nmap into an
       executable installer to constitute a derived work and thus  subject  to
       the  GPL	 restrictions.	We also	consider certain programs that tightly
       integrate with Nmap to constitute derivative works, even	if  they  only
       interface  with	Nmap by	executing the Nmap binary and interpreting its
       output rather than by direct linking.  If you are interested in includ-
       ing Nmap	with your proprietary software or appliance, please contact us
       first to	ensure proper licensing.

       Source is provided to this software because we  believe	users  have  a
       right to	know exactly what a program is going to	do before they run it.
       This also allows	you to audit the software  for	security  holes	 (none
       have been found so far).

       Source  code  also  allows you to port Nmap to new platforms, fix bugs,
       and add new features.  You are highly encouraged	to send	 your  changes
       to fyodor@insecure.org for possible incorporation into the main distri-
       bution.	By sending these changes to Fyodor or one the Insecure.Org de-
       velopment mailing lists,	it is assumed that you are offering Fyodor and
       Insecure.Com LLC	the unlimited, non-exclusive right to  reuse,  modify,
       and relicense the code.	Nmap will always be available Open Source, but
       this is important because the inability to relicense  code  has	caused
       devastating  problems for other Free Software projects (such as KDE and
       NASM).  We also occasionally relicense the code	to  third  parties  as
       discussed  above.  If you wish to specify special license conditions of
       your contributions, just	say so when you	send them.

       This program is distributed in the hope that it	will  be  useful,  but
       WITHOUT	ANY  WARRANTY;	without	 even  the  implied  warranty  of MER-
       CHANTABILITY or FITNESS FOR A PARTICULAR	PURPOSE.  See the GNU  General
       Public  License for more	details	(it is in the COPYING file of the nmap
       distribution).

       It should also be noted that Nmap  has  been  known  to	crash  certain
       poorly written applications, TCP/IP stacks, and even operating systems.
       Nmap should never be run	against	mission	critical  systems  unless  you
       are  prepared  to  suffer  downtime.  We	acknowledge here that Nmap may
       crash your systems or networks and we disclaim all  liability  for  any
       damage or problems Nmap could cause.

       Because of the slight risk of crashes and because a few black hats like
       to use Nmap for reconnaissance prior to attacking  systems,  there  are
       administrators  who  become upset and may complain when their system is
       scanned.	 Thus, it is often advisable to	request	permission before  do-
       ing even	a light	scan of	a network.

       Nmap  should  never  be run with	privileges (eg suid root) for security
       reasons.

       This product includes software developed	by the Apache Software Founda-
       tion (http://www.apache.org/).  The Libpcap portable packet capture li-
       brary is	distributed along with nmap.   Libpcap	was  originally	 copy-
       righted	by  Van	 Jacobson,  Craig Leres	and Steven McCanne, all	of the
       Lawrence	Berkeley National Laboratory, University of California,	Berke-
       ley, CA.	 It is now maintained by http://www.tcpdump.org	.

       Regular	expression  support  is	 provided by the PCRE library package,
       which is	open source software, written by Philip	Hazel,	and  copyright
       by the University of Cambridge, England.	 See http://www.pcre.org/ .

       US  Export  Control: Insecure.Com LLC believes that Nmap	falls under US
       ECCN (export control classification number) 5D992.   This  category  is
       called  '"Information  Security"	 "software"  not controlled by 5D002'.
       The only	restriction of this  classification  is	 AT  (anti-terrorism),
       which  applies  to  almost  all goods and denies	export to a handful of
       rogue nations such as Iraq and North Korea.  Thus exporting  Nmap  does
       not  require  any special license, permit, or other governmental	autho-
       rization.

								       NMAP(1)

NAME | SYNOPSIS | DESCRIPTION | OPTIONS | EXAMPLES | BUGS | AUTHOR | DISTRIBUTION

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=nmap&manpath=FreeBSD+5.2-RELEASE+and+Ports>

home | help