|
ネットワーク WG Request for Comments: 4778 分類：情報提供 |
M. Kaeo Double Shot Security, Inc. 2007年1月 |
このメモは、インターネットコミュニティに情報を提供するものです。 これは、いかなるインターネット標準をも定めるものではありません。 このメモの配布には制限はありません。
Copyright (C) The IETF Trust (2007).
本書は、今日の大規模ISPの運用的ネットワークにおいて、 レイヤ2およびレイヤ3のインフラストラクチャ・デバイスをセキュアにするために行われている現在の実践の調査です。 ここに掲げられた情報は、ISPにおいて、 セキュアなインフラストラクチャを規定して実装することについて直接責任を負う人々から集められた情報の結果です。
セキュリティ実践は、長年、 ネットワーク・インフラストラクチャをセキュアにすることについて、 増しつつある痛みを経験したネットワーク運用者には、よく理解されています。 しかし、これらのセキュリティ実践を挙げて書かれた文書は、存在しません。 ネットワーク攻撃は、継続的に増加しており、 インターネット・ポリスとしてふるまうことは、 必ずしもISPの役割ではありませんが、各ISPは、「そのネットワークが、 運用的に、顧客が利用可能であること」を確保するため、 一定のセキュリティ実践が行われることを確保する必要があります。 本書は、「どのような現在のセキュリティ実践が、 ネットワーク・インフラストラクチャをセキュアにするために実施されているか？」を見つけるために行われた調査の結果です。
この調査の範囲は、 ネットワークの利用可能性や信頼性に負の影響を与える可能性があるリスクにさらされることを軽減するセキュリティ実践に制限されています。 実際のデータトラフィックをセキュアにすることは、 行われた調査の範囲外です。 本書は、 レイヤ2とレイヤ3のネットワーク・インフラストラクチャのデバイスについて、 現在、 配備されているセキュリティ・メカニズムを文書化することにのみ焦点を当てます。 主にIPv4に焦点を当てていますが、同じ実践の多くは、 IPv6ネットワークに適用でき(ると共に、適用する必要があり)ます。 IPv4とIPv6の両方のネットワーク・インフラストラクチャが、 この調査において考慮されています。
脅威は、セキュリティ侵害についての潜在的可能性であり、これは、 セキュリティを侵害し、加害する可能性がある状況、能力、 活動もしくはイベントがあるとき、存在します。 [RFC2828] すべての運用ネットワークは、 多数の脅威となる活動(もしくは、攻撃)の対象となります。 すなわち、 セキュリティ・サービスを回避する計画的な試みである知的な活動に起因し、 そのシステムのセキュリティ・ポリシーを侵害するシステム・セキュリティについての猛撃です。 [RFC2828] ネットワーク・インフラストラクチャに対する脅威の多くは、 下記の項目(もしくは、その組み合わせ)から起きます。：
「しばしば、サービス妨害攻撃は、 独立した分類として掲げられること」に注意してください。 サービス妨害は、攻撃の結果であり、過剰なトラフィック (すなわち、 フラッディング(flooding))、プロトコルの脆弱性の攻略、 メッセージの挿入／削除／宛先変更(diverting)／改変の結果である可能性があります。
これらの攻撃元については、様々な分類法があります。：
あらゆる潜在的な攻撃シナリオについての主な関心事は、それが、 そのネットワーク・インフラストラクチャに対してもたらす可能性のある影響と被害です。 その脅威の結末は、脅威となる活動(すなわち、 攻撃)に起因するセキュリティ侵害です。 これらは、典型的には、下記のように分類されます。：
これらの脅威の結末をもたらす可能性がある脅威となる活動についての完全な記述は、 [RFC2828] にあります。 典型的には、数多くの異なるネットワーク攻撃が、ひとつ、もしくは、 複数の、上述の脅威の結末をもたらすために、組み合わされて使われます。 一例は、トラフィック上で盗聴する能力をもつ悪意あるユーザです。 まず、彼は、しばらくの間、探索作業や確認を行いながら、 IPアドレスが(ルータのような)特定のデバイスに属しているトラフィックを盗聴する可能性があります。 この悪人が、平文で送られたルータのパスワードのように、 情報を取得しようとした場合、彼は、次に、 実際のルータを侵すことに進むことができます。 そこから、その悪人は、 トラフィックをリダイレクトするために、 偽のルーティングの更新を送ったり、あるいは、 他のネットワーク・デバイスを侵すために追加的なトラフィックを捕捉するような様々な積極的な攻撃を放つことができます。 本書は、「どの対策をISPは、今日、配備しているか？」を目録化しますが、 実際のバックボーン・インフラストラクチャ攻撃と、 その適切な対策の有用な一般的分析は、[RTGWG] にあります。
本書は、あらゆる脅威となる活動に影響を受けやすい状態になるリスクを軽減する現在の運用的実践の調査結果です。 それゆえ、主な焦点は、攻撃を検知、 かつ／または、軽減するために使われる現在実施されているセキュリティ実践にあります。 本書における最上段の分類は、ISPについての運用的機能に基づき、一般に、 「何が、防護されるべきか？」に関連します。 この次に、「どの攻撃が可能か？」と、 現在行われているセキュリティ実践が記述されます。 これは、これらの攻撃の緩和を支援するために必要不可欠なセキュリティサービスを提供します。 これらのセキュリティサービスは、下記のように分類されます。：
多くの事例において、現在、配備されている特定のプロトコルは、 これらのサービスの組み合わせを提供します。 例えば、認証(Authentication)、 認可(Authorization)および説明責任用(Accounting)のAAAは、ユーザ認証、 ユーザ認可、および、監査／記録のサービスを提供できる一方、 SSH (Secure SHell)プロトコルは、データ発信元認証、 データのインテグリティ、および、データの秘匿性を提供できます。 提供されるサービスは、使われる実際のプロトコルより重要です。 「アクセス制御とは、基本的に、論理的アクセス制御(すなわち、 フィルタリング)を言うこと」に注意してください。 各節は、「なぜ、特定のプロトコルを使ってよいのか、あるいは、 使ってはいけないのか？」を説明する追加的な考慮事項の節で締めくくられ、 いくつかのバグもしくは「ユーザビリティの欠如」に起因して、現在では、 まだ不可能な機能に関する情報も提供します。
デバイスへの物理的アクセスは、その物理的場所の防護と、 レイヤ2もしくはレイヤ3のネットワーク・インフラストラクチャのデバイスへのアクセスに関係します。 物理的セキュリティは、調査／実践の対象としても、 それ自体としても大きな分野であり、ほぼ間違いなく、 セキュリティ分野において最大、最古の、最も良く理解された分野です。 ネットワークのデバイスに被害を与える可能性がある自然災害(例：地震や洪水)について非常時対応計画(contingency plan)をもつことは重要ですが、 これは、対象範囲外です。 ここで、我々は、物理的場所へのアクセスの防護と、 「物理的な場所がが侵された場合、どのように、デバイスは、 認可されていないアクセスから、さらに防護できるか？(すなわち、 コンソール・アクセスを防護すること)」に関心をもちます。 これは、概ね、侵入者が物理的にアクセスして、 そのデバイスを運用的に制御できるようになることを止めることを目的とします。 「攻撃者が、そのデバイスの電源を切ること、あるいは、 単に何らかのケーブルを引き抜くことによって、 容易に達成可能なサービス妨害攻撃を遂げるために、 物理的にアクセスすることを止めるものは無いこと」に注意してください。
何らかの侵入者がレイヤ2もしくはレイヤ3デバイスに物理的にアクセスできる場合、 そのネットワーク・インフラストラクチャ全体は、 侵入者の制御下になる可能性があります。 少なくとも、その侵入者は、 侵されたデバイスがサービスできないようにすることができ、 ネットワーク崩壊をもたらす可能性があり、その程度は、 そのネットワークのトポロジに拠ります。 より悪いシナリオは、侵入者が、 そのコンソールのパスワードをクラックするために、このデバイスを使い、 そのデバイスと、 そのネットワーク全体を完全に制御できるようになる場合です。 (おそらく、誰もそのような侵害を検知することなく、あるいは、 別のネットワークのデバイスをポートに取り付け、 侵入者がそのネットワーク・トポロジを確認できるデータを吸い上げます。)
物理的にアクセスできることの脅威は、 たとえ極めて重要なデバイスが高いセキュリティのもとにある場合でも、 多様に実現してしまう可能性があります。 攻撃者が、重大な停止時間やプライバシーの侵害を引き起こした、 きわめて重要なデバイスに物理的にアクセスできるようにするために、 メンテナンス作業者になりすました事例は、なおも起きます。 認可された者による内部からの攻撃も、現実の脅威を提起し、 適切に理解され、対応されなければなりません。
物理的なデバイスのセキュリティについて、機器は、 かなり制限された環境に保たれます。 カードキー・バッジをもつ認可されたユーザのみが、 極めて重要なネットワーク・インフラストラクチャのデバイスが在る、 あらゆる物理的場所にアクセスできます。 これらのカードキー・システムは、「誰が、どの場所に、いつ、 アクセスしたか？」を記録します。 大部分のカードキー・システムは、 そのカード・システムがダウンしている場合の予備(fail-back)の「マスターキー」 をもちます。 この「マスターキー」は、通常、アクセスが制限されており、 (そのカードキー・システムがオンライン状態でない／機能しない場合にのみ発生する)マスターキーの利用も、 慎重に記録されます。
すべてのコンソール・アクセスは、常に、パスワードで防護されており、 そのログイン時間は、一定時間の無操作(典型的には、 3分～10分の間)ののちにタイム・アウトするように設定されます。 あなたがコンソール・ログインから得る特権の種類は、 個々のベンダーのデバイス間で様々です。 場合によっては、あなたは、初期の基本的なアクセスができ、 より高い特権のアクセス(すなわち、enableもしくはroot)を得るために、 2番目の認証ステップを行う必要があります。 他のベンダー(のもの)において、あなたは、 コンソールにrootとしてログインするとき、 2番目の認証ステップを要すること無しに、 より高い特権のアクセス権を得ます。
「どのようにISPは、このようなログインを管理するか？」は、 大幅に多様です。 ただし、多くのより大きなISPは、 特権レベルの認可の自動化を支援するために、 ある種のAAAメカニズムを採用し、 2番目の認証ステップの必要性を回避するために、 その自動化を活用しています。 また、多くのISPは、ユーザについて、コンソールにログオンしている間、 分離されたクラスを、異なる特権をもつように定義します。 典型的には、すべてのコンソール・アクセスは、 本書の2.2節において検討される帯域外管理インフラストラクチャ経由で提供されます。
下記のセキュリティサービスは、 以前の節において述べた実践の利用を通じて提供されています。：
物理的セキュリティは、本書において述べたように、大部分は、 コンソール・アクセスの観点から、運用的セキュリティ実践に関連します。 大部分のISPは、 帯域外管理インフラストラクチャ経由のコンソール・アクセスを提供します。 これは、本書の2.2節において検討されます。
物理的・論理的な認証システムや記録システムは、 互いに独立して動作する必要があり、 物理的に異なる場所に在る必要があります。 これらのシステムは、「侵入者に脆弱な認証や記録の情報を与えかねない、 それら自体が侵されないこと」を確保するためにセキュアにされる必要があります。
ソーシャル・エンジニアリングは、多くの物理的アクセス侵害において、 大きな役割を果たしています。 大部分のISPは、極めて重要なインフラストラクチャのデバイスに、 物理的にアクセスすることを正当に本人認証・認可されていない人々に物理的なアクセスをさせないように、 会社の要員を教育するために、 トレーニング・クラスや啓発プログラムを設けています。
帯域内管理は、一般に、デバイスへのアクセスであると考えられています。 ここでは、制御トラフィックは、 そのネットワークを渡っていくデータと同じデータ・パスを通ります。 帯域外管理は、一般に、デバイスへのアクセスであると考えられます。 ここでは、制御トラフィックは、 そのネットワークを通過するデータとは分離されたパスを通ります。 多くの環境において、 レイヤ2とレイヤ3のインフラストラクチャ・デバイスについてのデバイス管理は、 帯域内として配備された、いくつかの事例もありますが、 帯域外管理インフラストラクチャの一部として配備されます。 「多くのセキュリティの関心事と実践は、帯域外管理と帯域内管理について、 同様ですが、大部分のISPは、 帯域外管理システムを選好すること」に注意してください。 なぜならば、この管理ネットワークを構成するデバイスに対するアクセスは、 より用心深く防護されており、 悪意ある活動がなされにくいと見なされるからです。
コンソールアクセスは、常に、帯域外ネットワーク経由の構図になります。 現在、帯域内管理か、あるいは、 帯域外のいずれかで使われているメカニズムは、 仮想的なターミナル・アクセス(すなわち、TelnetもしくはSSH)、 SNMP (Simple Network Management Protocol)、 もしくはHTTP経由です。 取材したすべての大きなISPにおいて、HTTP管理は、決して使われず、 明示的に不能にされていました。 ファイル転送プロトコル(TFTP, FTPおよびSCP)は、 本書の 2.5節において扱われることに注意してください。
デバイス管理について、待ち伏せ攻撃は、 誰かがその管理デバイスと管理されるデバイス間のデータを傍受する能力をもつ場合、可能です。 その脅威は、あるインフラストラクチャのデバイスが何らかの方法で侵されて、 ネットワークスニッファの役割を果たすことができる場合、あるいは、 ネットワーク・スニッファとしての役割を果たす新しいデバイスを挿入することが不可能な場合、 可能です。
積極的な攻撃は、パス上と、パス外の両方のシナリオについて可能です。 パス上の積極的な攻撃について、その状況は、 デバイスが既に侵されているか、あるいは、デバイスが、 そのパス中に挿入される可能性がある場合の待ち伏せ攻撃についてと同様です。 パス外の積極的な攻撃について、 トポロジの破壊(subversion)がトラフィックを再度、 経路制御(reroute)することを要求され、要するに、 その攻撃者をパス上に連れてくる場合、その攻撃は、一般に、 メッセージの挿入あるいは改変に限られます。
秘匿性の侵害は、悪人が平文で、あるいは、 弱い暗号化で送られた何らかの管理データを傍受するとき、 起きる可能性があります。 これは、ユーザ名とパスワードの傍受を含み、これによって、侵入者は、 ネットワーク・デバイスへの認可されていないアクセスを得ることができます。 これは、 運用管理者が遠隔からローカルのログファイルもしくは設定情報を見ている場合、 記録情報や設定情報のような他の情報も含めることができます。
ユーザ名／パスワード情報が暗号化されているが、 その使われている暗号技術的メカニズムについて「データを捕捉し、 その暗号化鍵を解読すること」が容易にされている場合、 そのデバイス管理トラフィックは、侵される可能性があります。 そのトラフィックは、そのネットワーク上の盗聴によるか、あるいは、 悪意あるユーザ宛にそらせることができることによるかのいずれかで捕捉される必要があります。
再生攻撃が成功するためには、その管理トラフィックは、まず、パス上か、 あるいは、あとで意図された受信者宛に再生されるように、 攻撃者宛に変更されるか、のいずれかで捕捉される必要があります。
データは、 中間にあるホストを制御している誰かによって操作される可能性があります。 偽のデータは、IPスプーフィング(spoofing：偽装)についても可能です。 ここでは、遠隔のホストが、 別の信頼されるホストから到来したように見えるパケットを送信します。
中間者(man-in-the-middle)による攻撃は、データストリーム自体ではなく、 通信を行うピアの身元を攻撃します。 その攻撃者は、 管理システムからそのネットワーク・インフラストラクチャのデバイス宛に送られるトラフィックと、 そのネットワーク・インフラストラクチャのデバイスから管理システム宛に送られるトラフィックを傍受します。
帯域外管理は、各場所において、ターミナル・サーバー経由で行われます。 SSHアクセスは、そのデバイス宛のセッションが開始されたところから、 そのターミナル・サーバーにアクセスするために使われます。 ダイアルイン・アクセスは、 そのネットワークが利用できない場合のバックアップとして配備されます。 しかし、素のダイアルイン・アクセスのセキュリティの弱点を避けるために、 ダイアル・バック、暗号化モデム、かつ／または、 OTP(ワンタイム・パスワード)モデムを使うのが普通です。
すべてのレイヤ2とレイヤ3のデバイスについての帯域内管理と帯域外管理アクセスは、 認証されます。 そのユーザ認証と認可は、典型的には、AAAサーバーによって制御されます。 (すなわち、RADIUS (Remote Authentication Dial-in User Service)かつ／またはTACACS+ (Terminal Access Controller Access-Control System +)。) ユーザの身元を判定するために使われるクレデンシャルは、 固定的なユーザ名／パスワードから、 Secure-IDのようなワンタイム・ユーザ名／パスワード・スキームまで多様です。 固定的なユーザ名／パスワードは、 一定期間(通常30日)後に期限切れとされます。 AAA経由で認証されたすべての主体は、より細かな粒度の制御のためには、 個人ユーザとなります。 「しばしば、帯域外管理認証のために使われるAAAサーバーは、 帯域内管理のユーザ認証用に使われるAAA サーバーとは分離された物理的デバイスであること」に注意してください。 配備法によっては、 デバイス管理の認証／認可／accountingのために使われるAAAサーバーは、 いかなる他の認証機能とも区別するために分離されたネットワークにあることがあります。
バックアップの目的で、しばしば、ごく少人数のキーとなる要員のみが知る、 ひとつのローカル・データベース・エントリが、認証用に設けられます。 これは、通常、(大部分の場合において、 すべてのデバイスに渡って同一な) 最高の特権レベルのユーザ名／パスワードの組み合わせです。 このローカル・デバイスのパスワードは、定期的に、 2～3ヶ月ごとに再生成され、また、 そのパスワードにアクセスできた従業員がその会社を去るか、あるいは、 もはや、そのパスワードの知識をもつことが認可されなくなる直後に再生成されます。
AAAデータベース中で、各個人ユーザは、 特定の認可機能によって設定されます。 特定のコマンドが、アクセスされるデバイスの能力に依存して、 個別に拒絶されるか、あるいは、許可されるか、のいずれかです。 複数の特権レベルが、配備されます。 大部分の個人は、 最小限のコマンド群を実行するための基本的な認可で認可され、一方、 個人ユーザの部分集合が、 より高い特権のコマンドを実行することが認可されます。 AAAサーバーをセキュアにすることは、絶対必要であり、 そのAAAサーバー自体に対するアクセスは、厳格に制御されます。 個人がその会社を去るとき、彼／彼女のAAAアカウントは、 すぐに削除され、そのTACACS/RADIUSのshared secretは、 すべてのデバイスについて、リセットされます。
管理機能には、CLI (Command Line Interface)のスクリプティングを使って行われるものがあります。 これらのシナリオにおいて、専任のユーザが、 CLIスクリプティングを行うスクリプトにおける身元用に使われます。 いったん本人認証されると、これらのスクリプトは、 本人認証された個人の認可権限に依存して、「どのコマンドが、 正規のものか？」を制御します。
SSHは、常に、 暗号化された通信チャネルを提供する仮想的なターミナル・アクセスのために使われます。 「追加的な考慮事項」の節に記述された機器の制約に起因して、 例外があります。
SNMPが管理のために使われる場合、これは、readクエリ用のみであり、 特定のホストに制限されます。 可能であれば、そのviewも、read-only SNMPコミュニティで、 その設定ファイル全体を露出するのではなく、 その管理ステーションが必要とする情報のみを送るように制限されます。 そのコミュニティstringsは、解読し難くなるように慎重に選択され、 これらのコミュニティstringsを30日～90日の間に変更するために、 ふさわしい手続きがあります。 システムが2つのSNMPコミュニティstringsをサポートする場合、 その古いstringは、まず、2番目のより新しいコミュニティstringを設定し、 現在、 使われているstringから新しいものに移行することによって置き換えられます。 大部分の大規模ISPは、 彼らのルータにアクセスする複数のSNMPシステムをもつので、 すべての正しいシステムについて、 すべてのことを完了するまでに1メンテナンス期間以上を要します。 SNMP RWは、使われておらず、設定によって無効化されています。
アクセス制御は、インフラストラクチャのデバイスについて、 厳密な(stringent)フィルタリング・ルールを使うことによって厳格に強制されます。 限られたIPアドレスの集合が、 そのインフラストラクチャのデバイス宛のコネクションの開始を許可され、 それらは、限られているサービス(すなわち、SSHとSNMP)ごとに固有です。
すべてのデバイス管理アクセスは、監査され、あらゆる侵害は、 自動化された電子メール、pager、かつ／または、 電話通知を開始するアラームを発します。 AAAサーバーは、認証された主体の記録と共に、 特定のデバイス上で行われた、すべてのコマンドを保ちます。 さらに、そのデバイス自体が、あらゆるアクセス制御の侵害(すなわち、 明示的に許可されていないIPアドレスから到来するSSHリクエスト)を記録する場合、 そのイベントは、その攻撃している IP アドレスを追跡でき、 原因究明が「なぜ、 特定のインフラストラクチャのデバイスにアクセスすることを試みていたか？」に関して、 できるように記録されます。
デバイスの帯域外管理のために提供されるセキュリティ・サービスは、ほぼ、 デバイスの帯域内管理のセキュリティサービスと同じです。 デバイス・アクセスを制御し、制限することの重要性に起因して、 多くのISPは、 「管理トラフィックを通常の顧客データのトラフィックから物理的に分離することは、 リスク軽減のレベルを上げて提供し、 潜在的な攻撃ベクトルを制限する」という感触をもっています。 下記のセキュリティ・サービスが、 以前の節において述べられた実践の利用を通じて提供されます。：
使われている、あらゆるデバイス管理プロトコルについて、 パスワードの選択は、「そのパスワードが、 全数検索(brute-force)攻撃による推測もしくは解読が困難であること」を確保するために、 きわめて重要です。
IPsecは、配備するのが難しすぎると考えられており、 秘匿する管理アクセスのために提供される卑近なプロトコルは、SSHです。 SSHの利用については、 SSHが旧式(legacy)の機器においてサポートされていない可能性があるので、 機器の制限に起因して、例外があります。 場合によっては、デバイスのホスト名の変更は、 SSH rekeyイベントを要求します。 なぜならば、その鍵は、ホスト名、MAC (Message Authentication Code)アドレスおよび時刻の何らかの組み合わせに基づくからです。 また、そのSSH鍵が経路processorカード上に保存される場合、 その経路processorカードが交換(swap)される必要があるときはいつも、 SSHのre-keyingが要求されます。 ISPには、「この運用的影響は、 必要不可欠なセキュリテを越えている」という感触をもっているところがあり、 代わりに、 (「ジャンプ・ホスト」もしくは 「要塞(bastion)ホスト」と呼ばれる)信頼される内部のホストから、 それらのデバイスを管理するためにTelnetを使っています。 個人は、まず、そのジャンプ・ホストにSSHし、次に、 そのジャンプ・ホストから実際のインフラストラクチャのデバイスに、 「あらゆるパスワードは、そのジャンプ・ホストと、 接続中のデバイス間を平文で送られること」をよく理解しながらTelnetします。 すべての認証と認可は、なおもAAAサーバーを使って行われます。
Telnetアクセスが使われている場合、そのAAAサーバー上の記録は、 より冗長(verbose)であり、それらについて、 あらゆる不自然なふるまいを検知するために、より、注意が払われます。 そのジャンプ・ホスト自体は、慎重に制御されたマシンであり、通常、 アクセスが制限されています。 「Telnetは、特定のジャンプ・ホストからを除いて、 インフラストラクチャのデバイスに対して決して許可されないこと」に注意してください。 すなわち、パケットフィルタは、コンソール・サーバー、かつ／または、 インフラストラクチャ・デバイスにおいて、「Telnetは、 特定のIPアドレスからのみ許可されること」を確保するために使われます。
何千もの管理すべきデバイスをもつISPには、デバイスを認証するために、 自動化されたメカニズムを作成したところがあります。 一例として、Kerberosは、 Kerberosをサポートするデバイスについて認証プロセスを自動化するために使われてきました。 個人は、まず、Kerberos化されたUNIXサーバーにSSHを使ってログインし、 Kerberos「チケット」を生成します。 この「チケット」は、通常、10時間の有効期間をもつように設定され、 その個人をそのインフラストラクチャのデバイス宛に自動的に本人認証するために使われます。
SNMPが使われている事例において、legacyデバイスによっては、 SNMPv1のみをサポートするものがあり、これは、運用的なシンプルさのために、 そのISPにすべてのインフラストラクチャのデバイスに渡って、 その利用を必須とすることを要求します。 SNMPv2が、v3よりも設定が容易であるので、主に配備されています。
この節では、「どのように、 そのネットワーク・インフラストラクチャのデバイスを通るトラフィックは、 扱われるか？」について述べます。 ISPの主要な目標は、顧客のトラフィックを転送することです。 しかし、サービス妨害攻撃をもたらし、 そのネットワークを利用不能にする可能性がある大量の悪意あるトラフィックに起因して、 しばしば、正規の顧客のトラフィックを転送することの可用能性を確保するための特定の手段が配備されます。
あらゆるデータ・トラフィックは、潜在的に、 攻撃トラフィックである可能性があり、挑戦することは、 「あらゆる悪意あるトラフィックを検知し、潜在的には、 転送を止めること」です。 計画的に発信された攻撃トラフィックは、偽装された発信元、 かつ／または、宛先のアドレスをもつパケット、もしくは、 プロトコル関連のセキュリティ問題を引き起こすためにヘッダー・フィールドの部分を台無しにする他の何らかの改変されたパケットから成る可能性があります。 (例：接続のリセット、歓迎されないICMPリダイレクト、 歓迎されないIPオプションの作成、パケットのフラグメント化)
フィルタリングと、レート制限は、 ISPサービスを利用不能にする悪意あるトラフィックのリスク軽減を提供する主要なメカニズムです。 しかし、 データ・パスのトラフィックのフィルタリングとレート制限は、 「どのように、そのプロセスは、自動化されているか？」と「何が、 既存の配備されているハードウェアの機能と性能の制約であるか？」に依存して、 様々な方法で配備されます。
機器について性能問題を抱えていないISPは、 イングレス・フィルタリングについてBCP38 [RFC2827] とBCP84 [RFC3704] のガイドラインに従います。 BCP38は、 サービス妨害(DoS)攻撃の影響を制限するために、 入方向のパケットを明らかに偽装された、かつ／または、 「予約された(reserved)」発信元アドレスでフィルタすることを推奨し、 一方、BCP84は、 その推奨事項をマルチホームされた環境について発展させています。 フィルタも、ISP間の緩和の論点を支援するために扱われます。 何のフィルタリングも無しには、exchangeをまたぐピアは、 単に固定的な経路の利用によって通過を盗み、要するに、 データ・トラフィックをリダイレクトする可能性があります。 それゆえ、ISPには、上述の文書中には規定されていない、 予期しなかった発信元と宛先のアドレスをブロックする入方向／出方向のフィルタを実装したところがあります。 Null経路と、ブラックホールtriggeredルーティング [RFC3882] は、 あらゆる検知された悪意あるトラフィック・ストリームを判定するために使われます。 これらの2つのテクニックは、 下記2.8節に詳述されています。
大部分のISPは、レイヤ4フィルタリングを有用と考えていますが、 これは、性能の限界がそれを許容する場合のみ、実装されます。 これは、運用管理的に大きな一般管理(overhead)をもたらし、ISPは、 インターネット・ファイアウォールとしての役割をすることを、 とても嫌うので、レイヤ4フィルタリングは、典型的には、 最後のオプションとして実装されます。 Netflowは、トラフィック・フローを追跡するために使われますが、 サンプリングは、 悪意あるふるまいを検知するために十分であるか否か？」といった関心事があります。
Unicast RPF (Reverse Path Forwarding)は、 整合的に実装されていません。 ISPには、実装しつつあるところがある一方、他のISPは、 「偽装されたトラフィックが正規のアドレスから来ることを知ることによって知覚される恩恵は、 運用上の複雑性に値しない」と考えています。 ISPには、DS3 (Digital Signal 3)以下のリンク速度において、 uRPFを実装するポリシーをもつところがあります。 これは、「ネットワーク中のすべてのハードウェアは、 DS3以下の速度について、 uRPFをサポートしていた」という事実に起因します。 より高速なリンクにおいて、uRPFのサポートは、 整合的ではありませんでした。 そして、運用要員にとっては、 整合性ある解決策を実施することがより容易でした。
レイヤ2デバイスについて、MACアドレスのフィルタリングや認証は、 大規模な配備において使われていません。 それは、これがネットワークの論点についてトラブル・シュートするとき、 もたらす可能性がある問題に起因します。 ポートのセキュリティは、何千ものスイッチが配備されている大規模において、 管理不能になります。
Rate limitingは、いくつかのISPによって、使われています。 ただし、他のISPには、攻撃者は、都合よくふるまってはくれず、これは、 何ら複雑性を上まわる運用的な便益を提供しないので、「これは、 現実には有用でない」と信じているところがあります。 ISPには、「レート制限は、 正規のトラフィックを切望するレート制限スキームの一部となるような、 より少ないトラフィックを送信することを要求することによって、 攻撃者の仕事を、 より容易にする可能性もある」という感触をもっているところがあります。 レート制限は、 フィルタリングhooksをもつフローに基づくレート制限機能を開発することによって、 改善される可能性があります。 これは、現在の機能を越えて、粒度のみならず、性能も改善します。
フィルタできる機能に関する整合性の欠如は、 (特に性能の論点に関して)いくつかのISPがBCP38とBCP84のイングレス・フィルタリングについてのガイドラインを実施しない事態をもたらします。 そのような一例は、ルータにOC-12 (Optical Carrier) uplinkで接続する1000のT1を上限とするエッジ・ボックスにおいてです。 配備されたデバイスには、フィルタリングについて、 顧客のトラフィックを通過させるために、許容できないほど、 性能に大きな影響が出る実験結果となったものがありますが、 イングレス・フィルタリング(uRPF)は、 これらのアグリげーション・ルータを接続しているデバイスにおいて適用可能である可能性があります。 性能が論点とならない場合、 そのISPは、「管理対リスク」間の二律背反を選択することになります。
ルーティング面は、 ルーティング・プロトコル情報の確立と維持の一部となるすべてのトラフィックを扱います。
ルーティング面上の攻撃は、 待ち伏せ攻撃と積極的な攻撃の両方である可能性があります。 待ち伏せ攻撃は、誰かが、 その通信を行うルーティング・ピア間のデータを傍受する能力をもつ場合、 可能です。 これは、単一のルーティングピアが何らかの方法で侵され、 ネットワーク・スニッファとしての役割を果たす可能性がある場合、 あるいは、ネットワーク・スニッファの役割をする新しいデバイスを挿入することが可能な場合、 完遂される可能性があります。
積極的な攻撃は、パス上と、パス外の両方のシナリオについて可能です。 パス上の積極的な攻撃について、その状況は、待ち伏せ攻撃と同様です。 ここで、デバイスが既に侵されている必要があるか、あるいは、デバイスが、 そのパス中に挿入される可能性があるかのいずれかです。 これは、攻撃者が正規のルーティングピアになりすまし、 ルーティング情報を交換することをもたらす可能性があります。 意図的ではない積極的な攻撃は、設定エラーに起因して、より卑近です。 これは、正規のルーティングピアが、 他の近隣のピアに不正なルーティング情報を与えることをもたらします。
パス外の積極的な攻撃について、この攻撃は、一般に、 トラフィックの宛先を不正なものに変更して、 トラフィックが意図された宛先には決して到達しないことをもたらす可能性がある、 メッセージの挿入もしくは改変に限られます。
秘匿性の侵害は、 悪人が何らかのルーティングの更新トラフィックを傍受するとき、 起きる可能性があります。 これは、多くのISPがアドレス割り当てスキームとネットワーク・トポロジをプライベートかつ私有の(proprietary)情報と位置づけているので、 より関心が高まりつつあります。 これは、そのルーティング・プロトコルのパケットが、 ルーティングセッションが偽装されうる、あるいは、 ハイジャックされうる方法を示す可能性がある情報を含むゆえの関心事でもあります。 これは、かえって、 中間者(man-in-the-middle)攻撃をもたらす可能性があります。 ここで、その悪人は、自身を、そのトラフィック・パス中に挿入するか、 あるいは、そのトラフィック・パスを変更して、 ユーザのデータの秘匿性を侵害できます。
何らかの暗号技術的なメカニズムがデータのインテグリティや秘匿性を提供するために使われていた場合、 オフラインの暗号技術的な攻撃は、潜在的に、 そのデータを侵すことができます。 そのトラフィックは、ネットワーク上で盗聴することによって、あるいは、 トラフィックを悪意あるユーザ宛にそらせることができるによって、 捕捉される必要があります。 「暗号技術的に防護されたルーティング情報を使うことによって、後者は、 その暗号鍵が何らかの方法によって既に侵されていることを要求し、 それゆえ、この攻撃は、 デバイスが暗号技術的に防護されたルーティング情報を盗聴・捕捉できる場合にのみ現実的であること」に注意してください。
再生攻撃が成功するためには、ルーティング面のトラフィックは、 まず、パス上か、あるいは、 あとで意図した受信者宛に再生されるように攻撃者宛に変更するか、 のいずれかで捕捉される必要があります。 さらに、これらのプロトコルの多くは、 再生攻撃を防護するメカニズムを含むので、適用可能な場合、 これらも、調査される必要があります。
ルーティング面のトラフィックは、 中間にあるホストを制御している誰かによって操作される可能性があります。 さらに、トラフィックは、 IPアドレスを偽造することによって挿入される可能性があります。 ここで、遠隔のルータは、 別のtrustedルータから来るように見えるパケットを送信します。 メモリ(の容量)が限られたルータによって、 十分過ぎるトラフィックが処理されるように挿入される場合、これは、 サービス妨害攻撃(DoS 攻撃)をもたらす可能性があります。
中間者(man-in-the-middle)による攻撃は、データ・ストリーム自体ではなく、 通信を行うピアの身元を攻撃します。 その攻撃者は、 一方のルーティングピアから他方宛に送信されるトラフィックを傍受し、 そのピアの一方に代わって通信します。 これは、そのユーザ・トラフィックを認可されていない受信者宛にそらしたり、 あるいは、 意図した宛先には決して到達しない正規のトラフィックをもたらす可能性があります。
ルーティング面をセキュアにすることは、 一般的にシステムとして配備されている多くの機能を要します。 MD5 (Message Digest 5)認証は、送信側のピアを検証し、 「その転送中のデータが、改変されていないこと」を確保するために、 いくつかのISPによって使われています。 ISPには、顧客の要求に応じてMD5認証のみを配備するところがあります。 「受信したルーティングの更新についての追加的な健全性(sanity)チェックは、 経路フィルタと、(しばしば、TTL-Hackとも呼ばれる)」GTSM (Generalized TTL Security Mechanism)機能 [RFC3682] を含みます。 GTSM機能は、 妥当なルーティング・ピアによって起点としたものであることを合理的な確信をもって確認するために、 BGP (Border Gatewayプロトコル)のようなプロトコルに使われ、 通信を行うピアを護るためにパケットのTTL (Time To Live)フィールド(IPv4)、 もしくは、Hop Limit (IPv6)を利用しています。 GTSMが使われる場合、これは、典型的には、ベンダー製品と、 オペレーティング・システムのバージョン間の整合性あるサポートの欠如に起因して、 内部BGPピア間の限られたシナリオにのみ配備されます。
パケットフィルタは、「どのシステムが、 妥当なピアに見えるか？」を制限するために使われ、一方、 経路フィルタは、「どの経路が、 妥当なピアからのものであると信じられているか？」を制限するために使われます。 BGPルーティングの場合、 様々なポリシーが不正なルーティング情報の伝搬を制限するために適用されます。 これらは、次の事項を含みます。： BGP顧客用の入方向と出方向のプリフィックス・フィルタ、 ピアやアップストリームの近隣用の入方向と出方向のプリフィックス・フィルタ、 BGP顧客用の入方向AS-PATHフィルタ、 ピアおよびアップストリームの近隣に向かう出方向のAS-PATHフィルタ、 依存している経路、および、棄却している選択された属性とコミュニティ。 これらのポリシー間の整合性は、一般に多様であり、「他方の終端は、 末端のサイト、内部のピア、別の大きなISP、 顧客のいずれか？」という決定的な違いがあります。 概ねISPは、 末端サイトの顧客に対してプリフィックス・フィルタを行っていますが、 大きなプリフィックス・フィルタ・リストを維持管理することの運用的制約に起因して、 多くのISPは、 そのピアやアップストリームの近隣宛／発のBGP AS-PATHフィルタに依拠し始めています。
プリフィックス・リストが使われない場合、運用者は、しばしば、 誤設定(例：意図的でない集合の逆行(de-aggregation)、あるいは、 近隣のルーティング・ポリシーの誤設定)あるいは過負荷攻撃を防ぐために、 ピアあたり最大のプリフィックス限度を定義します。 ISPは、相互に「何が期待されるプリフィックス交換であるのか？」を調整し、 この番号をまともな量ずつ増加させる必要があります。 ISPにとって、ルーティングannouncements中に妥当なswingsを許容するように十分な最大プリフィックス番号を付加して、 BGPセッションの意図しないシャットダウンを予防することは、重要です。 ISPにおける個々の実装は、固有であり、機器の供給者に依存して、 異なる実装オプションが、利用可能です。 大部分の機器ベンダーは、 単に受信した過剰なプリフィックス記録するものから、自動的に、 そのセッションをシャットダウンするものまで、 幅のある実装オプションを提供しています。 事前設定された一定の無操作時間のタイムアウトが働くようになったあとにセッションを再確立するオプションが利用可能な場合、 「自動的にセッションを再確立することは、 近隣上のポリシーの誤設定がその状況をもたらしている場合、潜在的に、 そのルーティング・テーブル全体に継続的な不安定性をもたらす可能性があること」が理解される必要があります。 ピアとなる近隣上に深刻な誤設定が起きた場合、 自動的にそのセッションをシャットダウンし、手動でクリアされるまで、 シャットダウンしたままにすることが、しばしば、最善であり、 運用者が、必要とあらば、正すために原因究明できるようにします。
大規模 ISP には、「経路がRADb (Routing Assets Database：フィルタ・リストを生成するために使えるインターネット中のネットワークについてのルーティング情報の公衆のレジストリ)の一部となりうるIRR (Internet Routing Registry)中に登録されていること」を要求するところがあります。 ISPには、(特にヨーロッパにおいて)誰かとeBGPピアとなる合意をする前に登録された経路を要求するところがあります。
また、多くのISPは、ルータや接続された顧客に対する攻撃を、 さらに軽減するために、インタフェイスのIPアドレスを宣伝しません。
これまで、ルーティング面をセキュアにすることについての主要な関心は、 その送信側のピアを検証して、「転送中のデータは、 書き換えられていないこと」を確認することでした。 MD5ルーティング・プロトコル拡張が、実装されてきましたが、これは、 ISP界において整合的に配備されていない両方のサービスを提供できます。 2つの主要な配備における関心事は、実装の論点でした。 ここでは、ソフトウェアのバグと、 寛容なre-keyingオプションの欠如の両方が、 顕著なネットワーク・ダウン時間をもたらしました。 また、ISPには、「MD5認証の配備自体は、 より悪いサービス妨害攻撃の標的であり、 GTSM (for BGP)や経路フィルタのような、 他のリスク軽減メカニズムの組み合わせを使うことを選好する」という関心を表明するところがあります。 GTSMについての論点は、「これは、 異なるベンダーの製品に渡るすべてのデバイス」においてサポートされていないことです。
IPsecについては、相互運用可能性と、 信頼できる設定を確保するという運用管理の観点から、あまりに複雑であり、 運用上、実現可能となるには時間を要するものであるので、 実装されていません。 そのルーティング情報の秘匿性についての関心も限られていました。 更新のインテグリティと妥当性は、はるかに大きな関心がもたれています。
新しい経路を導入し、 ルーティング・ドメイン全体に反映できる手動の活動もしくは自動化された活動について、 関心があります。
ソフトウェアの更新や設定変更は、通常、帯域内か、あるいは、 帯域外管理機能のいずれかの一部として行われます。 しかし、追加的に考慮すべき事項があり、それらは、 この節で挙げられます。
システム・ソフトウェアや設定について行われる攻撃は、 「待ち伏せ攻撃」と「積極的な攻撃」の両方である可能性があります。 待ち伏せ攻撃は、 誰かがそのネットワーク・インフラストラクチャのデバイスと、 ソフトウェアもしくは設定情報をダウンロードする(／アップロードする)システム間のデータを傍受する能力をもつ場合、可能です。 これは、単一のインフラストラクチャのデバイスが、何らかの方法で侵され、 ネットワーク・スニッファとしての役割をする可能性がある場合、もしくは、 ネットワーク・スニッファの役割をする新しいデバイスを挿入することが可能な場合、 完遂される可能性があります。
積極的な攻撃は、パス上と、パス外の両方のシナリオについて可能です。 パス上の積極的な攻撃について、その状況は、デバイスが既に侵されているか、 あるいは、デバイスが、そのパス中に挿入できるか、 のいずれかの場合の待ち伏せ攻撃についてと同様です。 パス外の積極的な攻撃について、その攻撃は、一般に、 メッセージの挿入もしくは改変に制限されます。 ここで、その攻撃者は、不法なソフトウェアもしくは設定ファイルをインフラストラクチャのデバイスにロードすることを望む可能性があります。
「同様な論点は、ソフトウェアの更新がソフトウェア更新、かつ／または、 設定情報について責任を負うベンダーのサイトからISPのネットワーク管理システム宛にダウンロードされるとき、 関連すること」に注意してください。
秘匿性の侵害は、 悪人が何らかのソフトウェアのイメージもしくは設定情報を傍受するとき、 起きる可能性があります。 そのソフトウェアのイメージは、 そのデバイスが脆弱となる攻略法を示す可能性がある一方、設定情報は、 不注意に、 攻撃者が極めて重要なインフラストラクチャのIPアドレスやパスワードを識別することをもたらす可能性があります。
何らかの暗号技術的メカニズムがデータのインテグリティと秘匿性を提供するために使われた場合、 オフラインの暗号技術的な攻撃は、潜在的に、 そのデータを侵す可能性があります。 そのトラフィックは、その通信パス上における盗聴によるか、あるいは、 トラフィックの宛先を悪意あるユーザに変更できることのいずれかによって、 捕捉される必要があります。
再生攻撃が成功するためには、 そのソフトウェアのイメージもしくは設定ファイルは、まず、パス上か、 あるいは、 あとで意図された受信者宛に再生するために攻撃者に宛先を変更するか、 のいずれかで捕捉される必要があります。 さらに、多くのプロトコルは、再生攻撃を防護する機能をもっているので、 これらも、適用可能な状況において、調査される必要があります。
ソフトウェアのイメージと設定ファイルは、 中間にあるホストを制御している誰かによって作成される可能性があります。 IPアドレスを偽装し、 ソフトウェアのイメージもしくは設定ファイルをダウンロードできる妥当なホストになりすますことによって、 不正なファイルが、 インフラストラクチャのデバイスにダウンロードされる可能性があります。 これは、 侵された信頼されるホストをもっていることが知られていない可能性がある信頼されたベンダーからの場合である可能性があります。 不正なソフトウェアのイメージもしくは設定ファイルは、 デバイスをハングさせ、運用不能になる可能性があります。 偽装された設定ファイルは、検知困難である可能性もあります。 特に、唯一の追加コマンドが、 悪人が特定のホスト・アクセスを許可するフィルタを入れることと、 ローカルのユーザ名／パスワードのデータベース・エントリを、 そのデバイスに対する認証用に設定することによって、 そのデバイスにアクセスすることを許容しているときです。
中間者(man-in-the-middle)攻撃は、データ・ストリーム自体ではなく、 通信を行うピアの身元を攻撃します。 その攻撃者は、インフラストラクチャのデバイスと、 システムのイメージもしくは設定ファイルをアップロード／ダウンロードするために使われるホスト間を送られたトラフィックを傍受します。 次に、彼(／彼女)は、 これらのシステムの一方もしくは両方に代わってふるまうことができます。
攻撃者が配備されているソフトウェアのイメージのコピーを攻撃した場合、 彼は、潜在的に、既知の脆弱性を攻略して、 システムにアクセスする可能性があります。
捕捉された設定ファイルからは、 その設定ファイル中の何らかのパスワードが暗号化されていなかった場合、 彼は、秘密のネットワーク・トポロジー情報や、 より打撃となるような情報さえも得ることができました。
イメージや設定は、アクセスが制限された特定のホストに保存されます。 すべてのアクセスと、これらのホストに関する活動は、 AAAサービス経由で本人認証され、記録されます。 何らかのシステムのソフトウェアもしくは設定ファイルをアップロードさした(／ダウンロードする)とき、 TFTP, FTP, SCPのいずれもが、使えます。 可能であれば、SCPは、そのデータ転送をセキュアにするために使われ、 FTPは、一般に、決して使われません。 すべてのSCPアクセスは、ユーザ名／パスワードで本人認証されますが、 これは、対話的なシェルを要求するので、大部分のISPは、 その対話型シェルを避けるために、shared key認証を使います。 TFTPアクセスは、セキュリティ機能をまったくもちませんが、まだ、 特に帯域外管理シナリオにおいて、広く使われています。 ISPには、そのTFTPサーバー上にIPに基づく制限を実装するところがありますが、 特注(custom)として書かれたTFTPサーバーには、 MACに基づく認証をサポートするものがあります。 MACに基づく認証は、ルータを起動するためにTFTPを遠隔から使うとき、 より卑近です。
大部分の環境において、スクリプト類が、 多数のルータのイメージや設定を維持管理するために使われます。 設定のインテグリティを確保するため、毎時、その設定ファイルは、 ポーリングされ、食い違い(discrepancies)を見つけるために、 以前にポーリングされたバージョンと比較されます。 少なくとも、ある環境において、これらのツールは、 (秘匿性ではなく)自動化された認証を利用するためにKerberos化されます。 「Rancid」は、設定やシステムの変更の検知用の、 有名な公衆が利用可能なツールのひとつです。
フィルタは、 設定ファイルやシステムのイメージをアップロード／ダウンロードするための特定のIPアドレスやプロトコルへのアクセスを制限するために使われます。
そのソフトウェアのイメージは、CRC (Cyclic Redundancy Check)を行い、 そのシステムのバイナリは、インテグリティを検証するため、 MD5アルゴリズムを使います。 多くのISPは、セキュリティを充実させるために、 MD5アルゴリズムに基づくソフトウェアのイメージのインテグリティ検証をもつことについての関心を表明しました。
すべての設定ファイルにおいて、大部分のパスワードは、 暗号化されたフォーマットで保存されます。 「多様な製品において使われる暗号化テクニックは、 多様である可能性があり、それゆえ、 何らかの弱い暗号化スキームがオフラインの辞書攻撃の対象となる可能性があること」に注意してください。 これは、ユーザ認証用のパスワード、 MD5認証のshared secrets、AAAサーバのshared secrets、 NTPのshared secrets等を含みます。 この機能をサポートしない可能性がある、より古いソフトウェアについて、 設定ファイルは、 何らかのパスワードを可読なフォーマットで含む可能性があります。 大部分のISPは、何らかのパスワードの侵害のリスクを、 これらの設定ファイルをパスワードの行を除いて保存することによるか、 あるいは、 防護された帯域外管理デバイス上に保存される設定ファイルへの本人認証・認可されたアクセスを要求するか、 のいずれかによって、軽減します。
インフラストラクチャのデバイスについて、 多くの良く知られた攻撃に対抗する妥当な設定を確保するために、 自動化されたセキュリティ検証が、 Nmap (Network Mapping)やNessusを使って行われます。
MD5アルゴリズムがソフトウェアのイメージや設定ファイルのデータ・インテグリティをチェックするために使われていない場合、 ISPは、この機能をもつことに興味を表明しました。 IPsecは、あまりに扱いにくいものであり、 データのインテグリティと秘匿性のために使うことは運用的に困難であると見なされました。
記録(logging)は、すべての以前の節の一部ですが、 単独の項目として扱われることは、十分に重要です。 主な論点は、「何が記録されるか？」、「どれだけの期間、 記録は保たれるか？」および「転送中と、保存中に、 どのメカニズムが記録された情報をセキュアにするために使われたか？」を含みます。
記録されたデータについての攻撃は、 待ち伏せ攻撃と積極的攻撃の両方である可能性があります。 待ち伏せ攻撃は、誰かが、受信する記録用サーバと、 記録されたデータの発信元のデバイス間のデータを傍受する能力をもつ場合、 可能です。 これは、あるインフラストラクチャのデバイスが、何らかの方法で侵され、 ネットワーク・スニッファ役割をすることができる場合、あるいは、 ネットワーク・スニッファとしての役割をする新しいデバイスを挿入することが可能な場合、 遂行される可能性があります。
積極的攻撃は、パス上と、パス外の両方のシナリオについて可能です。 パス上の積極的な攻撃について、その状況は、 デバイスが既に侵されてしまっているか、あるいは、デバイスが、 そのパス中に挿入される可能性があるか、 のいずれかである待ち伏せ攻撃についてと同様です。 パス外の積極的な攻撃について、この攻撃は、一般に、 何らかの侵害が検知されないように保つため、あるいは、 犯罪の訴訟のために使われる可能性がある何らかの証拠を破壊するために、 記録されたデータを変更する可能性がある、 メッセージの挿入もしくは改変に限られます。
秘匿性の侵害は、 悪人がネットワーク上を転送中の何らかの記録用データを傍受するとき、 起きる可能性があります。 これは、 記録されたデータ中に含まれるとプライバシの侵害となる可能性があるようなあらゆるデータを不許可とする分析が行われていない場合、 プライバシーの侵害もたらす可能性があります。
何らかの暗号技術的なメカニズムがデータのインテグリティと秘匿性を提供するために使われた場合、 オフラインの暗号技術的な攻撃は、潜在的に、 そのデータを侵すことができます。 そのトラフィックは、そのネットワーク上の盗聴によるか、あるいは、 トラフィックをの宛先を悪意あるユーザに変更できることによって、 捕捉される必要があります。
再生攻撃が成功するためには、その記録しているデータは、まず、パス上か、 あるいは、攻撃者に宛先を変更して、あとで受信者宛に再生されるか、 のいずれかで捕捉される必要があります。
データを記録することには、中間にあるホストを制御している誰かによって、 挿入、削除あるいは改変される可能性があります。 データを記録することには、正規の IP アドレスからの、あるいは、 不正なIPアドレスからの偽のパケットによって挿入される可能性もあります。
中間者(man-in-the-middle)による攻撃は、データ・ストリーム自体ではなく、 通信を行うピアの身元を攻撃します。 その攻撃者は、 インフラストラクチャのデバイスと記録サーバー間を送信されるトラフィック、 もしくは、記録サーバーと、 記録されたデータ保存するために使われているデータベース間を送信されるトラフィックを傍受します。 logging情報に対する、あらゆる認可されていないアクセスは、 プライベートかつ特有のネットワーク・トポロジ情報についての知識をもたらす可能性があります。 これは、そのネットワークの部分を侵すために使われる可能性があります。 追加的な関心事は、何らかのセキュリティ侵害の痕跡を隠すために、 削除あるいは改変される可能性がある記録情報にアクセスできるようにすることです。
フィルタリングにおいて、記録は、 概ね「例外事項を監査する」という基準で行われます。 (すなわち、許可されていないトラフィックが、 記録されます。) これは、「記録サーバーが、データで圧倒されて、 大部分のログが使えなくなってしまうようにはないこと」を確保するためです。 典型的には、記録されたデータは、発信元と宛先のIPアドレス、 レイヤ4のポート番号、およびタイムスタンプを含みます。 syslogプロトコルは、 インフラストラクチャのデバイスからsyslogサーバー間を、 その記録されたデータを転送するために使われます。 多くのISPは、syslogサーバーと、 そのデバイス間で仮想的になされるセキュリティが無いので、 syslogデータを転送するために、帯域外管理ネットワークを使います。 すべてのISPは、複数のsyslogサーバーをもち、ISPには、 多様なインフラストラクチャ・デバイスについて、 別々のsyslogサーバーの利用を選択するところがあります。 (すなわち、ひとつのsyslogサーバーをバックボーン・ルータ用にし、 ひとつのsyslogサーバーを顧客のエッジ・ルータ用にする等。)
タイムスタンプは、NTPから取得され、これは、一般に、 stratum1およびstratum2において、少ない設定と維持管理で済むように、 平坦な階層に設定されます。 設定の整合性と冗長性(redundancy)が、主な目的です。 「正しいNTP時刻が利用可能であること」を確認するために選択された、 いくつかのstratum1サーバーの源泉と共に、各ルータは、 たとえ様々なネットワークの停止が起きたとしても、設定されます。
フィルタリングの例外事項を記録することに加えて、典型的には、 下記の事項が記録されます。：
これらすべてのログ・メッセージの主な機能は、「何を、そのデバイスは、 行っているか？」を観ることと、「特定の悪意ある攻撃者は、 何をしようとしているのか？」を試して確かめることです。 syslogは、信頼できないプロトコルですので、ルータが起動するとき、 あるいは、近接を失うとき、 すべてのメッセージが遠隔のsyslogサーバー宛に配信されるわけではありません。 ベンダーによっては、 syslogバッファに貯める機能を実装する可能性があります。 (例：syslogの宛先への経路ができるまで、 メッセージをバッファに貯める) しかし、これは、標準ではありません。 それゆえ、運用者は、しばしば、 「そのサーバーに基づくsyslogファイルには、 典型的には、とても小さなメモリ容量がそのために割り当てられており、 不完全である可能性がある」という事実を構成するために、 デバイス上のローカルのsyslog情報を見る必要があります。 ISPには、 ルーティング更新や撤回(withdrawal)を見るために待ち伏せるデバイスを設置し、 ログ・ファイル用のデバイスのみには依存しないところもあります。 これは、「そのネットワークにおいて、CPUの負荷が高い場合、 デバイスがsyslogを動作させることを『忘れる』可能性があるとしたら、 何が起きているか？」を見るために、 バックアップ・メカニズムを提供します。
様々なsyslogサーバー・デバイスからの記録は、一般に、 (毎10分から毎時までの)一定間隔で、 あらゆる場所にありうるデータベースに転送されます。 あるISPは、 そのデータをデータベース中に押し込むためにRsyncを使い、その情報は、 そのデータベース宛にSSHする誰かによって、手動で保存されます。
syslogについて、セキュリティは無く、ISPは、 このことをよく認識しています。 IPsecは、運用的に、あまりに高価であり、 配備するには扱いにくいものであると見なされています。 Syslog-ngやstunnelは、より良く認証(authenticate)され、 インテグリティが保護された解決策を提供すると見られています。 認可されていない要員がログ・メカニズムを不正にいじることを防ぐことは、 「誰が、 その記録サーバーやファイルにアクセスできるか？」を監査することと考えられています。
ISPは、単なるUDP syslogについて以上の要件を表明しました。 さらに、彼らは、より粒度が細かく、かつ、柔軟な設備や機器(すなわち、 特定のサーバーについての特定のログ)を好みます。 また、 ベンダーのデバイスもしくはソフトウェアの各更新のあとにパーサを変更できるような、 標準イベントを報告するための共通フォーマットは、 必要不可欠ではありません。
フィルタリングは、以前の節の多くにおいて扱われてきましたが、この節は、 現在、考慮されつつあるフィルタリングについての考慮事項に関して、 より深い思慮を提供します。 フィルタリングは、今や、3つの特定分野に分類されています。：
データ面のフィルタは、デバイスを通過するトラフィックを制御し、 通過トラフィックに影響を与えます。 大部分のISPは、 BCP38とBCP84のガイドラインを使って、 この種のフィルタをスプーフィング(spoofing)攻撃を軽減するために、 顧客に面したエッジデバイスに配備しています。
管理フィルタは、 デバイス宛のトラフィックとデバイスからのトラフィックを制御します。 デバイス管理のために使われるすべてのプロトコルは、この分類となり、 下記の事項を含みます。：
この種のトラフィックは、しばしば、インタフェイスごとにフィルタされ、 プロトコル、発信元と宛先のIPアドレス、および、 発信元と宛先のポート番号のあらゆる組み合わせに基づきます。 デバイスには、管理フィルタを、特定のインタフェイス(例：receive ACLもしくはloopbackインタフェイスACL)についてではなく、 デバイスに適用する機能をサポートするものがあり、これは、 より広く受容されつつあります。 「フィルタリングのルールを記録することは、今日、 多くのシステムに負荷をかける可能性があり、より細かな粒度が、しばしば、 より具体的に要求される例外事項を記録することが要求されること」に注意してください。
具体的に使われていない、あらゆるサービスは、切られます。
IPv6ネットワークは、正しいプロトコル運用のために、 特定のICMPメッセージの利用を要求します。 それゆえ、ICMPは、デバイス宛と、 デバイス発のものを完全にはフィルタできません。 代わりに、ネットワークのデバイス発／宛の特定のICMPv6種別について、 より粒度が細かいICMPv6フィルタリングが、常に、できるように配備されます。 IPv6フィルタリングについての良いガイドラインは、 「ファイアウォールにおけるICMPv6メッセージのフィルタリングについての推奨事項」 [ICMPv6] にあります。
ルーティング・フィルタは、 ルーティング情報のフローを制御するために使われます。 IPv6ネットワークにおいて、ISPには、 まだ解決されていないマルチホーミングの論点に起因して、 /48を許容することに寛容なところがある一方、 割り当て(allocation)の境界における他のフィルタは、 典型的には/32においてです。 IPv6ルーティングについては/48より長い、そして、 IPv4ルーティングについては/24より長い、受け取った、 あらゆるannouncementは、eBGPからフィルタされます。 「これは、非顧客用トラフィックであること」に注意してください。 大部分のISPは、その顧客からの、 いかなるagreed uponプリフィックスの長さも許容します。
サービス妨害攻撃(DoS攻撃)は、絶えず増加している問題であり、 効果的に闘うためには莫大な資源を要します。 大規模ISPには、 帯域において1Gbps未満の攻撃ストリームに関心をもたないところがあります。 (これは、要するに、1Gbpsが与えられた負荷の5%未満となる、 より太いパイプにおいてです。) これは、概ね、大量のサービス妨害(DoS)トラフィックに起因します。 これは、継続的に、原因究明と軽減を要します。
最後に、大規模な分散型DoSボットネットを構成するホストの数は、 100万を越えます。
DoSの発信元を検知し、可能な限り迅速に、 あらゆる攻撃の影響を軽減するプロセスを自動化するために、 継続的に新しいテクニックが、あみ出されています。 現在、ISPは、様々な軽減テクニックを使っており、 下記の事項を含みます。：
これらのテクニックの各々については、後述されます。
Sinkholeルーティングとは、「あらゆる既知の攻撃トラフィックについて、 より具体的な経路を挿入すること」を言います。 これは、「その悪意あるトラフィックは、 それを解析できる妥当なデバイスもしくは特定のシステム宛に転送されること」を確保します。
ブラックホールを狙ったルーティング(Remote Triggeredブラックホール・フィルタリング」とも呼ばれる)は、 BGPルーティング・プロトコルが経路を宣伝するために使われるテクニックです。 これは、攻撃トラフィックを順番にヌル・インタフェイス宛にリダイレクトし、 ここで、攻撃トラフィックは、効果的に棄却されます。 このテクニックは、しばしば、 ルーティング・インフラストラクチャに扇動する際に使われます。 なぜならば、BGPは、数百もしくは数千のルータ上の、 あらゆるパケットに基づくフィルタリング・テクニックの利用とは対局となり、 速く効果的な作法で、その情報を宣伝できるからです。 (より詳細な記述については、 右記のNANOGのプレゼンテーションを参照：http://www.nanog.org/mtg-0402/pdf/morrow.pdf)
「このブラックホール化テクニックは、その目的が、 『特定のサイトから来たように見えるブラックホール化するトラフィックをけしかけること』であった場合、 実際に、その攻撃者の目的を満たす可能性があること」に注意してください。 他方、このブラックホール・テクニックは、 極めて重要なサービス以外の何かを狙った、 あまりに大きな攻撃によって引き起こされた同時多発被害を低減できます。
uRPF (Unicast Reverse Path Forwarding)は、「入方向のパケットは、 正規の発信元アドレスをもっているか否か？」を検証するためのメカニズムです。 これは、2つのモードをもちます。： strictモードとlooseモードです。 strictモード において、uRPFは、「入方向のパケットは、 ルーティング・テーブル中のプリフィックスと一致する発信元アドレスをもつか否か？」と、 「そのインタフェイスは、 この発信元アドレスのプリフィックスをもつパケットを受信することを期待しているか否か？」をチェックします。 その入方向パケットがそのunicast RPFチェックに失敗する場合、 そのパケットは、入方向のインタフェイスにおいて、許容されません。 LooseモードuRPFは、さほど特定的ではなく、その入方向パケットは、 その発信元アドレスについて、 ルーティング・テーブル中にいずれかの経路がある場合、許容されます。
BCP84 [RFC3704] とRPF experiencesについての調査 [BCP84-URPF] は、 「非対称性が(すなわち、パケットの発信元への複数の経路が)、 いかにfeasibleパスのstrict uRPFの適用を妨げないか？」について詳説していますが、これは、通常、 それらは、 非対称的なルーティングをもちがちなインタフェイス上で使われません。 通常、より大きなISPにおいては、 uRPFがネットワークの顧客エッジに設置されます。
レート制限(Rate limiting)とは、「一定の帯域、もしくは、 特定のトラフィックの種類についての秒あたりのパケット数を確保すること」を言います。 このテクニックは、 多数の資源が偽装されたTCPトラフィックについて割り当てられる場合、 TCP-SYN攻撃のような、 既知のプロトコル攻撃を軽減するために広く使われています。 このテクニックは、攻撃を止めませんが、しばしば、特定のサービスについて、 被害と影響を低減できます。 しかし、これは、そのレート制限が、 より正規のトラフィックに影響を与えている場合(すなわち、 棄却してしまう場合)、DoS攻撃の影響を、 もっと悪くしてしまう可能性もあります。
ISPには、そのフィルタリングと、 制御トラフィックのレート制限をシンプルにするために、 いくつかのベンダーから入手可能な機能を使い始めているところがあります。 ここでは、制御トラフィックとは、 CPUサイクルを要求するルーティング制御面と管理面のトラフィックを言います。 それゆえ、あらゆる制御面のトラフィックに対するサービス妨害攻撃は、 極めて重要なデバイスに対して、他の種類のトラフィックより、 はるかに破壊的である可能性があります。 この執筆時点において、この機能の整合的な配備は、 見受けられませんでした。
本書全体が、大規模ISP環境における現在のセキュリティ実践を扱っています。 これは、今日の環境において使われている具体的な実践を掲げており、 それゆえ、これ自体は、 いかなるセキュリティ・リスクをも提起するものではありません。
著者は、下記の方々の貢献に大いに感謝しています。： George Jonesは、本書について、ガイダンスや方向性を与えてくれて、 助けてくれました。 Ross Callon, Ron Bonica, Ryan Mcdowell, Gaurab Upadhaya, Warren Kumari, Pekka Savola, Fernando Gont, Chris Morrow, Ted Seely, Donald Smithは、顕著なコメントを寄せてくれました。 そして、多数のISP運用者が、 本書が頼っている情報を提供してくれました。
| [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月. |
| [RFC2828] |
Shirey, R., 「インターネットセキュリティ小辞典(Internet Security Glossary)」, RFC 2828, 2000年5月. |
| [RFC3552] |
Rescorla, E. and B. Korver, 「RFCの『セキュリティについての考慮事項』についての文章を書くためのガイドライン(Guidelines for Writing RFC Text on Security Considerations)」, BCP 72, RFC 3552, 2003年7月. |
| [RFC3682] |
Gill, V., Heasley, J., and D. Meyer, 「GTSM(The Generalized TTL Security Mechanism (GTSM))」, RFC 3682, 2004年2月. |
| [RFC3704] |
Baker, F. and P. Savola, 「マルチホームされたネットワークのためのイングレスフィルタリング(Ingress Filtering for Multihomed Networks)」, BCP 84, RFC 3704, 2004年3月. |
| [RFC3882] |
Turk, D., 「サービス妨害攻撃を防ぐためにBGPを設定する(Configuring BGP to Block Denial-of-Service Attacks)」, RFC 3882, 2004年9月. |
| [BCP84-URPF] |
Savola, P., "Experiences from Using Unicast RPF", 作業中, 2006年11月時点. |
| [ICMPv6] |
Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", 作業中, 2006年7月時点.(→ RFC 4890として発行されました。) |
| [RTGWG] |
Savola, P., "Backbone Infrastructure Attacks and Protections", 作業中, 2006年6月時点. |
この節では、数年来、悪意をもって作られたパケット 、かつ／または、 プロトコルdeficienciesの攻略をもたらすことが観測されてきた、 多くの従来型のプロトコルに基づく攻撃を挙げます。 「それらすべては、実際のプロトコル自体の中の脆弱性を攻略し、しばしば、 追加的な認証と監査するメカニズムが、現在、これらの攻撃の影響を検知し、 軽減するために使われていること」に注意してください。 このリストは、網羅的ではありませんが、「どの種類の攻撃が、 多様なプロトコルについて可能か？」についての表現の断片(fraction)です。
次に、追加的な攻撃を掲げますが、明示的にそれらを詳細に目録化しません。 これは、情報提供のためにすぎません。
上述の、あらゆるIPv4攻撃は、 (何らかのフラグメント化やブロードキャスト・トラフィックの例外はありますが)IPv6ネットワークにおいても使われる可能性があり、 これは、IPv6において、異なる操作をします。 「これらの攻撃のすべては、偽装(spoofing)か、あるいは、 いずれかのプロトコル・フィールドの誤用のいずれかに基づくこと」に注意してください。
今日、IPv6対応のホストが、IPv6トンネルを作るために使われ始めています。 これは、ファイアウォールや、ネットワークflow collectionツールがこのトラフィックを検知できない場合、 ボットネットや他の悪意あるトラフィックを効果的に隠すことができます。 IPv6インフラストラクチャの防護に使われているセキュリティ手段は、 IPv4ネットワークにおけるものと同じである必要がありますが、 IPv4とは異なる可能性があるIPv6ネットワーク運用について、 追加的な考慮事項を伴う必要があります。
Merike Kaeo
Double Shot Security, Inc.
3518 Fremont Avenue North #363
Seattle, WA 98103
U.S.A.
電話： +1 310 866 0165
EMail： merike＠doubleshotsecurity.com
独立行政法人 情報処理推進機構
セキュリティセンター
EMail： miyakawa＠ipa.go.jp
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr＠ietf.org.
Funding for the RFC Editor function is currently provided by the Internet Society.