Nmap Security Scanner
Ref Guide
Security Lists
Security Tools
Site News
Advertising
About/Contact
Credits
Sponsors
|

 |
Intro |
Reference Guide |
Book |
Install Guide |
Download |
Changelog |
Zenmap GUI |
Docs |
Bug Reports |
OS Detection |
Propaganda |
Related Projects |
In the Movies |
In the News |
|
 |
Firewall/IDS Evasion and SpoofingMany Internet pioneers envisioned a global open network with a
universal IP address space allowing virtual connections between any
two nodes. This allows hosts to act as true peers, serving and
retrieving information from each other. People could access all of
their home systems from work, changing the climate control settings or
unlocking the doors for early guests. This vision of universal
connectivity has been stifled by address space shortages and security
concerns. In the early 1990s, organizations began deploying
firewalls for the express purpose of reducing connectivity. Huge
networks were cordoned off from the unfiltered Internet by application
proxies, network address translation, and packet filters. The
unrestricted flow of information gave way to tight regulation of
approved communication channels and the content that passes over
them. Network obstructions such as firewalls can make mapping a
network exceedingly difficult. It will not get any easier, as
stifling casual reconnaissance is often a key goal of implementing the
devices. Nevertheless, Nmap offers many features to help understand these
complex networks, and to verify that filters are working as intended.
It even supports mechanisms for bypassing poorly implemented
defenses. One of the best methods of understanding your
network security posture is to try to defeat it. Place yourself in
the mind-set of an attacker, and deploy techniques from this section
against your networks. Launch an FTP bounce scan, idle scan,
fragmentation attack, or try to tunnel through one of your own
proxies. In addition to restricting network activity, companies are
increasingly monitoring traffic with intrusion detection systems
(IDS). All of the major IDSs ship with rules designed to detect Nmap
scans because scans are sometimes a precursor to attacks. Many of
these products have recently morphed into intrusion
prevention systems (IPS) that actively block
traffic deemed malicious. Unfortunately for network administrators
and IDS vendors, reliably detecting bad intentions by analyzing packet
data is a tough problem. Attackers with patience, skill, and the help
of certain Nmap options can usually pass by IDSs undetected.
Meanwhile, administrators must cope with large numbers of false
positive results where innocent activity is misdiagnosed and alerted
on or blocked. Occasionally people suggest that Nmap should not offer features
for evading firewall rules or sneaking past IDSs. They argue
that these features are just as likely to be misused by attackers as
used by administrators to enhance security. The problem with this
logic is that these methods would still be used by attackers, who
would just find other tools or patch the functionality into Nmap.
Meanwhile, administrators would find it that much harder to do their
jobs. Deploying only modern, patched FTP servers is a far more
powerful defense than trying to prevent the distribution of tools
implementing the FTP bounce attack.
There is no magic bullet (or Nmap option) for detecting and
subverting firewalls and IDS systems. It takes skill and experience.
A tutorial is beyond the scope of this reference guide, which only
lists the relevant options and describes what they do. -
-f (fragment packets);
--mtu (using the specified MTU)
The -f option causes the requested scan (including
ping scans) to use tiny fragmented IP packets. The idea
is to split up the TCP header over several packets to
make it harder for packet filters, 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
Sniffit segmentation faulted immediately upon receiving
the first fragment. Specify this option once, and Nmap
splits the packets into 8 bytes or less after the IP
header. So a 20-byte TCP header would be split 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 you use --mtu . The offset must be a
multiple of 8. While fragmented packets won't get by
packet filters and firewalls that queue all IP fragments,
such as the CONFIG_IP_ALWAYS_DEFRAG option in the Linux
kernel, some networks can't afford the performance hit
this causes and thus leave it disabled. Others can't enable
this because fragments may take different routes into their
networks. Some source
systems defragment outgoing packets in the kernel. Linux
with the iptables connection tracking module is one such
example. Do a scan while a sniffer such as Wireshark
is running to ensure that sent packets are
fragmented. If your host OS is causing problems, try the --send-eth option to bypass the IP layer and send raw ethernet frames. -
-D <decoy1 [,decoy2][,ME],...>
(Cloak a scan with decoys)
Causes a decoy scan to be performed, which makes it
appear to the remote host that the host(s) you specify as
decoys are scanning the target network too. Thus their IDS
might report 5-10 port scans from unique IP addresses, but
they won't know which IP was scanning them and which were
innocent decoys. While this can be defeated through router
path tracing, response-dropping, and other active
mechanisms, it is generally an effective technique for
hiding your IP address. Separate each decoy host with commas, and you can
optionally use ME as one of the decoys to
represent the position for your real IP address. If you put
ME in 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 a random position. You can also use RND to generate
a random, non-reserved IP address, or RND:<number> to
generate <number> addresses. Note that the hosts
you use as decoys should be up or you might accidentally SYN
flood your targets. Also it will be pretty easy to determine
which host is scanning if only one is actually up on the
network. You might want to use IP addresses instead of names
(so the decoy networks don't see you in their nameserver
logs). Decoys are used both in the initial ping scan (using
ICMP, SYN, ACK, or whatever) and during the actual port
scanning phase. Decoys are also used during remote OS
detection (-O ). Decoys do not work with
version detection or TCP connect scan. When a scan delay is
in effect, the delay is enforced between each batch of
spoofed probes, not between each individual probe. Because
decoys are sent as a batch all at once, they may temporarily
violate congestion control limits. It is worth noting that using too many decoys may
slow your scan and potentially even make it less
accurate. Also, some ISPs will filter out your spoofed
packets, but many do not restrict
spoofed IP packets at all. -
-S <IP_Address> (Spoof source address)
In some circumstances,
Nmap may not be able to determine your
source address (
Nmap will tell you if this is the
case). In this situation, use -S with the IP address of
the interface you wish to send packets through. Another possible use of this flag is to spoof the scan
to make the targets think that someone
else is scanning them. Imagine a company being
repeatedly port scanned by a competitor! The
-e option and -PN are
generally required for this sort of usage. Note that you
usually won't receive reply packets back (they will be
addressed to the IP you are spoofing), so Nmap won't produce
useful reports. -
-e <interface> (Use specified interface)
Tells Nmap what interface to send and receive
packets on. Nmap should be able to detect this
automatically, but it
will tell you if it cannot. -
--source-port <portnumber>;
-g <portnumber> (Spoof source port number)
One surprisingly common misconfiguration is to trust traffic
based only on the source port number. It is easy to understand how
this comes about. An administrator will set up a shiny new firewall,
only to be flooded with complains from ungrateful users whose
applications stopped working. In particular, DNS may be broken
because the UDP DNS replies from external servers can no longer enter
the network. FTP is another common example. In active FTP transfers,
the remote server tries to establish a connection back to the client
to transfer the requested file. Secure solutions to these problems exist, often in the form of
application-level proxies or protocol-parsing firewall modules.
Unfortunately there are also easier, insecure solutions. Noting that
DNS replies come from port 53 and active FTP from port 20, many administrators
have fallen into the trap of simply allowing incoming traffic from
those ports. They often assume that no attacker would notice and
exploit such firewall holes. In other cases, administrators consider this a
short-term stop-gap measure until they can implement a more secure
solution. Then they forget the security upgrade.
Overworked network administrators are not the only ones to fall
into this trap. Numerous products have shipped with these insecure
rules. Even Microsoft has been guilty. The IPsec filters that
shipped with Windows 2000 and Windows XP contain an implicit rule that
allows all TCP or UDP traffic from port 88 (Kerberos). In another well-known
case, versions of the Zone Alarm personal firewall up to 2.1.25
allowed any incoming UDP packets with the source port 53 (DNS) or 67
(DHCP). Nmap offers the -g and
--source-port options (they are equivalent) to exploit these
weaknesses. Simply provide a port number and Nmap will send packets
from that port where possible. Nmap must use different port numbers
for certain OS detection tests to work properly, and DNS requests
ignore the --source-port flag because Nmap relies on system
libraries to handle those. Most TCP scans, including SYN scan,
support the option completely, as does UDP scan. -
--data-length <number> (Append random
data to sent packets)
Normally Nmap sends minimalist packets containing only
a header. So its TCP packets are generally 40
bytes and ICMP echo requests are just 28. This option
tells Nmap to append the given number of random bytes to
most of the packets it sends. OS detection (-O ) packets
are not affected because accuracy there requires probe consistency, but most pinging and portscan packets
support this. It slows things down a little, but can make a scan slightly less
conspicuous. -
--ip-options <S|R [route]|L [route]|T|U ... >;
--ip-options <hex string> (Send packets with specified ip options)
The
IP protocol offers several options which may be placed in
packet headers. Unlike the ubiquitous TCP options, IP options
are rarely seen due to practicality and security concerns. In
fact, many Internet routers block the most dangerous options
such as source routing. Yet options can still be useful in some
cases for determining and manipulating the network route to
target machines. For example, you may be able to use the record
route option to determine a path to a target even when more
traditional traceroute-style approaches fail. Or if your
packets are being dropped by a certain firewall, you may be able
to specify a different route with the strict or loose source
routing options. The most powerful way to specify IP options is to simply
pass in values as the argument to
--ip-options . Precede each hex number with
\x then the two digits. You may repeat
certain characters by following them with an asterisk and then
the number of times you wish them to repeat. For example,
\x01\x07\x04\x00*36\x01 is a hex string
containing 36 NUL bytes. Nmap also offers a shortcut mechanism for specifying
options. Simply pass the letter R ,
T , or U to request
record-route, record-timestamp, or both options together,
respectively. Loose or strict source routing may be specified
with an L or S followed by
a space and then a space-separated list of IP addresses. If you wish to see the options in packets sent and
received, specify --packet-trace . For more
information and examples of using IP options with Nmap, see
http://seclists.org/nmap-dev/2006/q3/0052.html
-
--ttl <value> (Set IP time-to-live field)
Sets the IPv4 time-to-live field in sent packets to
the given value. -
--randomize-hosts (Randomize target host order)
Tells Nmap to shuffle each group of up to 16384 hosts
before it scans them. This can make the scans less obvious
to various network monitoring systems, especially when you
combine it with slow timing options. If you
want to randomize over larger group sizes, increase
PING_GROUP_SZ in nmap.h and recompile.
An alternative solution is to generate the target IP list
with a list scan (-sL -n -oN
filename ), randomize it
with a Perl script, then provide the whole list to Nmap with
-iL . -
--spoof-mac <MAC address, prefix, or vendor
name> (Spoof MAC address)
Asks Nmap to use the given MAC address for all of the
raw ethernet frames it sends. This option implies
--send-eth to ensure that Nmap actually sends
ethernet-level packets. The MAC given can take several formats. If
it is simply the string “0”, Nmap chooses a completely random MAC
for the session. If the given string is an even number of hex
digits (with the pairs optionally separated by a colon), Nmap will
use those as the MAC. If less than 12 hex digits are provided, Nmap
fills in the remainder of the 6 bytes with random values. If the
argument isn't a 0 or hex string, Nmap looks through
nmap-mac-prefixes to find a vendor name containing the given string
(it is case insensitive). If a match is found, Nmap uses the
vendor's OUI (3-byte prefix) and fills out the remaining 3 bytes
randomly. Valid --spoof-mac argument examples are Apple , 0 ,
01:02:03:04:05:06 , deadbeefcafe , 0020F2 , and Cisco . -
--badsum (Send packets with bogus TCP/UDP checksums)
Asks Nmap to use an invalid TCP or UDP checksum for
packets sent to target hosts. Since virtually all
host IP stacks properly drop these packets, any responses received
are likely coming from a firewall or IDS that didn't bother to
verify the checksum. For more details on this technique, see http://nmap.org/p60-12.html
|
|