TCP's three-way handshake 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, this article explains the SYN flood and DDoS defense-centrically, faithful to RFC 4987 (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 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).
正常な接続：
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), 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 lists is SYN cookies. The idea is brilliant — save no state at all at the moment the SYN is received.
2.1 The mechanism
通常：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.
# 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 (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 (Standard auto-mitigates L3/L4), Cloudflare, Google Cloud Armor.
- Anycast + scrubbing: geographically distribute traffic and absorb/clean it with enormous capacity.
- WAF: 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.
# 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).
/** ある観測時点の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 — 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.