Last login: Sun Nov 24 03:10:44 on ttyp1
Welcome to Darwin!
[Uisce:~] mcarroll% ssh red.ils.unc.edu
mcarroll@red.ils.unc.edu's password:
Last login: Sat Nov 23 17:36:24 2002 from rdu57-242-138.nc.rr.com
[mcarroll@red mcarroll]$ nmap -sF 66.57.242.138
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
You requested a scan type which requires r00t privileges, and you do not have them.
QUITTING!
[mcarroll@red mcarroll]$ sudo nmap -sF 66.57.242.138
Password:
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Note: Host seems down. If it is really up, but blocking our ping probes, try -P0
Nmap run completed -- 1 IP address (0 hosts up) scanned in 30 seconds
[mcarroll@red mcarroll]$ sudo nmap -sP 66.57.242.138
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Note: Host seems down. If it is really up, but blocking our ping probes, try -P0
Nmap run completed -- 1 IP address (0 hosts up) scanned in 30 seconds
[mcarroll@red mcarroll]$ nmap -sF 66.57.242.132
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
You requested a scan type which requires r00t privileges, and you do not have them.
QUITTING!
[mcarroll@red mcarroll]$ sudo nmap -sF 66.57.242.132
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Interesting ports on rdu57-242-132.nc.rr.com (66.57.242.132):
(The 1596 ports scanned but not shown below are in state: closed)
Port State Service
69/tcp filtered tftp
137/tcp open netbios-ns
138/tcp open netbios-dgm
139/tcp open netbios-ssn
445/tcp open microsoft-ds
Nmap run completed -- 1 IP address (1 host up) scanned in 16 seconds
[mcarroll@red mcarroll]$ echo this is a neighbor!man nmap
echo this is a neighborman nmap nmap
this is a neighborman nmap nmap
[mcarroll@red mcarroll]$ man nmap
NMAP(1) NMAP(1)
NAME
nmap - Network exploration tool and security scanner
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 services 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 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 retransmis-
sion calculations, parallel scanning, detection of down hosts via parallel
pings, decoy scanning, port filtering detection, direct (non-portmapper)
RPC scanning, fragmentation scanning, and flexible target and port specifi-
cation.
Significant effort has been put into decent nmap performance for non-root
users. Unfortunately, many critical kernel interfaces (such as raw sock-
ets) require root privileges. nmap should be run as root whenever 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 pre-
venting 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 determine 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 characteris-
tics of the remote host: OS in use, TCP sequencability, 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 ref-
erence 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 listening. 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, otherwise 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 shutdown. 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 unmo-
lested.
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. Unfortu-
nately Microsoft (like usual) decided to completely ignore the stan-
dard and do things their own way. Thus this scan type will not work
against systems running Windows95/NT. On the positive side, this is
a good way to distinguish between the two platforms. If the scan
finds open ports, you know the machine is not a Windows box. If a
-sF,-sX,or -sN scan shows all ports closed, yet a SYN (-sS) scan
shows ports being opened, you are probably looking at a Windows box.
This is less useful now that nmap has proper OS detection built in.
There are also a few other systems that are broken in the same way
Windows is. They include Cisco, BSDI, HP/UX, MVS, and IRIX. All of
the above send resets from the open ports when they should just drop
the packet.
-sP Ping scanning: Sometimes you only want to know which hosts on a net-
work 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 tech-
niques 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.
-sU UDP scans: 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 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 Orifice backdoor program which
hides on a configurable UDP port on Windows machines. Not to men-
tion 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 limit-
ing 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 second)
and thus takes even longer to scan. nmap detects this rate limiting
and slows down accordingly, rather than flood the network with use-
less 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.
Woop!
-sO IP protocol scans: This method is used to determine which IP proto-
cols are supported on a host. The technique is to send raw IP pack-
ets 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 scan-
ning, 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 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 certain criteria). I
am planning to put a more detailed explanation up at
http://www.insecure.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 per-
spective of the zombie host. So you can try scanning a target using
various zombies that you think might be trusted (via router/packet
filter rules). Obviously this is crucial information when priori-
tizing attack targets. Otherwise, you penetration testers might
have to expend considerable resources "owning" an intermediate sys-
tem, only to find out that its IP isn't even trusted by the target
host/network you are ultimately 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 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 acknowledge-
ment/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 "fil-
tered". 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/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.
-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 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.
-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 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 notation. 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).
GENERAL OPTIONS
None of these are required but some can be quite useful.
-P0 Do not try and ping hosts at all before scanning them. This allows
the scanning of networks that don't allow ICMP echo requests (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.
-PT Use TCP "ping" to determine what hosts are up. Instead of sending
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 preserves the effi-
ciency of only scanning hosts that are up while still allowing you
to scan networks/hosts that block ping packets. For non root users,
we use connect(). To set the destination port of the probe packets
use -PT<port number>. The default port is 80, since this port is
often not filtered out.
-PS 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 port in the
same manner as -PT above.
-PI 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 exter-
nally reachable and translate to a broadcast of incomming 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 listening
hosts.
-PM Same as -PI 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 ( -PI ) sweeps in parallel. This way you can get
firewalls that filter either one (but not both). The TCP probe des-
tination port can be set in the same manner as with -PT above.
-O This option activates remote host identification via TCP/IP finger-
printing. 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 information to create a
firewalls that filter either one (but not both). The TCP probe des-
tination port can be set in the same manner as with -PT above.
-O This option activates remote host identification via TCP/IP finger-
printing. 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 information to create a
'fingerprint' which it compares with its database of known OS fin-
gerprints (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 (eg 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 operat-
ing 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 "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 Classifi-
cation. 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 hiding the source of an
attack. The actual difficulty number is based on statistical sam-
pling 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.
[mcarroll@red mcarroll]$ sudo nmap -sA -O 66.57.242.138
Password:
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Note: Host seems down. If it is really up, but blocking our ping probes, try -P0
Nmap run completed -- 1 IP address (0 hosts up) scanned in 30 seconds
[mcarroll@red mcarroll]$ sudo nmap -sA -O 66.57.242.132
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Warning: OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port
Interesting ports on rdu57-242-132.nc.rr.com (66.57.242.132):
(The 1596 ports scanned but not shown below are in state: UNfiltered)
Port State Service
69/tcp filtered tftp
137/tcp filtered netbios-ns
138/tcp filtered netbios-dgm
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
Too many fingerprints match this host for me to give an accurate OS guess
Nmap run completed -- 1 IP address (1 host up) scanned in 31 seconds
[mcarroll@red mcarroll]$ sudo nmap -sA -O -P0 66.57.242.132
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Warning: OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port
Interesting ports on rdu57-242-132.nc.rr.com (66.57.242.132):
(The 1596 ports scanned but not shown below are in state: UNfiltered)
Port State Service
69/tcp filtered tftp
137/tcp filtered netbios-ns
138/tcp filtered netbios-dgm
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
Too many fingerprints match this host for me to give an accurate OS guess
Nmap run completed -- 1 IP address (1 host up) scanned in 31 seconds
[mcarroll@red mcarroll]$ sudo nmap -sA -O -P0 66.57.242.138
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
qcaught SIGINT signal, cleaning up
[mcarroll@red mcarroll]$ finger 66.57.242.138
finger: 66.57.242.138: no such user.
[mcarroll@red mcarroll]$
