Why Default Nmap Scans Fail in Production
A default nmap target runs a SYN scan against the top 1,000 ports with timing template -T3, sending dozens of packets per second. Firewalls see a single source IP opening connections to sequential ports within milliseconds, a pattern that matches every SYN flood signature. Stateful firewalls track the half-open connections; rate limiters drop packets once you exceed thresholds; fail2ban or similar tools blacklist your IP after a few dozen attempts.
Snort and Suricata have built-in rules for nmap fingerprints. A SYN scan to 1,000 ports generates logs like this on the target's IDS:
01/15-14:22:31.445203 [**] [1:469:3] SCAN nmap XMAS [**] 192.0.2.50:12345 -> 198.51.100.10:80
01/15-14:22:31.512847 [**] [1:1228:8] SCAN nmap TCP [**] 192.0.2.50 -> 198.51.100.10
The firewall either drops your packets silently or sends ICMP unreachables, and you see thousands of filtered ports in nmap's output with no useful data. Modern defensive stacks combine signature detection with rate limits; you hit both within seconds. If the scan continues, connection logs show RST storms as the firewall tears down your half-open sockets, and your IP ends up on a blocklist before you finish the first 200 ports.
Choosing the Right Scan Type for Firewalls
Different scan types leave different footprints. The default -sS SYN scan requires root and sends a SYN packet, waits for SYN-ACK (port open) or RST (port closed), then sends RST to tear down the connection without completing the handshake. It is faster and generates fewer logs than a full connect scan, but stateful firewalls still track the half-open socket. A full connect scan with -sT completes the three-way handshake, which means it appears in application logs and takes longer, but it works without root privileges and on systems where raw sockets are restricted.
SYN Scan vs Connect Scan in Stateful Environments
Use -sS when you have root and the firewall is stateless or you are scanning from a trusted segment. Use -sT when raw sockets are unavailable or when blending into normal application traffic matters more than speed. A SYN scan to port 443 looks like this:
nmap -sS -p 443 198.51.100.10
You see open, closed, or filtered in the output. A stateful firewall that allows established connections but blocks new SYN packets will show filtered for both open and closed ports behind it. The -sT scan generates more noise but can sometimes pass through stateful rules that permit outbound-initiated connections.
ACK and Window Scans for Firewall Rule Mapping
An ACK scan with -sA does not determine if a port is open; it maps firewall rules. It sends a packet with the ACK flag set. If the firewall drops it, nmap reports filtered. If the packet reaches the host, the host sends RST (because there is no established connection), and nmap reports unfiltered. This tells you which ports the firewall blocks versus which it allows through to the host:
nmap -sA -p 22,80,443,8080 198.51.100.10
Output might show ports 22 and 8080 as filtered and 80, 443 as unfiltered, meaning the firewall has rules blocking the first two. A window scan -sW is similar but examines the TCP window size in RST responses; some systems report a positive window for open ports even when responding with RST. It works on older BSD and some Linux kernels but fails on modern Windows.
When to Use NULL, FIN, and Xmas Scans
NULL (-sN), FIN (-sF), and Xmas (-sX) scans send packets with unusual flag combinations that can slip past stateless firewalls or simple packet filters that only check for SYN. A NULL scan sends a packet with no flags; FIN sets only the FIN flag; Xmas sets FIN, PSH, and URG. According to RFC 793, a closed port should respond with RST, and an open port should ignore the packet. If you see no response, the port is open or filtered:
nmap -sN -p 1-1000 198.51.100.10
These scans fail on Windows, which sends RST for all ports regardless of state. They work on many Linux and Unix systems, but modern stateful firewalls track connection state and drop packets that do not belong to an established flow. Use them when you suspect an older stateless firewall or ACL that only filters SYN packets. For detailed explanations of each scan type, see the nmap port scanning techniques documentation.
Timing and Rate-Limiting Your Scans
Nmap's timing templates range from -T0 (paranoid) to -T5 (insane). The default -T3 sends packets quickly enough to finish a 1,000-port scan in under a minute on a responsive host, but that speed triggers rate limits and IDS signatures. Template -T2 (polite) waits 0.4 seconds between probes; -T1 (sneaky) waits 15 seconds; -T0 waits 5 minutes between each packet. In production, -T2 or -T1 keeps you under most firewall rate thresholds:
nmap -sS -T1 -p 1-1000 198.51.100.10
This scan takes 4-5 hours for 1,000 ports but generates a steady trickle of packets that blends into background traffic. IDS engines key on packet rate; a burst of 50 SYN packets in two seconds flags as a scan, but one packet every 15 seconds looks like slow application polling. If you scan a range of hosts, add --randomize-hosts to avoid sequential IP patterns that also trigger detection.
The -T Templates and When to Go Slower
Each template sets multiple timing parameters: initial RTT timeout, maximum retries, host group size, scan delay. -T3 has no forced delay between probes; -T2 adds 0.4 seconds; -T1 adds 15 seconds; -T0 adds 5 minutes. Lower templates also reduce parallelism, scanning fewer hosts and ports simultaneously. Use -T2 for general production scans where you have hours but not days. Use -T1 when you know the firewall has strict rate limits or the IDS is tuned aggressively. Use -T0 only for high-security targets where any anomaly triggers investigation.
Custom Timing with --scan-delay and --max-rate
For finer control, set --scan-delay and --max-rate directly. A delay of 1 second between probes combined with a maximum rate of 10 packets per second keeps the scan under most thresholds:
nmap -sS -p 1-65535 --scan-delay 1s --max-rate 10 198.51.100.10
This scan of all 65,535 ports takes about 110 minutes but avoids the bursts that trigger alerts. In one real scenario, a -T3 scan of a /24 network finished in 8 minutes but triggered firewall blocks on 18 of 24 hosts, yielding partial results. The same scan with -T1 --max-rate 5 took 42 minutes and completed all hosts without a single alert in the IDS logs. The tradeoff is time, but incomplete data from a blocked scan is worthless.
Fragmenting Packets to Evade Simple Filters
Packet fragmentation splits IP packets into smaller pieces, each carrying a fragment of the original payload. Some older intrusion detection systems inspect each fragment independently and cannot reassemble them to analyze the complete packet, so a fragmented scan slips past their signatures. Nmap offers -f to fragment packets into 8-byte chunks after the IP header, -ff for 16-byte chunks, and --mtu to set a custom maximum transmission unit for fragment size:
nmap -sS -f 198.51.100.10
This SYN scan splits each probe into multiple fragments. A packet that would normally be 40 bytes (20-byte IP header, 20-byte TCP header) becomes several fragments of 8 bytes plus overhead. In tcpdump on the target, you see fragments instead of complete packets:
14:35:12.334455 IP 192.0.2.50 > 198.51.100.10: frag (0|8)
14:35:12.334502 IP 192.0.2.50 > 198.51.100.10: frag (8|8)
14:35:12.334548 IP 192.0.2.50 > 198.51.100.10: frag (16|16)
Without -f, you see the complete SYN packet with flags and port numbers visible. Fragmentation obscures this until reassembly.
Using -f and --mtu for IP Fragmentation
The -f flag uses 8-byte fragments, which maximizes the number of pieces and the effort required for reassembly. Use -ff for 16-byte fragments if you want slightly less overhead. For precise control, --mtu sets the fragment size to a multiple of 8 bytes:
nmap -sS --mtu 24 198.51.100.10
This creates fragments of 24 bytes. Smaller fragments mean more pieces and more processing for reassembly; larger fragments reduce overhead but make reassembly easier. You can combine fragmentation with --data-length to append random bytes to each probe, changing the packet size and making it less recognizable as stock nmap traffic:
nmap -sS -f --data-length 24 198.51.100.10
This adds 24 bytes of random data to each packet after fragmentation. The target sees packets that do not match standard nmap packet lengths, which can evade length-based signatures. For background on fragmentation mechanics, see Network Security Basics.
What Fragmentation Defeats and What It Doesn't
Fragmentation works against simple stateless packet filters and older IDS engines that inspect fragments in isolation. It fails against modern stateful firewalls and intrusion prevention systems that reassemble fragments before applying rules or signatures. Linux netfilter, for example, reassembles fragments in the PREROUTING chain before iptables rules see them, so a fragmented scan looks identical to a normal scan after reassembly. Cisco ASA, Palo Alto, and Fortinet firewalls all reassemble by default.
Fragmentation also increases the chance of packet loss; each fragment must arrive for reassembly to succeed, and losing any fragment discards the entire packet. In high-latency or lossy networks, fragmented scans produce more filtered results than unfragmented scans. Use fragmentation when you know the target has legacy filtering or when combined with other evasion techniques like timing delays and decoys; alone, it is weak against current defensive stacks.
Decoys and Spoofing Source Information
Decoy scanning sends probes from multiple spoofed source IP addresses alongside your real IP, making it harder for defenders to identify which host is actually scanning. Nmap generates the decoy traffic, but only your real IP receives responses, so you still get complete scan results while the target logs show scans from many sources. Use -D with a comma-separated list of IPs or RND: followed by a count for random decoys:
nmap -sS -D RND:5 198.51.100.10
This scan appears to come from your IP plus five randomly chosen decoy IPs. The target's firewall logs show six source addresses scanning simultaneously. If you want control over which decoy IPs appear, list them explicitly and include ME to specify where your real IP appears in the sequence:
nmap -sS -D 192.0.2.100,192.0.2.101,ME,192.0.2.102 198.51.100.10
Your real IP is the third in the list. Responses only come to your IP; the decoys receive nothing because they did not actually send the packets. Choose decoy IPs that are plausible for the network segment you are scanning; using IPs from a different subnet or known-offline addresses makes the decoys obvious. If the decoy IPs are real hosts on the same network, those hosts may see RST or ICMP responses from the target and log anomalies, potentially triggering alerts on multiple systems instead of just yours.
Decoy Scans with -D to Hide Your Real IP
Decoy scans complicate forensic analysis. An IDS analyst reviewing logs sees scans from six IPs and must determine which is the real attacker. If you randomize decoys across multiple scans, correlation becomes harder. However, decoys increase the packet rate by the number of decoys plus one; a scan with five decoys sends six times the traffic, which can exceed rate limits faster than a single-source scan. Combine decoys with slower timing templates to stay under thresholds:
nmap -sS -D RND:3 -T2 198.51.100.10
This uses three decoys with polite timing, spreading the traffic over a longer period. Decoy scans also fail if the network uses ingress filtering (BCP 38) that drops packets with source IPs not valid for the ingress interface; this is common at ISP borders but rare inside enterprise networks.
Warning: Using decoy IPs that belong to real hosts can cause those hosts to receive unexpected traffic or alerts. Choose unused IPs from the same subnet or use
RNDand accept that some random IPs may be live.
Source Port Manipulation with -g
Some firewalls permit traffic from specific source ports under the assumption that responses to DNS queries (source port 53) or HTTP requests (source port 80) are legitimate. The -g or --source-port flag forces nmap to send packets from a chosen source port:
nmap -sS -g 53 198.51.100.10
This scan sends SYN packets with source port 53. If the firewall allows replies to port 53 without stateful inspection, your probes pass through and you receive responses. Port 53 and 80 are common choices; some firewalls also trust port 88 (Kerberos) or 123 (NTP). Test this by comparing results with and without -g; if you see more open ports with -g 53, the firewall is filtering based on source port. This technique fails on stateful firewalls that track the full connection tuple (source IP, source port, destination IP, destination port, protocol) and verify that responses match initiated connections.
Spoofing the source IP entirely with -S requires raw socket access and routing that allows spoofed packets to leave your network. In most production environments, egress filtering drops packets with source IPs that do not match your subnet, so -S is only useful on local segments or in lab environments. Stick with decoys and source port manipulation for real production scans.
Disabling and Customizing Host Discovery
By default, nmap performs host discovery before scanning ports: it sends ICMP echo requests, TCP SYN to port 443, TCP ACK to port 80, and an ICMP timestamp request. If a host does not respond to any of these probes, nmap marks it as down and skips port scanning. In production networks where ICMP is blocked or hosts are configured not to respond to pings, this default discovery causes nmap to skip live hosts. The -Pn flag disables host discovery and assumes all specified IPs are up:
nmap -Pn -sS -p 22,80,443 198.51.100.0/24
This scans all 256 IPs in the subnet for ports 22, 80, and 443 without sending any ping probes first. You see results for every IP, though hosts that are genuinely offline show all ports as filtered or no response. Use -Pn when you know ICMP is blocked or when scanning a small range where the overhead of probing offline IPs is acceptable. For more on host discovery options, consult the nmap host discovery documentation.
Skipping Ping with -Pn When ICMP Is Blocked
When you run a default scan on a network that blocks ICMP, nmap output shows most hosts as down:
nmap -sS 198.51.100.0/24
Nmap scan report for 198.51.100.1
Host is up (0.0012s latency).
Nmap scan report for 198.51.100.2
Host is down.
Nmap scan report for 198.51.100.3
Host is down.
With -Pn, every host is treated as up and you get port scan results for all of them. The tradeoff is time; scanning 256 IPs with closed or filtered ports takes longer than skipping them after a failed ping. Combine -Pn with a targeted port list to limit the overhead.
Custom Ping Probes: -PS, -PA, -PU
If you want discovery but ICMP is blocked, customize the probes nmap uses. The -PS flag sends TCP SYN packets to specified ports for discovery; -PA sends TCP ACK packets; -PU sends UDP packets. For example, if you know the target network runs SSH on port 22 and HTTPS on port 443, send SYN pings to those ports:
nmap -PS22,443 -sS 198.51.100.0/24
Nmap sends SYN to ports 22 and 443 on each IP. If the port is open, the host responds with SYN-ACK (nmap marks the host up). If the port is closed, the host responds with RST (still marks the host up because it responded). If the host is down or firewalled, no response arrives and nmap marks it down. This is more reliable than ICMP in environments where SSH and HTTPS are permitted but ICMP is dropped.
Use -PA when the firewall allows established traffic (ACK packets) but blocks new SYN packets during discovery. An ACK probe to port 80 looks like part of an existing HTTP connection:
nmap -PA80 -sS 198.51.100.0/24
If the firewall permits ACK packets, hosts respond with RST and nmap discovers them. Use -PU for UDP services; a UDP packet to a closed port typically triggers an ICMP port unreachable response, confirming the host is up:
nmap -PU53,161 -sS 198.51.100.0/24
This sends UDP probes to DNS (53) and SNMP (161). If you want to avoid ARP requests on a local subnet, add --disable-arp-ping; nmap will skip ARP discovery and rely only on the higher-layer probes you specify. This is useful when you want to test how the network layer responds without involving layer 2.
NSE Scripts and Signature Reduction
The -A flag (aggressive scan) runs OS detection, version detection, script scanning, and traceroute; -sC runs nmap's default script set. Both are extremely noisy. The default NSE scripts include vulnerability checks, brute-force attempts, and banner-grabbing that send dozens of recognizable probes. An IDS watching HTTP traffic sees user-agent strings like Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html) and flags it immediately. Running -A on a production web server triggers alerts for SQL injection tests, directory traversal attempts, and known exploit probes within seconds.
Use --script= with specific script names or categories to run only what you need. For basic service identification, --script=banner grabs banners without running vulnerability checks:
nmap -sS --script=banner -p 22,80,443 198.51.100.10
This retrieves SSH and HTTP banners without launching brute-force or exploit scripts. To see what a category or script does before running it, use nmap --script-help <category>:
nmap --script-help vuln
This lists all scripts in the vuln category with descriptions. You see scripts like http-vuln-cve2017-5638 that test for specific CVEs. Running the entire vuln category against a production system generates hundreds of requests and almost certainly triggers alerts. Pick individual scripts: --script=ssl-cert,ssh-hostkey retrieves certificates and host keys without active exploitation attempts.
Selective Script Use to Avoid Fingerprinting
Version detection with -sV sends a series of probes to each open port, trying to match responses against nmap's signature database. The default --version-intensity is 7, which sends many probes per port. Reduce intensity to 2 or 3 for lighter detection:
nmap -sS -sV --version-intensity 2 -p 80,443 198.51.100.10
Intensity 2 sends only the most common probes; you get fewer matches but generate far less traffic. Intensity 0 sends no probes (version detection is effectively disabled); intensity 9 sends every probe nmap has. For production scans, intensity 3 balances detection rate and noise. The output shows version information for services that respond to the reduced probe set; others appear as open without version details.
Custom User-Agent and Version Detection Flags
HTTP-related NSE scripts send requests with nmap's default user-agent string, which appears in web server logs and is trivial to filter. Change it with --script-args:
nmap -sS --script=http-title --script-args http.useragent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" 198.51.100.10
The target's web server logs now show a standard browser user-agent instead of the nmap string. Combine this with selective scripts and reduced version intensity for a scan that blends into normal traffic:
nmap -sS -sV --version-intensity 3 --script=banner --script-args http.useragent="Mozilla/5.0 (X11; Linux x86_64)" 198.51.100.10
This command runs a SYN scan, performs light version detection, grabs banners, and sends HTTP requests with a Linux Firefox user-agent. The IDS sees what looks like a slow browser session rather than an nmap scan. For a deeper understanding of NSE capabilities, see Nmap Cheat Sheet: The Complete Network Scanning Reference for 2026.
Verifying What the Target Sees
The only way to know if your evasion techniques work is to check what the target's defenses record. Run a scan, then examine firewall logs, IDS alerts, and packet captures on the target side. If you see your source IP, scan signatures, or rate-limit triggers, adjust your technique and scan again. This feedback loop turns guesswork into a repeatable process.
On the target system, run tcpdump to capture packets from your scanning IP:
tcpdump -i eth0 -n host 192.0.2.50
Replace 192.0.2.50 with your scanner's IP and eth0 with the target's interface. You see every packet that arrives: SYN, ACK, RST, ICMP, fragments. Look for timing patterns, source ports, and fragmentation. A -T3 scan shows bursts of SYN packets milliseconds apart:
14:42:10.123456 IP 192.0.2.50.54321 > 198.51.100.10.22: Flags [S], seq 123456789
14:42:10.125678 IP 192.0.2.50.54322 > 198.51.100.10.80: Flags [S], seq 987654321
14:42:10.127890 IP 192.0.2.50.54323 > 198.51.100.10.443: Flags [S], seq 112233445
A -T1 scan shows packets 15 seconds apart. If you used -f, you see fragmented packets instead of complete TCP headers. If you used -g 53, the source port is 53 on every packet. This direct observation tells you exactly what defenses see, independent of what nmap reports.
Running tcpdump on the Target Side
Save the capture to a file for analysis in Wireshark:
tcpdump -i eth0 -n host 192.0.2.50 -w scan.pcap
After the scan finishes, open scan.pcap in Wireshark and filter by tcp.flags.syn==1 to see all SYN packets. Check the time delta between packets (right-click a packet, choose "Set/Unset Time Reference", then view the "Time" column for subsequent packets). If deltas are under 0.1 seconds, your timing was too aggressive for stealth. Check IP identification numbers; sequential IDs indicate packets from the same source, while randomized IDs (from decoys or fragmentation) show more variation.
Fragmented packets appear with "Fragment" in the Info column. Right-click one and choose "Follow > UDP Stream" or "Follow > TCP Stream" to see if Wireshark can reassemble them. If Wireshark reassembles successfully, a modern stateful firewall will too, meaning fragmentation provided no evasion benefit against that target.
Checking IDS Logs and Adjusting Technique
If the target runs Suricata or Snort, check /var/log/suricata/fast.log or the equivalent Snort alert log for your IP:
grep 192.0.2.50 /var/log/suricata/fast.log
You see alerts like:
01/15-15:10:42.556789 [**] [1:2100498:7] GPL SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.0.2.50:12345 -> 198.51.100.10:80
This signature fired because you used -sX (Xmas scan). Switch to -sS and the signature does not match. If you see "ET SCAN Potential SSH Scan" after a -T3 scan of port 22 across a subnet, slow down to -T2 --max-rate 3 and run again. Check the logs; if the signature no longer appears, you found the threshold. In one real case, a security team scanned their own infrastructure with -T3 and saw 47 IDS alerts. They re-scanned with -T2 --scan-delay 2s and saw zero alerts while still completing the scan in under two hours.
If you cannot access the target's logs, set up a test system with Suricata and the ET Open ruleset, then scan it with your planned technique. The alerts you see on the test system will match what a production IDS sees. This lets you iterate on evasion techniques in a safe environment before touching production. For configuring IDS rules and testing, Firewall Configuration: The Complete Guide covers both firewall and IDS integration in depth.
Building a Reusable Production Scan Checklist
Create a standard procedure for production scans to avoid repeating trial-and-error every time. Start with a conservative baseline: -sS -T2 -Pn --max-rate 5 for general port scans, -sV --version-intensity 3 for version detection, and --script=banner instead of -sC. Test this on a non-critical host first, check IDS logs, and adjust timing or fragmentation if needed. Document what works for each network segment; an internal server VLAN may tolerate -T3, while a DMZ with aggressive IPS requires -T1.
For recurring audits, script your scans with consistent flags and output formats. Save results to XML with -oX so you can diff them over time:
nmap -sS -T2 -p 1-65535 --max-rate 10 -oX scan-$(date +%F).xml 198.51.100.0/24
Compare this month's scan to last month's to identify new open ports or services. Use ndiff (included with nmap) to automate comparison:
ndiff scan-2026-01-15.xml scan-2026-02-15.xml
This shows added, removed, and changed ports. For teams managing scans across many networks, Ansible Automation: From Zero to Production demonstrates how to orchestrate nmap scans with playbooks, collect results centrally, and integrate with ticketing systems for change tracking.
Always coordinate with the security and network operations teams before scanning production. Even stealthy scans can cause issues if they coincide with maintenance windows or trigger automated responses you are unaware of. A checklist should include: authorization documented, IDS team notified, scan window agreed, baseline technique tested, post-scan log review scheduled. This turns ad-hoc scanning into a controlled, repeatable process that produces reliable data without surprises.
Frequently Asked Questions
Is it legal to use nmap evasion techniques in production?
Evasion techniques are legal when you have explicit written authorization to scan the target network, such as during a contracted security audit or internal vulnerability assessment. Unauthorized scanning, even with evasion, violates the Computer Fraud and Abuse Act in the US and similar laws elsewhere. Always obtain permission from the network owner, document the scope and timing, and notify relevant teams. Using evasion on your own infrastructure for testing defenses is legal and recommended.
Which nmap scan type is hardest for IDS to detect?
No single scan type is universally hardest to detect; it depends on the IDS configuration. Against signature-based IDS, a slow SYN scan with -sS -T1 --max-rate 3 avoids rate-based signatures. Against stateful IDS, a connect scan -sT that completes handshakes blends into normal traffic better than half-open scans. NULL, FIN, and Xmas scans evade some stateless filters but have well-known signatures in modern rulesets. Combine slow timing, randomized decoys, and selective scripts for the best chance of staying under thresholds.
How do I avoid getting my IP blacklisted during a security audit?
Use slow timing templates (-T2 or -T1), limit packet rate with --max-rate, and scan during agreed maintenance windows when rate-limit thresholds may be relaxed. Whitelist your scanning IP in the firewall and IPS beforehand if possible. Scan from a dedicated IP that can be blocked without affecting other services, and monitor IDS logs during the scan to catch blocks early. If you get blacklisted, coordinate with the firewall team to remove the block and adjust your technique before resuming.
What is the difference between -sS and -sT scans?
A SYN scan (-sS) sends a SYN packet, waits for SYN-ACK or RST, then sends RST to abort the handshake without completing it. It requires root privileges and raw socket access. A connect scan (-sT) uses the operating system's connect() call to complete the full three-way handshake, which works without root but generates more logs and takes longer. Use -sS for speed and lower log footprint when you have root; use -sT when raw sockets are unavailable or when blending into application traffic matters more.
Can firewalls detect nmap fragmentation and decoy scans?
Modern stateful firewalls reassemble IP fragments before applying rules, so fragmentation offers no evasion against them. Decoy scans are visible in firewall logs as multiple source IPs scanning simultaneously, which may actually increase suspicion if the decoy IPs are implausible. Some firewalls correlate scans from multiple sources and flag coordinated activity. Fragmentation works against legacy stateless packet filters; decoys work when the goal is to obscure your real IP in a large volume of alerts. Neither technique is reliable against current enterprise firewalls or IPS with default configurations.
