Scan Folder Page
The scan page lets you select the scan method to use to the nmap scan. The following picture shows
a screenshot of the scan page:

The following methods are supported:
- Connect 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, other wise the port
isn't reachable. One strong advantage to this technique is that you don't need any spe cial
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 con nection just to have it immediately shutdown.
- SYN Stealth: 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 listening. A RST is
indicative of a non-lis tener. If a SYN|ACK is received, a RST is immedi ately sent to tear down
the connection (actually our OS kernel does this for us). The primary advan tage to this scanning
technique is that fewer sites will log it. Unfortunately you need root privi leges to build these
custom SYN packets.
- FIN Stealth, Xmas Tree, Null Scan: 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 Synlog ger 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 packets 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 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 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.
- Ping: 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.
- UDP Port Scan: This method is used to determine which UDP (User Datagram Protocol, RFC 768)
ports are open on a host. The technique 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.
Some people think UDP scanning is pointless. I usu ally remind them of the recent Solaris rcpbind hole.
Rpcbind can be found hiding on an undocu mented 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 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 message 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 sec ond) and thus takes even longer
to scan. nmap detects this rate limiting and slows down accord ingly, 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.
- IP protocol: 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 pro tocol 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.
- Idle Scan: This advanced scan method allows for a truly blind TCP
port scan of the target (meaning no packets are sent to the target from your real IP address). Instead, a
unique side-channel attack exploits predictable "IP fragmentation ID" sequence generation on the zombie
host to glean information about the open ports on the target. IDS systems will display the scan as coming
from the zombie machine you specify (which must be up and meet cer tain criteria). I am planning to put
a more detailed explanation up at http://www.inse cure.org/nmap/nmap_documentation.html in the near future.
Besides being extraordinarily stealthy (due to its blind nature), this scan type permits mapping out
IP-based trust relationships between machines. The port listing shows open ports from the perspective of
the zombie host. So you can try scanning a tar get using various zombies that you think might be trusted
(via router/packet filter rules). Obvi ously this is crucial information when prioritizing attack targets.
Otherwise, you penetration testers might have to expend considerable resources "own ing" an intermediate
system, only to find out that its IP isn't even trusted by the target host/net work you are ultimately
after a particular port on the zombie host for IPID changes. Otherwise Nmap will use the port it uses by
default for "tcp pings".
- ACK scan: This advanced method is usually used to map out firewall 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 acknowledgement/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 usu ally 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.
- Window scan: This advanced scan is very similar to the ACK scan, except that it can sometimes
detect open ports as well as filtered/nonfiltered due to an anomaly in 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.
- 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
effectively obtain the same info as 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.
- 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.
- FTP Bounce: 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 tar get.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 untraceable 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 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 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 nota tion. The
format is: username:pass word@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).
Copyright © JV Software