While mapping out firewall rules can be valuable, bypassingrules is often the primary goal. Nmap implements many techniques fordoing this, though most are only effective against poorly configurednetworks. Unfortunately, those are common. Individual techniqueseach have a low probability of success, so try as many different methodsas possible. The attacker need only find one misconfiguration to succeed, whilethe network defenders must close every hole.

The previous section discussed using an ACK scan to map outwhich target network ports are filtered. However, it could not determinewhich of the accessible ports were open or closed. Nmap offersseveral scan methods that are good at sneaking past firewalls whilestill providing the desired port state information.FIN scanis onesuch technique. In the section called “ACK Scan”, SYN and ACK scans were run against a machine named Para. The SYNscan showed only two open ports, perhaps due to firewall restrictions.Meanwhile, the ACK scan is unable to recognize open ports from closedones. Example 10.6 shows anotherscan attempt against Para, this time using a FIN scan.Because a naked FIN packet is being set, this packet flies past therules blocking SYN packets. While a SYN scan only found one open portbelow 100, the FIN scan finds both of them.

Nmap supports MAC address spoofing with the -spoof-mac option. The argument given can take several forms. If it is simply the number 0, Nmap chooses a completely random MAC address 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. This command will scan your network from 192.168.0.1 to 255 and will display the hosts with their MAC address on your network. In case you want to display the mac address for a single client, use this command make sure you are on root or use 'sudo' sudo nmap -Pn 192.168.0.1 this command will display the host MAC address and the open ports.

Example 10.6. FIN scan against stateless firewall

Many other scan types are worth trying, since the targetfirewall rules and target host type determine which techniques willwork. Some particularly valuable scan types areFIN,Maimon,Window,SYN/FIN, andNULL scans.These are all described in Chapter 5, Port Scanning Techniques and Algorithms.

One surprisingly common misconfiguration is to trust trafficbased only on the source port number. It is easy to understand howthis comes about. An administrator will set up a shiny new firewall,only to be flooded with complains from ungrateful users whoseapplications stopped working. In particular, DNS may be brokenbecause the UDP DNS replies from external servers can no longer enterthe network. FTP is another common example. In active FTP transfers,the remote server tries to establish a connection back to the clientto transfer the requested file.

Secure solutions to these problems exist, often in the form ofapplication-level proxies or protocol-parsing firewall modules.Unfortunately there are also easier, insecure solutions. Noting thatDNS replies come from port 53 and active FTP from port 20, many administratorshave fallen into the trap of simply allowing incoming traffic fromthose ports. They often assume that no attacker would notice andexploit such firewall holes. In other cases, administrators consider this ashort-term stop-gap measure until they can implement a more securesolution. Then they forget the security upgrade.

Overworked network administrators are not the only ones to fallinto this trap. Numerous products have shipped with these insecurerules. Even Microsoft has been guilty. The IPsec filters thatshipped with Windows 2000 and Windows XP contain an implicit rule thatallows all TCP or UDP traffic from port 88 (Kerberos). Apple fansshouldn't get too smug about this because the firewall which shippedwith Mac OS X Tiger is just as bad. Jay Bealediscoveredthat even if you enable the “Block UDP Traffic” box in the firewallGUI, packets from port 67 (DHCP) and 5,353 (Zeroconf) pass rightthrough. Yet another pathetic example of this configuration is that Zone Alarm personal firewall (versions up to 2.1.25) allowed any incoming UDP packetswith the source port 53 (DNS) or 67 (DHCP).

Nmap offers the -g and--source-portoptions (they are equivalent) to exploit theseweaknesses. Simply provide a port number, and Nmap will send packetsfrom that port where possible. Nmap must use different port numbersfor certain OS detection tests to work properly. Most TCP scans, including SYN scan,support the option completely, as does UDP scan. In May 2004,JJ Grayposted example Nmap scans to Bugtraq that demonstrate exploitation ofthe Windows IPsec source port 88 bug against one of his clients. Anormal scan, followed by a -g 88 scan are shown inExample 10.7. Some output hasbeen removed for brevity and clarity.

Example 10.7. Bypassing Windows IPsec filter using source port 88

Note that the closed port 88 was the hint that lead JJ to tryusing it as a source port. For further information on thisvulnerability, see MicrosoftKnowledge Base Article 811832.

While IPv6 has not exactly taken the world by storm, it isreasonably popular in Japan and certain other regions. Whenorganizations adopt this protocol, they often forget to lock it downas they have instinctively learned to do with IPv4. Or they may tryto, but find that their hardware does not support IPv6 filteringrules. Filtering IPv6 can sometimes be more critical than IPv4because the expanded address space often allows the allocation ofglobally addressable IPv6 addresses to hosts that would normally haveto use theprivate IPv4 addressesspecified by RFC 1918.

Performing an IPv6 scan rather than the IPv4 default is often aseasy as adding -6to the command line. Certainfeatures such as OS detection and UDP scanning are not yet supportedfor this protocol, but the most popular features work. Example 10.8 demonstrates IPv4 and IPv6scans, performed long ago, of a well-known IPv6 development andadvocacy organization.

Example 10.8. Comparing IPv4 and IPv6 scans

The first scan shows numerous filtered ports, includingfrequently exploitable services such as SunRPC, Windows NetBIOS, andNFS. Yet scanning the same host with IPv6 shows no filtered ports!Suddenly SunRPC (port 111)is available, and waiting to be queried by an IPv6-enabledrpcinfoor by Nmap versiondetection, which supports IPv6. They fixed the issue shortly after Inotified them of it.

In order to perform an IPv6 scan, a system must be configuredfor IPv6. It must have an IPv6 address and routing information.Since my ISPs do not provide IPv6 addresses, I use the free IPv6 tunnelbrokerservice at http://www.tunnelbroker.net. Other tunnel brokers are listed at Wikipedia. 6to4 tunnels are another popular,free approach. Of course, this technique also requires that the targetuse IPv6.

The IP ID idle scan has a reputation for being one of the moststealthy scan types, since no packets are sent to the target from yourreal address. Open ports are inferred from the IP ID sequences of achosen zombie machine. A less recognized feature of idle scan is thatthe results obtained are actually those you would get if the zombiewas to scan the target host directly. In a similar way that the-g option allows exploitation of trusted sourceports, idle scan can sometimes exploit trusted source IP addresses.This ingenious scan type, which was originally conceived by securityresearcher Antirez, is described fully in the section called “TCP Idle Scan (-sI)”.

A common issue when trying to scan through firewalled networksis that dropped ping probes can lead to missed hosts. To reduce thisproblem, Nmap allows a very wide variety of probes to be sent inparallel. Hopefully at least one will get through. Chapter 3, Host Discovery (“Ping Scanning”) discusses these techniques in depth, including empirical data on thebest firewall-busting techniques.

Some packet filters have trouble dealing with IP packetfragments. They could reassemble the packets themselves, but thatrequires extra resources. There is also the possibility thatfragments will take different paths, preventing reassembly. Due tothis complexity, some filters ignore all fragments, while othersautomatically pass all but the first fragment. Interesting things canhappen if the first fragment is not long enough to contain the wholeTCP header, or if the second packet partially overwrites it. Thenumber of filtering devices vulnerable to these problems is shrinking,though it never hurts to try.

An Nmap scan will use tiny IP fragmentsif the-fis specified. By default Nmap will include up to eight bytes of data ineach fragment, so a typical 20 or 24 byte (depending on options) TCPpacket is sent in three tiny fragments. Every instanceof -f adds eight to the maximum fragment data size.So -f -f allows up to 16 data bytes within eachfragment. Alternatively, you can specify the --mtuoption and give the maximum data bytes as an argument.The --mtu argument must be a multiple of eight, andcannot be combined with the -f option.

Some source systems defragment outgoing packets in the kernel. Linuxwith the iptablesconnection tracking module is one such example. Do a scan while asniffer such asWiresharkis running to ensure that sent packets are fragmented. If your hostOS is causing problems, trythe --send-ethoption to bypass the IP layer and send raw ethernet frames.

Fragmentation is only supported for Nmap's raw packet features,which includes TCP and UDP port scans (except connect scan and FTPbounce scan) and OS detection. Features such as version detection andthe Nmap Scripting Engine generally don't support fragmentation becausethey rely on your host's TCP stack to communicate with target services.

Out-of-order and partially overlapping IP fragments can beuseful for Network research and exploitation, but that calls for aneven lower-level networking tool than Nmap. Nmap sends fragments inorder without any overlaps.

If a fragmented port scan gets through, a tool such as Fragroutecan be used to fragment other tools and exploits used toattack the host.

Application-level proxies, particularly for the Web, have becomepopular due to perceived security and network efficiency (throughcaching) benefits. Like firewalls and IDS, misconfigured proxies cancause far more security problems than they solve. The most frequentproblem is a failure to set appropriate access controls. Hundreds ofthousands of wide-open proxiesexist on the Internet, allowinganyone to use them as anonymous hopping points to other Internetsites. Dozens of organizations use automated scanners to find theseopen proxies and distribute the IP addresses. Occasionally theproxies are used for arguably positive things, such as escaping thedraconian censorship imposed by the Chinese government on itsresidents. This “great firewall of China” has been known to block theNew York Times web site as well as other news, political, and spiritualsites that the government disagrees with. Unfortunately, the openproxies are more frequently abused by more sinister folks who want toanonymously crack into sites, commit credit card fraud, or flood theInternet with spam.

While hosting a wide-open proxy to Internet resources can causenumerous problems, a more serious condition is when the open proxiesallow connections back into the protected network. Administrators whodecide that internal hosts must use a proxy to access Internetresources often inadvertently allow traffic in the opposite directionas well. The hackerAdrian Lamois famous for breaking into Microsoft,Excite, Yahoo, WorldCom, the New York Times, and other large networks,usually by exploiting this reverse-proxy technique.

Nmap does not presently offer a proxy scan-through option,though it is high on the priority list. the section called “SOLUTION: Hack Version Detection to Suit Custom Needs, such as Open Proxy Detection” discusses a way to find open proxies usingNmap version detection. In addition, plentyof dedicated free proxy scanners are available on Internet sites such asPacket Storm.Lists of thousands of open proxies are widespread as well.

Ethernet devices (including Wi-Fi) are identified by a uniquesix-byte media access control (MAC) address. The first three bytes makeup an organizationally unique identifier(OUI). This prefix is assigned to avendor by the IEEE. The vendor is then responsible for assigning theremaining three bytes uniquely in the adapters and devices it sells.Nmap includes a database which maps OUIs to the vendor names they areassigned to. This helps in identifying devices while scanning anetwork, though this section describes why it can't be completelytrusted. The OUI database file,nmap-mac-prefixes,is described in the section called “MAC Address Vendor Prefixes: nmap-mac-prefixes”.

While MAC addresses are pre-assigned to ethernet devices, theycan be changed with a driver on most current hardware. But since fewpeople change their MAC address (or even know they have one), manynetworks use them for identification and authorization purposes. Forexample, most wireless access points provide a configuration optionfor limiting access to a certain set of MAC addresses. Similarly,some paid or private networks will force you to authenticate or payafter you connect using a web form. Then they will allow you accessto the rest of the network based on your MAC address. Given that itis generally easy to sniff MAC addresses (they must be sent in everyframe sent and received), and then to spoof that MAC to gainunauthorized access to the network, this form of access control israther weak. It is also only effective at the edges of a network,since an end-host's MAC address is replaced when traversing arouter.

In addition to access control, MAC addresses are sometimes usedfor accountability. Network admins will record MAC addresses whenthey obtain a DHCP lease or when a new machine communicates on thenetwork. If network abuse or piracy complaints are received later,they figure out the MAC address based on the IP address and incidenttime. Then they use the MAC to track down the responsible machine andits owner. The ease of MAC address spoofing undermines this approachto some degree. Even when users are guilty, they may raise thespecter of MAC address spoofing to deflect responsibility.

Nmap supports MAC address spoofing with the--spoof-mac option.The argument given can take several forms. If it is simply the number 0, Nmap chooses a completely random MAC address 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 fewer than 12 hex digits are provided, Nmap fills in the remainder of the six bytes with random values. If the argument isn't a zero 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 and fills out the remaining three bytes randomly. Valid --spoof-mac argument examples are Apple, 0, 01:02:03:04:05:06, deadbeefcafe, 0020F2, and Cisco. This option implies --send-eth to ensure that Nmap actually sends ethernet-level packets. This option only affects raw packet scans such as SYN scan or OS detection, not connection-oriented features such as version detection or the Nmap Scripting Engine.

Even when MAC address spoofing isn't needed for network access,it can be used for deception. If I'm at a conference and launch ascan from my Thinkpad with --spoof-mac Apple,suspicious eyes may turn to the MacBook users in the room.

This old-school technique is still effective in some cases.Ifa particular router on the path is causing you trouble, try to find aroute around it. Effectiveness of this technique is limited becausepacket filtering problems usually occur on or near the target network.Those machines are likely to either drop all source routed packets orto be the only way into the network. Nmap supports both loose andstrict source routing using the--ip-options option.For example, specifying --ip-options 'L 192.168.0.7192.168.30.9' requests that the packet be loose source routedthrough those two given IP way points. Specify Sinstead of L for strict source routing. If youchoose strict source routing, keep in mind that you will have tospecify every single hop along the path.

For a real-life example of source routing used to evadefiltering policies on a modern network, seethe section called “A Practical Real-life Example of Firewall Subversion”. While IPv4 source routing isvery commonly blocked, theIPv6form of source routing is much morepervasive. An interesting article on that problem is available athttp://lwn.net/Articles/232781/.

If a source routed path to a target machine is discovered withNmap, exploitability is not limited to port scanning.Ncatcan enable TCP and UDP communication over source routed paths (use the-goption).

While only a small percentage of FTP servers are stillvulnerable, it is worth checking all of your clients' systemsfor this problem. At a minimum, it allows outside attackers toutilize vulnerable systems to scan other parties. Worseconfigurations even allow attackers to bypass the organization'sfirewalls. Details and examples of this technique are provided inthe section called “TCP FTP Bounce Scan (-b)”. Example 10.9 shows an HP printer beingused to relay a port scan. If this printer is behind theorganization's firewall, it can be used to scan normally inaccessible(to the attacker) internal addresses as well.

Example 10.9. Exploitinga printer with the FTP bounce scan

I hate to overuse the “think outside the box”cliché, but continually banging on the front door of a well-securednetwork is not always the best approach. Look for other ways in.Wardial their phone lines, attack subsidiaries who may have specialnetwork access, or show up at their offices with Wi-Fi sniffingequipment, or even sneak in and plug into a convenient ethernet jack.Nmap works well through all of these connections. Just make sure thatyourpenetration-testing contractcovers these methods before yourclient catches you in a ninja suit grappling onto their datacenterrooftop.

Now that many individual techniques forbypassing firewall rules have been covered, it is time to put them together in a real-life penetration testing scenario. Itall started witha postto the SecurityFocus pen-test list from security proMichael Cain.He and coworkerDemetris Papapetrouwere penetration testing theinternal network of a large corporation and had just bypassed firewall rules meant toprevent one VLAN from accessing another. I was pleased to read thatthey performed this feat using Nmap, and I wrote them for the wholestory. It is both instructional and inspirational in that itdemonstrates the value of perseverance and trying every technique youknow, even after the most common exploits fail. Don't let thatfirewall beat you!

The story starts with Michael and Demetris performing anNmap scan which shows that they arestuck on a heavily filtered network. They can reach somecorporate servers, but not any of the (potentially vulnerable) desktopclient machines which have to exist somewhere on the network. Perhaps they are on arestricted conference room or lobby network, or maybe a wirelessaccess point set up for corporate guests. Some of the discovered hosts and networksare shown in Example 10.10. A few details in thisstory (such as IP addresses) have been changed for confidentialityreasons. I will call the target corporation Megacorp.

Example 10.10. Some interesting hosts and networks at Megacorp

Given the goal of determining if any hosts are hiding on the10.10.10.0/24 network, Demetris starts with a simple ping scan usingICMP echo request queries (-PE). The results areshown in Example 10.11.

Example 10.11. Ping scan against the target network

The ping scan fails to find any responsive hosts. Demetris is understandably disappointed, but at least it makes thissection more interesting and instructive. Perhaps the network trulyis empty, but it could also be packed with vulnerable machines whichDemetris is blocked from accessing. He needs to dig deeper. InExample 10.12, Demetris chooses one IP onthat network and performs a ping scan. He specifies the packettracing (--packet-trace) and extra verbosity(-vv) options to determine what is going on at thepacket level. The reason for choosing just one IP is to avoid aconfusing flood of hundreds of packets.

Example 10.12. Packet trace against a single IP

It seems that Demetris is receiving ICMP host unreachablemessages when trying to scan these IPs (or at least this one). Routerscommonly do that when a host is unavailable and so they can't determinea MAC address. It is also occasionally caused by filtering.Demetris scans the other hosts on the network and verifies that theybehave the same way. It is possible that only ICMP packets arefiltered, so Demetris decides to try a TCP SYN scan. He runs thecommand nmap -vv -n -sS -T4 -Pn --reason10.10.10.0/24.All ports are shown as filtered, andthe --reason results blame some host unreachablemessages and some nonresponsive ports. The nonresponsive ports maybe due to rate limiting ofhost unreachablemessages sent by therouter. Many routers will only send one of these every few seconds.Demetris can verify whether rate limiting is the cause by running thescan again and seeing if the host unreachable messages come forexactly the same set of ports. If the ports are the same, it may be aspecific port-based filter. If Nmap receives host-unreachablemessages for different ports each time, rate limiting is likely thecause.

If a filter is causing the problem, it could be a simplestateless firewall as is commonly available on routers and switches.As discussed in previous sections, these sometimes allow TCP ACKpackets through unmolested. Demetris repeats the scan, butspecifies -sA for an ACK scan ratherthan -sS. Any unfiltered portsfound by the scan would suggest that the ACK packets made it throughand elicited a TCP RST response from the target host. Unfortunately,the results were all filtered in this case, just aswith the SYN scan.

Demetris decides to try something more advanced. He alreadyknows that port 445 is open on the Windows machine at 10.10.6.30(files2.megacorp.com) from his initial Nmap scan. While Demetrishasn't been able to reach the 10.10.10.0/24 network directly, perhaps files2 (beingan important company file server) is able to access that IP range.Demetris decides to try bouncing his scans off files2 using the IPID Idlescan. First he wants to ensure that files2 works as a zombie bytesting it against 10.10.6.60—a known-responsive machine with port 25 open. The results of this test are shown in Example 10.13.

Example 10.13. Testing an idle scan

Using 10.10.6.30 as an Idle Zombie didn't work out well. If theproblem was due to heavy traffic, he could try again in the middle ofthe night. The --packet-trace option combined withthorough reading of the section called “TCP Idle Scan (-sI)” couldhelp determine why 10.10.6.30 isn't working as a zombie. Demetristries the handful of other hosts he has found on the network, and nonework as zombies.

Demetris begins to worry about whether he will ever crack intothe 10.10.10.0/24 network. Fortunately, he is an old hand atthis and has another trick up his sleeve—IPsource routing.Inthe early days of the Internet (and even today with IPv6), sourcerouting was an important and widely deployed network diagnosis feature.It allows you to specify the hops you want a packet totake to its target rather than relying on normal routing rules. Withstrict source routing, you must specify every hop. Loosesource routing allows you to fill in key IP way points, while normalInternet routing fills in hop details between those way points.

Long ago the networking community reached consensus that sourcerouting is more trouble (particularly for security) than it isworth. Many (if not most) routers are configured to drop sourcerouted IPv4 packets, so some folks have considered the problem fixedsince the early 90's. Yet source routing, like SYN flooding andTelnet password sniffing, continues as a rare but potentrisk. Demetris tests this attack by ping-scanning files2(10.10.6.30) using packets loose-source-routed through the 10.10.6.60 mail server.Results are shown in Example 10.14.

Example 10.14. Testing source routing

Demetris is both surprised and delighted that the test works. He immediately turns his attention to his true target network, repeating his initial ping scan with an additional option: --ip-options 'L 10.10.6.60'. This time, Nmap reports that the machine at 10.10.10.7 is responsive. Demetris learns that it wasn't reachable before because the 10.10.10.0/24 and 10.10.5.0/24 subnets are on different router VLANs configured to prevent them from communicating to each other. Demetris' source routing technique opened a big loophole in that policy! Demetris follows up with a SYN scan of the 10.10.10.7 machine, as shown in Example 10.15.

Example 10.15. Success at last

Demetris omitted OS detection and version detectionfrom this initial scan, but this looks like a Windows machine from the openport profile. Demetris can now connect to and access these ports aslong as he uses tools such as Ncatwhich offer source routingoptions. I don't know what happens next in the story, but I'mguessing that it involves Demetris fully penetrating the networkand then helping the company redesign it more securely.

Nmap Get Only Hostname

Many Internet pioneers envisioned a global open network with auniversal IP address space allowing virtual connections between anytwo nodes. This allows hosts to act as true peers, serving andretrieving information from each other. People could access all oftheir home systems from work, changing the climate control settings orunlocking the doors for early guests. This vision of universalconnectivity has been stifled by address space shortages and securityconcerns. In the early 1990s, organizations began deployingfirewalls for the express purpose of reducing connectivity. Hugenetworks were cordoned off from the unfiltered Internet by applicationproxies, network address translation, and packet filters. Theunrestricted flow of information gave way to tight regulation ofapproved communication channels and the content that passes overthem.

Network obstructions such as firewalls can make mapping anetwork exceedingly difficult. It will not get any easier, asstifling casual reconnaissance is often a key goal of implementing thedevices. Nevertheless, Nmap offers many features to help understand thesecomplex networks, and to verify that filters are working as intended.It even supports mechanisms for bypassing poorly implementeddefenses. One of the best methods of understanding yournetwork security posture is to try to defeat it. Place yourself inthe mind-set of an attacker, and deploy techniques from this sectionagainst your networks. Launch an FTP bounce scan, idle scan,fragmentation attack, or try to tunnel through one of your ownproxies.

In addition to restricting network activity, companies areincreasingly monitoring traffic with intrusion detection systems(IDS). All of the major IDSs ship with rules designed to detect Nmapscans because scans are sometimes a precursor to attacks. Many ofthese products have recently morphed into intrusionprevention systems(IPS)that actively blocktraffic deemed malicious. Unfortunately for network administratorsand IDS vendors, reliably detecting bad intentions by analyzing packetdata is a tough problem. Attackers with patience, skill, and the helpof certain Nmap options can usually pass by IDSs undetected.Meanwhile, administrators must cope with large numbers of falsepositive results where innocent activity is misdiagnosed and alertedon or blocked.

Occasionally people suggest that Nmap should not offer featuresfor evading firewall rules or sneaking past IDSs. They arguethat these features are just as likely to be misused by attackers asused by administrators to enhance security. The problem with thislogic is that these methods would still be used by attackers, whowould just find other tools or patch the functionality into Nmap.Meanwhile, administrators would find it that much harder to do theirjobs. Deploying only modern, patched FTP servers is a far morepowerful defense than trying to prevent the distribution of toolsimplementing the FTP bounce attack.

There is no magic bullet (or Nmap option) for detecting andsubverting firewalls and IDS systems. It takes skill and experience.A tutorial is beyond the scope of this reference guide, which onlylists the relevant options and describes what they do.

The -f option causes the requested scan (including host discovery 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 eight bytes or less after the IP header. So a 20-byte TCP header would be split into three 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 eight. 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.

Fragmentation is only supported for Nmap's raw packet features,which includes TCP and UDP port scans (except connect scan and FTPbounce scan) and OS detection. Features such as version detection andthe Nmap Scripting Engine generally don't support fragmentationbecause they rely on your host's TCP stack to communicate with targetservices.

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 sixth 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). Right now random IP address generation is only supported with IPv4

Decoys are used both in the initial host discovery 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.

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.

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.

Nmap Scan For Mac Address Filter

One surprisingly common misconfiguration is to trust trafficbased only on the source port number. It is easy to understand howthis comes about. An administrator will set up a shiny new firewall,only to be flooded with complaints from ungrateful users whoseapplications stopped working. In particular, DNS may be brokenbecause the UDP DNS replies from external servers can no longer enterthe network. FTP is another common example. In active FTP transfers,the remote server tries to establish a connection back to the clientto transfer the requested file.

Secure solutions to these problems exist, often in the form ofapplication-level proxies or protocol-parsing firewall modules.Unfortunately there are also easier, insecure solutions. Noting thatDNS replies come from port 53 and active FTP from port 20, many administratorshave fallen into the trap of simply allowing incoming traffic fromthose ports. They often assume that no attacker would notice andexploit such firewall holes. In other cases, administrators consider this ashort-term stop-gap measure until they can implement a more securesolution. Then they forget the security upgrade.

Overworked network administrators are not the only ones to fallinto this trap. Numerous products have shipped with these insecurerules. Even Microsoft has been guilty. The IPsec filters thatshipped with Windows 2000 and Windows XP contain an implicit rule thatallows all TCP or UDP traffic from port 88 (Kerberos). In another well-knowncase, versions of the Zone Alarm personal firewall up to 2.1.25allowed 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 theseweaknesses. Simply provide a port number and Nmap will send packetsfrom that port where possible. Most scanning operations that use raw sockets,including SYN and UDP scans, support the option completely. The option notablydoesn't have an effect for any operations that use normal operating systemsockets, including DNS requests, TCP connectscan, version detection,and script scanning. Setting the source port also doesn't work for OS detection,because Nmap must use different port numbers for certain OS detection tests towork properly.

Linux Nmap Scan Mac Address

This option lets you include binary data as payload in sent packets. <hex string> may be specified in any of the following formats: 0xAABBCCDDEEFF<...>, AABBCCDDEEFF<...> or xAAxBBxCCxDDxEExFF<...>. Examples of use are --data 0xdeadbeef and --data xCAxFEx09. Note that if you specify a number like 0x00ff no byte-order conversion is performed. Make sure you specify the information in the byte order expected by the receiver.

This option lets you include a regular string as payload in sent packets. <string> can contain any string. However, note that some characters may depend on your system's locale and the receiver may not see the same information. Also, make sure you enclose the string in double quotes and escape any special characters from the shell. Examples: --data-string 'Scan conducted by Security Ops, extension 7192' or --data-string 'Ph34r my l33t skills'. Keep in mind that nobody is likely to actually see any comments left by this option unless they are carefully monitoring the network with a sniffer or custom IDS rules.

Normally Nmap sends minimalist packets containing only a header. So its TCP packets are generally 40 bytes and ICMP echo requests are just 28. Some UDP ports and IP protocols get a custom payload by default. This option tells Nmap to append the given number of random bytes to most of the packets it sends, and not to use any protocol-specific payloads. (Use --data-length 0 for no random or protocol-specific payloads. 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.

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, x01x07x04x00*36x01 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/52.

Sets the IPv4 time-to-live field in sent packets to the given value.

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.

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 number 0, Nmap chooses a completely random MAC address 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 fewer than 12 hex digits are provided, Nmap fills in the remainder of the six bytes with random values. If the argument isn't a zero 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 (three-byte prefix) and fills out the remaining three bytes randomly. Valid --spoof-mac argument examples are Apple, 0, 01:02:03:04:05:06, deadbeefcafe, 0020F2, and Cisco. This option only affects raw packet scans such as SYN scan or OS detection, not connection-oriented features such as version detection or the Nmap Scripting Engine.

Asks Nmap to establish TCP connections with a final target through supplied chain of one or more HTTP or SOCKS4 proxies. Proxies can help hide the true source of a scan or evade certain firewall restrictions, but they can hamper scan performance by increasing latency. Users may need to adjust Nmap timeouts and other scan parameters accordingly. In particular, a lower --max-parallelism may help because some proxies refuse to handle as many concurrent connections as Nmap opens by default.

This option takes a list of proxies as argument, expressed as URLs in the format proto://host:port. Use commas to separate node URLs in a chain. No authentication is supported yet. Valid protocols are HTTP and SOCKS4.

Warning: this feature is still under development and has limitations. It is implemented within the nsock library and thus has no effect on the ping, port scanning and OS discovery phases of a scan. Only NSE and version scan benefit from this option so far—other features may disclose your true address. SSL connections are not yet supported, nor is proxy-side DNS resolution (hostnames are always resolved by Nmap).

Asks Nmap to use an invalid TCP, UDP or SCTP 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 https://nmap.org/p60-12.html

Asks Nmap to use the deprecated Adler32 algorithm for calculating the SCTP checksum. If --adler32 is not given, CRC-32C (Castagnoli) is used. RFC 2960 originally defined Adler32 as checksum algorithm for SCTP; RFC 4960 later redefined the SCTP checksums to use CRC-32C. Current SCTP implementations should be using CRC-32C, but in order to elicit responses from old, legacy SCTP implementations, it may be preferable to use Adler32.