MENU

Windows Server 2019でSynAttackProtectは設定すべき？SYNフラッド対策の既定動作と確認方法

Windows Server

古いTechNetで紹介されるSynAttackProtect（SYNフラッド対策）のレジストリ調整は、Windows Server 2019でも必要なのか。既定のSYN攻撃保護の仕様、設定の是非、確認・調査の手順を運用目線で整理します。

目次

結論：Windows Server 2019で「SynAttackProtectを有効化する」必要は基本的にない

先に結論から言うと、Windows Server 2019では、昔のTechNet記事にあるようなSynAttackProtectなどのレジストリ値を“入れて有効化する”という運用は、現代的なベストプラクティスとしては推奨しにくいです。理由はシンプルで、Windows Vista / Windows Server 2008以降のTCP/IPスタックでは、SYN攻撃保護（Syn attack protection）は既定で有効であり、さらに管理者がレジストリやnetshでしきい値を調整できない設計に変わっているためです。

つまり、Windows Server 2019においては「レジストリに値が存在しない＝対策が無効」という読み替えは成立しません。むしろ、古いキーを追加すると、組織内のハードニング基準・監査対応・トラブルシュートがややこしくなりやすく、“効果が不明な変更を増やす”側のリスクが勝ちがちです。

SynAttackProtectとは何か：なぜ古いレジストリ調整が今でも検索されるのか

SynAttackProtectは、TCPの3ウェイハンドシェイク（SYN → SYN/ACK → ACK）を悪用してサーバー資源を枯渇させるSYNフラッドへの耐性を上げるため、昔のWindowsで使われていた対策系パラメータの代表格です。

Windows 2000〜Windows Server 2003頃の実装では、SYN攻撃保護はレジストリで複数の値（SynAttackProtect / TcpMaxHalfOpen / TcpMaxHalfOpenRetried / TcpMaxPortsExhausted など）を持ち、管理者がしきい値を“固定値”でチューニングする発想がありました。

ところがVista/2008以降はTCP/IPスタックの仕様が変わり、「固定値チューニングで守る」よりも「OSが自動で最適化して守る」方向に舵が切られました。結果として、古いTechNet記事だけが検索結果に残り、現在のWindows Server（2016/2019/2022など）にそのまま当てはめようとして混乱が起きやすくなっています。

観点旧来（Windows 2000 / 2003系）現行（Vista / 2008以降〜Server 2019）
有効/無効（時期により）任意・または既定有効既定で有効、無効化できない
しきい値管理者がレジストリで固定値設定CPUコア数・メモリ量に応じて動的算出（自己調整）
設定インターフェースレジストリ（SynAttackProtect等）レジストリ/ netsh等での調整パラメータは公開されない
発動確認状況によりログや挙動で判断イベントログは基本的に残らないため、ETL/ETWトレースで追う

Windows Server 2019のSYN攻撃保護：既定で有効、そして“自己調整”

Microsoftの説明（Vista/2008以降）でポイントになるのは、次の3つです。

  • SYN攻撃保護は既定で有効で、無効化できない
  • 攻撃と判定するしきい値は、CPUコア数・メモリ量などに応じて動的に決まる
  • そのため、レジストリやnetshで調整するためのパラメータを公開していない

運用の感覚として重要なのは、「OSが勝手に最適化する＝何もしなくてよい」ではなく、「OSが勝手に最適化する＝いじるより、状況把握と上流対策に注力した方が早い」という整理です。

“攻撃状態（attack state）”に入ると何が起きるのか

Vista/2008以降のSYN攻撃保護では、TCP/IPスタックが“攻撃状態”と判断すると、サーバー資源の枯渇を避けるために新規の接続要求（SYN）を落とし始める場合があります。これは防御としては合理的ですが、運用上は「正当なアクセスが弾かれる」こともあり得ます。

ここで厄介なのが、攻撃状態に入ったかどうかをイベントログで簡単に判定できる仕組みが基本的にない点です。発動有無の判断は、ETL（ETW）トレースを事前に開始しておき、該当のエントリを追う、という方針になります。

レジストリにSynAttackProtectを追加すべきか：実務的な判断基準

Windows Server 2019で「SynAttackProtectを設定すべきか」を、現場で迷うポイントに落とすと次のようになります。

状況よくある発想推奨アクション（Server 2019）
過去記事に「SynAttackProtect=2/3」が出てくるとりあえず入れて守りを強化したい入れない。既定で保護は有効で、調整用パラメータが公開されていない前提で設計する
高負荷時に接続失敗が増えるSynAttackProtectを0にして無効化したいまず証跡採取（ETL/PKTMON）で「SYN落ち」が本当に原因か確認。上流対策・スケール・設計改善を優先
脆弱性診断ツールが「SynAttackProtect未設定」を指摘監査対応のため設定しないと…OS世代差の誤検知を疑う。根拠としてMicrosoftの仕様説明（既定有効・非公開パラメータ）を文書化

まず疑うべきは「SYNフラッド」ではなく「SYNが詰まる設計・経路」

「SYNフラッド対策のはずが、逆に接続が切れる」という相談は、SYNフラッド“そのもの”より、次のような要因が混ざっていることが多いです。

  • インターネット直結でサーバーを公開している（上流で受け止めていない）
  • ロードバランサ/プロキシ/ファイアウォール側のセッション制限・レート制限が先に当たっている
  • アプリ側が瞬間的なコネクションスパイクを作っている（再試行設計・タイムアウト設計・コネクションプール不備）
  • OSの“攻撃状態”ではなく、別の層（NIC/仮想スイッチ/フィルタドライバ等）でドロップしている

つまり、レジストリの1項目で片付けようとすると、真因から遠ざかることがあります。ここからは、Windows Server 2019で「本当にSYNが落ちているのか」を現実的に確かめる手順を紹介します。

確認の第一歩：SYN_RECEIVEDが異常に増えていないか

まずはOS上で、半開き（ハンドシェイク未完了）のTCPが増えていないかをざっくり見ます。瞬間的な増加は正常でも、継続的に増え続ける場合は要注意です。

REM 半開きの接続（SYN_RECEIVED）をざっくり確認
netstat -an | findstr SYN_RECEIVED

この時点では「SYNが多い」以上のことは断定できません。ですが、次のような状況なら、SYNフラッドだけでなく経路のドロップやLBの設定も含めて調査対象に入ります。

  • SYN_RECEIVEDが増えているのに、アプリのログ上はリクエストが到達していない
  • 特定の送信元（CIDR）に偏る、または特定の時間帯にだけ集中する
  • 外形監視だけが落ち、同一ネットワーク内からは正常に見える

Server 2019で「発動したか」を追う：ETL/ETWを取る

Vista/2008以降のSYN攻撃保護は、発動をイベントログで見分けるのが難しいため、ETLトレースを事前に開始して証跡を取るのが基本方針です。

netsh traceでTCP/IP（Microsoft-Windows-TCPIP）のETLを採取する

Microsoftの案内例として、次のコマンドでTCPIPプロバイダのトレースを取得できます（管理者権限のコマンドプロンプトで実行）。

netsh trace start capture=yes provider=Microsoft-Windows-TCPIP level=0x05 tracefile=TCPIP.etl
netsh trace stop

ETLは「事象が起きてから開始」だと肝心の入口が取れないことがあります。外形監視で再現が難しい場合は、次のように“循環（circular）”で回しながら再現を待つ運用が現実的です（例）。

netsh trace start capture=yes packettruncatebytes=512 tracefile=C:\%computername%.etl maxsize=1000 filemode=circular overwrite=yes report=no
netsh trace stop

また、利用可能なプロバイダやキーワードはnetsh側から確認できます。例えばTCPIPプロバイダの情報を出すなら次の形式です。

netsh trace show provider Microsoft-Windows-TCPIP

Packet Monitor（pktmon）で「どこで落ちたか」まで寄せる

Windows Server 2019には、標準機能としてPacket Monitor（pktmon.exe）があり、パケットキャプチャ・ドロップ検知・フィルタリング・カウントなどを行えます。特に仮想化（コンテナやSDNなど）を含む複雑な経路で、どの層で落ちたかを追いやすいのが強みです。

基本の流れは次の通りです（フィルタ → 開始 → 再現 → カウンタ確認 → 停止 → 解析用に変換）。

REM フィルタのヘルプ確認（例）
pktmon filter add help

REM キャプチャ開始（例）
pktmon start -c

REM カウンタで傾向を確認（例）
pktmon counters

REM 停止
pktmon stop

REM テキスト化（例）
pktmon etl2txt <etl file>

「SYNだけを拾いたい」など、ノイズを抑えた取り方もできます。例えば、特定IPに対するTCP SYNを対象にする例は次の形式です。

pktmon filter add -i 10.0.0.10 -t tcp syn

ログはETL形式で出力されますが、必要に応じてpcapngへ変換してWiresharkなどで解析できます（ETL→pcapng変換の考え方）。

変換コマンドの仕様例は次の通りです（出力名指定やドロップのみ抽出も可能）。

pktmon etl2pcap <file> --out <name>

さらに、pktmonはログモード（循環・マルチファイル・リアルタイム・メモリ）を持ち、既定は循環ログです。長時間再現待ちのときは「いつの間にかログが巨大化する」を避けつつ取り続けられます。

「設定」より効く：Windows Server 2019で現実的なSYNフラッド対策

Windows Server 2019上でレジストリを追加するより、効果と再現性が高い対策を優先するのが現実的です。ここでは“机上の一般論”ではなく、実運用で効きやすい順に整理します。

インターネット直結を避ける（上流で受け止める）

  • 公開サーバーは、可能な限りロードバランサ/リバースプロキシ/CDN/WAFの背後に置く
  • グローバル公開が不要な管理ポート（RDP/WinRM等）は閉じる、または限定した送信元だけ許可する
  • 「サーバーがSYNを受ける前」に弾ける構成にする（回線・境界装置・クラウドDDoS等）

Windows Defender Firewallで“開けるものだけ開ける”を徹底する

  • 不要な受信ポートは閉じる（サービスを止めるだけでなく、ファイアウォールで遮断する）
  • 許可ルールは、可能なら送信元（スコープ）を限定する
  • アプリの公開ポートが少ないほど、攻撃面（attack surface）は小さくなる

アプリ側の“接続スパイク”を潰す

  • 再試行（リトライ）の設計が雑だと、障害時に自分でSYNを増幅させる
  • コネクションプールやKeep-Aliveが効いていないと、短時間に新規接続が集中しやすい
  • 外形監視の頻度・タイムアウト設定が過激だと、監視自身が負荷源になることがある

疑似DDoS（正当な高負荷）ならスケールで解決する

“攻撃”ではなく、キャンペーン・障害時リトライ・バッチ集中などで正当なSYNが増えているケースは珍しくありません。この場合、守りを強める（無効化/有効化）よりも、台数・帯域・LB分散の方が再現性高く効きます。

「SynAttackProtect=0で無効化した」という情報はどう扱うべきか

運用現場のブログや掲示板で「高負荷で切断が増えたのでSynAttackProtect=0を入れて無効化した」という話が出ることがあります。しかし、Microsoft側の説明では、Vista/2008以降は無効化できず、かつレジストリ等で調整するパラメータを公開していないとされています。

このズレが生まれる典型パターンは次の通りです。

ありがちな状況起きがちな誤解切り分けのポイント
レジストリ変更後に改善したキーが効いた再起動・NIC再初期化・ルール更新・タイミング要因など“同時に変わったもの”を疑う
別レイヤでドロップしていたOSのSYN攻撃保護が原因pktmonでドロップ箇所/理由を確認し、OS外（LB/Firewall/仮想スイッチ等）を含めて見る
診断ツールの指摘に追従した未設定=危険OS世代差で“設定項目として存在しない/意味が変わった”可能性を考慮し、根拠を残す

どうしても組織として「レジストリ変更を検討」する状況（例：重大インシデント時の暫定回避）になった場合でも、まずはETL/PKTMONで証跡を採取し、攻撃状態・ドロップ・経路のどこで起きているかを特定してからにしてください。

監査・脆弱性診断で「SynAttackProtect未設定」と言われたときの対応例

実務でよくあるのが、診断ツールやチェックリストが古い基準を参照していて、「SynAttackProtectが設定されていない＝脆弱」という指摘が出るケースです。ここでレジストリを足してしまうと、Windows Server 2019の設計思想（自己調整・非公開パラメータ）と矛盾し、後から説明が難しくなります。

対応としては、次のように“仕様に基づく説明”を残すのが無難です。

  • Vista/2008以降では、SYN攻撃保護は既定で有効で無効化できない
  • しきい値はCPU/メモリなどに基づき動的算出され、レジストリ/netsh等での調整パラメータは公開されない
  • 発動確認はイベントログではなく、ETL/ETWトレース（netsh trace等）で行う

この整理を運用標準（サーバー構築手順、例外申請テンプレ、監査証跡）に落としておくと、担当者が変わっても同じ混乱を繰り返しにくくなります。

運用フロー：迷ったらこの順で進める

ステップやること狙い
1netstatでSYN_RECEIVEDの増加をざっくり確認症状が「SYN系」かを初動で当てる
2上流（LB/WAF/Firewall）のログ・制限値も同時に確認OSの前に落ちていないかを外す
3ETL（netsh trace）またはpktmonで証跡採取“どこで落ちたか”を事実で固める
4対策は「上流で受け止める」「公開面を狭める」「スケール」を優先再現性の高い改善につなげる
5レジストリ変更は最終手段（検証・影響評価・戻し手順を含める）不可逆な混乱・属人化を防ぐ

Windows Server 2019の「SynAttackProtect問題」は、設定の有無よりも“現代OSの既定防御を前提に、観測と設計で勝つ”ことが重要です。古い記事のレジストリ値を追いかけるより、まずはトレースで事実を取り、境界と構成を整えるところから始めてください。

Windows Server
TCP/IP Windows Server 2019 SYNフラッド SynAttackProtect

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次