# Understanding and defending against SYN flood / DDoS [2026] — don't exhaust half-open connections, with RFC 4987's SYN cookies

> An explanation, 'defense-centric' and faithful to RFC 4987, of the SYN flood that abuses TCP's half-open state and the broader DDoS. It explains from TCP's state transitions why stopping mid-handshake exhausts the server's resources, and shows multi-layered mitigations — SYN cookies, backlog, rate limiting, SYN proxy, and cloud DDoS protection (AWS Shield/WAF) — with configuration and type-safe code. It doesn't handle attack tools and sticks to defense.

- Published: 2026-06-28
- Author: 友田 陽大
- Tags: セキュリティ, ネットワーク, TCP/IP, TCP, 可観測性, アーキテクチャ設計
- URL: https://tomodahinata.com/en/blog/syn-flood-ddos-attack-defense-syn-cookies-guide
- Category: 実践ネットワーク攻撃と防御
- Pillar guide: https://tomodahinata.com/en/blog/network-penetration-testing-methodology-attack-defense-guide

## Key points

- A SYN flood abuses the 'half-open' state of the three-way handshake. By sending only SYN and not returning the final ACK, it fills the server's connection queue (backlog) with incomplete connections and makes it refuse legitimate use.
- This article doesn't handle attack procedures and sticks to defense. DoS is an attack on others and illegal. As defender's knowledge, it explains only why exhaustion happens and how to mitigate, faithful to RFC 4987.
- RFC 4987's main mitigation is SYN cookies. On SYN receipt, save no state; return an ISN that cryptographically encodes the connection info in the SYN/ACK, and restore it when the final ACK arrives. It consumes no backlog.
- Defend in layers: backlog expansion, SYN cookies (only under high load), connection/rate limiting, SYN proxy (the FW/LB handles the handshake), and upstream cloud DDoS protection (AWS Shield).
- Modern volumetric DDoS can't be defended by a server alone. BCP 38 source verification suppresses reflection/amplification, and Anycast + cloud scrubbing absorbs the volume. Make upstream defense a premise at the design stage.

---

[TCP's three-way handshake](/blog/tcp-three-way-handshake-state-transition-retransmission-congestion-control-guide) establishes a connection in three moves: "SYN → SYN/ACK → ACK." So what happens if an attacker **sends only the first SYN and never returns the final ACK**? The server keeps holding resources while carrying "an incomplete connection waiting for the peer's ACK (the half-open state)." Doing this en masse to fill the connection queue and **make legitimate users unable to connect** is a **SYN flood** — a classic yet still-effective DoS (denial of service) attack.

Following [the big picture of network pentesting](/blog/network-penetration-testing-methodology-attack-defense-guide), this article explains the SYN flood and DDoS **defense-centrically, faithful to [RFC 4987](https://www.rfc-editor.org/rfc/rfc4987) (TCP SYN Flooding Attacks and Common Mitigations).**

> **This article's policy — it doesn't handle attack procedures**
> DoS/DDoS is **an attack that disrupts others' services** and, in Japan, a clearly illegal act that can be charged as obstruction of business by damaging a computer, etc. As **defender's knowledge**, this article handles only "why resources are exhausted" and "how to mitigate," and **shows no attack tools or load-generation commands at all.** Even when testing your own server's resilience, always do it within an [isolated lab](/blog/ethical-hacking-home-lab-kali-juice-shop-ctf-self-study-roadmap-guide) or a load test agreed in writing (an official load-testing service).

---

## 1. Why a half-open connection exhausts resources

When the server receives a SYN, it transitions to the `SYN-RECEIVED` state and, **while waiting for the final ACK, holds that connection's info in the SYN backlog (queue)** (see [TCP's state transitions](/blog/tcp-three-way-handshake-state-transition-retransmission-congestion-control-guide)).

```text
正常な接続：
  client ── SYN ──►  server (SYN-RECEIVED：バックログに1枠確保し ACK を待つ)
  client ◄ SYN/ACK ─ server
  client ── ACK ──►  server (ESTABLISHED：バックログの枠を解放)

SYNフラッド：
  attacker ── SYN ──►  server (SYN-RECEIVED：枠を確保)
  attacker ◄ SYN/ACK ─ server
  attacker  ……（ACK を返さない）……   ← 枠が解放されないまま放置
  これを大量に繰り返す → バックログが半開接続で満杯 → 正規の SYN を受け付けられない
```

The core RFC 4987 explains is **"occupying the finite resource of the backlog with incomplete connections."** Since the attacker has no intention of completing the connection, it consumes almost none of its own resources. Moreover, if it [spoofs the source IP (IP spoofing)](/blog/tcp-session-hijacking-rst-injection-ip-spoofing-defense-guide), the SYN/ACK flies to an unrelated third party, also making the attacker hard to trace. Being **asymmetric (light for the attacker, heavy for the victim)** is the trouble of this attack.

---

## 2. The main defense: SYN cookies (RFC 4987)

The center of the mitigations [RFC 4987](https://www.rfc-editor.org/rfc/rfc4987) lists is **SYN cookies.** The idea is brilliant — **save no state at all at the moment the SYN is received.**

### 2.1 The mechanism

```text
通常：SYN 受信 → バックログに状態を保存 → ACK を待つ（ここが枯渇する）

SYN cookies：
  SYN 受信 → 状態を保存しない！
            代わりに「接続情報＋時刻＋秘密鍵」を暗号的に符号化した値を
            初期シーケンス番号(ISN)として SYN/ACK で送り返す（= cookie）
  ACK 受信 → ACK 番号 = cookie+1 から、接続情報を復元・検証
            正しければ、その時点で初めて接続を構築（ESTABLISHED）
```

If the final ACK doesn't come, nothing happens — **since it consumes no backlog, it isn't exhausted by a flood.** This is the power of SYN cookies.

### 2.2 Not "always on" by default

As RFC 4987 notes, SYN cookies have a trade-off in that they **can't fully preserve some TCP options (window scale, SACK, etc.)**, so on many OSes they're designed to **"trigger automatically only under high load (when the backlog is strained)."** They're not left always on.

```bash
# Linux: SYN cookies を有効化（高負荷時に自動発動する“安全弁”）
sysctl net.ipv4.tcp_syncookies        # = 1 が推奨（多くのディストリで既定）

# 併せてバックログ関連を環境に応じて調整（むやみに巨大化しない）
sysctl net.ipv4.tcp_max_syn_backlog   # 未完成接続キューの上限
sysctl net.core.somaxconn             # accept 待ちキューの上限（アプリの listen backlog と整合させる）
```

---

## 3. Defense in depth — don't fully defend with a server alone

SYN cookies are powerful, but **modern DDoS is mainly volumetric**, overflowing the line itself. This can't be defended by a single server. Think in layers.

### 3.1 Host/kernel layer

- **Enable SYN cookies** (§2).
- **Suppress `tcp_synack_retries`**: shorten the time half-open connections keep resending SYN/ACK, resolving exhaustion faster.
- Excessive backlog expansion is **not a cure** (if the attack volume exceeds it, the same happens). The safety valve is SYN cookies.

### 3.2 Network/edge layer

- **SYN proxy**: the firewall/load balancer **handles the handshake** and passes only connections with a completed three-way to the backend. The backend never sees a half-open connection.
- **Rate limiting**: cap the new-connection rate per source.
- **[BCP 38](/blog/tcp-session-hijacking-rst-injection-ip-spoofing-defense-guide) (ingress filtering)**: drop source spoofing at the route to suppress reflection/amplification.

### 3.3 Upstream/cloud layer (the main play for volumetric DDoS)

Volumetric attacks can only be **absorbed before they reach your line.**

- **Cloud DDoS protection**: [AWS Shield](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-overview.html) (Standard auto-mitigates L3/L4), Cloudflare, Google Cloud Armor.
- **Anycast + scrubbing**: geographically distribute traffic and absorb/clean it with enormous capacity.
- **[WAF](/blog/network-penetration-testing-methodology-attack-defense-guide)**: against L7 (HTTP floods), separate legitimate/malicious with rate-limit rules and BotID/CAPTCHA.

> **Design implication**: DDoS resilience is decided not by "the app's code" but by **"architecture."** Make it a design-stage premise to not expose the server directly to the internet but place it **behind CDN/WAF/cloud DDoS protection.** This is my basic stance when building production systems on AWS.

---

## 4. Detection — visualize "an abnormal increase in half-open connections"

To know whether the defense is working, observe half-open connections and the SYN rate.

```bash
# SYN-RECV（半開）状態の接続数を数える。平常時から跳ね上がっていれば SYN フラッドの兆候
ss -tan state syn-recv | wc -l

# 状態ごとの分布を俯瞰（SYN-RECV が支配的なら異常）
ss -tan | awk 'NR>1{print $1}' | sort | uniq -c | sort -rn
```

### 4.1 A pure function that judges from observed values (type-safe)

Let's write, side-effect-free, the logic that judges "SYN-flood-likeness" from metrics (half-open count, new-SYN rate). It can connect to alerts and automatic mitigation (since SYN cookies auto-trigger in the kernel, here it's used for notification and the decision to activate upstream defense).

```ts
/** ある観測時点のTCP接続メトリクス。 */
interface TcpHealthSample {
  readonly synRecvCount: number;   // SYN-RECV(半開)の数
  readonly establishedCount: number; // ESTABLISHED の数
  readonly newSynPerSec: number;   // 新規SYN到着レート
}

interface FloodVerdict {
  readonly isLikelyFlood: boolean;
  readonly halfOpenRatio: number;
  readonly reason: string;
}

/**
 * 半開接続の比率と SYN レートから SYN フラッドの兆候を判定する純粋関数。
 * 「半開が確立済みに対して異常に多い」かつ「新規SYNレートが平常の閾値超」を兆候とする。
 * 副作用なし＝テスト容易・誤検知は閾値調整で安全に対応（正常なスパイクを誤報しない）。
 */
export function detectSynFlood(
  sample: TcpHealthSample,
  baselineSynPerSec: number,
  halfOpenRatioThreshold = 2,    // 半開 ÷ 確立 がこれを超えたら疑う
  synRateMultiplier = 5,          // 平常比 ×5 のSYNレートを疑う
): FloodVerdict {
  const established = Math.max(sample.establishedCount, 1); // 0除算回避
  const halfOpenRatio = sample.synRecvCount / established;

  const ratioHot = halfOpenRatio >= halfOpenRatioThreshold;
  const rateHot = sample.newSynPerSec >= baselineSynPerSec * synRateMultiplier;

  return {
    isLikelyFlood: ratioHot && rateHot,
    halfOpenRatio,
    reason: `halfOpenRatio=${halfOpenRatio.toFixed(2)} (hot=${ratioHot}), synRate=${sample.newSynPerSec} (hot=${rateHot})`,
  };
}
```

By making it an **AND of two conditions** (half-open ratio & SYN rate), it's harder to false-positive on a legitimate traffic spike (where the half-open ratio doesn't rise). Low-false-positive detection is important for keeping operational trust.

---

## 5. Summary

- **A SYN flood is an asymmetric attack that exhausts the backlog with half-open connections.** Light for the attacker, heavy for the victim. Often accompanied by source spoofing.
- **This article doesn't handle attack procedures and sticks to defense** — DoS is illegal. As defender's knowledge, grasp the principle and mitigation.
- **The main play is SYN cookies (RFC 4987)**: save no state on SYN receipt, and complete the handshake with a cryptographically encoded ISN. It consumes no backlog. Auto-triggering only under high load is the norm.
- **Defend in layers**: kernel (SYN cookies, retry suppression) → edge (SYN proxy, rate limiting, BCP 38) → upstream (cloud DDoS protection, Anycast, WAF).
- **Defend volumetric DDoS with architecture**: don't expose the server directly; make placing it behind CDN/WAF/cloud protection a design premise.
- **Detection**: observe the half-open ratio and SYN rate, and visualize with an AND condition to suppress false reports.

Next, we handle the "read" phase of MITM's spoils — **[packet sniffing / Wireshark / defense via encryption](/blog/packet-sniffing-wireshark-tls-encryption-defense-guide)** — to conclude the cluster.

---

I (Hinata Tomoda) have implemented DDoS-resilient architecture design premised on WAF/Shield/CDN on AWS, kernel/edge tuning including SYN cookies and rate limiting, and observability of half-open connections and traffic anomalies. "I want a configuration that withstands DDoS," "I'm anxious about exposing the server directly to the internet," "I want to detect traffic anomalies" — I diagnose such availability hardening from the attacker's perspective and cure it with defense in depth and observability. Feel free to reach out.