UDP反射・増幅の方向

公開Webの198.51.100.20:443が突然遅くなり、境界で大量のUDP応答とTCP SYNが観測されました。DDoSなのか、どの資源が詰まっているのか、反射・増幅の送信元IPをどう読むのかを、架空の10分間の障害で調べます。

読む順序は、用語と配置→正常な処理→異常ログ→調査と対策→復旧→演習です。接続・検知・遮断・被害を別々の事実として扱います。以下の構成、時刻、アドレス、ログ、設定値は教材用の架空例です。

1. 用語と役割を構成に結び付ける

用語	この事例での意味と限界
DoS/DDoS	可用性を落とす攻撃。DDoSは複数の送信源・経路を使う。単純な通信量の増加だけでは攻撃とは決まらない。
反射攻撃	攻撃者が被害者IPを送信元に偽装した要求を第三者サーバへ送り、応答を被害者へ向ける。ログ上の送信元は反射サーバであり、必ずしも攻撃者ではない。
増幅攻撃	小さい要求に対し大きい応答が返るサービスを悪用する。倍率は要求と応答のバイト数の比であり、実際の攻撃量はサーバ数や制限で変わる。
ボリューム型	回線帯域や境界装置を埋める。アプリサーバ側で拒否しても上流回線が既に飽和していれば届かない。
SYNフラッド	TCP接続開始を大量に送り、接続状態や処理能力を消費させる。送信元詐称もあり得るが、全てのSYN攻撃が詐称ではない。
アプリケーション層	通常に見えるHTTP要求でバックエンドやDBを圧迫する。バイト数が少なくても業務処理が重い場合がある。

2. 構成と信頼境界

外部公開IP198.51.100.20の手前にISP回線、DDoS緩和サービス、境界FW、WebサーバWEB-7を置きます。回線は1Gbps、WEB-7の通常ピークは150Mbpsとします。攻撃者は送信元を198.51.100.20に偽装して公開DNS等へUDP要求を送り、複数の反射サーバがWEB-7側へ応答を返す想定です。

UDP反射・増幅の方向

1. 送信元偽装：証跡被害IPを送信元に設定／防御・対処送信元検証で抑制
2. 反射サーバ：証跡 UDP応答を生成／防御・対処公開サービスを制限
3. 被害回線：証跡帯域とppsが上昇／防御・対処上流で緩和
4. 業務影響：証跡正規要求が失敗／防御・対処サービスを段階復旧

偽装要求は攻撃者から反射サーバへ、応答は被害IPへ届く。

図の反射サーバは実在する公開サービスかもしれません。被害側で見える送信元IPを直ちに攻撃者の端末とみなさず、偽装要求がどこから出たかは上流・反射側の証拠で調べます。

3. 正常な処理を順に追う

平常時の帯域Mbps、パケット数pps、接続数、HTTP成功率、遅延を時刻付きで記録する。
境界FWは許可されたHTTPSをWEB-7へ送り、監視は正規ピークの変動を確認する。
公開DNSのようなUDP応答はWEB-7へ要求していない限り不要であり、緩和装置のフローで異常な方向を調べる。
攻撃時は上流の緩和先へトラフィックを転送し、正規利用者が到達できるかを業務指標で検証する。

1Gbps回線に900Mbpsの流入があっても、即座に攻撃・飽和確定ではありません。実効容量、pps、装置の状態表、HTTP成功率を合わせます。逆に少量でも高コストなAPI呼び出しはアプリ層の障害になり得ます。

4. 設定値・ログの読み方

項目	値の意味と判断の限界
bps/pps	ビット毎秒とパケット毎秒。大きなUDP応答と小さなSYNでは同じbpsでも装置への負荷が違う。
src_ip/dst_ip	受信側ログのsrcは反射サーバかもしれない。NAT、CDN、プロキシ経由なら利用者のIPとも限らない。
protocol/port	UDP応答、TCP SYN、HTTPS要求を区別。ポートだけで合法・攻撃を断定しない。
syn/ack ratio	SYNに対する成立の比。片側観測や経路差で歪むため、サーバ・FWの状態表と照合する。
HTTP成功率	可用性に直結する指標。境界でdropしても正規要求が成功しなければ緩和は未完了。

次の架空ログではネットワーク負荷と業務影響の開始時刻を並べます。

text

11:00:00 edge=ISP-LINK rx_mbps=148 rx_pps=18000
  http_success=99.8%
11:04:00 edge=ISP-LINK rx_mbps=940 rx_pps=820000
  top_udp_src=203.0.113.53 dst=198.51.100.20
  tcp_syn_pps=120000 http_success=32%
11:06:00 mitigation=enabled rx_mbps=210
  http_success=97%

203.0.113.53は観測されたUDP送信元で、反射サーバの可能性があります。`mitigation=enabled`だけでは成功ではなく、正規HTTP成功率が32%から97%へ戻った点を確認します。なお通常99.8%には届いていないため、残る遅延や地域別失敗を調べます。

5. 攻撃・障害時の差分

異常・攻撃条件	観測、成立条件、対策の位置
UDP反射	送信元を被害IPに偽装できる経路と増幅可能な公開サーバが必要。上流の送信元検証と反射サービスの制限が重要。
SYNフラッド	接続状態を消費する。SYN cookieや上流のフロー制御を評価し、正常な新規接続を巻き込まない。
HTTP層	正規に見える大量要求でDBを圧迫。CDN・キャッシュ、レート制限、認証、重い処理の見直しを併用。
緩和装置の過剰遮断	大規模NAT利用者などを攻撃源と誤認し得る。地域・AS・利用者単位の成功率を見る。
自社が反射源	自社の公開UDPサービスが大きな応答を返すなら、不要な公開を停止し応答制限とパッチを行う。

BCP 38の送信元フィルタは、自組織が偽装パケットを外へ出さないための対策です。被害側の回線が既に飽和しているとき、被害側だけで追加したFWルールでは上流帯域を取り戻せません。ISPや緩和事業者と連携します。

6. 切り分けに必要な証拠

通常時と攻撃時のbps、pps、宛先、プロトコル、送信元分布を比較する。
ISP回線、緩和装置、FW、WEB-7の各段階で破棄数と資源使用率を揃える。
業務のHTTP成功率、p95遅延、認証・決済など重要APIの成功率を確認する。
反射元と見えるIPを攻撃者と断定せず、DNS等の応答方向と要求の有無を調べる。

フロー記録はパケット量と五つ組を示しますが、送信元の人間やボットの操作者を特定しません。WEB-7ログに要求がないのは、上流で捨てられたためか、アプリに到達しなかったためかも切り分けます。

6.1 判断を誤りやすい境界と詳しい確認

確認点	具体的な判断
攻撃規模	bpsは回線容量、ppsは機器のパケット処理能力に効く。例えば平均1,000バイトの10万ppsは概算800Mbpsであり、ヘッダ等を含めると回線負荷はさらに増える。
反射の向き	攻撃者は被害IPを送信元にした小さなUDP要求を反射サーバへ送る。被害側には反射サーバのIPから大きな応答が届く。応答元IPを攻撃者本人と扱わない。
増幅率	応答サイズ/要求サイズは一つの目安だが、帯域の実害は反射元の数、送信頻度、プロトコル、経路で変わる。大きな増幅率だけで被害規模を決めない。
SYNフラッド	TCPのSYNが増え、半開接続やFWの状態表を圧迫する。UDP反射とは転送と対処点が異なる。SYN cookie等の利用可否はサーバ・プロキシ構成で確かめる。
アプリ層	少数の高コストな検索やログインでもDBが詰まる。bpsが低くても成功率が下がれば、API別リクエスト量、p95遅延、DB待ち時間を調べる。
緩和の位置	回線手前の上流で破棄するか、CDN/スクラビングへ経路を切り替える。回線を通過した後のFWだけでは既に飽和した帯域は回復しない。
正規利用者	共有NATや大手プロキシをIP単位で一律遮断すると正規利用者を巻き込む。国やASによる荒い遮断には業務対象の影響評価が必要。

例の時系列では11:04にrx_mbpsが148から940へ、rx_ppsが1.8万から82万へ増え、HTTP成功率が99.8%から32%へ落ちます。回線が詰まったのか、FWの処理能力なのか、WEB-7のアプリ処理なのかは、この三値だけでは決まりません。ISPのインターフェースdrop、FWのCPU/セッション数、WEB-7の到達要求数を同じ時間窓で並べます。

反射攻撃の根本には送信元IP偽装を許すネットワークと、外部から悪用できる応答サービスがあります。BCP 38の送信元検証は偽装パケットを送り出す側で効きます。被害組織はISPと緩和事業者に連絡し、自社サービスが反射源なら不要なUDP公開と大きな応答を制限します。

緩和後の97%成功率は改善ですが、平常時99.8%より低い値です。失敗した利用者が特定地域に偏るなら誤遮断や経路変更が原因かもしれません。通常経路へ戻す際は、監視を残して段階的に戻し、再攻撃時に同じ切替を実行できる状態を保ちます。

7. 設定変更と例外運用

変更・例外	失敗しやすい点と確認
緩和事業者の契約	事前に切替手順、連絡先、許容遅延、DNS・BGPの変更点を確認する。事故中の初設定は遅い。
CDN導入	オリジンIPが直接公開されていればCDNを迂回される。オリジンへの到達条件を制限する。
ブラックホール	被害IP宛てを上流で破棄し回線を守れるが、正規通信も止まる。承認者と復旧条件を決める。
レート制限	共有NATやAPI利用者を巻き込まない単位を選び、例外に期限を付ける。

平常時から安全な負荷試験と緩和切替訓練を行い、攻撃中の変更履歴を保存します。緩和サービスの管理画面に「停止」と出ても、遅れて届くフローや別ベクトルを監視します。

8. 封じ込めと復旧条件

攻撃開始前後のトラフィックと業務指標を保全し、ISPと緩和事業者へ連絡する。
回線飽和なら上流のスクラビングや経路制御を行い、アプリ層なら対象APIのキャッシュ・制限を調整する。
緩和の誤遮断で失敗した正規利用者を確認し、必要な範囲で例外を調整する。
攻撃が収束しても段階的に通常経路へ戻し、重要API成功率と遅延を確認する。
自社が反射源なら公開サービスの制限と送信元検証を確認する。

復旧の基準は単にMbpsが下がったことではありません。正規利用者の成功率、サービスの応答時間、誤遮断、再攻撃時の切替可能性を含めます。

9. 科目B（午後）での解答手順

設問では攻撃者、反射サーバ、被害者の三者を分け、パケットの送信元と受信者を矢印で書きます。次にどこが詰まったかを回線、FW、アプリで特定し、対策をその位置へ当てます。

bpsとpps、HTTP成功率を同じ時刻で比べる。
観測した送信元IPを攻撃者と即断しない。
被害側緩和と送信元偽装対策の適用場所を区別する。

10. 短答演習

演習1：反射元

条件：UDPのsrc=203.0.113.53。質問：攻撃者IPか。

解答：断定不可。反射サーバかもしれない。誤答の理由：被害側から見たsrcだけで操作者を特定している。

演習2：回線飽和

条件：上流回線が満杯。質問：WEB-7のFWだけで直るか。

解答：上流緩和が必要。誤答の理由：被害側へ着く前の帯域を見落としている。

演習3：BCP38

条件：自社送信網で偽装IPを防ぐ。質問：被害側の通信を直接止めるか。

解答：主に偽装パケットの発生を抑える。誤答の理由：適用するネットワークの方向を混同している。

演習4：成功率

条件：rx_mbps低下後も成功率97%。質問：完全復旧か。

解答：通常99.8%との差を調べる。誤答の理由：帯域だけを復旧指標にしている。

演習5：SYNとUDP

条件：SYNが増えた。質問：全て反射攻撃か。

解答：違う。SYNフラッドとUDP反射を分ける。誤答の理由：複数の攻撃ベクトルをまとめている。

演習6：ブラックホール

条件：上流で被害IPを破棄。質問：正規通信はどうなるか。

解答：同時に停止する。誤答の理由：可用性への副作用を無視している。

11. 一次資料

CISA：UDP反射・増幅攻撃

RFC 2827：送信元IPの入口フィルタ

RFC 3704：複数回線での送信元検証

DDoSと反射・増幅攻撃の分析・緩和