Seth Woolley's Man Viewer

nmap(1) - nmap, nmap - Network exploration tool and security scanner - man 1 nmap

([section] manual, -k keyword, -K [section] search, -f whatis)
man plain no title

NMAP(1)                                                                NMAP(1)

       nmap - Network exploration tool and security scanner

       nmap [Scan Type(s)] [Options] <host(1,5) or net #1 ... [#N]>

       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(2,3,n)), 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(3x,7,8,3x cbreak) 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(3,n) any).  Nmap always  gives  the  port's
       "well  known"  service name (if(3,n) any), number, state, and protocol.  The
       state is either "open(2,3,n)", "filtered", or "unfiltered".  Open  means  that
       the  target  machine  will accept(2,8)() connections on that port.  Filtered
       means that a firewall, filter(1,3x,3x curs_util), 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(1,3x,3x curs_util)  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(1,8) the filtered state.

       Depending  on  options used, nmap may also report the following charac-
       teristics of the remote host: OS in(1,8) use, TCP  sequentiality,  usernames
       running  the  programs  which  have  bound  to each port, the DNS name,
       whether the host(1,5) is a smurf address, and a few others.

       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.


       -sS    TCP SYN scan: This technique is often referred to as "half-open"
              scanning, because you don't open(2,3,n) a full TCP connection. You send(2,n)
              a SYN packet, as if(3,n) you are going to open(2,3,n) 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(2,3,n)  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(1,3) of scan is easily detectable as target host(1,5) logs will
              show a bunch of connection and error(8,n) messages for  the  services
              which  accept(2,8)() 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(2,3,n) ports must ignore the pack-
              ets in(1,8) question (see RFC 793 pp 64).  Filered ports also tend to
              drop  probes  without  a  response,  so  Nmap  considers   ports
              "open(2,3,n)|filtered"  when  it  fails to elicit any response.  If you
              add version(1,3,5) detection (-sV), it will try to verify(1,8)  whether  the
              ports  are  actually  open(2,3,n)  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(2,3,n) 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(1,3) useful now that nmap  has  proper  OS
              detection built in.  There are also a few other systems that are
              broken in(1,8) the same way Windows is.  They  include  Cisco,  BSDI,
              HP/UX,  MVS,  and  IRIX.   All of the above send(2,n) resets from the
              open(2,3,n) 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(1,3x,1 builtins) request
              packets to every IP address on the networks you specify.   Hosts
              that   respond  are  up.   Unfortunately,  some  sites  such  as
     block echo(1,3x,1 builtins) request packets.  Thus  nmap  can  also
              send(2,n) 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(1,5), a connect() method is used.

              By default (for root users(1,5)), nmap uses both  the  ICMP  and  ACK
              techniques  in(1,8) parallel.  You can change the -P option described

              Note that pinging is done by default anyway, and only hosts that
              respond  are  scanned.  Only use this option if(3,n) 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(1,3,5) detection communi-
              cates with those ports to try and determine more about  what  is
              actually  running.  A file(1,n) 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(1,3,5) num-
              ber, and sometimes  miscellaneous  details  like  whether  an  X
              server  is open(2,3,n) to connections or the SSH protocol version(1,3,5)).  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(1,3,5) numbers.  Some UDP
              ports are left in(1,8) the "open(2,3,n)|filtered" state after a UDP scan  is
              unable  to determine whether the port is open(2,3,n) or filtered.  Ver-
              sion detection will try to elicit a response  from  these  ports
              (just  as it does with open(2,3,n) ports), and change the state to open(2,3,n)
              if(3,n) it succeeds. Note that the Nmap -A option also  enables  this
              feature.   For  a much more detailed description of Nmap service
              detection, read(2,n,1 builtins) our paper  at
              sionscan.html .  There is a related --version_trace option which
              causes Nmap to print out extensive  debugging  info(1,5,n)  about  what
              version(1,3,5)  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(2,3,n) on a host.  The tech-
              nique is to send(2,n) 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(2,3,n)|filtered", meaning that the port is  either  open(2,3,n)
              or packet filters are blocking the communication.  Versions scan
              (-sV) can be used to help differentiate  the  truly  open(2,3,n)  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(2,3)  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(1,8) RFC 1812 (section
              of limiting the ICMP error(8,n) message rate.  For example, the Linux
              kernel (in(1,8) net/ipv4/icmp.h) limits destination unreachable  mes-
              sage  generation  to 80 per 4 seconds, with a 1/4 second penalty
              if(3,n) 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(2,n) raw(3x,7,8,3x cbreak)
              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(1,8) use.  Otherwise
              we assume it is open.  Note that some hosts (AIX, HP-UX, Digital
              UNIX)  and firewalls may not send(2,n) protocol unreachable messages.
              This causes all of the protocols to appear "open(2,3,n)".

              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(1,8) reasonable time(1,2,n) anyway.

       -sI <zombie host(1,5)[: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(1,5) to glean information about the open(2,3,n)
              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 .

              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(2,3,n) 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(1,3x,3x curs_util)  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(1,5)/network  you  are
              ultimately after.

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

       -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(1,3x,3x curs_util) that  blocks
              incoming SYN packets.

              This scan type sends an ACK packet (with random(3,4,6) 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(3,n) 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(1,8) the  output  is
              usually  a  sign  that  all the probes got through (and returned
              RSTs). This scan will obviously never show ports in(1,8)  the  "open(2,3,n)"

       -sW    Window scan: This advanced scan is very similar to the ACK scan,
              except that it can sometimes detect open(2,3,n) ports as well  as  fil-
              tered/unfiltered  due  to  an  anomaly  in(1,8)  the  TCP window size
              reporting 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(1,8) combination with the various
              port scan methods of Nmap.  It takes all the TCP/UDP ports found
              open(2,3,n)  and  then floods them with SunRPC program NULL commands in(1,8)
              an attempt to determine whether they are RPC ports, and  if(3,n)  so,
              what  program  and  version(1,3,5)  number they serve up.  Thus you can
              effectively obtain the same info(1,5,n) as "rpcinfo  -p"  even  if(3,n)  the
              target's  portmapper  is  behind a firewall (or protected by TCP
              wrappers).  Decoys do not currently work with RPC scan, at  some
              point  I may add decoy support for UDP RPC scans.  This is auto-
              matically enabled as part of version(1,3,5) scan (-sV) if(3,n)  you  request

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

       -b <ftp relay host(1,5)>
              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  to  the  FTP
              server  of  and  request that the server send(2,n) a file(1,n)
              ANYWHERE on the Internet!  Now this may have worked well in(1,8) 1985
              when the RFC was written. But in(1,8) 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(1,8) 1995, this protocol flaw  "can  be  used  to  post  virtually
              untraceable  mail(1,8)  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
              behind 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(2,n) arbitrary data to ports that you do find open(2,3,n) (nmap doesn't
              do this for you though).

              The argument passed to the "b" option is the host(1,5)  you  want  to
              use  as a proxy, in(1,8) 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(1,8) Phrack 51.  An updated version(1,3,5) is available at
              the nmap URL (

              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 to ping hosts at  all  before  scanning  them.   This
              allows  the  scanning  of  networks  that  don't allow ICMP echo(1,3x,1 builtins)
              requests (or responses) through their  firewall.
              is  an example of such a network, and thus you should always use
              -P0 or -PS80 when portscanning  Note that  "ping"
              in(1,8)  this context may involve more than the traditional ICMP echo(1,3x,1 builtins)
              request packet.  Nmap supports many such probes, including arbi-
              trary  combinations  of  TCP, UDP, and ICMP probes.  By default,
              Nmap sends an ICMP echo(1,3x,1 builtins) request and a TCP ACK packet to port 80.

       -PA [portlist]
              Use  TCP  ACK "ping" to determine what hosts are up.  Instead of
              sending ICMP echo(1,3x,1 builtins) 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 UNIX users(1,5), we use connect() and thus  a  SYN
              is  actually  being  sent.   To set(7,n,1 builtins) the destination ports of the
              probe packets use -PA<port1>[,port2][...].  The default port  is
              80,  since  this port is often not filtered out.  Note that this
              option now accepts multiple, comma-separated 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(7,n,1 builtins) the destination  ports
              in(1,8) the same manner as -PA above.

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

       -PE    This  option  uses  a  true ping (ICMP echo(1,3x,1 builtins) 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(3,n) found as they allow for numerous denial of service
              attacks (Smurf is the most common).

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

       -PM    Same as -PE and -PP except uses a  netmask  request  (ICMP  type

       -PB    This is the default ping type.  It uses both the ACK ( -PA ) and
              ICMP echo(1,3x,1 builtins) request ( -PE ) sweeps in(1,8) parallel.  This way you  can
              get  firewalls  that  filter(1,3x,3x curs_util) either one (but not both).  The TCP
              probe destination port can be set(7,n,1 builtins) in(1,8) the same manner as with -PA
              above.   Note that this flag is now deprecated as pingtype flags
              can now be used in(1,8) combination.  So you should use both "PE" and
              "PA"  (or  rely  on  the  default behavior) to achieve this same

       -O     This option activates remote host(1,5) identification via TCP/IP fin-
              gerprinting.   In  other words, it uses a bunch of techniques to
              detect subtleties in(1,8) 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(1,n)) 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(2,3,n) port), Nmap will provide a URL
              you can use to submit the fingerprint if(3,n) 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(3,n) 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
              "Uptime" 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
              remote  host.   This  is  useful  for exploiting source-IP based
              trust relationships (rlogin, firewall filters, etc) or for  hid-
              ing  the  source  of an attack.  The actual difficulty number is
              based on statistical sampling and may fluctuate.  It  is  gener-
              ally  better  to  use the English classification such as "worthy
              challenge" or "trivial joke".  This is only reported  in(1,8)  normal
              output with -v.

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

              OS  detection is far more effective if(3,n) at least one open(2,3,n) and one
              closed TCP port are found.  Set this option and  Nmap  will  not
              even try OS detection against hosts that do not meet this crite-
              ria.  This can save substantial time(1,2,n), particularly on -P0  scans
              against  many  hosts.   It  only  matters  when  OS detection is
              requested (-O or -A options).

       -A     This option enables  _a_dditional  _a_dvanced  and  _a_ggressive
              options.   I haven't decided exactly which it stands for yet :).
              Presently this enables OS Detection (-O)  and  version(1,3,5)  scanning
              (-sV).   More features may be added in(1,8) the future.  The point is
              to enable a comprehensive set(7,n,1 builtins) of  scan  options  without  people
              having  to  remember  a  large  set(7,n,1 builtins)  of flags.  This option only
              enables 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(3,n)
              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(1,8,3 Search::Dict)  at  http://nmap6.source-

       -f     This  option causes the requested scan (including ping scans) to
              use tiny fragmented IP packets.  The idea is to split(1,n) up the TCP
              header  over  several  packets to make it harder for packet fil-
              ters, intrusion  detection  systems,  and  other  annoyances  to
              detect  what  you are doing. Be careful with this! Some programs
              have trouble handling these tiny packets. The old-school sniffer
              named(5,8)  Sniffit  segmentation  faulted immediately upon receiving
              the first fragment.  Specify this option once, and  Nmap  splits
              the  packets  into  8  bytes  or less(1,3) after the IP header.  So a
              20-byte TCP header would be split(1,n) into 3 packets.
               Two with eight bytes of the TCP header, and one with the  final
              four.   Of  course each fragment also has an IP header.  Specify
              -f again to use 16 bytes per fragment (reducing  the  number  of
              fragments).   Or  you  can specify your own offset size with the
              --mtu option.  Don't also specify -f if(3,n) you use --mtu.  The off-
              set(7,n,1 builtins) must be a multiple of 8.  While fragmented packets won't get
              by packet filters and firewalls that  queue(1,3)  all  IP  fragments,
              such  as the CONFIG_IP_ALWAYS_DEFRAG option in(1,8) the Linux kernel,
              some networks can't afford the performance hit this  causes  and
              thus leave it disabled.  Some source systems defragment outgoing
              packets in(1,8) the kernel.  Linux  with  the  ip(7,8)  tables  connection
              tracking  module  is one such example.  Do a scan with a sniffer
              such as ethereal running to ensure that sent packets  are  frag-

              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(3,n)
              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(1,5,7) page is not exactly
              a "quick reference" :)

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

       -oX <logfilename>
              This  logs  the  results of your scans in(1,8) XML form into the file(1,n)
              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(8,n) messages if(3,n) 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-

       --stylesheet <filename>
              Nmap ships with an XSL stylesheet named(5,8) nmap.xsl for viewing  or
              translating XML output to HTML.  The XML output includes an xml-
              stylesheet directive which points to nmap.xml where it was  ini-
              tially installed by Nmap (or in(1,8) the current working directory on
              Windows).  Simply load(7,n) Nmap's XML output in(1,8) a modern web browser
              and  it  should retrieve nmap.xsl from the filesystem and use it
              to render results.  If you wish to use a  different  stylesheet,
              specify  it  as the argument to --stylesheet.  You must pass the
              full pathname or URL.  One  common  invocation  is  --stylesheet
       .    This  tells  a
              browser to load(7,n) the latest version(1,3,5) of the stylesheet from  Inse-
              cure.Org.   This  makes  it  easier to view results on a machine
              that doesn't have Nmap (and thus nmap.xsl)  installed.   So  the
              URL  is  often  more useful, but the local filesystem locaton of
              nmap.xsl is used by default for privacy reasons.

              Specify this option to prevent Nmap  from  associating  any  XSL
              stylesheet with its XML output.  The xml-stylesheet directive is

       -oG <logfilename>
              This logs the results of your scans in(1,8) a grepable form into  the
              file(1,n)  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(8,n) messages if(3,n) 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(1,8)  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(1,8) the log file.

       --exclude <host1 [,host2][,host3],...">
              Specifies a list of  targets  (hosts,  ranges,  netblocks)  that
              should  be  excluded  from  a scan. Useful to keep from scanning
              yourself, your ISP, particularly sensitive hosts, etc.

       --excludefile <exclude_file>
              Same functionality as the --exclude option,  only  the  excluded
              targets are provided in(1,8) an newline-delimited exclude_file rather
              than on the command line.

              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(1,n) specified RATHER than
              from the command line.  The file(1,n) should contain a list  of  host(1,5)
              or  network  expressions separated by spaces, tabs, or newlines.
              Use a hyphen (-) as inputfilename if(3,n) you want nmap to read(2,n,1 builtins)  host(1,5)
              expressions  from  stdin  (like  at the end of a pipe(2,8)).  See the
              section target specification for more information on the expres-
              sions you fill the file(1,n) with.

       -iR <num hosts>
              This option tells Nmap to generate its own hosts to scan by sim-
              ply picking random(3,4,6) 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(1,8,3 Search::Dict) 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(1,5)(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(1,8) the services
              file(1,n) 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(1,8)  the
              services  file(1,n)  which comes with nmap (or the protocols file(1,n) 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(1,5) that the host(1,5)(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(1,5) 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(1,8) the 6th position
              or  later,  some  common  port  scan  detectors  (such  as Solar
              Designer's excellent scanlogd) are  unlikely  to  show  your  IP
              address  at  all.  If you don't use "ME", nmap will put you in(1,8) a
              random(3,4,6) 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(1,5) is scanning if(3,n) 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(1,8)  their  name-
              server logs).

              Also  note  that  some  "port scan detectors" will firewall/deny
              routing to hosts that attempt port scans.  The problem  is  that
              many scan types can be forged (as this option demonstrates).  So
              attackers can cause such a machine to  sever  connectivity  with
              important  hosts  such as its internet gateway, DNS TLD servers,
              sites like Windows  Update,  etc.   Most  such  software  offers
              whitelist capabilities, but you are unlikely to enumerate all of
              the critical machines.  For this reason we never recommend  tak-
              ing  action against port scans that can be forged, including SYN
              scans, UDP scans, etc.  The machine you block could  just  be  a

              Decoys  are used both in(1,8) 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(1,3)  accurate.   Also,  some  ISPs
              will  filter(1,3x,3x curs_util)  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(3,n) this is the case).  In
              this situation, use -S with your IP address  (of  the  interface
              you wish to send(2,n) 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(1,3) of

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

       --source_port <portnumber>
              Sets the source port number used in(1,8) scans.  Many naive  firewall
              and packet filter(1,3x,3x curs_util) installations make an exception in(1,8) their rule-
              set(7,n,1 builtins) 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(3,n) 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(3,n) you used this
              option.   This is an alias for the shorter, but harder to remem-
              ber, -g option.

              Be aware that there is a small performance penalty on some scans
              for using this option, because I sometimes store useful informa-
              tion in(1,8) 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(1,3x,1 builtins)
              requests are just 28.  This option  tells  Nmap  to  append  the
              given  number  of  random(3,4,6) 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(1,3) 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(1,8)  which  ports  are

       --ttl <value>
              Sets  the  IPv4  time(1,2,n) to live field in(1,8) sent packets to the given

              Tells Nmap to shuffle each group of up to 2048 hosts  before  it
              scans  them.   This  can  make the scans less(1,3) 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(1,8) 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.

              Tells  Nmap  to  show all the packets it sends and receives in(1,8) 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(1,8) files named(5,8) nmap-
              service-probes, nmap-services, nmap-protocols,  nmap-rpc,  nmap-
              mac-prefixes,  and  nmap-os-fingerprints.   Nmap  first searches
              these files in(1,8) the directory option to --datadir.  Any files not
              found  there, are searched for in(1,8) the directory specified by the
              NMAPDIR environmental variable.  Next comes ~/.nmap for real and
              effective UIDs (POSIX systems only) or location of the Nmap exe-
              cutable (Win32 only), and then a compiled-in  location  such  as
              /usr/local/share/nmap  or  /usr/share/nmap  .  As a last resort,
              Nmap will look(1,8,3 Search::Dict) in(1,8) the current directory.

              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(1,8) 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(7,n)  on  the  network  and reduce the chances of crashing
              machines.  It serializes the probes and waits at least 0.4  sec-
              onds  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 net-
              work  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(1,8) 15 minutes and won't wait more than 0.3  sec-
              onds  for  individual probes.  It does allow for very quick net-
              work sweeps though :).

              You can also reference these  by  number  (0-5).   For  example,
              "-T0"  gives you Paranoid mode and "-T5" is Insane mode.  If you
              wish to set(7,n,1 builtins) specific timing values such as --max_rtt_timeout  or
              --host_timeout,  place  them  after any -T option on the command
              line.  Otherwise the defaults for the selected timing mode  will
              override your choices.

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

       --max_rtt_timeout <milliseconds>
              Specifies the maximum amount of time(1,2,n) 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(1,2,n)  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(1,2,n) 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_hostgroup <numhosts>
              Specifies  the  maximum  number of hosts that Nmap is allowed to
              scan in(1,8) parallel.  Most of  the  port  scan  techniques  support
              multi-host  operation, which makes them much quicker.  Spreading
              the load(7,n) among multiple target hosts makes  the  scans  gentler.
              The downside is increased results latency.  You need to wait for
              all hosts in(1,8) a group to finish, rather than having them  pop  up
              one  by one.  Specify an argument of one for old-style (one host(1,5)
              at a time(1,2,n)) Nmap behavior.  Note that the  ping  scanner  handles
              its own grouping, and ignores this value.

       --min_hostgroup <numhosts>
              Specifies  the  minimum  host(1,5)  group  size (see previous entry).
              Large values (such as 50) are often  beneficial  for  unattended
              scans,  though  they  do take up more memory.  Nmap may override
              this preference when it needs to, because a group must  all  use
              the  same network interface, and some scan types can only handle
              one host(1,5) at a time.

       --max_parallelism <number>
              Specifies the maximum number of scans Nmap is allowed to perform
              in(1,8)  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(1,8) paral-
              lel.  This can speed up scans against certain  firewalled  hosts
              by an order of magnitude.  But be careful -- results will become
              unreliable if(3,n) you push it too far.

       --scan_delay <milliseconds>
              Specifies the minimum amount of  time(1,2,n)  Nmap  must  wait  between
              probes.  This is mostly useful to reduce network load(7,n) or to slow
              the scan way down to sneak  under  IDS  thresholds.   Nmap  will
              sometimes increase the delay itself when it detects many dropped
              packets.  For example, Solaris systems tend to respond with only
              one  ICMP  port unreachable packet per second during a UDP scan.
              So Nmap will try to detect this and lower its rate of UDP probes
              to one per second.

       --max_scan_delay <milliseconds>
              As  noted  above,  Nmap  will  sometimes enforce a special delay
              between sending packets.  This can provide more accurate results
              while  reducing  network  congestion,  but it can slow the scans
              down substantially.  By default (with no -T options  specified),
              Nmap  allows  this  delay to grow to one second per probe.  This
              option allows you to set(7,n,1 builtins) a lower or higher maximum.  Even if(3,n) you
              set(7,n,1 builtins)  it  to zero, Nmap will have some delay between packet sends
              so that it can wait for responses and avoid having too many out-
              standing probes in(1,8) parallel.

       Everything that isn't an option (or option argument) in(1,8) nmap is treated
       as a target host(1,5) 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(1,5) specified).  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: "".  These are
       all equivalent.  If you use asterisks ("*"), remember that most  shells
       require  you  to  escape  them  with  back slashes or protect them with

       Another interesting thing to do is slice the Internet  the  other  way.
       Instead  of  scanning all the hosts in(1,8) a class "B", scan "*.*.5.6-7" to
       scan every IP address that ends in(1,8) .5.6 or .5.7 Pick your own  numbers.
       For more information on specifying hosts to scan, see the examples sec-

       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

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

       nmap -sS -O

       Launches  a stealth SYN scan against each machine that is up out of the
       255 machines on class "C" where  resides.   It  also
       tries  to  determine what operating system is running on each host(1,5) 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(1,8) the 198.116 class "B" address  space.   We  are  testing
       whether  the  systems  run sshd, DNS, pop3d(1,8), imapd(5,8), 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
       addresses ending in(1,8) .2.3, .2.4, or .2.5.  If you are root you might  as
       well add -sS.  Also you will 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 interesting machines

       host(1,5) -l | cut  -d  -f 4 | ./nmap -v -iL -

       Do a DNS zone transfer to find the hosts in(1,8) 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?  What bugs?  Send me any that you find.  Patches are nice(1,2) too  :)
       Remember  to  also send(2,n) in(1,8) new OS fingerprints so we can grow the data-
       base.  Nmap will give you a submission URL when an appropriate  finger-
       print is found.

       Fyodor <>

       The  newest  version(1,3,5)  of  nmap  can  be  obtained from http://www.inse-

       The Nmap Security Scanner is (C) 1996-2004 Insecure.Com  LLC.  Nmap  is
       also  a registered trademark of Insecure.Com LLC.  This program is free
       software; you may redistribute and/or modify it under the terms of  the
       GNU  General  Public  License as published by the Free Software Founda-
       tion; Version 2.  This guarantees your right to use, modify, and redis-
       tribute  this  software under certain conditions.  If you wish to embed
       Nmap technology into proprietary software, we may be  willing  to  sell
       alternative licenses (contact  Many security scan-
       ner vendors already license Nmap technology such as our remote OS  fin-
       gerprinting  database  and  code, service/version(1,3,5) detection system, and
       port scanning code.

       Note that the GPL places important restrictions on "derived works", yet
       it  does not provide a detailed definition of that term.  To avoid mis-
       understandings, we consider an application to constitute a  "derivative
       work" for the purpose of this license if(3,n) it does any of the following:

       o Integrates source code from Nmap

       o  Reads  or includes Nmap copyrighted data files, such as nmap-os-fin-
       gerprints or nmap-service-probes.

       o Executes Nmap and parses the results (as opposed to typical shell  or
       execution-menu  apps,  which  simply display raw(3x,7,8,3x cbreak) Nmap output and so are
       not derivative works.)

       o Integrates/includes/aggregates Nmap  into  a  proprietary  executable
       installer, such as those produced by InstallShield.

       o Links to a library or executes a program that does any of the above

       The term(5,7) "Nmap" should be taken to also include any portions or derived
       works of Nmap.  This list is not exclusive, but is just meant to  clar-
       ify  our  interpretation  of  derived  works with some common examples.
       These restrictions only apply when you actually redistribute Nmap.  For
       example,  nothing  stops  you  from  writing  and selling a proprietary
       front-end to Nmap.  Just distribute it by itself, and point  people  to to download Nmap.

       We don't consider these to be added restrictions on top of the GPL, but
       just a clarification of how we interpret "derived works" as it  applies
       to  our  GPL-licensed  Nmap  product.  This is similar to the way Linus
       Torvalds has  announced  his  interpretation  of  how  "derived  works"
       applies  to  Linux  kernel  modules.  Our interpretation refers only to
       Nmap - we don't speak for any other GPL products.

       If you have any questions about the GPL licensing restrictions on using
       Nmap  in(1,8) non-GPL works, we would be happy to help.  As mentioned above,
       we also offer alternative license to integrate  Nmap  into  proprietary
       applications  and  appliances.   These contracts have been sold to many
       security vendors, and generally include a perpetual license as well  as
       providing  for  priority support and updates as well as helping to fund
       the continued development of Nmap technology.  Please email sales@inse- for further information.

       As  a  special exception to the GPL terms, Insecure.Com LLC grants per-
       mission to link(1,2) the code of  this  program  with  any  version(1,3,5)  of  the
       OpenSSL  library which is distributed under a license identical to that
       listed in(1,8) the included Copying.OpenSSL file(1,n), and distribute linked com-
       binations  including the two. You must obey the GNU GPL in(1,8) all respects
       for all of the code used other than OpenSSL.  If you modify this  file(1,n),
       you  may extend this exception to your version(1,3,5) of the file(1,n), but you are
       not obligated to do so.

       If you received these files with a written license  agreement  or  con-
       tract  stating  terms other than the terms above, then that alternative
       license agreement takes precedence over these comments.

       Source is provided to this software because we  believe  users(1,5)  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(2,n)  your  changes
       to for possible incorporation into the main distri-
       bution.  By sending these changes to Fyodor  or  one  the  Insecure.Org
       development  mailing  lists, it is assumed that you are offering Fyodor
       and Insecure.Com LLC the unlimited, non-exclusive right to reuse,  mod-
       ify,  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(2,n) them.

       This program is distributed in(1,8) the hope that it  will  be  useful,  but
       WITHOUT  ANY  WARRANTY;  without  even  the  implied  warranty  of MER-
       Public License for more details at
       , or in(1,8) the COPYING file(1,n) included with Nmap.

       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
       doing even a light scan of a network.

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

       This product includes software developed by the Apache Software Founda-
       tion  (   The  Libpcap  portable packet capture
       library 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 .

       Regular  expression  support  is  provided by the PCRE library package,
       which is open(2,3,n) source software, written by Philip Hazel,  and  copyright
       by the University of Cambridge, England.  See .

       Nmap  can optionally link(1,2) to the OpenSSL cryptography toolkit, which is
       available from .

       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 Iran and North Korea.  Thus exporting Nmap does
       not require any special license, permit, or other  governmental  autho-


References for this manual (incoming links)