|
ネットワーク WG Request for Comments： 3013 BCP： 46 分類： ベストカレントプラクティス |
T. Killalea neart.org 2000年11月 |
本書は、 インターネットの「現時点における最善の実践(ベストカレントプラクティス)」をインターネットコミュニティのために規定し、 改善のために議論や示唆を要求するものです。 このメモの配布に制限はありません。
Copyright (C) The Internet Society (2000). All Rights Reserved.
本書の目的は、 「IETFによって代表されるエンジニアリングコミュニティがセキュリティに関連してISPに何を期待しているか」を表明することにあります。
すべてのISPを対象に適切な要件集を規定することは、 本書の意図ではなく、むしろ、 コミュニティの期待についてISPの間で認識を喚起し、 コミュニティに現在と将来のサービスプロバイダーについてのセキュリティ期待についての議論のためのフレームワークを提供することにあります。
本書の目的は、 「IETFによって代表されるエンジニアリングコミュニティが、 セキュリティに関連してISPに何を期待しているか」を表明することにあります。 本書は、ISPに宛てたものです。
ISPに、このコミュニティが何を望み、期待するかを知らせることによって、 このコミュニティは、ISPをしてセキュリティを優先させるばかりでなく、 そのサービスを販売するときにセキュリティを誇りをもって示すものとすることに積極的になるように応援することを望みます。
決して商慣習を指示することは、本書の意図ではありません。
本書において ISPを、インターネット接続性、 もしくは他のインターネットサービスを提供する事業を行っている組織体を含むように定義し、 Webホスティングサービス、コンテンツプロバイダー、 メールサービスが含まれますが、これに限定されるものではありません。 このISPの定義は、自身のための目的で、 それらのサービスを提供している組織体は含みません。
本書は、ISPに対する、 いかなるセキュリティと攻撃管理の準備がサポートされる必要があるかに関する一連の推奨事項として、 そしてユーザに対する、 何を高品質サービスプロバイダーから期待すべきかに関するアドバイスとして提示されています。 自身の権利においては、規範的な通念とはなっていません。 やがて、時代遅れのものとなりがちであり、 他の期待がふくらむかもしれません。 しかし、これは、 インターネットとそのテクノロジーの発展における一定時点における、 この分野のプロフェッショナル一同の推奨事項のスナップショットをまさに表現しているのです。
本書中のキーワード、"REQUIRED"、"MUST"、"MUST NOT"、"SHOULD"、"SHOULD NOT"、"MAY"は、 「RFCにおいて要請の程度を示すために用いるキーワード(Key words for use in RFCs to Indicate Requirement Levels)」 [RFC2119] に記述されているように解釈されるべきもの です。
コミュニティの最も顕著なISPに対するセキュリティ関連の期待は、 セキュリティインシデントを取り扱うコミュニケーションチャネルの利用可能性に関するものです。
ISPは、ネットワークセキュリティに関する論点用にSECURITY、 不適切な公共での行為に関する論点用にABUSE、 それからネットワークインフラストラクチャに関する論点用にNOCのメールボックスを割り当てている [RFC2142] を遵守する必要があります(SHOULD)。
これは、 特定のサービスに関する問い合わせや報告を受け取るために割り当てられた追加的なメールボックスもリストしています。
ISPは、上記のより詳細なことについて、 共通のURLを使用することを検討することができます。 (例：http://www.ISP-name-here.net/security/)
さらにISPは、その連絡先情報が、Whoisの中であれ、 ルーティングレジストリ [RFC1786] の中であれ、他のいかなるリポジトリの中であれ、完全で、正確で、 そして連絡可能であることを確保にする義務があります。
ISPは、対顧客、対他のISP、対IRT、対法執行機関、 もしくは対プレスや一般公衆に、 セキュリティインシデントについての情報の共有上の明確なポリシーと手順をもつことが必要です(SHOULD)。
ISPは、自身と他のISPの間の境界をまたぐセキュリティインシデントを取り扱うためのプロセスを実際にもつ必要があります。
ISPは、 このようなコミュニケーションをセキュアチャネル越しに行うことができる必要があります(SHOULD)。 しかし、司法管轄圏によっては、 セキュアチャネルが許されていないこともあることを銘記しておいてください。
ISPは、 その提供しているサービスにおけるセキュリティ脆弱性情報を顧客に通知することにおいて、 積極的である必要があります(SHOULD)。 さらに、新しい脆弱性がシステムやソフトウェアに発見され次第、 そのサービスがそれらのリスクによって脅かされているか否かを示す必要があります。
あるISPのインフラストラクチャのコンポーネントに影響を与えるセキュリティインシデントがおきた場合、 そのISPは、その顧客に(下記の事項を)報告する必要があります。
多くのISPは、 顧客に停電やサービス停止について通知する手続きを確立しています。 ISPが、 これらのチャネルをセキュリティ関連のインシデントを報告することのために利用することは、 妥当といえます。 このような場合、その顧客のセキュリティ連絡窓口は、 通知される担当者ではないかもしれません。 むしろ、通常の連絡窓口がその報告を受け取るでしょう。 顧客は、このことを知っておく必要があり、 そのような通知を適切に転送するようにしなければなりません。
CSIRTとは、 定められた構成員のサイトを巻き込むセキュリティインシデントへの対応を、 行ったり、コーディネートしたり、サポートするチームです。 インターネットコミュニティのCSIRTについての期待は、 「コンピュータセキュリティインシデント対応への期待 (Expectations for Computer Security Incident Response)」 [RFC2350] に記述されています。
ISPがCSIRTをもっているか否かにかかわらず、 ISPは、その顧客から報告されたインシデントを受け取り扱うための、 よく宣伝されたやり方をもつ必要があります。 さらにISPは、 報告されたインシデントに対応する能力主体を明確に文書化する必要があり、 CSIRTがある場合には、どの(CSIRTの)構成員がその顧客を含むかと、 誰にインシデントを報告することができるかを表示する必要があります。
CSIRTをもっているISPもあります。 しかし、そのISPの接続性顧客、 そのISPの顧客によって攻撃されているサイトのどちらも、自動的に、 そのISPのCSIRTサービスを利用することができると想定すべきではありません。 ISPのCSIRTは、しばしば、 構成員をインシデント対応サービスに特別に登録した(そしておそらく支払った)者のみに限定しているチームによって、 追加料金のサービスとして提供されます。
それゆえISPにとって、その顧客がインシデントが起きる「事前」に、 そのインシデント対応の一連の段階を規定できるようにするために、 どのインシデント対応／セキュリティ資源を顧客に入手可能にしているかを公表することは重要です。
顧客は、そのISPがCSIRTをもっているか否か、もっている場合には、 そのチームの憲章、ポリシー、 サービスが何であるかを見つける必要があります。 この情報は、「コンピュータセキュリティインシデント対応への期待 (Expectations for Computer Security Incident Response)」 [RFC2350] のAppendix D中に示されているCSIRTテンプレートを使用することによって最もよく表明されます。
各ISPは、 適切な利用法に関するポリシー(AUP)をもつ必要があります(SHOULD)。
ISPが顧客と、 インターネットへの接続性を提供することの契約をする際には常に、 その契約はAUPの配下におかれる必要があります。 AUPは、契約が更新されるたびにレヴューされる必要があり、さらに、 ISPは、 積極的にポリシーが更新されるたびに顧客に通知する必要があります。
AUPは、システムもしくはネットワークの様々なコンポーネントにおいて、 顧客がすべきことと、すべからざることを明確に識別する必要があり、 そのネットワーク上で許容されるトラフィックの種類が含まれます。 そのAUPは、あいまいさ、もしくは誤解を避けるために、 可能な限り明解である必要があります。 例えば、IPスプ－フィングを禁止するAUPもあるでしょう。
ISPは、自身のAUPをその顧客に対して伝えることに加えて、 そのコミュニティが、 そのISPが何を適切と考えているかを認識できるように、 そして、不適切な行為が起きた場合において、 どんなアクションを期待するかを知ることができるように、 自身のポリシーを、 そのWebサイトのような公的な場で公表する必要があります。
AUPは、不適切な行為が行われた場合において、 いかなる制裁が執行されることになるか、 表明において明確である必要があります。
多くの司法管轄単位はデータ保護の法規制をもっています。 このような法規制が適用されるところでは、ISPは、 保持する個人データを考慮する必要があり、必須とあらば、 自身をデータコントローラーとして登録し、 そのデータを法規制の文言に従ってのみ使用するように備える必要があります。 インターネットのグローバルな性格によって、 このような法規制が存在しないところに位置するISPは、 少なくとも典型的なデータ保護法(例： [DPR1998] )を読むことによってデータ保護の発想に慣れておく必要があります。
ISPは、このようなやり方で、 インターネットのネットワークインフラストラクチャを管理することに責任を負います。
ISPは通常、IRR (Internet Routing Registry)やAPNIC、ARIN、 RIPEデータベースのようなグローバルなリポジトリに蓄積されたデータを保守することに責任を負います。 このデータへの更新は、 強い認証を使用することによってのみ可能である必要があります。
ISPは、その顧客に割り当てるアドレス空間を、 その代表者欄により詳細な連絡先情報があるように、 公的に登録する必要があります。
ISPのトラフィックを正しい宛先に経路制御する能力は、 ルーティングレジストリ [RFC1786] 中で設定されるルーティングポリシーに依存することがあります。 その場合で、かつそのレジストリがサポートしているならば、 ISPは、 保守しているレジストリ情報が強い認証を使用しているときにのみ更新できるようにし、 更新を行う権限者が適切に制限されるようにする必要があります。
善良なる管理者の注意義務はまた、 宛先にとって経路の選択肢がある場合に、 誰のルーティング告知により大きな信頼をおくかを決定する際にも払われる必要があります。 過去においては、にせの告知によって、 トラフィックが「ブラックホールに吸い込まれた」り、 さらに悪いことにハイジャックされる結果をもたらしたことがあります。
BGP認証 [RFC2385] が、 ルーティングピアに使用される必要があります(SHOULD)。
このようなフィルタリングの方向は、 末端サイト(顧客)からインターネットへです。
攻撃者はしばしば、偽ったソースアドレスを使用することによって、 痕跡を隠します。 注意を自身のサイトからそらすために、 攻撃者が選ぶソースアドレスは通常、無実の遠隔サイトから、 もしくは実際に、 プライベートなイントラネットのために割り当てられたアドレス [RFC1918] からのものです。 さらに、偽ったソースアドレスは、しばしば、 ホスト間の信頼関係を攻略するために、 スプーフに基づく攻撃に使用されます。
偽ったソースアドレスに依拠する攻撃のインシデントを低減するために、 ISPは、下記の事項を行う必要があります。 ISPの各顧客との境界ルーターにおいてISPは、顧客から来る、 その顧客に割り当てたアドレス以外のソースアドレスをもつ、 すべてのトラフィックを積極的にフィルタする必要があります。 この話題のより詳細な検討については、 [RFC2827] をご覧ください。
入方向フィルタリングが現状では不可能な(希な)状況があり、例えば、 パケットフィルタ適用の追加的な負荷を負うことができない大きなアグリゲーション(集合)ルーターがあります。 さらに、このようなフィルタリングは、 モービルユーザーにとって困難を引き起こす可能性があります。 それゆえ、 スプ－フィングを防ぐためにこのテクニックの使用は強く推奨されますが、 常に使用可能というわけではありません。
顧客とISP間のインターフェイスにおける入方向フィルタリングが不可能である、 これらの希な場合においては、その顧客には、 彼らのネットワーク中に入方向フィルタリングを実装することが強く薦められる必要があります。 一般に、フィルタリングは、 できる限り実際のホストの近くで行われる必要があります。
このようなフィルタリングの方向は、 インターネットから末端サイト(顧客)へです。
今日、インターネット上で広く使用されていて、 IPアドレスのみに基づいて他のホストに信頼を認める多くのアプリケーション (例：バークレー'r'コマンド)があります。 これらは、 [CA-95.01.IP.spoofing] に記述されているように、 IPスプーフィングを認めてしまうものです。 さらに [CA-97.28. Teardrop_Land] に記述されている'land'のように、仮定上、 ローカルアドレスの濫用に依拠する脆弱性があります。
ISPの顧客が、 偽のソースアドレスに依拠する攻撃にさらされることを低減するために、 ISPは下記の事項を行う必要があります。 各顧客との境界ルーターにおいて、ISPは、顧客宛ての、 その顧客に割り当てたことのあるあらゆるアドレスに該当するソースアドレスをもつすべてのトラフィックを積極的にフィルタする必要があります。
入方向フィルタリングが不可能な4.3に記述した状況は、 出方向フィルタリングにも同様に該当します。
過剰なルーティング更新は、攻撃者によって、 DoS攻撃(サービス妨害攻撃)を組み立てる前提となる負荷として、 悪用される可能性があります。 少なくとも、パフォーマンス低下をもたらします。
ISPは、例えば、 プライベートなイントラネットのために割り当てられたアドレスへの経路を無視するため、 偽の経路を避けるため、"BGP Route Flap Dampening" [RFC2439] とアグリゲーション(集合)ポリシーを実装するために、 ISPが聞くルーティング告知をフィルタする必要があります。
ISPは、 そのネットワークの他の部分におけるルーティングについて過剰な負荷にさらすことのリスクを低減させるテクニックを実装する必要があります。 テクニックとは、「固定」経路、攻撃的アグリゲーション(集約)、 経路ダンピングを含むもので、これらすべては、 あなたの内部ルーティングを他者に関係ないように変更する場合、 他者へのインパクト(影響)を下げるものです。
IPプロトコルは、ブロードキャストの指図、すなわち、 特定のサブネット上でブロードキャストされるパケットをネットワーク越しに送信することを許容しています。 この機能については実践的な使用法はほとんど無いのですが、 様々なセキュリティ攻撃(主にDoS攻撃(サービス妨害攻撃))が、 これを使用しますが、 ブロードキャストのパケット増幅効果を利用します。 それゆえ、ブロードキャストメディアに接続されているルーターは、 そのメディアへの指図されるブロードキャスト [RFC2644] を許容するように設定されてはなりません(MUST NOT)。
ISPが自身のシステムを管理するやり方は、 そのネットワークのセキュリティと信頼性にとって決定的に重要です。 そのシステムの侵害は、控えめにもパフォーマンス、 もしくは機能の低下をもたらしますが、データの損失、 もしくはトラフィックが盗聴されることのリスクをもたらす可能性があります。 (それゆえ、 ひいては「中間者による攻撃(man-in-the-middle攻撃)」をもたらすことになります。)
(メール、News、Webホスティングのような)それぞれのサービスが個別のシステムに収められるようにすれば、 セキュアなシステムを構築するのが容易であるとが広く認知されています。
メール、 NewsやWebホスティングのような極めて重要なISP機能を行っているすべてのシステムは、 それらへのアクセスが、 それらのサービスの管理者にのみ可能であるように制約される必要があります。 そのアクセスは、強い認証に従ってのみ許可される必要があり、 暗号化されたリンク越しである必要があります。 それらのサービスがリッスンしているポートだけが、 ISPのシステムネットワークの外部から到達可能である必要があります。
ISPは、サービスを提供することにおいて、 よりセキュアな手法が利用可能となり次第、 その手法について最新であることを保つ必要があります。 (例えば、シンプルチャレンジ／レスポンス対応のIMAP/POP AUTH拡張 [RFC2195])
システムは、 トランジットネットワークセグメントに設置されるべきではありません。
ISPは、そのメールインフラストラクチャが、 送信者の身元を隠しながらUBE (Unsolicited Bulk E-mail)を投入する「スパマー」によって利用されることを防ぐために、 積極的な手順をふむ必要があります [RFC2505]。 必ずしもすべての手順が各サイトにとって適切とは限りませんが、 最も効果的な「サイトに適切な」手法が使用される必要があります。
ISPはまた、その顧客に、自身のシステム上で、 この活動を防ぐのに必須の手順をふむことを強く薦める必要があります。
メッセージ送信は、"SMTP Service Extension for Authentication" [RFC2554] に記述されているAUTH SMTPサービス拡張を使用して、 認証される必要があります。
SMTP AUTHは、IPアドレスに基づく送信制限よりも好ましく、 これによって、ISPの顧客に、 たとえそのISPのネットワーク経由で接続されていないとき (例：作業中)でもメールを送信することができる柔軟性を与え、 よりスプ－フィングに耐性があり、 より新しい認証機構が利用可能となり次第、 アップグレードされることができます。
さらに、セキュリティポリシーの執行を促すために、 メッセージがSMTP ポート(25)経由ではなく、 "Message Submission" [RFC2476] で検討されているMAIL SUBMITポート(587)を使用して送信されることが強く推奨されます。 このようにするとSMTP ポート(25)が、 ローカル配信のみに制限されるようにすることができます。
この理由は、入り方向ローカル配信と中継(つまり、 顧客にISPのSMTPサービス経由でメールをインターネット上の任意の受信者宛てに送信することができること)を区別できるようにすることにあります。 認証されていないSMTPは、 ローカル配信用にのみ許可される必要があります。
より多くのメールクライアントが(明示的であれ、 もしくはSMTPポートを設定することによってであれ)SMTP AUTHとメッセージ送信ポートの両方をサポートするようになってきたので、 ISPは、入り方向のメールポート(25)のみを許可しつつ、 送信ポートとSMTP AUTHの両方を使用した顧客の送信メッセージを要求することを有用と認識することでしょう。
これらの手段(SMTP AUTHと送信ポート)は、ISPが、 第三者中継経由のUBE投入点としての役割を果たすのを防ぐのみならず、 顧客がUBEを送信する場合において、 メッセージ送信の説明責任を追跡する際にも役立ちます。
| [CA-95.01.IP.spoofing] |
"IP Spoofing
Attacks and Hijacked Terminal Connections", ftp://info.cert.org/pub/cert_advisories/ |
| [CA-97.28.Teardrop_Land] |
"IP
Denial-of-Service Attacks", ftp://info.cert.org/pub/cert_advisories/ |
| [DPR1998] |
英国 "Data Protection Act 1998 (c. 29)", http://www.hmso.gov.uk/acts/acts1998/19980029.htm |
| [RFC1786] |
Bates, T., Gerich, E., Joncheray, L., Jouanigot, J., Karrenberg,
D., Terpstra, M. and J. Yu, "Representation of IP outing Policies in a Routing Registry (ripe-81++)", RFC 1786, 1995年3月. |
| [RFC1834] |
Gargano, J. and K. Weiss, "Whois and Network Information Lookup Service", RFC 1834, 1995年8月. |
| [RFC1835] |
Deutsch, P., Schoultz, R., Faltstrom, P. and C. Weider,
"Architecture of the WHOIS++ service", RFC 1835, 1995年8月. |
| [RFC1918] |
Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
G. J. and E. Lear,
"Address Allocation for Private Internets", BCP 5, RFC 1918, 1996年2月. |
| [RFC2119] |
Bradner, S., 「RFCにおいて要請の程度を示すために用いるキーワード (Key words for use in RFCs to Indicate Requirement Levels)」, BCP 14, RFC 2119, 1997年3月. |
| [RFC2142] |
Crocker, D., "Mailbox Names for Common Services, Roles and Functions", RFC 2142, 1997年5月. |
| [RFC2195] |
Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, 1997年9月. |
| [RFC2196] |
Fraser, B., 「サイトセキュリティハンドブック (Site Security Handbook)」, FYI 8, RFC 2196, 1997年9月. |
| [RFC2350] |
Brownlee, N. and E. Guttman, 「コンピュータセキュリティインシデント対応への期待 (Expectations for Computer Security Incident Response)」, BCP 21, RFC 2350, 1998年6月. |
| [RFC2385] |
Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, 1998年8月. |
| [RFC2439] |
Chandra R., Govindan R. and C. Villamizar, "BGP Route Flap Damping", RFC 2439, 1998年11月. |
| [RFC2476] |
Gellens R. and J. Klensin, "Message Submission", RFC 2476, 1998年12月. |
| [RFC2505] |
Lindberg, G., 「SMTP MTAについてのspam対策推奨事項(Anti-Spam Recommendations for SMTP MTAs)」, BCP 30, RFC 2505, 1999年2月. |
| [RFC2554] |
Myers, J., "SMTP Service Extension for Authentication", RFC 2554, 1999年3月. |
| [RFC2644] |
Senie, D., 「ルーターにおいて指図されるブロードキャストについてのデフォルトを変更する(Changing the Default for Directed Broadcasts in Routers)」, BCP 34, RFC 2644, 1999年8月. |
| [RFC2827] |
Ferguson, P. and D. Senie, 「ネットワークイングレスフィルタリング：IPソースアドレスを偽ったサービス妨害攻撃をくじく(Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing)」, BCP 38, RFC 2827, 2000年5月. |
私は、Nevil Brownlee氏、Randy Bush氏、Bill Cheswick氏、Barbara Y. Fraser氏、Randall Gellens氏、Erik Guttman氏、Larry J. Hughes Jr.氏、Klaus-Peter Kossakowski氏、Michael A. Patton氏、Don Stikvoort氏およびBill Woodcock氏から受けた建設的なコメントに大いに感謝します。
本書全体が、セキュリティの諸論点を検討しています。
Tom Killalea
Lisi/n na Bro/n
Be/al A/tha na Muice
Co. Mhaigh Eo
IRELAND
電話： +1 206 266-2196
EMail： tomk＠neart.org
宮川 寧夫
情報処理振興事業協会
セキュリティセンター
EMail： miyakawa＠ipa.go.jp
Copyright (C) The Internet Society (2000). 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.
RFCエディタのための財源は現在、 Internet Societyによって提供されています。