nmap man page

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

nmap is a powerful command line driven network scanner for linux although it has been ported to other operating systems

Hope this helps you budding network security folk who dont know how to read man pages ;)

Code:

NMAP(1)															 NMAP(1)

NAME
	   nmap - Network exploration tool and security scanner

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

DESCRIPTION
	   Nmap is designed to allow system administrators and curious individuals
	   to scan large networks to determine which hosts are up  and  what  ser-
	   vices  they  are  offering.   nmap  supports a large number of scanning
	   techniques such as: UDP, TCP connect(), TCP SYN (half open), ftp  proxy
	   (bounce  attack),  ICMP  (ping  sweep),  FIN, ACK sweep, Xmas Tree, SYN
	   sweep, IP Protocol, and Null scan.  See the Scan Types section for more
	   details.  nmap also offers a number of advanced features such as remote
	   OS detection via TCP/IP fingerprinting, stealth scanning, dynamic delay
	   and  retransmission  calculations, parallel scanning, detection of down
	   hosts via parallel pings, decoy  scanning,  port  filtering  detection,
	   direct (non-portmapper) RPC scanning, fragmentation scanning, and flex-
	   ible target and port specification.

	   Significant effort has been put into decent nmap performance  for  non-
	   root  users.   Unfortunately,  many critical kernel interfaces (such as
	   raw sockets) require root privileges.  nmap should be run as root when-
	   ever possible (not setuid root, of course).

	   The  result  of  running nmap is usually a list of interesting ports on
	   the machine(s) being scanned (if any).  Nmap always  gives  the  portâs
	   "well  known"  service name (if any), number, state, and protocol.  The
	   state is either "open", "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
 options  are  specific  to certain scan modes.  nmap tries to catch and
	   warn the user about psychotic or unsupported option combinations.

	   If you are impatient, you can skip to the examples section at the  end,
	   which  demonstrates common usage.  You can also run nmap -h for a quick
	   reference page listing all the options.

	   SCAN TYPES

	   -sS	TCP SYN scan: This technique is often referred to as "half-open"
			 scanning, because you donât open a full TCP connection. You send
			 a SYN packet, as if you are going to open a real connection and
			 you wait for a response. A SYN|ACK indicates the port is listen-
			 ing. A RST is indicative of a non-listener. If a SYN|ACK is
			 received, a RST is immediately sent to tear down the connection
			 (actually our OS kernel does this for us). The primary advantage
			 to this scanning technique is that fewer sites will log it.
			 Unfortunately you need root privileges to build these custom SYN
			 packets. This is the default scan type for privileged users.

	   -sT	TCP connect() scan: This is the most basic form of TCP scanning.
			 The connect() system call provided by your operating system is
			 used to open a connection to every interesting port on the
			 machine. If the port is listening, connect() will succeed, oth-
			 erwise the port isnât reachable. One strong advantage to this
			 technique is that you donât need any special privileges. Any
			  user on most UNIX boxes is free to use this call.

			 This sort of scan is easily detectable as target host logs will
			 show a bunch of connection and error messages for the services
			 which accept() the connection just to have it immediately shut-
			 down. This is the default scan type for unprivileged users.

	   -sF -sX -sN
			 Stealth FIN, Xmas Tree, or Null scan modes: There are times when
			 even SYN scanning isnât clandestine enough. Some firewalls and
			 packet filters watch for SYNs to restricted ports, and programs
			 like Synlogger and Courtney are available to detect these scans.
			 These advanced scans, on the other hand, may be able to pass
			  through unmolested.

			 The idea is that closed ports are required to reply to your
			 probe packet with an RST, while open ports must ignore the pack-
			 ets in question (see RFC 793 pp 64). 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
			 microsoft.com block echo request packets. Thus nmap can also
			 send a TCP ack packet to (by default) port 80. If we get an RST
			 back, that machine is up. A third technique involves sending a
			 SYN packet and waiting for a RST or a SYN/ACK. For non-root
			  users, a connect() method is used.

			 By default (for root users), nmap uses both the ICMP and ACK
			 techniques in parallel. You can change 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
			 using one of the other scan methods, version detection communi-
			 cates with those ports to try and determine more about what is
			 actually running. A file called nmap-service-probes is used to
			 determine the best probes for detecting various services and the
			 match strings to expect. Nmap tries to determine the service
			 protocol (e.g. ftp, ssh, telnet, http), the application name
			 (e.g. ISC Bind, Apache httpd, Solaris telnetd), the version num-
			 ber, and sometimes miscellaneous details like whether an X
			 server is open to connections or the SSH protocol version). If
			 Nmap was compiled with OpenSSL support, it will connect to SSL
			 servers to deduce the service listening behind the encryption.
			 When RPC services are discovered, the Nmap RPC grinder is used
			 to determine the RPC program and version numbers. Some UDP
			 ports are left in the "open|filtered" state after a UDP scan is
			 unable to determine whether the port is open or filtered. Ver-
			 sion detection will try to elicit a response from these ports
			 (just as it does with open ports), and change the state to open
			 if it succeeds. Note that the Nmap -A option also enables this
			 feature. For a much more detailed description of Nmap service
			  detection, read our paper  at  [url="http://www.insecure.org/nmap/ver-"]http://www.insecure.org/nmap/ver-[/url]
			 sionscan.html . There is a related --version_trace option which
			 causes Nmap to print out extensive debugging info about what
			 version scanning is doing (this is a subset of what you would
			  get with --packet_trace).

	   -sU	UDP scans: This method is used  to  determine  which  UDP  (User
			 Datagram Protocol, RFC 768) ports are open on a host. The tech-
			 nique is to send 0 byte UDP packets to each port on the target
			 machine. If we receive an ICMP port unreachable message, then
			 the port is closed. If a UDP response is received to the probe
			 (unusual), the port is open. If we get no response at all, the
			 state is "open|filtered", meaning that the port is either open
			 or packet filters are blocking the communication. Versions scan
			 (-sV) can be used to help differentiate the truly open ports
			  from the filtered ones.
			 Some people think UDP scanning is pointless. I usually remind
			 them of the Solaris rpcbind hole. Rpcbind can be found hiding on
			 an undocumented UDP port somewhere above 32770. So it doesnât
			 matter that 111 is blocked by the firewall. But can you find
			 which of the more than 30,000 high ports it is listening on?
			 With a UDP scanner you can! There is also the cDc Back Orifice
			 backdoor program which hides on a configurable UDP port on Win-
			 dows machines. Not to mention the many commonly vulnerable ser-
			  vices that utilize UDP such as snmp, tftp, NFS, etc.

			 Unfortunately UDP scanning is sometimes painfully slow since
			 most hosts implement a suggestion in RFC 1812 (section 4.3.2.8)
			 of limiting the ICMP error message rate. For example, the Linux
			 kernel (in net/ipv4/icmp.h) limits destination unreachable mes-
			 sage generation to 80 per 4 seconds, with a 1/4 second penalty
			 if that is exceeded. Solaris has much more strict limits (about
			 2 messages per second) and thus takes even longer to scan. nmap
			 detects this rate limiting and slows down accordingly, rather
			 than flood the network with useless packets that will be ignored
			  by the target machine.

			 As is typical, Microsoft ignored the suggestion of the RFC and
			 does not seem to do any rate limiting at all on Win95 and NT
			 machines. Thus we can scan all 65K ports of a Windows machine
			  very quickly.  Whoop!

	   -s

 

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Thanks for that mate.