| ネットワーク WG Request for Comments： 1858 分類： 情報提供 |
G. Ziemba |
IP フラグメントフィルタリングについてのセキュリティ上の考察
(Security Considerations for IP Fragment Filtering)
このメモの位置づけ
要旨
IP フラグメンテーションは、ルーターやホストにおいて使用されている IP フィルタに対して TCP パケットを偽るのに利用することができてしまいます。本書においては、2つの攻撃手法とともに、それらを防ぐための救済策について述べます。
1. 背景 English
システム管理者は、ネットワーキング機器にパケットフィルタ機能を付加して提供するのに、それらのベンダーに依存します。； これらのフィルタは、攻撃者がプライベートなシステムや情報にアクセスすることを防ぐ一方で、友好的な主体がプライベートなネットやインターネット間でデータを転送することを許可するのに使用されます。この理由で、ネットワーク機器のベンダーは、自身の機器について想定される攻撃を予期し、そのような攻撃をかわす丈夫な機構を実装することが重要です。グローバルなインターネットの発展によって、反社会的な行為であることが明らかになってきた「望まれない要素」の増加がもたらされました。最近、インターネットホスト上で、目新しい攻撃法の 利用が観察されています。中には、取り扱いに注意を要するデータの改ざんに至ったものもあります。
熟練した攻撃者たちは、ますます、インターネットプロトコルの些細な点を攻略しようとするようになっています。； 異成分から成るインターネットワークにおいて重要な機能である IP パケットのフラグメンテーションは、我々がここで解き明かす、いくつかの潜在的な問題点を引き起こします。
2. IP フラグメントをフィルタすること English
ルーター上の IP パケットフィルタは、管理者にパケットフラグメンテーションを見せないユーザインターフェイスを持つ設計がなされています。； 概念的には IP フィルタは、完全な形をした各 IP パケットに適用されます。
フラグメントフィルタリングについてのひとつのアプローチに、Mogul によって書かれたもの [1] があり、最初のフラグメント（ FO==0 ）へのフィルタルールの適用結果の記録をとっておき、それらを同じパケットの以降のフラグメントに適用するものです。そのフィルタリングモジュールは、発信元アドレス、宛先のアドレス、プロトコル、IP ID によってインデックスされたパケットのリストを保持します。最初（ FO==0 ）のフラグメントが観察され、MF ビットがセットされていたら、リストの要素がフィルタアクセスチェックの結果を保持するために確保されます。FO が 0 でないパケットが来たら、SA/DA/PROT/ID が一致するそのリストの要素を参照し、その保持された結果（通過もしくはブロック）を適用します。MF ビットが 0 のフラグメントが観察されたら、リストの要素を解放します。
この手法（あるいは、ある種のこの改良）によって、あらゆる攻撃パケット全体をうまく除去することができるでしょうが、これにはいくつかの困難があります。異なる経路を通ってきたといった理由で順序通りに到着しないフラグメントは、ひとつの設計上の仮定を壊し、結果として望まれないフラグメントが漏れてしまう可能性があります。さらに、そのフィルタリングルータが並列の経路のひとつである場合には、そのフィルタリングモジュールは、すべてのフラグメントを観ないでしょうし、ドロップする必要があるパケットについて完全なフラグメントフィルタリングを保証することはできません。
幸い、攻撃パケットのすべてのフラグメントを除去する必要はありません。「興味ある」パケット情報は先頭にあるヘッダーにあるので、フィルタは通常、最初のフラグメントだけに適用されます。最初でないフラグメントは、宛先のホストで最初のフラグメントがない場合、そのパケットの再構築を完遂することは不可能なので、フィルタリングされることなく渡り、それゆえそのパケット全体が捨てられます。インターネットプロトコルは、パケットのフラグメンテーションを、データや計算上のオーバーヘッドの理由で非現実的となるまでに小さくすることができてしまいます。攻撃者は、しばしば典型的なフィルタ機能を攻略し、さもなければ許されないパケットを密かにフィルタを通すために、変わったフラグメントシーケンスを作ることができるようになります。通常の実践においては、そのような病的なフラグメンテーションは決して使用され ないので、通常のオペレーションを妨げる危険がないよう、これらのフラグメントをドロップするのが安全です。
多くの IP 実装について、出ていくパケットのフラグメントサイズを非常に小くすることができます。TCP パケットの TCP ヘッダーフィールドの一部が次のフラグメントの中に入るようになるほど、フラグメントサイズが十分に小さくされた場合には、それらのフィールドのパターンを決めるフィルタルールは一致しないことでしょう。フィルタリング実装が最小フラグメント サイズを規定していない場合には、フィルタに一致しないので、許されないパケットが通過してしまうかもしれません。
STD 5, RFC 791 によれば：
各インターネットモジュールは、68オクテットのデータグラムを、これ以上のフラグメンテーションなしに転送できなければなりません。これは、インターネットヘッダーの上限は 60 オクテットで、最小フラグメントは 8 オクテットだからです。
セキュリティの目的では、ひとつのフラグメントが IP ヘッダーの後ろに少なくとも 8 オクテットのデータを含んでいることを保証するだけでは十分でないことを覚えておいてください。それは、重要なトランスポートヘッダー情報（例： TCP ヘッダーの CODE フィールド）は、8番目のデータオクテットより後ろにある可能性があるからです。
この例において最初のフラグメントには、たった 8 オクテット（最小フラグメントサイズ）のデータしか含まれていません。TCP の場合、これは発信元と宛先のポート番号を含むのには十分ですが、TCP フラグのフィールドは次のフラグメントになってしまいます。
コネクションリクエスト（ SYN=1 と ACK=0 をもつ TCP データグラム）をドロップするフィルタは、最初のオクテットにあるこれらのフラグをテストすることができない可能性があり、典型的には以降のフラグメントにあるそれらを無視します。
フラグメント 1 IP ヘッダー +-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+ | | ... | Fragment Offset = 0 | ... | | +-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+ TCP ヘッダー +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ フラグメント 2 IP ヘッダー +-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+ | | ... | Fragment Offset = 1 | ... | | +-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+ TCP ヘッダー +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3.2 タイニーフラグメント攻撃の予防 English
ルーターにおいて、通過するフラグメントに一定の制限を規定することによって、要するに最初のフラグメントが、すべての必須ヘッダー情報を含むのに十分な大きさをもつようにすることによって、この種の攻撃を防ぐことができます。
「通過した」パケットの最初のフラグメントが、すべての必要なフィールドを持っていることを保証するためには 2つのやり方があり、ひとつは直接的であり、もうひとつは間接的です。
3.2.1 直接的手法 English
｢興味ある｣フィールドを含むのに要求されるトランスポートヘッダーの最小の長さ（つまり、パケットフィルタにとって極めて重要な値）を示す TMIN という数字があります。この長さは、元のフラグメントされていない IP パケットのトランスポート ヘッダーの先頭から測られます。
TMIN は、関連するトランスポートプロトコルの機能であり、正しく設定された特定のフィルタの機能でもあることを覚えておいてください。
直接的手法は、各 0 オフセットのフラグメント中のトランスポートヘッダーの長さを計算し、それを TMIN と比較するものです。トランスポートヘッダー長が TMIN より短い場合には、そのフラグメントは捨てられます。オフセットが 0 でないフラグメントは、チェックされる必要があります。それは、0 オフセットのフラグメントが捨てられた場合、宛先のホストは、再構築を完遂することができないからです。これまでのところ、このようになります。：
if FO=0 and TRANSPORTLEN
< tmin then DROP PACKET
しかしTCP 以外では、通常のトランスポートプロトコルの「興味ある」フィールドはトランスポートヘッダーの最初の 8 オクテットにあるので、オフセットが 0 でないフラグメントに適用することはできません。それゆえ、この執筆時点では、TCP パケットだけがタイニーフラグメント攻撃に対して脆弱で、他のトランスポートプロトコルを運ぶ IP パケットに適用する必要はありません。それゆえ、タイニーフラグメントテストの改良版はこのようになります。：
if FO=0 and PROTOCOL=TCP and TRANSPORTLEN
< tmin then DROP PACKET
しかし、下記のオーバーラッピングフラグメントについての章で検討するように、このテストではすべてのフラグメンテーション攻撃をブロックすることはできず、実際、より一般的なテクニックが使用される場合には不要です。
間接的手法は、0 オフセットのフラグメントの外に「興味ある」ヘッダーフィールドがあるようにするために TCP パケットがフラグメントされている場合、FO が 1 であるフラグメントが存在しなければならないという経験則に依拠します。
逆に FO==1 のパケットが観察されたら、フラグメントセットの中に 8 オクテットの長さのトランスポートヘッダーをもった 0 オフセットのフラグメントがあることを示します。この 1 オフセット フラグメントを捨てることは、受け手のホストにおける再構築をブロックし、上記の直接的手法と同程度に有効です。
現行の IP プロトコル仕様、RFC 791 では、新しいフラグメントが、以前に受け取ったいかなるフラグメントのオーバーラップした部分をも上書きしてしまうことになる、再構築アルゴリズムについて記述しています。
そのような再構築の実装においては、攻撃者は、最初の（ 0 オフセットの）フラグメントは無害なデータを含んでいて（それゆえ管理しているパケットフィルタを通過し）、以降の 0 でないオフセットをもつパケットが（例えば宛先ポートを） TCP ヘッダー情報をオーバーラップして書き換えてしまうような一連のパケットを作成することができてしまいます。これは 0 フラグメントオフセットを持っていないので、次のパケットは、大部分のフィルタ実装を通過してしまうことでしょう。
RFC 815 は、改良版のデータグラム再構築アルゴリズムについて概説していますが、これ自体は主に再構築過程におけるギャップを埋めることに関するものです。この RFC は、オーバーラッピングフラグメントの論点については触れていません。
それゆえ完全に準拠した IP 実装が、オーバーラッピングフラグメント攻撃を受け付けないものであることを保証されているわけではありません。BSD 4.3 の再構築の実装は、先のフラグメントのデータを後のフラグメントのデータよりも優先するようにすることによって、これらの攻撃を避ける注意をしています。しかし、必ずしもすべての IP 実装がオリジナルの BSD コードに基づいているわけではなく、そのようなものの中には脆弱なものもありそうです。
4.1 オーバーラッピングフラグメント攻撃の例 English
この例において、フラグメントは、上記の節で述べた最小サイズの要件を満たすのに十分な大きさです。このフィルタは、TCP コネクション要求パケットをドロップするように設定されています。
最初のフラグメントは、例えば、SYN=0, ACK=1 といったフィルタを通過することができる無害な値をもっています。
8 オクテットのフラグメントをもった、2 番目のフラグメントは、TCP フラグをもっています。これは、例えば、SYN=1, ACK=0 といった最初のフラグメントのものとは異なります。この 2 番目のフラグメントは 0 オフセットのフラグメントではないのでチェックされず、これもまたフィルタを通過します。
RFC 791 にあるアルゴリズムを完全に確認する場合、受け手のホストは「悪い」データが後から着たので、そのパケットをコネクション要求として再構築します。
フラグメント 1
IP ヘッダー
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
| | ... | Fragment Offset = 0 | ... | |
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
TCP ヘッダー
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
.
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Other data) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+フラグメント 2
IP ヘッダー
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
| | ... | Fragment Offset = 1 | ... | |
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
TCP ヘッダー
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
.
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Other data) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
受け手のホストが、新しいデータが以前に受け取ったデータを上書きしないようにする再構築アルゴリズムを持っている場合、フラグメント 2 を先に送信し、フラグメント 1 を次に送ることによって、同様の攻撃を遂行することができてしまいます。
4.2 オーバーラッピングフラグメント攻撃の予防 English
オーバーラップセーフな再構築アルゴリズムを使用することを要求する標準はないので、この攻撃に対するホストの潜在的脆弱性は、極めて大きいといえます。
ルーターの IP フィルタリングコードについて、より良い戦略を採用することによって、この「攻撃」をブロックすることができるようになります。ルーターのフィルタリングモジュールが 0 オフセットでないフラグメントに最小フラグメントオフセットを指定している場合、トランスポートヘッダーのフィルタパラメータ部分中のオーバーラップを防ぐことができます。
TCP フラグフィールドが、0 オフセットでないフラグメントに含まれないようにするための最小値は、TCP の場合、16 オクテットです。TCP フラグメントが FO==1 を持っている場合、これは捨てられる必要があります。それは トランスポートヘッダーに、たった 8 オクテットしかスタートさせないからです。便利なことに、FO==1 フラグメントをドロップさせることによって、前で検討したようにタイニーフラグメント攻撃からも防ぐことができます。
RFC 791 は、IP スタックが 8 バイトの IP データペイロードを、それ以上フラグメンテーションせずに転送（8 バイトごとのフラグメント ）できることを要求します。 IP ヘッダーは、 最大長が 60 バイト（オプションを含む）なので、これはリンク上の最小 MTU は、68 バイトである必要があることを意味します。
典型的な IP ヘッダーは、たった 20 バイトの長さなので、48 バイトのデータを運ぶことができます。この世に誰も、FO=1 をもった TCP パケットを生成したりはしません。それは、上述のシステムが IP データを最小 8 バイトまで フラグメントさせることと、60 バイトの IP ヘッダーを要するからです。
結局、フィルタがタイニーフラグメント攻撃とオーバーラッピングフラグメント攻撃の両方で動作するようにするための一般的なアルゴリズムは、このようになります。：
IF FO=1 and PROTOCOL=TCP
then DROP PACKET
他のトランスポートプロトコルヘッダーにあるフィールドに基づいたフィルタリングが、ルーターによって提供されている場合には、ヘッダーの中におけるそれらのフィールドの位置によって最小値は、より大きい可能性があります。特に、フィルタリングがトランスポートヘッダーの 16 オクテット以降のデータについて許されている場合には、柔軟なユーザインターフェイスと何らかの新しいトランスポートプロトコルのためのフィルタの実装の理由で、FO==1パケットをドロップするだけでは十分ではないことでしょう。
5. セキュリティについての考慮事項 English
このメモ全体が、フラグメントされた IP パケットをフィルタすることについて、セキュリティの観点からの意味合いに関するものです。
6. 謝辞 English
上記の攻撃シナリオは、1995年 5月におけるファイアウォールメーリングリストでの議論から発展しました。参加者には次の方々がいました。： Darren Reed 氏 、Tom Fitzgerald 氏 、Paul Traina 氏。
7. 参考文献 English
[1] Mogul, J.,
"Simple and Flexible Datagram Access Controls for Unix-based Gateways",
Digital Equipment Corporation, 1989年 3月.
[2] Postel, J., Editor,
"Internet Protocol - DARPA Internet Program Protocol Specification",
STD 5, RFC 791, USC/Information Sciences Institute, 1981年 9月.
[3] Postel, J., Editor,
"Transmission Control Protocol - DARPA Internet Program Protocol Specification",
STD 7, RFC 793, USC/Information Sciences Institute, 1981年 9月.
[4] Clark, D.,
"IP Datagram Reassembly Algorithms",
RFC 815, MIT Laboratory for Computer Science/Computer Systems and Communications Group, 1982年 7月.
著者のアドレス
G. Paul Ziemba
Alantec
2115 O'Nel Drive
San Jose, CA 95131EMail： paul＠alantec.com
Darren Reed
Cybersource
1275A Malvern Rd
Melbourne, Vic 3144
AustraliaEMail： darrenr＠cyber.com.au
Paul Traina
cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95028EMail： pst＠cisco.com
翻訳者のアドレス
宮川 寧夫
情報処理振興事業協会
セキュリティセンターEMail： miyakawa＠ipa.go.jp
Copyright (C) The Internet Society (1995). All Rights Reserved.