SYNPROXY iptables-based DDoS protection

SYNPROXY is Linux's kernel-level SYN-flood mitigation. Before a TCP connection completes its three-way handshake, SYNPROXY intercepts and validates SYN packets to filter out spoofed-source flood traffic. BOA wires this up as the lowest layer of its DDoS defence.

The CLI is the synproxy* family: synproxy_monitor plus the collapsed synproxy / synproxy_hook_fix / synproxy_reassert / synproxy_rollback / synproxy_snapshot / synproxy_status commands.

How SYNPROXY fits

Packet from internet
   ↓
SYNPROXY (kernel)        ← SYN flood filtering, this page
   ↓
SYNPROXY_EARLY iptables  ← early-decision iptables rules
   ↓
CSF / LFD                ← per-IP block/allow, see CSF + LFD firewall
   ↓
Nginx (Abuse Guard)      ← application-layer
   ↓
PHP-FPM
   ↓
Drupal

Each layer filters more — by the time traffic reaches Nginx it has already passed kernel-level SYNPROXY and CSF rules.

The CLI family

Command Purpose
synproxy Install + apply the primary rule set
synproxy_monitor Display real-time SYNPROXY counters (operator dashboard)
synproxy_status Quick "is SYNPROXY on?" status output
synproxy_hook_fix Repair the iptables hook if it gets out of sync
synproxy_reassert Re-apply rules after a reboot or iptables flush
synproxy_rollback Revert SYNPROXY rules
synproxy_snapshot Save current state (rule set + counters)

synproxy and synproxy_reassert are the two commands you will use most. The others are diagnostic / recovery.

synproxy_monitor — live counter display

synproxy_monitor

Shows top iptables counters: INPUT, OUTPUT, the raw/PREROUTING NOTRACK hits, plus the SYNPROXY_EARLY chain hits. Tunables via env vars or the matching CLI flags (defaults from the script):

_INTERVAL=2            # -n SEC : refresh interval (default 2)
_TCP_PORTS="443 80"    # -p "…" : ports to highlight (default "443 80")
_SHOW_INPUT_LINES=8    # -l NUM : how many INPUT lines to show (default 8)
_SHOW_OUTPUT_LINES=8   #          OUTPUT lines (default 8)

Useful while watching a suspected attack — repeated SYNPROXY_EARLY hits on a specific port indicate a SYN flood.

When SYNPROXY kicks in

The Linux kernel applies SYNPROXY to incoming SYN packets matching the iptables rule pattern. For each SYN:

  1. The kernel validates the source IP via cookies (à la SYN cookies).
  2. Invalid sources are dropped without consuming socket resources.
  3. Valid sources see a normal TCP handshake.

This blocks the classic SYN-flood pattern where an attacker sends millions of SYNs with spoofed sources, exhausting the target's socket table.

After a reboot

iptables rules do not persist by default. After a reboot:

synproxy_reassert

re-applies the SYNPROXY rule set to live iptables. BOA automates this via cron and the BOA monitor stack, but if something interferes (a manual iptables flush, a custom firewall script unaware of SYNPROXY) you may need to run synproxy_reassert by hand.

Snapshot + rollback for testing

synproxy_snapshot     # Save current state
# ... try changes ...
synproxy_rollback     # Revert to snapshot

The rollback is a clean revert — no surprises.

Tunables

SYNPROXY rate thresholds live in the script — operators can adjust based on their host's traffic profile. Defaults are tuned for typical BOA hosts; only adjust if you have seen specific issues (e.g. legitimate traffic getting dropped under load).

When SYNPROXY blocks legitimate traffic

Rare but possible:

  • Source-IP spoofing detection has false positives on unusual network paths.
  • Very fast retry patterns from a single source can look like a flood.

If a tenant reports "I cannot connect," check:

synproxy_monitor          # Are SYNPROXY_EARLY counters spiking?
csf -i 1.2.3.4            # Is their IP in CSF deny?

If CSF deny is empty but SYNPROXY counters spike from their IP, SYNPROXY may be (incorrectly) filtering them. A csf -a whitelist does not help (CSF is downstream of SYNPROXY). The recovery is either to relax the SYNPROXY rate thresholds, or to add an explicit SYNPROXY skip rule for that IP range — not a typical operation.

Disabling SYNPROXY

synproxy_rollback

rolls back the SYNPROXY rules entirely; the host falls back to kernel-default SYN handling. Use only for short windows (e.g. diagnosing a routing issue). Re-enable with synproxy, or wait for the next BOA cron pass, which reasserts.

Related