This walkthrough confirms an uncomfortable truth for defenders: flag-based firewall rules age poorly because Nmap supplies enough scan variants to circumvent any single combination. Length-based filtering scales better, but it remains a reactive control that an attacker can defeat through fragmentation or custom payloads. Effective network defence, therefore, demands layered controls — stateful inspection, intrusion detection signatures, rate limiting, and host-based monitoring — rather than reliance on iptables alone. For penetration testers, the lessons are equally clear: vary your scan techniques, observe how the target responds at the packet level, and let the defender’s rule choices guide your next probe.

Introduction

Firewalls remain the first line of defence against network reconnaissance, yet attackers continue to refine techniques that slip past static rule sets. This article walks the reader through the complete arc of a reconnaissance battle between an Nmap-equipped attacker and a defender wielding iptables. Each scan technique exposes a new packet attribute that the defender can match on, and each new firewall rule prompts the attacker to craft probes that evade it. By the end of the walkthrough, virtually every attribute that iptables can inspect — TCP flags, packet length, Time-To-Live, source port, source MAC, source IP, payload bytes, and TCP options — has been challenged and defeated by a one-line Nmap argument.

The exercise serves two communities. For penetration testers, it provides a structured methodology for probing unfamiliar firewalls, reading their behaviour as a fingerprint of the rules they enforce, and selecting the next probe that targets exactly that rule. For defenders, it demonstrates why static rule-by-rule filtering ultimately fails and why robust security must combine stateful inspection, anomaly detection, behavioural analytics, and layered controls rather than rely on iptables alone. Every probe in the walkthrough is captured in Wireshark, allowing the reader to observe the byte-level behaviour that determines whether each scan succeeds or fails.

Table of Contents

• Introduction
• Lab Environment
• Understanding Nmap scan signatures
• The Baseline: TCP Connect Scan (-sT)
• Blocking the SYN Probe at the Firewall
• FIN Scan (-sF)
• NULL Scan (-sN)
• XMAS Scan (-sX)
• Hardening Against FIN Scans
  • Reject Data-length with IPTables
  • Bypassing the Length Filter with a SYN Scan
• Fragment Scan
  • Closing the Common Length Signatures
  • Verifying the Defence: All Standard Scans Blocked
  • Data Length Scan
• TTL Scan
• Strengthening Security: Blocking TTL 64 and Below
• Source Port Spoofing Scan
• Decoy Scan
• Hiding in the Crowd: Decoy Scanning
• Spoof MAC Address Scan
• Spoof IP Address Scan
• Data-String Scan
• Hex String Scan
• IP-Options Scan
• Mitigation Strategies
  • Adopt Stateful Inspection
  • Deploy Intrusion Detection and Prevention Systems
  • Apply Rate Limiting and Connection Throttling
  • Avoid Relying on Spoofable Headers for Authentication
  • Implement Centralised Logging and Correlation
  • Block Fragmentation and Anomalous Packets
  • Practise Network Segmentation and Least Privilege
  • Maintain Patching and Configuration Hygiene
  • Conduct Regular Penetration Testing
• Final Analysis

Lab Environment

The lab consists of two virtual machines on the 192.168.1.0/24 segment. The attacker runs Kali Linux at 192.168.1.17 with Nmap 7.99, while the target runs Ubuntu at 192.168.1.5 and exposes an SSH service on port 22 (and HTTP on port 80 in later sections). The Ubuntu host also acts as the iptables firewall, with rules added or modified throughout the walkthrough as the defender reacts to each new evasion technique. Wireshark captures every probe from the attacker side using the display filter “ip.addr == 192.168.1.5”, which isolates the relevant traffic and exposes the precise packet structure produced by each Nmap scan mode.

Understanding Nmap scan signatures

The following image maps three diagnostic fields—TCP flags, data length, and TTL—across five Nmap scan modes, revealing exactly how each leaks its identity to an IDS.

-sT (TCP connect): Flags follow a textbook handshake (SYN → SYN,ACK → ACK, then RST,ACK teardown). Data length is 60 bytes because the OS kernel attaches full options: MSS, window scale, timestamp, SACK permitted. TTL is the native 64—no Nmap fingerprint, but every connection hits application logs.

-sS (Stealth SYN): Flags abort mid-handshake (SYN → SYN,ACK → RST), never completing. Data length drops to 44 bytes since Nmap’s raw socket includes only MSS, omitting the three options a kernel-built SYN always carries. TTL is below 64, often randomized—a non-default outbound TTL alone is suspicious to tuned sensors.

-sF (FIN): Flag is a lone FIN with no prior session, illegal per RFC 793; open ports stay silent, closed ports reply RST. Data length collapses to 40 bytes—20B IP plus 20B TCP, zero options. TTL is sub-64, custom-set. This trio is an immediate IDS hit.

-sN (Null): Flag field is completely empty—zero control bits, something no legitimate stack emits. Data length 40 bytes, identical raw template. TTL sub-64. Length 40 plus no flags plus odd TTL is a signature signed by Nmap.

-sX (Xmas): Flags FIN, PSH, URG illuminated together—impossible on a real opening packet. Data length 40 bytes, TTL sub-64; the most recognizable signature in the wild.

Together, these three fields convert Nmap probes into self-labeling traffic—signature gold for IDS engines worldwide.

The Baseline: TCP Connect Scan (-sT)

A TCP Connect scan completes the full three-way handshake by invoking the operating system’s connect() system call. It produces the most reliable result because it uses the same code path as any normal client application, but it is also the noisiest scan available in Nmap. This scan is activated through the following command:

nmap -sT -p 22 192.168.1.5

Nmap reports port 22/tcp as open with the SSH service identified, confirming that no filtering currently exists between the two hosts.

The image below shows the corresponding network traffic of the scan in Wireshark. The exchange contains a SYN, a SYN-ACK, and a final ACK followed by RST-ACK, which proves that the kernel completed a real connection before tearing it down. Two fingerprintable values stand out in the IPv4 header: a Total Length of 60 bytes and a Time-To-Live of 64. These attributes will become important when we move to length-based and TTL-based filtering later in the article.

Blocking the SYN Probe at the Firewall

Because every TCP-based scan begins with a SYN flag (including the connect scan), an obvious defensive move is to drop or reject any incoming packet that carries only the SYN bit. The iptables rule below performs exactly that, replying with a TCP reset so the attacker sees a “closed” state rather than silence.

iptables -I INPUT -p tcp --tcp-flags ALL SYN -j REJECT --reject-with tcp-reset

Nmap ships several scan modes that never set the SYN flag. These so-called stealth scans rely on RFC 793 behaviour: a closed port must reply with RST to any unsolicited packet, while an open port must silently drop it. The attacker therefore infers port state from the absence of a reply.

FIN Scan (-sF)

The following command demonstrates the FIN scan returning a state of open|filtered. Because the probe carries only the FIN flag, the SYN-blocking rule never triggers, and Nmap receives no reply from the open SSH port — the textbook indicator of an open or filtered service.

nmap -sF -p 22 192.168.1.5

The following image reveals what travels on Wireshark. Wireshark labels the frames as [FIN] with no other flags set. The IPv4 Total Length drops to 40 bytes (a bare 20-byte IP header plus a 20-byte TCP header with no options), and the TTL of 37 reflects the smaller hop budget Nmap selects for raw probes.

NULL Scan (-sN)

The following NULL scan. The probe contains no flags whatsoever, which violates RFC 793 and forces compliant TCP stacks to drop it silently when the port is open. The result, identical to the FIN scan, is open|filtered.

nmap -sN -p 22 192.168.1.5

The following image of Wireshark confirms the empty flag field. Wireshark renders the Info column as “[<None>]”, and the Total Length again sits at 40 bytes — the same minimal footprint produced by the FIN scan.

XMAS Scan (-sX)

The following scan captures the XMAS scan, so named because it lights up the TCP header like a Christmas tree by setting the FIN, PSH, and URG flags simultaneously. The SYN-blocking rule once again does nothing, and Nmap reports open|filtered.

nmap -sX -p 22 192.168.1.5

The following image verifies the unusual flag combination on the wire. Despite the additional flags, the IPv4 Total Length stays at 40 bytes because the TCP options field remains empty.

Hardening Against FIN Scans

The defender now extends the rule set to drop any packet whose only flag is FIN. This single addition immediately defeats the FIN scan, but a closer look reveals an interesting blind spot.

iptables -I INPUT -p tcp --tcp-flags ALL FIN -j REJECT --reject-with tcp-reset

The image below confirms that the FIN scan now returns closed because the rule injects a TCP reset back to the attacker. Nmap interprets the RST as evidence of a closed port.

The next scan exposes the limitation of flag-specific rules. The NULL scan (no flags) and the XMAS scan (FIN+PSH+URG) both fail to match the rule, which insists on FIN alone. Both scans continue to report open|filtered, demonstrating that flag-by-flag filtering quickly becomes an unwinnable game of whack-a-mole.

Reject  Data-length with IPTables

Rather than chase every possible flag combination, the defender exploits a structural property of Nmap probes — they all produce IPv4 packets with very predictable total lengths. The TCP Connect scan emits 60-byte packets (because the OS adds TCP options), while raw stealth scans emit 40-byte packets. Iptables can match on length directly using the “length” module.

The following command shows the defender clearing the chain to start from a clean state.

iptables -F

Now we will use the following command to install the first length-based rule that is any inbound TCP packet whose IPv4 Total Length is exactly 60 bytes — the signature of a TCP Connect scan — is now rejected.

iptables -I INPUT -p tcp -m length --length 60 -j REJECT --reject-with tcp-reset

The following scan will verify that the rule works and now returns closed, exactly as the defender intended.

nmap -sT -p 22 192.168.1.5

Bypassing the Length Filter with a SYN Scan

The 60-byte rule defeats the connect scan, but the half-open SYN scan produces a slightly different packet. Nmap crafts SYN probes with fewer TCP options, yielding a smaller packet that slips beneath the rule.

The following scan demonstrates that the length-60 rule has no effect because the SYN scan produces a different packet size.

nmap -sS -p 22 192.168.1.5

The Wireshark capture reveals an IPv4 Total Length of 44 bytes for the SYN probe — Nmap appends only one TCP option (the Maximum Segment Size, 4 bytes) instead of the full set used by the kernel. The defender’s length-60 filter never matches.

Fragment Scan

Nmap’s -f flag instructs it to fragment probe packets into 8-byte pieces, distributing the TCP header across multiple IP fragments. Each fragment carries its own IP header but only a slice of the TCP header, dramatically reducing per-packet length.

The following command shows reporting port 22 as open. The fragmented probes evade any length-based rule that targets full-sized packets.

nmap -f -p 22 192.168.1.5

The following captures two “Fragmented IP protocol” packets followed by the resulting TCP exchange. Each fragment carries an IPv4 Total Length of only 28 bytes (a 20-byte IP header plus 8 bytes of TCP payload), and the More Fragments flag is set, indicating that additional fragments will follow.

Closing the Common Length Signatures

A robust length-based defence must therefore block multiple sizes simultaneously. The defender combines three rules to cover the most common Nmap signatures.

The following commands show the layered rule set: length 60 blocks the connect scan, length 44 blocks the SYN scan, and length 40 blocks every raw stealth scan (FIN, NULL, XMAS). Together, these three rules cover the dominant footprint of standard Nmap probes, although a determined attacker can still evade them by adjusting the data payload or by chaining fragmentation with custom MTU values.

iptables -I INPUT -p tcp -m length --length 60 -j REJECT --reject-with tcp-reset
iptables -I INPUT -p tcp -m length --length 44 -j REJECT --reject-with tcp-reset
iptables -I INPUT -p tcp -m length --length 40 -j REJECT --reject-with tcp-reset

Verifying the Defence: All Standard Scans Blocked

Before introducing new evasion techniques, the attacker confirms that every conventional scan now fails against the previously installed layered length filter. The following scans capture five consecutive scans from the Kali host. The TCP Connect, SYN, FIN, NULL, and XMAS scans each return “closed” because their characteristic packet sizes (60, 44, and 40 bytes) match the existing iptables rules. The defender appears to have won — but only against the default Nmap behaviour. The commands for the said scans are:

nmap -sT -p 22 192.168.1.5
nmap -sS -p 22 192.168.1.5
nmap -sF -p 22 192.168.1.5
nmap -sN -p 22 192.168.1.5
nmap -sX -p 22 192.168.1.5

Data Length Scan

Nmap exposes the –data-length flag, which appends arbitrary padding bytes to every probe. By inflating the payload, the attacker shifts the IPv4 Total Length out of the blocked range. The extra 12 bytes push the SYN packet outside the 40 / 44 / 60-byte blocklist, and Nmap immediately reports port 22 as open. For this, we will use the following command:

nmap --data-length 12 -p 22 192.168.1.5

The previous namp scan verifies the change on the wire. Wireshark labels the highlighted frame as “Client: Encrypted packet (len=12)” and reports an IPv4 Total Length of 56 bytes (20 IP + 20 TCP + 4 options + 12 payload). None of the existing length rules matches this size, so the packet reaches the SSH service and elicits a normal response.

TTL Scan

Every IPv4 packet carries a TTL field that the source operating system initialises to a fixed value (Linux uses 64 by default). The defender exploits this fingerprint by rejecting packets whose TTL exactly matches the typical Linux origin value. Every TCP packet whose TTL field equals 64 now triggers a TCP reset. We will use the following rule for the said:

iptables -I INPUT -p tcp -m ttl --ttl 64 -j REJECT --reject-with tcp-reset

The following scans reveal an immediate weakness. The TCP Connect scan, which the kernel sends with TTL 64, is blocked. The half-open SYN scan, however, continues to succeed because Nmap crafts -sS probes with a randomised TTL drawn from a different range.

nmap -sT -p 22 192.168.1.5
nmap -sS -p 22 192.168.1.5

The Wireshark trace shows the SYN probe arriving with a TTL of 54 — Nmap intentionally selects a value that no normal Linux host would emit, and the equality-only iptables rule does not match.

Strengthening Security: Blocking TTL 64 and Below

The defender layers a second rule that captures every packet with a TTL below 64, eliminating the gap exposed by the SYN scan. The following rule is added alongside the original rule. Together, they cover every TTL value at or below 64.

iptables -I INPUT -p tcp -m ttl –ttl 64 -j REJECT --reject-with tcp-reset
iptables -I INPUT -p tcp -m ttl --ttl-lt 64 -j REJECT --reject-with tcp-reset

The following scans demonstrate the success of the combined ruleset. Every standard scan — connect, SYN, FIN, NULL, and XMAS — returns closed because Nmap’s default TTL choices fall within the blocked range.

nmap -sT -p 22 192.168.1.5
nmap -sS -p 22 192.168.1.5
nmap -sF -p 22 192.168.1.5
nmap -sN -p 22 192.168.1.5
nmap -sX -p 22 192.168.1.5

The following image shows the attacker overriding Nmap’s default with the following scan. The single value above the blocked range slips through both rules, and port 22 is once again reported as open.

nmap -p22 --ttl 65 192.168.1.5

It is now confirmed that the manipulated TTL of 65 in the captured frame. The defender could extend the rule with –ttl-gt, but the larger lesson is that header-field filtering merely shifts the cat-and-mouse game to a new attribute.

Source Port Spoofing Scan

Some legacy firewalls trust traffic that originates from common service ports such as DNS (53), FTP-data (20), or HTTP (80) on the assumption that it represents a legitimate response. Nmap’s -g flag exploits this trust by setting an arbitrary source port on every probe.

The following rules will implement this misconfiguration deliberately: the first rule accepts any TCP packet whose source port is 80, while the second rejects all other TCP traffic. A normal Nmap scan would be denied, but a spoofed source port slips through.

iptables -I INPUT -p tcp -m ttl –ttl 64 -j REJECT --reject-with tcp-reset

The following scan shows the attacker running probes now appear to originate from port 80, the firewall accepts them, and Nmap enumerates port 22 (SSH) and port 80 (HTTP) as open. A single overly permissive rule has nullified the entire chain.

nmap -g 80 192.168.1.5

Decoy Scan

Before tightening the firewall further, the defender enables logging so that every probe leaves an audit trail. The LOG target writes matching packets to the kernel log via syslog without dropping them.

Every matching packet, because of the following rule, now appears in /var/log/syslog with the searchable prefix “kaliNmap”, giving the defender both real-time visibility and an evidence trail. This rule will become essential in evaluating the next evasion technique.

iptables -I INPUT -p tcp -j LOG --log-prefix \"kaliNmap\" --log-level=4

Hiding in the Crowd: Decoy Scanning

Nmap’s -D option floods the wire with additional probe packets that appear to originate from spoofed IP addresses. The real attacker’s probes are mixed in with the decoys, making it difficult for an analyst to distinguish the genuine source.

Nmap inserts the decoy address into the probe stream and reports port 22 as open.

nmap -D 216.58.203.164 -p22 192.168.1.5

The deception will be confirmed in Wireshark. Several captured packets list 216.58.203.164 as the Source field, even though the attacker’s real address remains 192.168.1.17. To a casual log reader, the decoy IP is indistinguishable from a legitimate scanner.

The following image shows “tail -f /var/log/syslog” on the Ubuntu target. The kaliNmap-prefixed log line records “SRC=216.58.203.164” as the source of an incoming packet. Without correlating multiple sources or analysing MAC addresses, the defender cannot easily identify the real attacker.

Spoof MAC Address Scan

On a single broadcast domain, MAC addresses provide a more reliable identifier than IP addresses because they sit one layer lower and are not trivially spoofable from across the internet. The defender, therefore, restricts SSH access to a known MAC address.

The following rule is followed by a blanket REJECT rule. Only packets originating from the whitelisted MAC address may now reach the SSH service.

iptables -I INPUT -p tcp -m mac --mac-source c8:3a:35:44:fd:d0 -j ACCEPT
iptables -I INPUT -p tcp -j REJECT –reject-with tcp-reset

The following scan demonstrates the bypass. Nmap sets the source MAC to the trusted value (which the OUI lookup identifies as Tenda Technology) and the firewall accepts the probe. Port 22 once again reports as open. This works because the attacker shares the same Layer 2 segment as the target — a critical caveat for any MAC-based access control.

nmap --spoof-mac c8:3a:35:44:fd:d0 -p 22 192.168.1.5

Spoof IP Address Scan

A common firewall pattern accepts traffic only from a small list of trusted source IPs and rejects everything else. The defender below configures exactly that policy, then watches the attacker bypass it with a forged source address.

The following commands show the defender installing two rules in sequence. The first rule denies all TCP traffic, while the inserted second rule carves out an exception for the trusted address 8.8.8.8. Because I prepends the rule, the ACCEPT is evaluated before the REJECT.

iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
iptables -I INPUT -p tcp -s 8.8.8.8 -j ACCEPT

The attacker runs the following scan, explicitly binding the scan to interface eth0 and spoofing the source address to 8.8.8.8. Although Nmap warns about the spoofed address and reports a “Bind to 8.8.8.8:0 failed” error (because the host does not actually own that IP), the raw probes reach the target with the forged source field. The firewall matches the ACCEPT rule, the SSH service responds, and Nmap reports port 22 as open. The attacker pays a price — the SYN-ACK reply to travels back to 8.8.8.8 rather than to Kali — but for stateless scans that observe responses by other means, the bypass is complete.

nmap -e eth0 -S 8.8.8.8 -p 22 192.168.1.5

Data-String Scan

The iptables string module performs deep packet inspection by searching the payload for a specific byte sequence. The defender below allows traffic only when the packet payload contains a chosen secret phrase, effectively turning the firewall into a payload-based knock mechanism.

The defender installs two rules. The first one is followed by a blanket REJECT. The string module uses the Boyer-Moore algorithm (–algo bm) to scan every byte of the payload for the phrase “Khulja sim sim”. Any TCP packet that does not contain those bytes is rejected with a TCP reset.

iptables -I INPUT -p tcp -m string --algo bm --string \"Khulja sim sim\" -j ACCEPT
iptables -A INPUT -p tcp -j REJECT –reject-with tcp-reset

The first scan reports every port as closed because no probe carries the secret phrase. The second scan appends the matching string to every probe payload. The string module triggers the ACCEPT rule, and Nmap correctly identifies port 22 as open. A defender who treats the payload as a shared secret has therefore created exactly the kind of “secret password” that an attacker can replay.

nmap 192.168.1.5
nmap --data-string \"Khulja sim sim\" -p 22 192.168.1.5

Hex String Scan

The string module also accepts a hexadecimal pattern through the –hex-string option, which lets the defender match non-printable byte sequences. The attacker counters by injecting raw hex bytes into the probe payload using Nmap’s –data flag. The first rule is followed by a blanket REJECT. The Knuth-Morris-Pratt algorithm (–algo kmp) searches every TCP payload for the byte sequence corresponding to “RAJ” — that is, the hex values 0x52, 0x41, 0x4A. Without those exact bytes, traffic is denied.

iptables -I INPUT -p tcp -m string --algo kmp --hex-string \"RAJ\" -j ACCEPT
iptables -A INPUT -p tcp -j REJECT –reject-with tcp-resetr

The –data flag attaches the literal hex bytes 0x52, 0x41, 0x4A to every probe, satisfying the iptables match. The firewall accepts the packets, and the scan enumerates two open services: SSH on port 22 and HTTP on port 80. The lesson mirrors the previous section — payload-based access control is a static secret, and any attacker who learns or guesses the pattern reproduces it trivially.

nmap --data \"\x52\x41\x4A\" 192.168.1.5

IP-Options Scan

The TCP header reserves an Options field that carries items such as Maximum Segment Size, SACK Permitted, Timestamps, and Window Scale. Iptables can match on a specific TCP option number, allowing the defender to reject any packet that requests a particular option.

The attacker counters by manipulating IP-level options instead, which are never inspected by the TCP-option rule. TCP option number 4 is SACK Permitted, an option that Linux kernels include by default in their SYN packets. Any standard scan from a Linux host therefore matches this rule and is reset.

iptables -I INPUT -p tcp --tcp-option 4 -j REJECT --reject-with tcp-reset

The following scan shows the workaround the previous rule. The –ip-options flag injects four NOP bytes (0x00) into the IPv4 options field, with the trailing asterisk requesting that Nmap pad the field to a 4-byte boundary. The crucial detail is that this manipulation occurs at the IP layer, not the TCP layer, and the iptables rule that targets –tcp-option 4 does not affect IP-level options. The scan succeeds, and ports 22 and 80 once again appear as open.

nmap --ip-options \"\x00\x00\x00\x00*\" 192.168.1.5

Mitigation Strategies

The walkthrough makes clear that no single iptables rule can stand alone against a determined Nmap user. Effective network defence demands a layered approach in which multiple controls operate at different abstraction levels and reinforce each other. The following strategies address the weaknesses exposed throughout this article and form a practical hardening checklist for any administrator who relies on iptables as part of a broader security architecture.

Adopt Stateful Inspection

Replace stateless rule chains with stateful filtering using the conntrack module (“iptables -m conntrack –ctstate ESTABLISHED,RELATED -j ACCEPT” combined with a default-deny policy). Stateful rules track legitimate connection flows and automatically reject out-of-state packets, which neutralises stealth scans, fragmented probes, and many flag-manipulation tricks because none of them belong to an established session.

Deploy Intrusion Detection and Prevention Systems

Tools such as Snort, Suricata, and Zeek inspect traffic at a much higher level than iptables and recognise the behavioural fingerprints of scanning activity — a sudden burst of SYNs, sequential port probes, or packets with unusual flag combinations. Coupling iptables with an IDS/IPS converts a passive ruleset into an active monitoring system that can alert on, throttle, or block reconnaissance patterns rather than individual packets.

Apply Rate Limiting and Connection Throttling

Even when individual probes evade signature matching, the volume and timing of an Nmap scan remain distinctive. Rules such as “iptables -A INPUT -p tcp –syn -m limit –limit 5/s –limit-burst 10 -j ACCEPT” cap the rate at which new connections can be established, which dramatically slows full-port scans and makes them easier to detect through other means.

Avoid Relying on Spoofable Headers for Authentication

Source IP, source port, source MAC, and TTL can all be forged by an attacker who shares the network segment or who can craft raw packets. None of these fields should serve as the sole basis for granting access to a sensitive service. Strong authentication mechanisms — SSH public-key authentication, mutual TLS, multi-factor authentication, and properly issued certificates — provide guarantees that header inspection cannot.

Implement Centralised Logging and Correlation

The decoy-scanning section of this walkthrough showed how an attacker can drown a single log in spoofed source addresses. A centralised SIEM that correlates events across multiple sensors, captures Layer 2 information such as source MAC, and applies behavioural baselines defeats this kind of obfuscation by exposing the underlying pattern that no single decoy can hide.

Block Fragmentation and Anomalous Packets

Most modern networks have no legitimate need for IP fragmentation between internal hosts. Rules that drop fragments outright (“iptables -A INPUT -f -j DROP”) eliminate the -f bypass entirely. Similarly, stateful firewalls that normalise and reassemble packets before applying rules close many of the layer-confusion bypasses described in the TCP-option and IP-option sections.

Practise Network Segmentation and Least Privilege

A flat network amplifies every weakness exposed in this article. Segmenting infrastructure into isolated VLANs or zones, placing administrative interfaces behind a bastion host or VPN, and enforcing the principle of least privilege at every boundary reduce the attack surface long before iptables rules become the last line of defence.

Maintain Patching and Configuration Hygiene

Many of the bypass techniques in this article exploit kernel-level behaviour that has been refined over decades of Linux development. Keeping the operating system, iptables/nftables tooling, and the SSH daemon itself up to date ensures that newly disclosed evasion techniques are addressed promptly. Regular configuration reviews catch the kind of overly permissive rules — such as the source-port-80 ACCEPT — that nullify an entire chain.

Conduct Regular Penetration Testing

The structured attack-and-response cycle demonstrated here is exactly the methodology a professional penetration tester applies during an engagement. Scheduling regular tests, ideally with the scan techniques described in this article as a starting point, surfaces weaknesses while they can still be fixed and gives the security team a realistic measure of the firewall’s effectiveness against modern reconnaissance tooling.

Final Analysis

Across forty-eight figures, this article has demonstrated a single recurring truth: every static attribute that iptables can match — TCP flags, packet length, Time-To-Live, source port, source MAC, source IP, payload bytes, and TCP options — falls to a corresponding one-line Nmap argument. -sS defeats SYN-block; -sF, -sN, and -sX defeat SYN-only filters; –data-length defeats length matching; –ttl defeats TTL matching; -g defeats source-port trust; –spoof-mac defeats MAC whitelisting; -S defeats source-IP whitelisting; –data-string and –data defeat string-based deep inspection; and –ip-options sidesteps TCP-option filtering by attacking a different layer entirely. The defender’s flat ruleset accumulates exceptions that ultimately weaken the policy rather than strengthen it.

The deeper takeaway is therefore architectural rather than tactical. Static, attribute-by-attribute filtering is a losing game because every attribute belongs to a header field that the attacker can craft. Robust defence requires moving up the abstraction stack to stateful inspection, behavioural analytics, and identity-based authentication — controls that operate on context, history, and proven trust rather than on bytes alone. Iptables retains an important role within this architecture, but only as one layer among several, not as the sole gatekeeper.

For penetration testers, the same lessons apply in reverse. Each iptables rule reveals itself in the firewall’s response: a TCP reset where silence was expected, a “closed” verdict that contradicts a known service, or a sudden change in latency. Treating these signals as fingerprints of the underlying rule turns every probe into intelligence, and every rejection becomes a clue that points to the next probe variant worth attempting. The complete cycle of probe, detect, evade, and re-detect captured in this walkthrough is the foundation of professional network reconnaissance — and, when read from the other direction, the blueprint for a security strategy that can finally outpace it.