An Evening with ChaosTables: A Field Report from a Published IP

This article presents a two‑part exploration of deploying ChaosTables on a published IP address within a distributed enterprise firewall environment. The first part is a narrative written in the spirit of "An Evening with Berferd" — a lightly humorous, observational, sysadmin story of watching ChaosTables deal with a curious external visitor. The second part is a full technical deep dive showing how to build the same system in production.

---

Part I — The Narrative

An Evening with ChaosTables

It was a quiet night on the edge of the network — the sort of night where the log files breathe slowly, the CPUs hum contentedly, and nothing particularly odd happens. Then, at 23:14, a packet tapped on the metaphorical window.

Not a SYN packet — that would suggest someone wanted a conversation. No, this was stranger. A little FIN packet wandered in alone, no context, no prior relationship, no introduction. The firewall raised an eyebrow.

ChaosTables perked up.

> "Normal TCP connections begin with a SYN packet… everything else must be forged." — ChaosTables documentation. citeturn1search1

The packet drifted in like a drunk tourist trying to find the hotel bar at 3 AM. ChaosTables placed one hand on its hip and waited to see what else would happen.

Moments later: NULL scan. XMAS scan. A malformed ACK. A touch of idle curiosity about OS fingerprinting. The visitor was clearly running nmap with enthusiasm but not subtlety.

ChaosTables smiled — or would have, if kernel modules could smile. It reached into its toolbox and began responding with a selection of confusing, misleading, deliberately unhelpful packets. The kind of responses that make scanners stop, scratch their heads, and wonder whether the host is running a refrigerator or a battleship.

> "It may happen that nmap’s OS detection gets confused as a welcomed side effect." — ChaosTables documentation. citeturn1search1

Meanwhile, behind the curtain, the DNAT rule sat quietly, forwarding only legitimate SYNs to the internal server. The server remained blissfully unaware of the drama occurring just centimetres away in PREROUTING.

Suricata logged the anomalies. The SIEM correlated them with a shrug. Nagios noted: "No service impact."

And ChaosTables? ChaosTables played with the visitor like a cat with a laser pointer.

Eventually the visitor got bored. The scans stopped. The logs grew quiet again.

At 23:27, the firewall went back to its peaceful hum, and the only real disturbance was the sysadmin chuckling to themselves as they reviewed the logs, appreciating the elegance of simple, kernel‑level deception.

Just another evening with ChaosTables.

---

Part II — Technical Build Guide

Building the Scenario: ChaosTables on a Published IP Address

This section explains exactly how to reproduce the behaviour described above. All factual references to ChaosTables are taken from the official documentation packaged with the original ChaosTables release, later merged into Xtables‑addons. citeturn1search1

1. What ChaosTables Actually Is

ChaosTables is a software package that provides Netfilter/Xtables/iptables extensions (plugins). It is not itself a chain (like INPUT) nor a table (like mangle or nat). citeturn1search1

• Purpose: detect anomalous/stealth scanning traffic and optionally respond with deceptive behaviours.
• Notable targets include CHAOS and DELUDE for confusing scanners, with documented effects like breaking or misleading OS fingerprinting. citeturn1search1
• The ChaosTables codebase was merged into Xtables‑addons in April 2008; modern deployments obtain its functionality via xtables‑addons modules. citeturn1search1

2. Install Required Components

2.1 Install Xtables‑addons

On modern Linux distributions (example commands shown): <syntaxhighlight lang="bash"> sudo apt update && sudo apt install -y xtables-addons-common

1. or on RHEL/CentOS/Alma/Rocky:

sudo yum install -y xtables-addons </syntaxhighlight>

2.2 Load Kernel Modules

Load the relevant extension targets (names may vary slightly by distro/kernel build): <syntaxhighlight lang="bash"> sudo modprobe xt_chaos sudo modprobe xt_delude </syntaxhighlight> These supply the CHAOS/DELUDE targets referenced in the ChaosTables documentation. citeturn1search1

3. ChaosTables’ Detection Logic (Theory to Practice)

The detection approach rests on a simple TCP truth: normal connections start with SYN; first packets without SYN are anomalous. citeturn1search1

A representative matching pattern (inspired by the documentation’s stealth‑scan detection walkthrough) is: <syntaxhighlight lang="bash"> -p tcp ! --syn -m conntrack --ctstate INVALID </syntaxhighlight> This matches typical stealth scanning patterns (NULL, FIN, XMAS) where initial packets don’t carry SYN. An explicit exception is needed for valid RST/RST-ACK behaviour per RFC 793. The ChaosTables doc shows an example exclusion using RST flags before general handling. citeturn1search1

3.1 RST Exception Example

<syntaxhighlight lang="bash">

1. Inside our custom chain, first allow RST/RST-ACK to avoid breaking legitimate behaviour

iptables -A CHAOS_FILTER -p tcp --tcp-flags SYN,FIN,RST,ACK RST,ACK -j RETURN </syntaxhighlight> Rationale: RFC793 specifies RST handling, and the documentation explains why allowing RST (and RST‑ACK in certain cases) avoids information leaks while preserving expected behaviour. citeturn1search1

4. Build the CHAOS_FILTER Chain

Create a user-defined chain and add detection + response actions. <syntaxhighlight lang="bash">

1. 4.1 Create the chain

iptables -N CHAOS_FILTER

1. 4.2 RST exception (as above)

iptables -A CHAOS_FILTER -p tcp --tcp-flags SYN,FIN,RST,ACK RST,ACK -j RETURN

1. 4.3 Log and apply deception target

iptables -A CHAOS_FILTER -j LOG --log-prefix "[CHAOSTABLES] " --log-level 4

1. You can choose CHAOS or DELUDE depending on desired behaviour

iptables -A CHAOS_FILTER -j CHAOS

1. or:
2. iptables -A CHAOS_FILTER -j DELUDE

</syntaxhighlight> The CHAOS/DELUDE targets are specific to ChaosTables/Xtables‑addons and are used to deceive scanners; the documentation notes OS detection confusion as a possible outcome. citeturn1search1

5. Apply ChaosTables Before DNAT

To protect a published IP (e.g., PublicIP:443 → InternalServer:443), hook CHAOS_FILTER in PREROUTING (raw or mangle) so that stealth scans are handled before DNAT/forwarding.

5.1 DNAT Rule (nat table)

<syntaxhighlight lang="bash"> iptables -t nat -A PREROUTING -d <PUBLIC_IP> -p tcp --dport 443 \

 -j DNAT --to-destination <INTERNAL_IP>:443

</syntaxhighlight>

5.2 ChaosTables Hook (raw table)

<syntaxhighlight lang="bash"> iptables -t raw -A PREROUTING -d <PUBLIC_IP> -j CHAOS_FILTER </syntaxhighlight> This ordering ensures stealthy/non‑SYN probes are intercepted by CHAOS/DELUDE responses while legitimate SYN-based connections flow to DNAT and on to the internal server. citeturn1search1

6. Expected Behaviour Under Scan

The documentation states that OS detection (e.g., by nmap) may become confused as a side effect of ChaosTables’ responses. Expect NULL/FIN/XMAS scans to produce inconsistent/filtered results, while proper SYN scans continue to succeed to the DNATed service. citeturn1search1

6.1 Quick nmap Test Set

<syntaxhighlight lang="bash">

1. SYN scan + service/version + OS detection

nmap -sS -sV -O <PUBLIC_IP>

1. NULL scan

nmap -sN <PUBLIC_IP>

1. XMAS scan

nmap -sX <PUBLIC_IP>

1. FIN scan

nmap -sF <PUBLIC_IP> </syntaxhighlight> Interpretation: OS fingerprinting should be unreliable; stealth scans should not reveal stable host traits; valid SYN handshake traffic continues to reach the internal service. citeturn1search1

7. Integrating with a Distributed Firewall Fabric

This ChaosTables layer becomes an outer deception shell that reduces noise and reconnaissance value, while your deeper layers (IPS/IDS, proxies, SIEM correlation) do heavy lifting.

• IPS/IDS — Suricata/SNORT inline for signatures/anomalies; use SID-based policies and auto‑shun to inject temporary iptables drops.
• SIEM — ship ChaosTables logs; correlate with IDS, flow, and auth anomalies to identify active recon and pivot attempts.
• Monitoring (Nagios) — track node health, rate of CHAOS/DELUDE hits, and unexpected spikes indicating targeted recon.
• Switchport Control — where appropriate, use RADIUS CoA / SNMP / NETCONF to quarantine compromised internal hosts; this is complementary and outside ChaosTables itself.

(While not part of ChaosTables proper, these integrations form the enterprise‑grade response loop.)

8. Troubleshooting & Safety Notes

• Ensure the RST/RST‑ACK exception is present to avoid interfering with legitimate TCP behaviours noted in RFC793; the ChaosTables documentation discusses this nuance. citeturn1search1
• Place CHAOS_FILTER in a table/chain that evaluates before DNAT; otherwise, stealth probes may be forwarded to servers. citeturn1search1
• Always test in a maintenance window and have a rollback plan (remove the raw‑table hook first to restore default behaviour).
• Log with a unique prefix (e.g., [CHAOSTABLES]) so SIEM/Nagios filters are easy to build.

9. Minimal Rollback

To disable the deception quickly while leaving DNAT intact: <syntaxhighlight lang="bash"> iptables -t raw -D PREROUTING -d <PUBLIC_IP> -j CHAOS_FILTER </syntaxhighlight> You may then flush or remove the CHAOS_FILTER chain later: <syntaxhighlight lang="bash"> iptables -F CHAOS_FILTER iptables -X CHAOS_FILTER </syntaxhighlight>

10. Conclusion

ChaosTables provides a lightweight, kernel‑level anti‑recon layer that complements deep inspection and proxying. By handling anomalous first packets and returning deceptive responses, it frustrates OS and service fingerprinting while allowing legitimate, SYN‑based connections to proceed via DNAT. In a distributed firewall stack, this becomes an elegant first line of playful defence — exactly as the narrative in Part I illustrated. citeturn1search1

---

References

• ChaosTables Documentation PDF (Detecting and deceiving network scans). Key facts used in this article: ChaosTables is a package of Netfilter/Xtables/iptables extensions (not a table/chain); normal TCP starts with SYN; RST/RST‑ACK exception logic; and OS detection confusion as a side effect. citeturn1search1