正常なパケットは、どこから攻撃になるのか – 通信量と資源から考えるファイアウォール設計

パケットの正当性と通信量の妥当性は別である

正常な TCP SYN、UDP クエリー、ICMP Echo Request であっても、短時間に大量に到着すれば、回線、セッションテーブル、CPU、ログ領域、バックエンドの処理能力を消費します。個々のパケットがプロトコル上正しく、許可されたサービスへ向かっていても、通信全体がシステムの処理限界を超えれば、正常な利用を阻害します。

このとき、ファイアウォールが判断できるのは送信者の悪意ではありません。正規利用者の集中、設定ミス、監視の暴走、アプリケーション障害でも、攻撃と同じような負荷が発生します。ファイアウォールが扱うべきなのは意図ではなく、通信が資源に与える影響です。

したがって、通信の許可条件には、プロトコル、接続状態、送信元、宛先、ポート番号だけでなく、処理可能な量であることも含まれます。

項目	許可可能な通信に含める条件
通信要件	送信元、宛先、プロトコル、サービスが許可条件に合うか
プロトコル	形式と状態遷移が成立しているか
接続状態	既存状態または正常な開始条件と対応するか
資源	帯域、pps、cps、セッション、CPU、ログなどの許容範囲内か

問題になるのは、何パケットを超えたら攻撃かという単純な境界ではありません。どの通信が、どの資源を、どれだけ消費するかを明らかにする必要があります。

この記事は「ポート番号から考えないファイアウォール設計」シリーズの第 5 回です。ここでは、単体では正常なパケットが、量、継続時間、分散数、処理コストによって資源を圧迫する条件を扱います。

ファイアウォールが保護する資源

通信量を考えるとき、帯域だけを見ても十分ではありません。同じ 1 Gbps でも、大きなパケットを転送する場合と、小さなパケットを大量に処理する場合では、装置へ与える負荷が異なります。

資源	主な指標	枯渇時の影響
回線帯域	bps	正常通信を含めて回線上で廃棄
パケット処理能力	pps	小さいパケットの大量処理で装置が飽和
新規接続処理	cps	セッション生成やポリシー評価が追いつかない
セッションテーブル	同時セッション数	新しい通信状態を作成できない
TCP 半開状態	Half-open 数	正常な TCP 接続を受け付けられない
NAT 資源	変換エントリー、送信元ポート	新規 NAT 変換を作成できない
フラグメント再構成領域	断片数、再構成待ち容量	正常なフラグメントを保持できない
Neighbor Cache	ARP／NDP エントリー数	新しい近隣へ到達できない
コントロールプレーン	CPU、キュー、例外パケット数	ルーティングや管理機能が停止
ログ処理	件数、書き込み量、転送帯域	ディスクやログ基盤が飽和
バックエンド	リクエスト数、処理時間、接続数	ファイアウォールは通過してもサービスが応答不能

ファイアウォールのスループットが十分でも、セッション生成性能やコントロールプレーンが先に限界へ達することがあります。反対に、ファイアウォールが処理できても、その先のロードバランサーや Web サーバー、DNS サーバーが先に枯渇する場合もあります。

通信量による制御は、最初に限界へ達する資源を基準に設計する必要があります。

bps だけでは通信負荷を表せない

ネットワーク機器の性能は、bps だけでなく pps や cps にも制約されます。大きなパケットを少数転送する場合は帯域が先に限界へ達し、小さなパケットを大量に送信する場合は、帯域を使い切る前にパケット処理能力が限界へ達する可能性があります。

ステートフルファイアウォールでは、新規フローの最初のパケットに対して、既存状態の検索、ポリシー評価、NAT 割り当て、ログ生成、脅威検査などを行います。既存セッションの後続パケットより、新規接続の方が処理コストが高くなる構成もあります。

そのため、次の指標を分けて監視します。

指標	確認する負荷
bps	回線および転送帯域
pps	パケット単位の処理能力
cps	新規セッション生成能力
同時セッション数	状態保持に必要なメモリー
Half-open 数	TCP 接続確立前の状態
セッション継続時間	長時間保持される資源
送信元・宛先の分散数	単一攻撃か分散攻撃か
アプリケーション処理時間	1 リクエスト当たりのバックエンド負荷

1 秒当たりの通信量が少なくても、終了しない接続を大量に保持すれば資源を枯渇させられます。反対に、短いバーストが大きくても、装置やアプリケーションが吸収できるなら制限する必要はありません。

通信の瞬間値、継続時間、同時数、1 件当たりの処理コストを分けて考える必要があります。

SYN フラッドはパケット数ではなく状態作成を狙う

TCP SYN は、公開サービスへ接続するために必要な正常パケットです。しかし、サーバーやファイアウォールが SYN を受信するたびに半開状態を作成する場合、応答を完了しない SYN を大量に送信することで状態資源を消費できます。

SYN フラッドへの対策には、SYN キャッシュ、SYN Cookie、SYN Proxy、半開状態のタイムアウト調整、接続数制限などがあります。RFC 4987 では、SYN フラッドの仕組みと、SYN キャッシュや SYN Cookie などの対策およびそのトレードオフが整理されています。

SYN Cookie は、3 ウェイハンドシェイクが完了するまで通常の接続状態を保持しないことで、半開状態の消費を抑えます。SYN Proxy も、クライアントとの接続成立を確認してからバックエンドへ接続します。ただし、これらは処理を消しているわけではありません。

SYN Proxy を導入すると、バックエンドが処理していたハンドシェイクをファイアウォールやロードバランサーが引き受けます。バックエンドの状態消費は抑えられますが、今度は SYN Proxy 側の pps、暗号計算、状態管理、応答生成能力が制約になります。

防御策によって負荷は消滅せず、より処理しやすい場所へ移動します。

また、送信元単位の SYN 制限だけでは十分ではありません。送信元が偽装されている場合や、多数の送信元から分散して到着する場合は、各送信元のレートが低くても全体として状態を枯渇させられます。一方、CGN や大規模プロキシの背後では、多数の正規利用者が同じ送信元 IP アドレスを共有します。送信元 IP アドレス単位の厳しい制限は、正規利用者をまとめて遮断する可能性があります。

UDP と QUIC では応答前の検証が難しい

UDP には TCP の 3 ウェイハンドシェイクがありません。送信元アドレスを偽装したパケットでも、UDP ヘッダーとしては正常に見えます。受信側が入力より大きな応答を返すサービスであれば、反射・増幅攻撃にも利用されます。

ステートフルファイアウォールは UDP フローについて一時的な状態を作成しますが、無条件に状態を作れば、異なる 5 タプルを持つ UDP パケットの大量送信によってセッションテーブルを消費されます。状態を作らずに処理すれば資源消費は抑えられますが、戻り通信の制御精度が下がります。

QUIC も UDP 上で動作するため、TCP SYN Cookie と同じ対策をそのまま適用できません。QUIC では Retry を使い、クライアントが送信元アドレスでパケットを受信できることを確認してからサーバー側の状態を確保できます。RFC 9312 は、QUIC Retry を SYN Cookie に相当する機能として説明しています。

ここでも、Retry によって処理がなくなるわけではありません。トークンの生成・検証、暗号処理、パケット送信は残るため、どの層でどのコストを負担するかを確認する必要があります。

ICMP と IPv6 制御通信は一律に制限しない

ICMP Echo Request や ICMP エラーも、大量に送信されれば帯域、CPU、ログを消費します。しかし、すべての ICMP Type へ同じ制限を適用すると、Path MTU Discovery、到達不能通知、Neighbor Discovery など、通信の成立に必要な機能まで失われます。

ICMP の制限は、少なくとも次の単位に分ける必要があります。

• Echo Request／Reply
• Destination Unreachable
• Packet Too Big
• Time Exceeded
• Router Solicitation／Advertisement
• Neighbor Solicitation／Advertisement
• 装置自身への通信
• ファイアウォールを通過する通信

IPv6 では、広いアドレス範囲へパケットを送信して Neighbor Cache の生成を誘発し、NDP 関連の状態や CPU を消費させる攻撃も考えられます。対策は ICMPv6 全体の制限ではなく、公開する IPv6 アドレスの限定、Neighbor Cache の上限、優先度制御、NDP 処理のレート制限などを組み合わせます。

必要な制御通信を維持しながら、制御通信が消費できる資源に上限を設けることが目的です。

コントロールプレーンは転送性能と別に保護する

ルーターやファイアウォールの転送処理がハードウェアで実行されていても、装置自身へ向かう通信や例外パケットは CPU へ送られる場合があります。

対象には、次のような通信があります。

• BGP、OSPF、IS-IS などのルーティングプロトコル
• SSH、HTTPS、SNMP などの管理通信
• ARP、NDP
• ICMP／ICMPv6
• TTL または Hop Limit が尽きたパケット
• IPv4 Options や IPv6 拡張ヘッダーを持つパケット
• フラグメントや解析不能パケット
• 未知の宛先や例外処理が必要なパケット

データプレーンでは数百万 pps を転送できても、CPU へ送られる例外パケットを同じ量だけ処理できるとは限りません。RFC 6192 では、正当なコントロールプレーン通信を識別し、それ以外を転送プレーンで遮断またはレート制限する考え方が示されています。

コントロールプレーン保護では、すべての CPU 向け通信を一つのクラスへまとめるべきではありません。ルーティングプロトコル、管理通信、ICMP、ARP／NDP、未知プロトコルでは、重要度と通常時の発生量が異なります。

クラス	設計例
ルーティングプロトコル	正規ピアとインターフェースを限定し、優先度を高く設定
管理通信	管理ネットワークからのみ許可し、接続数も制限
ARP／NDP	リンク単位で必要量を見積もり、異常増加を制限
ICMP エラー	必要な Type を維持し、過剰分を制限
Echo	診断要件に応じて低い優先度で制限
未分類例外	低い上限を設定し、超過分を破棄

CPU 使用率だけではなく、コントロールプレーンへ送られる理由別の pps とドロップ数を監視する必要があります。

ログ出力が DoS を完成させる場合がある

破棄したパケットをすべてログへ記録すると、通信自体の処理よりログ生成の方が大きな負荷になる場合があります。

ログ出力には、次の資源が必要です。

• CPU によるメッセージ生成
• メモリー上のバッファー
• ローカルディスクへの書き込み
• Syslog 転送帯域
• ログ収集基盤の受信処理
• インデックス作成と保存領域
• アラート処理

攻撃者が意図的に拒否ルールへ一致するパケットを大量送信すれば、ファイアウォールだけでなく、ログ基盤や監視担当者まで巻き込めます。

異常通信の把握には、パケットごとのログより理由別カウンターを基本とし、詳細ログはレート制限、サンプリング、集約を組み合わせます。

項目	ログ取得の段階
理由別カウンター	通常時は集計値で異常傾向を把握する
閾値超過	必要なときだけアラートする
詳細ログ・パケット取得	調査に必要な時間と範囲に限定する

ログを残すことと、すべてのパケットを記録することは同じではありません。

閾値は正常値と限界値の間に置く

レート制限を設計するには、正常時の通信量だけでなく、装置やサービスの限界を把握する必要があります。

例えば、通常時の新規接続が 100cps で、ピーク時に 500cps まで増えるサービスへ、経験則だけで 200cps の制限を設定すれば、正常なピークを遮断します。反対に、装置が 5,000cps で限界になるのに、4,900cps を許可すれば、わずかな変動や別処理の増加で余裕を失います。

閾値は次の関係から決めます。

項目	閾値を置く位置
正常ピーク	通常運用で発生し得る最大値
制限開始値	正常ピークを超えたところで制御を始める値
継続可能な処理限界	装置やサービスが安定して維持できる上限
破綻点	通信や運用が維持できなくなる領域

ここで必要になるのが、性能試験と実トラフィックの観測です。

• 通常時の平均値
• 時間帯別のピーク
• 瞬間的なバースト
• キャンペーンや障害時の増加
• フェイルオーバー時に片系へ集中する量
• 装置の継続可能な処理能力
• セッションテーブルや CPU の限界
• バックエンドが維持できる要求数
• 運用上必要な余裕

カタログ上の最大性能は、実際のポリシー、パケットサイズ、ログ、脅威検査、暗号処理を有効にした状態の性能とは限りません。閾値は実際の機能構成に近い条件で測定する必要があります。

レートとバーストを分ける

正常な通信には、短時間のバーストが発生します。平均レートだけを基準にすると、瞬間的な増加をすべて破棄することになります。

トークンバケット型のレート制限では、継続的に許可するレートと、一時的に吸収するバースト量を分けて設定できます。

項目	レートとバーストの分離
許可レート r	継続的に処理できる通信量
許容バースト b	短時間だけ吸収できる超過量

項目	ログ取得の段階
理由別カウンター	通常時は集計値で異常傾向を把握する
閾値超過	必要なときだけアラートする
詳細ログ・パケット取得	調査に必要な時間と範囲に限定する

rは継続的に処理できる通信量、bは短時間だけ吸収できる超過量を表します。

バーストを大きくすれば正常な急増を吸収できますが、短時間に大きな負荷がバックエンドへ到達します。小さくすれば保護は強くなりますが、正規利用者の同時接続や再接続を破棄しやすくなります。

レート制限は、平均値を抑える機能ではなく、どの程度の瞬間負荷をどこで吸収するかを決める機能です。

送信元単位の制限だけでは足りない

送信元 IP アドレス単位の制限は分かりやすい一方、次の問題があります。

• DDoS では多数の送信元へ分散される
• 送信元 IP アドレスが偽装される
• CGN 配下の多数利用者が同じ IP アドレスを共有する
• CDN やプロキシ経由で送信元が集約される
• IPv6 では一つの利用者が多数のアドレスを使用できる
• 低レートの通信を長時間維持する攻撃には効きにくい

そのため、制限軸を組み合わせます。

制限軸	主な目的
送信元単位	単一ホストの暴走や攻撃を抑える
送信元プレフィックス単位	IPv6 アドレス変更や同一組織からの集中を扱う
宛先単位	特定サービスの資源を保護する
サービス単位	TCP/443、DNS などの特性に合わせる
ゾーン単位	内部、外部、管理などで上限を分ける
全体上限	装置全体の破綻を防ぐ
同時接続数	長時間接続による状態消費を抑える
新規接続数	セッション作成負荷を抑える
処理時間	高コストな要求の占有を抑える

複数の制限を階層的に適用し、一部の送信元だけで資源を独占できないようにします。

境界ファイアウォールへ到達してからでは遅い場合がある

攻撃トラフィックがインターネット回線の帯域を使い切った場合、境界ファイアウォールで破棄しても正常通信は回線を通過できません。ファイアウォールが十分な性能を持っていても、保護対象の手前で帯域が枯渇しています。

この場合、破棄位置を上流へ移す必要があります。

破棄位置	保護できる資源	主な手段
ホスト・サーバー	アプリケーション、OS 資源	接続制限、アプリケーション制御
ロードバランサー・FW	バックエンド、セッション資源	SYN Proxy、レート制限
境界ルーター	FW、内部ネットワーク	ACL、CoPP、FlowSpec など
ISP・上流網	インターネット回線	スクラビング、RTBH、上流フィルター
送信元に近い網	ネットワーク全体	Ingress Filtering、送信元制御

Remote Triggered Black Hole は、攻撃対象への通信を上流で破棄し、ネットワーク全体への影響を抑える手法です。 ただし、攻撃通信だけでなく対象宛ての正常通信も破棄するため、サービス継続を犠牲にしてネットワークを保護する方法です。

スクラビングサービスは正常通信と攻撃通信を分離しようとしますが、検査基盤への経路変更、容量、誤検知、復旧手順が必要になります。上流対策も負荷をなくすわけではなく、より大きな設備を持つ場所へ処理を移しています。

防御策を評価するときは、何を防いだかだけでなく、負荷と障害範囲をどこへ移したかを確認する必要があります。

正常通信を残すための優先制御

資源が不足したとき、すべての通信を同じ割合で破棄すると、ルーティング、監視、管理、既存セッションなど、復旧に必要な通信まで失われます。

そのため、重要度に応じた優先制御を設計します。

1. ルーティングや冗長化など、ネットワーク維持に必要な通信
2. 既存の確立済みセッション
3. 管理・監視通信
4. 重要サービスへの新規接続
5. 一般サービスへの新規接続
6. 診断通信
7. 未分類または低優先度の通信

必ずしもこの順序がすべての環境に当てはまるわけではありませんが、資源不足時に何を残すかを決めておく必要があります。

既存セッションを優先すればサービス継続性は高まりますが、新規利用者が接続できなくなります。新規接続を広く受け入れれば公平性は高まりますが、既存通信を含めて不安定になる可能性があります。どの通信を守るかは、サービス要件と障害時の運用方針から決めます。

試験では限界到達後の動作を確認する

性能試験では最大値だけでなく、限界に近づいたときと、限界を超えた後の動作を確認します。

試験	確認内容
短時間バースト	許容したバーストを吸収できる
継続的な高負荷	制限開始値と安定時の処理量
高 pps・低 bps	小パケット処理の限界
高 cps	新規セッション生成の限界
長時間接続	セッションテーブルの消費
Half-open 接続	SYN 対策とバックエンド保護
分散送信元	送信元単位制限を回避された場合の動作
コントロールプレーン負荷	ルーティングや管理通信を維持できる
ログ大量発生	ログ処理が装置性能を奪わない
HA 切り替え中の負荷	片系集中時にも制限が機能する
上限超過	既存通信、管理通信、復旧経路を維持できる
負荷回復	制限解除後に自動で正常状態へ戻る

最大性能を一度記録するだけでは、実運用の限界を定義できません。継続可能な処理量、バースト耐性、破綻時の挙動、回復条件まで確認する必要があります。

まとめ

正常なパケットと攻撃パケットの間に、パケット単体で判定できる境界があるとは限りません。正当な SYN、UDP、ICMP、NDP であっても、量、継続時間、分散数、処理コストによってシステム資源を枯渇させます。

通信量によるファイアウォール設計では、単純な pps 閾値ではなく、回線帯域、パケット処理、新規接続、セッション、NAT、再構成領域、Neighbor Cache、コントロールプレーン、ログ、バックエンドを分けて考える必要があります。

また、防御策は負荷を消しません。SYN Proxy は負荷をバックエンドからファイアウォールへ移し、CoPP は CPU へ到達する前に転送プレーンで制限し、上流 DDoS 対策は処理を ISP やスクラビング基盤へ移します。RTBH はサービス到達性を犠牲にしてネットワーク全体を保護します。

どの通信を、どの量まで受け入れ、限界時に何を残し、どこで破棄するかを定義することが、資源保護としてのファイアウォール設計です。

参考資料

• RFC 4987 – TCP SYN Flooding Attacks and Common Mitigations
• RFC 9312 – Manageability of the QUIC Transport Protocol
• RFC 6192 – Protecting the Router Control Plane
• RFC 5635 – Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding