Nmap Firewall and IDS Evasion: Fragmentation, Decoys, and Timing

Nmap ships a whole family of options with names like fragmentation, decoys, and source-port spoofing, and it is easy to read that list as an attacker's cheat sheet. Flip the framing. As the engineer who owns the firewall and the IDS, these flags are your test harness: they are how you prove that your own controls actually catch and drop the tricks an attacker would use, instead of assuming they do. A firewall rule you have never tested is a hypothesis. Running these evasion techniques against your own perimeter turns the hypothesis into a result. This article walks the main evasion options with real captures from a Cisco lab and the internet, and it is a companion to the complete Nmap guide, which covers the rest of the scanning workflow.

One note before anything else. Every technique below is for validating infrastructure you own or are explicitly authorized to test. Aimed at someone else's network, these options are evasion in the criminal sense, not the diagnostic one. Keep them inside your own perimeter or a signed engagement, and where the target is a shared box, use a sanctioned one like scanme.nmap.org, which Nmap maintains for exactly this purpose.

Fragmentation: -f and --mtu

The oldest trick in the book is packet fragmentation. -f splits the probe into tiny IP fragments (8 bytes of payload each), and --mtu lets you pick your own fragment size. The theory is that a simple packet filter inspecting only the first fragment - or one that does not reassemble at all - never sees the full TCP header and lets the pieces through. Here it is on the lab LAN, where nothing sits in the path to drop the fragments, and the SYN still gets its SYN/ACK back:

$ nmap -f --packet-trace -p 22 10.10.10.1
SENT (0.2116s) TCP 10.10.10.10:44682 > 10.10.10.1:22 S ttl=53 id=11425 iplen=44  seq=11120976 win=1024 <mss 1460>
RCVD (0.2153s) TCP 10.10.10.1:22 > 10.10.10.10:44682 SA ttl=255 id=33340 iplen=48  seq=4165816293 win=65535 <mss 1460,sackOK,eol,eol>
Nmap scan report for 10.10.10.1
Host is up (0.0031s latency).
PORT   STATE SERVICE
22/tcp open  ssh
MAC Address: AA:BB:CC:00:5B:00 (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 0.24 seconds

On a flat LAN, fragmentation is a no-op: the packet reaches the host and 22 reports open. Now push the same idea across the internet to scanme.nmap.org and the result flips in an instructive way:

$ nmap -sS -f -p22,80 scanme.nmap.org
Starting Nmap 7.95 ( https://nmap.org ) at 2026-07-05 15:06 PDT
Nmap scan report for scanme.nmap.org (45.33.32.156)
Host is up (0.021s latency).

PORT   STATE    SERVICE
22/tcp filtered ssh
80/tcp filtered http

Nmap done: 1 IP address (1 host up) scanned in 1.55 seconds

Both ports come back filtered - and 22 and 80 on scanme are demonstrably open when you scan them normally. Something in the internet path dropped the tiny fragments. That is not a failure of the scan; it is the honest, useful result. A device between you and the target chose to discard malformed fragmentation rather than reassemble and forward it, which is precisely the behaviour you would want your own edge firewall to exhibit. When you run -f against your perimeter and get filtered back, that is your control doing its job. When you get open, you have found a gap.

Decoys: -D

Decoy scanning makes your real probe hide in a crowd. With -D you list spoofed source addresses, and Nmap sends copies of each probe from those decoys interleaved with your real one, so the target's logs show a scan coming from a dozen places at once and cannot easily tell which source is the human. The packet trace shows how convincing it is - three SYNs, identical in every field that matters, sourced from a decoy, then the real host, then another decoy:

$ nmap -sS -D 10.10.10.66,10.10.10.77 --packet-trace -p 22 10.10.10.1
SENT (0.2450s) TCP 10.10.10.66:56346 > 10.10.10.1:22 S ttl=56 id=38942 iplen=44  seq=590558048 win=1024 <mss 1460>
SENT (0.2451s) TCP 10.10.10.10:56346 > 10.10.10.1:22 S ttl=59 id=38942 iplen=44  seq=590558048 win=1024 <mss 1460>
SENT (0.2452s) TCP 10.10.10.77:56346 > 10.10.10.1:22 S ttl=48 id=38942 iplen=44  seq=590558048 win=1024 <mss 1460>
RCVD (0.2489s) TCP 10.10.10.1:22 > 10.10.10.10:56346 SA ttl=255 id=64983 iplen=48  seq=3681349475 win=65535 <mss 1460,sackOK,eol,eol>
Nmap scan report for 10.10.10.1
Host is up (0.0038s latency).
PORT   STATE SERVICE
22/tcp open  ssh

The target replied only to the real address (.10), because only it has a return path, but the log now records SYNs from .66, .10, and .77 that all look equally legitimate. The scan itself is unaffected. Across the internet, -D RND:5 generates five random decoys and the scan still returns clean results:

$ nmap -sS -D RND:5 -p22,80 scanme.nmap.org
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 0.36 seconds

For a defender, decoys are a test of whether your alerting keys on the true source or gets diluted by noise. A good detection pipeline should correlate on the source that actually completes handshakes, not on raw SYN counts per address. Run a decoy scan against your own IDS and see whether it still fingers you or whether it drowns in the polluted log.

Source-port spoofing: --source-port

Some firewalls carry sloppy legacy rules that trust traffic from certain ports - port 53 (DNS) and port 80 (HTTP) are the classic offenders, allowed inbound because someone once needed replies to get back through a stateless filter. --source-port (or its short form -g) lets you set your probe's source port to abuse that trust:

$ nmap -sS --source-port 53 -p22,80 scanme.nmap.org
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 0.33 seconds

Sourcing from port 53 got the scan through cleanly. The reason this matters to you as a defender: if a probe from --source-port 53 reaches a service that a probe from a random high port could not, you have a rule that trusts a source port, which is a stateless-era mistake worth ripping out. This is a one-line test that finds a specific, common misconfiguration.

Timing as evasion

Every IDS has a rate threshold - a certain number of probes per second from one source before it fires an alert. Scan slowly enough and you slide under it. The -T templates control this directly. Here is an identical top-100-port scan run at two timing levels:

$ nmap -T4 -F 10.10.10.1
... 22/tcp open ssh ; 23/tcp open telnet ...
Nmap done: 1 IP address (1 host up) scanned in 1.37 seconds

$ nmap -T2 -F 10.10.10.1
Nmap scan report for 10.10.10.1
Host is up (0.0033s latency).
Not shown: 98 closed tcp ports (reset)
PORT   STATE SERVICE
22/tcp open  ssh
23/tcp open  telnet
MAC Address: AA:BB:CC:00:5B:00 (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 40.67 seconds

Same scan, same result, wildly different footprint: 1.37 seconds at -T4 versus 40.67 seconds at -T2. The slow version spreads the probes out so thinly that a rate-based detector may never accumulate enough events in its window to trip. That is the evasion, and it is also the test - point a slow scan at your own sensors and find out how patient an attacker has to be before your IDS stops noticing. For the full breakdown of the timing templates and what each one tunes, see Nmap timing and performance.

Other evasion knobs

Beyond the big four, Nmap gives you a grab-bag of lower-level manipulations. Each one targets a specific weakness in how a filter or sensor inspects traffic. Test them against your own stack to see which your controls catch.

The idle scan (-sI) deserves a word because it is the purest form of source concealment: Nmap infers port state entirely from changes in an idle third party's IP ID counter, so the target only ever sees the zombie, never you. It is fiddly to set up and needs a genuinely idle host, but conceptually it is the reason "the logs only showed one internal server scanning us" is not proof of who ran the scan. The full catalogue lives in the Nmap firewall and IDS evasion reference.

What a correctly configured firewall does

The flip side of all this is knowing what a healthy result looks like. A stateful firewall does not just drop tricks; it drops anything that is not part of an established session, and Nmap has a scan type that exposes exactly that. The ACK scan (-sA) is a firewall-mapping tool: it sends bare ACKs and watches whether they draw a RST (unfiltered) or nothing (filtered). Run through the lab's Cisco ASA, every port comes back filtered:

$ nmap -sA -p 22,23,80,443 10.10.20.32
PORT    STATE    SERVICE
22/tcp  filtered ssh
23/tcp  filtered telnet
80/tcp  filtered http
443/tcp filtered https
Nmap done: 1 IP address (1 host up) scanned in 1.35 seconds

All filtered is the correct answer. The ASA is stateful, so an ACK with no matching connection in its table gets silently dropped regardless of port - it never reaches the host to draw a RST. Contrast that with a normal SYN scan of the same DMZ target, which shows the firewall's actual policy through the noise:

$ nmap --reason -p 22,23,80,443 10.10.20.32
PORT    STATE    SERVICE REASON
22/tcp  open     ssh     syn-ack ttl 254
23/tcp  filtered telnet  no-response
80/tcp  closed   http    reset ttl 254
443/tcp filtered https   no-response
Nmap done: 1 IP address (1 host up) scanned in 1.36 seconds

That is a well-behaved firewall in one screen: 22 is open (permitted and a service is listening), 80 is closed (the firewall permits it but the host answered with a RST - nothing is serving there), and 23 and 443 are filtered (silently dropped, no-response, the deny rules doing their work). If your evasion tests against a perimeter like this keep returning filtered, your ASA is earning its keep. For the deep dive on that behaviour and how to configure it, see the Cisco ASA firewall guide, and for how ACK, FIN, and the other probes differ, the Nmap scan types reference.

The defender's checklist

Turn every technique above into a control test you run on a schedule:

• Fragmentation: your edge should return filtered for -f and --mtu probes. If a fragmented SYN reaches an internal host, your firewall is not reassembling.
• Decoys: your IDS alert should still name the real source after a -D run. If the signal drowns in the decoys, tune your correlation.
• Source-port trust: a probe from --source-port 53 or -g 80 must not reach anything a random high port cannot. If it does, delete the legacy rule.
• Timing: know the slowest scan your IDS still catches. If -T2 or -T1 slips by, your rate window is too tight.
• Stateful baseline: an -sA ACK scan through your firewall should come back all filtered. Anything unfiltered means non-established traffic is passing.

Key takeaways

Nmap's evasion options are only "attacker tools" if you point them at someone else's network. Pointed at your own perimeter, they are the fastest honest test you have of whether your firewall and IDS do what you configured them to do. Fragmentation getting dropped in transit, decoys that fail to hide the real source, a source-port-53 probe that goes nowhere, a slow scan your sensor still catches, and an ACK scan that comes back all filtered are all wins - they are your controls being verified rather than assumed. Run these on a schedule, keep them strictly inside systems you own or are authorized to test, and read every result as a statement about your defences. To see how these probes relate to the underlying scan mechanics, work through the scan types and timing and performance guides, tune the firewall itself with the Cisco ASA guide, and keep the complete Nmap guide as your map of the whole toolkit.