開いているポートでも通してはいけない – 接続状態とパケット構造の検証

ポート許可が前提としているもの

「公開 Web サーバーへの TCP/443 を許可する」というルールは、通常、HTTPS サービスの公開要件を表しています。しかし、ファイアウォールが実際に処理するのは HTTPS という概念ではなく、IP ヘッダーや TCP ヘッダーを解析した結果、指定した条件に一致したパケットです。

このルールが正しく機能するためには、ファイアウォールがパケットを一意に解釈できなければなりません。フラグメントを正しく再構成できること、TCP の状態遷移を追跡できること、戻り通信を既存セッションへ関連付けられることも前提になります。これらが成立しなければ、宛先ポートが 443 であっても、許可した HTTPS 通信と同じものとして扱う根拠はありません。

検証層	成立条件	成立しない場合
パケット構造	ヘッダー、長さ、フラグを一意に解析できる	構造異常または解析不能として処理
フラグメント	元のパケットを矛盾なく再構成できる	再構成失敗または検査回避の可能性
接続状態	既存セッションまたは正常な開始条件と対応する	状態不明または不正な遷移として処理
サービスポリシー	送信元、宛先、プロトコル、ポートが許可条件に一致する	ポリシー違反として処理

ポート番号による許可は、この検証を通過した後に適用される条件の一つです。

この記事は「ポート番号から考えないファイアウォール設計」シリーズの第 3 回です。ここでは、ポート許可の前提になる接続状態、パケット構造、フラグメント、IPv6 拡張ヘッダーを扱い、許可ポートでも通してよいとは限らない理由を整理します。

コネクション追跡は正当性を保証しない

ステートフルファイアウォールは、パケットを個別に評価するだけでなく、過去に観測した通信との関係を保持します。Linux Netfilter では、代表的にNEW、ESTABLISHED、RELATED、INVALID、UNTRACKEDといった状態が使われます。

ただし、これらは TCP の状態遷移そのものではなく、コネクション追跡機能による分類結果です。

状態	設計上の解釈
NEW	追跡を開始した通信。正常な TCP 接続開始を保証するものではない
ESTABLISHED	既存エントリーに属する通信。アプリケーション上の正当性は別問題
RELATED	既存通信から派生したと解析された通信。ヘルパーや ICMP 解析に依存する
INVALID	既存状態へ関連付けられない、または正常に解析できない通信
UNTRACKED	設計上、追跡対象から除外した通信

TCP の新規接続を許可する場合、NEWという分類だけでは不十分です。既存状態がない ACK や FIN がNEWとして扱われる実装や条件もあるため、公開サービスへの新規通信は TCP の開始条件と合わせて評価する必要があります。

ESTABLISHEDも、そのパケットが安全であることを意味しません。既存フローに属するというだけで、アプリケーションデータの妥当性、認証状態、通信内容までは保証しません。

反対に、INVALIDは破棄対象として扱うのが基本ですが、攻撃と同義ではありません。非対称ルーティング、状態タイムアウト、HA 切り替え時の同期漏れ、極端な遅延、フラグメント再構成失敗、状態テーブルの資源不足などでも発生する可能性があります。

INVALIDの増加を検知した場合、単に遮断件数として評価するのではなく、経路異常、状態同期、装置性能、攻撃のどれに起因するかを分離する必要があります。

TCP はフラグの一覧ではなく状態遷移で見る

TCP は SYN、ACK、FIN、RST などを使って接続状態を遷移させます。現在の TCP 標準である RFC 9293 も、受信セグメント、フラグ、アプリケーションからの要求、タイムアウトを組み合わせた状態機械として TCP を定義しています。

SYN と FIN、SYN と RST、全フラグ、フラグなしといった組み合わせは、古くからスキャン検知や異常パケットの例として使われてきました。これらを検査する意味は残っていますが、固定的な TCP フラグ一覧を手作業で管理することが設計の中心ではありません。

同じ ACK、FIN、RST でも、現在のセッション状態によって正当性が変わります。確認すべきなのはフラグ単体ではなく、次の関係です。

観点	TCP の正当性を判断する条件
TCP フラグ	SYN、ACK、FIN、RST などの組み合わせが状態と矛盾しないか
現在の接続状態	新規、確立済み、終了処理中、状態なしのどれとして説明できるか
シーケンス番号	既存セッションのシーケンス空間と整合するか
ACK 番号	相手方向の送信済みデータと対応するか
受信方向	その方向から届くパケットとして自然か

例えば、確立済みセッションに属する FIN と、状態のない外部ホストから突然届く FIN は同じではありません。RST についても、既存セッションのシーケンス空間と整合するかによって扱いが変わります。

現代的なファイアウォールでは、TCP 正規化、シーケンス検査、状態遷移検査などを製品機能として実装している場合があります。設計では個々の異常フラグを列挙するより、製品がどこまで TCP を検証し、異常時にどのような処理を行うかを確認すべきです。

独自ルールと標準機能を重複させると、誤検知だけでなく、ハードウェア処理から低速なソフトウェア処理へ移る可能性もあります。

UDP と ICMP にも状態の概念はある

UDP には TCP のような接続確立と終了処理がありません。それでもステートフルファイアウォールは、送信元・宛先アドレス、ポート番号、プロトコルなどから一時的な状態を作り、内部から開始した通信への応答を識別します。

この状態はプロトコル上の接続ではなく、ファイアウォールが一定時間保持する対応関係です。タイムアウトを短くすれば状態テーブルの消費を抑えられますが、遅延した正常応答を破棄しやすくなります。長くすれば応答を受け入れやすくなる一方、不要な状態を保持し続けます。

DNS のような短時間の要求応答と、QUIC のような長時間動作する UDP ベースの通信を同じタイムアウトで扱うことには無理があります。

ICMP や ICMPv6 のエラーには、原因となった元パケットの情報が含まれます。ファイアウォールはその情報を既存の状態と照合し、実在する通信に対応するエラーか判断できます。RELATEDとして許可する場合も、単に ICMP Type を見るのではなく、内包された元パケットをどこまで検証しているかが重要です。

FTP などのプロトコルヘルパーによるRELATEDも同様です。制御通信から動的に別フローを許可する機能は便利ですが、ヘルパーが解析できるプロトコル、暗号化の有無、開放される通信範囲を確認しなければ、許可範囲が設計者の想定より広がります。

フラグメントではファイアウォールと宛先の解釈を一致させる

IP フラグメントでは、一つのパケットが複数の断片へ分割されます。最初のフラグメントに TCP または UDP ヘッダーが含まれていても、後続フラグメントにはポート番号や TCP フラグが含まれない場合があります。そのため、フラグメントを個別に評価するだけでは、すべての断片へ同じ L4 ポリシーを適用できません。

ここで重要なのは、ファイアウォールと宛先ホストが同じパケットを再構成することです。両者が重複部分を異なる規則で処理すれば、ファイアウォールが検査した内容と、サーバーが受信する内容が変わります。これはポートフィルターや侵入防止機能を回避する経路になります。

IPv6 では重複フラグメントが明示的に禁止されており、再構成中に重複が確認された場合は、パケット全体を破棄することが求められています。

また、IPv6 の最初のフラグメントには、上位層までの完全なヘッダーチェーンが含まれていなければなりません。 ファイアウォールが最初のフラグメントから TCP や UDP まで到達できなければ、ポートベースのポリシーを適用できないためです。

一方、フラグメントが存在するだけで不正と判断することもできません。RFC 8900 は IP フラグメンテーションが通信へ脆弱性と運用上の不安定性を持ち込むことを整理していますが、すべてのフラグメントを廃止しているわけではありません。

ファイアウォール設計では、少なくとも次を明確にする必要があります。

• ポリシー評価前に再構成するのか
• 後続フラグメントをどの状態へ関連付けるのか
• 重複、不足、タイムアウトをどう処理するのか
• 再構成用メモリーの上限をどう設定するのか
• 上限到達時に新規フラグメントと既存フローのどちらを優先するのか

フラグメント検査はパケット形式の問題であると同時に、再構成用資源の管理でもあります。

IPv6 拡張ヘッダーと解析上限

IPv6 では基本ヘッダーと TCP、UDP、ICMPv6 などの上位プロトコルの間に、複数の拡張ヘッダーが存在する場合があります。ファイアウォールが宛先ポートを確認するには、ヘッダーチェーンを解析して上位プロトコルへ到達しなければなりません。

装置には、解析できるヘッダー数、バイト数、繰り返し回数などの上限があります。上限を超えたパケットが低速処理へ送られる場合は、コントロールプレーンや CPU に対する DoS も考慮する必要があります。

一方、解析できないという実装上の都合だけで標準拡張ヘッダーを一律に破棄すれば、正常な通信を阻害します。

したがって、必要なのは「IPv6 拡張ヘッダーを許可するか」という一括判断ではなく、拡張ヘッダーごとに次を確認することです。

確認項目	設計上の意味
利用要件	そのネットワークで実際に使用するか
解析能力	装置が上位プロトコルまで追跡できるか
処理経路	ハードウェア処理か、低速処理か
解析上限	ヘッダー数・長さの上限はどこか
上限超過時	許可、破棄、拒否、レート制限のどれか
可視性	理由別カウンターやログを取得できるか

標準 IPv6 拡張ヘッダーの処理は、装置が認識できなかった結果として暗黙に落とすのではなく、設定可能なポリシーとして扱うことが求められています。

状態管理は経路と冗長化を含めて成立する

ステートフルファイアウォールは、原則として通信の両方向を観測する必要があります。行きと戻りが異なる装置を通る場合、一方のファイアウォールには戻り通信へ対応する状態が存在しません。

BGP マルチホーム、ECMP、Active-Active 構成、クラウド接続などで非対称ルーティングが発生すると、正常な応答がINVALIDまたは新規通信として扱われる可能性があります。HA 切り替えでも、セッション、NAT、フラグメント再構成状態が同期されていなければ同じ問題が生じます。

そのため、状態管理の設計には次の項目が含まれます。

項目	確認内容
経路対称性	双方向通信を同じ検査点で観測できるか
セッション同期	HA 装置間でどの状態を同期するか
NAT 同期	変換情報を切り替え後も維持できるか
UDP タイムアウト	アプリケーション特性と一致しているか
フラグメント状態	再構成途中の情報を維持・同期できるか
障害時動作	既存通信を維持するか、再接続させるか
テーブル枯渇時	新規状態の拒否と既存状態の保護をどう行うか

ステートフル検査は単体機能ではなく、ルーティング、HA、NAT、タイムアウト、装置資源を含むシステムとして成立します。

試験で確認すべきもの

許可した TCP/443 へ接続できることだけを確認しても、パケット構造と接続状態の検証にはなりません。正常系に加えて、状態不一致、再構成異常、解析限界、フェイルオーバーを試験する必要があります。

試験	確認する動作
正常な TCP 接続と再送	正常な状態遷移を誤破棄しない
状態のない ACK、FIN、RST	開放ポートでも新規通信として通さない
UDP 要求と遅延応答	タイムアウト設計と実通信が一致する
関連・非関連の ICMP エラー	元フローとの照合が機能する
正常・重複・欠落フラグメント	再構成と破棄動作が一貫する
IPv6 拡張ヘッダー	上位層まで解析し、同じポリシーを適用できる
非対称ルーティング	正常通信を状態不一致として落とさない
HA 切り替え	セッションと NAT 状態を設計どおり維持する
状態テーブル高負荷	既存通信を保護し、監視可能な状態になる

破棄ログを無制限に出力すれば、異常通信そのものよりログ処理が装置を圧迫します。理由別カウンターを基本とし、ログはレート制限し、必要な場合だけパケットを取得する方が実用的です。

まとめ

サービスポートの許可ルールは、パケットを正しく解釈でき、接続状態へ一意に関連付けられることを前提としています。

したがって、ファイアウォール設計ではポート番号に加えて、TCP 状態遷移、UDP タイムアウト、ICMP エラーとの関連、フラグメント再構成、IPv6 拡張ヘッダー、非対称ルーティング、HA 同期、状態テーブルの限界まで確認する必要があります。

TCP フラグの拒否パターンを大量に並べることが目的ではありません。ファイアウォールと宛先ホストがパケットを同じように解釈し、そのパケットを正しい通信状態へ関連付けられることが重要です。

TCP/443 が開いていることと、その TCP/443 パケットを通してよいことは同じではありません。

参考資料

• Netfilter iptables-extensions manual
• RFC 9293 – Transmission Control Protocol (TCP)
• RFC 5722 – Handling of Overlapping IPv6 Fragments
• RFC 7112 – Implications of Oversized IPv6 Header Chains
• RFC 8900 – IP Fragmentation Considered Fragile
• RFC 9288 – Filtering IPv6 Packets Containing IPv6 Extension Headers