Network Working Group S. Bellovin Request for Comments: 3514 AT&T Labs Research Category: Informational 1 April 2003 IPv4 ヘッダにおけるセキュリティフラグ このメモの位置づけ このメモはインターネットコミュニティのための情報を提供するものであ る。これはいかなる種類のインターネット標準を規定するものではない。 このメモの配布に制限はない。 著作権表示 Copyright (C) The Internet Society (2003). All Rights Reserved. 概要 ファイヤウォール、パケットフィルタ、侵入検知システム、などのシステ ムにおいては、悪意のあるパケットと単にちょっと変わっているだけのパ ケットとを区別することが困難であるという場合がよくある。我々はこの 二つの場合を区別するための意味を持つ、 IPv4 ヘッダのセキュリティフ ラグを定義した。 1. はじめに ファイヤウォール[CBR03]、パケットフィルタ、侵入検知システム、などの システムにおいては、悪意のあるパケットと単にちょっと変わっているだ けのパケットとを区別することが困難であるという場合がよくある。ここ での問題点は、そのような判別を行うのは非常に難しいということである。 我々はこの問題を解決するために、IPv4 [RFC791] に「邪悪ビット」と呼 ばれるセキュリティフラグを定義した。善良なパケットではこのビットを 0 に設定し、攻撃に使用されるパケットではこのビットを 1 に設定する。 1.1. 用語の定義 この文書において次の各キーワード MUST(しなければならない)、MUST NOT (してはならない)、REQUIRED(必須)、SHALL(すべし)、SHALL NOT(すべから ず)、SHOULD(した方が良い)、SHOULD NOT(しない方が良い)、RECOMMENDED (推奨)、MAY(しても良い)、OPTIONAL(省略可)が使用されている場合、その 意味は [RFC2119] で記述されている意味で解釈される。 2. 文法 IPフラグメントオフセットフィールドの最上位ビットは、IPヘッダの中で 唯一未使用の領域である。したがってこのビット位置を選んだことについ ては、IANA が口を出す筋合いはない。 Bellovin Informational [Page 1] RFC 3514 The Security Flag in the IPv4 Header 1 April 2003 ビット領域のレイアウトは以下のようになる。 0 +-+ |E| +-+ 現在割り当てられている値は以下のように定義されている。 0x0 このビットが 0 に設定されている場合、このパケットに悪意はない。 ネットワーク上の各ホスト、ノード等は、このパケットは無害である と想定すべき(SHOULD)であり、いかなる防御策も適用するべきではな い(SHOULD NOT)。(本仕様のこの部分については、現在のほとんどの デスクトップオペレーティングシステムでは既に実装済みである、と いうことを特筆しておく。) 0x1 このビットが 1 に設定されている場合、このパケットには悪意があ る。安全なシステムではこのようなパケットに対して防衛措置をとろ うとするべきである(SHOULD)。安全でないシステムではクラッシュす る、侵入される、などの動作を行っても良い(MAY)。 3. 邪悪ビットの設定 邪悪ビットを設定するにはいくつかの方法が存在する。攻撃アプリケーショ ンは、このビットの設定要求を行うために、それ用の API を使うものもあ る。他に仕組みを持っていなければ、システムはそのような API を必ず提 供しなければならない(MUST)。また攻撃プログラムはその API を必ず使用 しなければならない(MUST)。 マルチレベル非安全オペレーティングシステムでは、攻撃プログラムのた めの特別なレベルを持たせても良い。このレベルで実行されるプログラム から発せられるパケットは、デフォルトで邪悪ビットを設定しなければな らない(MUST)。ただし、通常は悪事を働いているユーザが無害な活動を行 うときのために、このビットをクリアする API を提供しても良い(MAY)。 フラグメントが、それ自身危険なものである場合、邪悪ビットが設定され なければならない(MUST)。邪悪ビットの立ったパケットが中継ルータで分 割されたとき、そのフラグメント自身が危険なものでは無い場合は、その フラグメント中の邪悪ビットはクリアされなければならない(MUST)。また そのパケットが再構成されたときには再設定されなければならない(MUST)。 中継システムは、攻撃用コネクションの踏み台とされることがある。この ようなシステムに向けられて、攻撃対象に中継されるように意図されたパ ケットは、邪悪ビットが設定されるべきである(SHOULD)。 アプリケーションの中には、パケットを自分で組み立てるものもある。も しこれらのパケットが攻撃の一部に使用されるのであれば、アプリケーショ ンは邪悪ビットを自分で設定しなければならない(MUST)。 ファイヤウォールに保護されたネットワーク内においては、攻撃者はファ イヤウォールの外側に居るということは自明である。したがって、ファイ ヤウォール内部にあるホストは、いかなるパケットに対しても邪悪ビット を設定してはならない(MUST NOT)。 Bellovin Informational [Page 2] RFC 3514 The Security Flag in the IPv4 Header 1 April 2003 NATマシンはパケットの中身をいじるので、それらのパケットの邪悪ビット を設定するべきである(SHOULD)。httpや電子メールの「透過型」プロキシー は、内部の無邪気なクライアントホストに向けられた応答パケットの邪悪 ビットを設定するべきである(SHOULD)。 ある種のホストは、侵入検知システムの警告に引っかかってしまうような 方法で他のホストをスキャンしていることがある。もしスキャンが善良な 研究プロジェクトの一部としてなされるのであれば、邪悪ビットは設定し てはならない(MUST NOT)。しかしスキャンそれ自身が潔白なものであって も、その最終的な意図が邪悪なものであって、目的サイトがそういった侵 入検知システムを持っているのであれば、邪悪ビットは設定するべきであ る(SHOULD)。 4. 邪悪ビットの処理 ファイヤウォールなどの装置は、邪悪ビットの設定された入力パケットは 全て落とさなければならない(MUST)。邪悪ビットの設定されていないパケッ トは落としてはならない(MUST NOT)。落とされたパケットについては適切 な MIB 変数に記録されるべきである(SHOULD)。 侵入検知システム(IDS)においてはより面倒な問題が存在する。IDS には、 誤判定(false negative / false positive)があるという、よく知られた 性質があるため、IDS は邪悪ビットを評価するときに、統計的な補正処理 を適用しなければならない(MUST)。もし邪悪ビットが設定されていれば、 その攻撃を記録するか否かを、適切な乱数発生器[RFC1750]を用いて判断 しなければならない。同様に邪悪ビットが設定されていない場合、設定に 関わらずそれを記録するか否かを別の乱数発生器を用いて判断しなければ ならない。 これらのテストに用いられる確率のデフォルト値は、IDS の種類に依存す る。したがって、シグネチャベースの IDS では false positive の値は低 くなり、 false negative の値は高くなる。管理者がこの値をリセットで きるように、何らかの適切な管理者インタフェースが提供されなければな らない(MUST)。 セキュリティ装置の役割を持たされていないルータでは、このビットを検 査するべきではない(SHOULD NOT)。これによってパケットの転送処理をよ り高速に行うことができる。 前にも少し触れた通り、邪悪パケットのホスト側での処理方法はオペレー ティングシステム依存である。しかし全てのホストは、その本来の姿に従っ て適切に反応しなければならない(MUST)。 5. 関連作業 この文書では IPv4 の邪悪ビットについてのみしか定義していないが、そ れ以外の邪悪なもの対する補足的な機構が存在する。そのいくつかをここ で簡単に説明する。 IPv6 [RFC2460] においては、邪悪度は二つのオプションによって伝達され る。一つ目は hop-by-hop オプションで、DDoS 攻撃のようなネットワーク に損害を与えるパケットに対して使われる。二つ目は end-to-end オプショ ンで、相手のホストに損害を与えるためのパケットに使用される。どちら のオプションにも、そのパケットがどれだけ邪悪かを示す 128ビットの強 度値と、どんな種類の攻撃を行おうとしているかを示す 128ビットのタイ プ値が含まれる。 Bellovin Informational [Page 3] RFC 3514 The Security Flag in the IPv4 Header 1 April 2003 リンク層の種類によっては、特に光中継をベースとしたものにおいては、 ルータ(およびファイヤウォール)を完全に通り抜けてしまうものもある。 したがって、リンク層において邪悪であることを示す何らかの機構が使用 されなければならない(MUST)。このようなものには邪悪波長、邪悪偏光な どが含まれる。 DDoS 攻撃用のパケットには、特別な diffserv コードポイントによって目 印をつける。 ウェブもしくは電子メール経由の悪戯のために、MIME タイプ application/evil が定義されている。その他の MIME タイプは邪悪セクショ ンの内部に埋め込むことが可能である。これにより、マクロウイルスが含 まれたワープロ文書などを簡単にエンコードすることができる。 6. IANA 割り当てに関する考慮 この文書においては、邪悪ビットの値が 0x0 と 0x1 の場合についての各 セキュリティ要素の振る舞いを規定している。このビットがその他の値を とった場合の振る舞いについては、IETF の合意方法 [RFC2434] に基づい てのみ定義される。 7. セキュリティに関する考慮 セキュリティ機構が正しく機能するためには、邪悪ビットが正しく設定さ れることが重要で不可欠である。邪悪ビットを必要なときに正しく設定し ない壊れたマシンがあると、ファイヤウォールはその仕事を正しくこなす ことができない。同様に邪悪ビットが不要なときに 1 に設定されていると、 サービス妨害状態が発生してしまう。 8. 参考文献 [CBR03] W.R. Cheswick, S.M. Bellovin, and A.D. Rubin, "Firewalls and Internet Security: Repelling the Wily Hacker", Second Edition, Addison-Wesley, 2003. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1750] Eastlake, D., 3rd, Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Bellovin Informational [Page 4] RFC 3514 The Security Flag in the IPv4 Header 1 April 2003 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. 9. 著者の連絡先 Steven M. Bellovin AT&T Labs Research Shannon Laboratory 180 Park Avenue Florham Park, NJ 07932 Phone: +1 973-360-8656 EMail: bellovin@acm.org Bellovin Informational [Page 5] RFC 3514 The Security Flag in the IPv4 Header 1 April 2003 10. 著作権表示全文 Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 謝辞 Funding for the RFC Editor function is currently provided by the Internet Society. Bellovin Informational [Page 6]