ネットワーク WG
Request for Comments: 4778
分類:情報提供

M. Kaeo
Double Shot Security, Inc.
2007年 1月

English

ISP 環境における現在の運用的なセキュリティ実践
(Current Operational Security Practices in Internet Service Provider Environments)

このメモの位置づけ

このメモは、インターネットコミュニティに情報を提供するものです。これは、いかなるインターネット標準をも定めるものではありません。このメモの配布には制限はありません。

著作権表記

Copyright (C) The IETF Trust (2007).

要旨

本書は、今日の大規模 ISP の運用的ネットワークにおいて、レイヤ 2 およびレイヤ 3 のインフラストラクチャ・デバイスをセキュアにするために行われている現在の実践の調査です。ここに掲げられた情報は、ISP において、セキュアなインフラストラクチャを規定して実装することについて直接責任を負う人々から集められた情報の結果です。

 

目次

1. はじめに
1.1. 範囲
1.2. 脅威モデル
1.3. 攻撃元
1.4. 脅威による運用的なセキュリティの影響
1.5. 文書レイアウト

2. 防護された運用的機能
2.1. デバイスへの物理的アクセス
2.2. デバイス管理(帯域内と帯域外)
2.3. データ・パス
2.4. ルーティング面
2.5. ソフトウェアの更新および設定のインテグリティ/検証
2.6. 記録についての考慮事項
2.7. フィルタリングについての考慮事項
2.8. サービス妨害の追跡(Tracking/Tracing)

3. セキュリティに関する考慮事項

4. 謝辞

5. 参考文献
5.1. 規範的参考文献
5.2. 参考資料

補遺 A. プロトコル固有の攻撃
A.1. レイヤ 2 攻撃
A.2. IPv4 プロトコルに基づく攻撃
A.3. IPv6 攻撃


1. はじめに English

セキュリティ実践は、長年、ネットワーク・インフラストラクチャをセキュアにすることについて、増しつつある痛みを経験したネットワーク運用者には、よく理解されています。しかし、これらのセキュリティ実践を挙げて書かれた文書は、存在しません。ネットワーク 攻撃は、継続的に増加しており、インターネット・ポリスとしてふるまうことは、必ずしも ISP の役割ではありませんが、各 ISP は、「そのネットワークが、運用的に、顧客が利用可能であること」を確保するため、一定のセキュリティ実践が行われることを確保する必要があります。本書は、「どのような現在のセキュリティ実践が、ネットワーク・インフラストラクチャをセキュアにするために実施されているか?」を見つけるために行われた調査の結果です。

1.1. 範囲 English

この調査 の範囲は、ネットワークの利用可能性や信頼性に負の影響を与える可能性があるリスクにさらされることを軽減するセキュリティ実践に制限されています。実際のデータトラフィックをセキュアにすることは、行われた調査の範囲外です。本書は、レイヤ 2 と レイヤ 3 のネットワーク・インフラストラクチャのデバイスについて、現在、配備されているセキュリティ・メカニズムを文書化することにのみ焦点を当てます。主に IPv4 に焦点を当てていますが、同じ実践の多くは、IPv6 ネットワークに適用でき(ると共に、適用する必要があり)ます。IPv4 と IPv6 の両方のネットワーク・インフラストラクチャが、この調査において考慮されています。

1.2. 脅威モデル English

脅威は、セキュリティ侵害についての潜在的可能性であり、 これは、セキュリティを侵害し、加害する可能性がある状況、能力、活動もしくはイベントがあるとき、存在します。[RFC2828] すべての運用ネットワークは、多数の脅威となる活動(もしくは、攻撃)の対象となります。すなわち、セキュリティ・サービスを回避する計画的な試みである知的な活動に起因し、そのシステムのセキュリティ・ポリシーを侵害するシステム・セキュリティについての猛撃です。[RFC2828] ネットワーク・インフラストラクチャに対する脅威の多くは、下記の項目(もしくは、その組み合わせ)から起きます。:

偵察(Reconnaissance):
以降、既知の脆弱性を攻略するために、使われる可能性があるネットワーク・トポロジあるいは特定のデバイス情報を確かめるために情報を集める攻撃。

中間者(Man-In-The-Middle):
悪意あるユーザが、通信ストリームの送信者か、あるいは、受信者のいずれかになりすまして、あるトラフィックに挿入したり、改変したり、棄却する攻撃。この種の攻撃は、フィッシング(phishing)やセッション・ハイジャックも扱います 。

プロトコルの脆弱性の攻略:
不適切なふるまいをもたらすために、設計または実装の欠陥に起因する既知のプロトコル脆弱性を悪用する攻撃。

メッセージ挿入:
これは、正当なメッセージである可能性があります。(これは、メッセージが捕捉され、後で再送されるシナリオとなる再生攻撃である可能性があります。)メッセージは、そのメッセージ中のいずれかのフィールド(例:IP アドレス、ポート番号、ヘッダー・フィールド、あるいはパケットの内容さえ)が偽装されて挿入される可能性もあります。フラッディング(Flooding:氾濫させること)も、この脅威の具体例の一部です。

メッセージの転用(Diversion)/削除:
正規のメッセージが望まれる受信者に届く前に削除されるか、あるいは、通常はデータ・パスの一部ではないネットワーク・セグメント宛にリダイレクトされる攻撃。

メッセージ改変:
これは、以前のメッセージが捕捉されており、転送される前に改変されるメッセージ挿入攻撃の部分集合です。そのメッセージは、中間者(man-in-the-middle)攻撃、もしくは、メッセージの転用を使って捕捉される可能性があります。

「しばしば、サービス妨害攻撃は、独立した分類として掲げられること」に注意してください。サービス妨害は、攻撃の結果であり、過剰なトラフィック (すなわち、フラッディング(flooding))、プロトコルの脆弱性の攻略、メッセージの挿入/削除/宛先変更(diverting)/改変の結果である可能性があります。

1.3. 攻撃元 English

これらの攻撃元については、様々な分類法があります。:

「積極的な攻撃」対「待ち伏せ攻撃」

「積極的な攻撃」は、データをネットワークに書くことを伴います。誰かのアドレスに変装し、トラフィックの送信者の身元を隠すことは、積極的な攻撃における普通の実践です。「待ち伏せ攻撃」は、そのネットワークの情報を読むことのみを伴います。これは、その攻撃者が 2 つの標的となるマシン間の通信パス中のホストを制御できる場合、あるいは、そのトラフィックが侵されたマシンを通過するように、その ルーティング インフラストラクチャがうまい具合に侵された場合、可能です。(しばしば、デバッグ目的、性能監視、説明責任(accounting)目的に使われる)ミラーされたトラフィックの宛先が侵されたマシンに変更される状況もあります。そのマシンは、必ずしも、既存のトポロジを破壊するとは限らず、検知しにくい可能性があります。一般に、待ち伏せ攻撃の目的は、その送信者や受信者がプライベートに留めようとする情報を取得することにあります [RFC3552]。

「パス上(On-path)攻撃」対「パス外(Off-path)攻撃」

データグラムが、あるホストから別のホスト宛に転送されるように、これは、一般に、何らかの中間にある links やルータを通らなければなりません。そのようなルータは、普通に、そのパス上を転送する、あらゆるデータグラムを読み、改変あるいは削除できます。これは、あなたがパス上にいる場合、広く多様な攻撃を放つことを、かなり容易にします。パス外のホストは、何らかのホストから来たように見える任意のデータグラムを転送できますが、必ずしも、他のホスト用に意図されたデータグラムを受信できません。それゆえ、攻撃がデータを受信できることに依存する場合、パス外のホストは、まず、自身をパス上におくようにするために、そのトポロジを破壊しなければなりません。これは、どうしても不可能ですが、必ずしも取るに足らないもの(trivial)というわけではありません。[RFC3552] より微妙な攻撃は、デバイスのトラフィック監視機能がハイジャックされ、そのトラフィックが侵されたホスト宛に変更される場合の攻撃です。なぜならば、そのネットワーク・トポロジは、破壊される必要がない可能性があるからです。

「内部者による攻撃」対「外部者による攻撃」

「内部者による攻撃」は、システム資源にアクセスすることが認可されている主体によって、所与のセキュリティ境界の内部から仕掛けられますが、認可した者によって承認されていない方法で、それらを使います。「外部者による攻撃」は、そのシステムの認可されていないユーザ、もしくは、正規のユーザによって、境界の外部から仕掛けられます。

「計画的攻撃」対「意図的でないイベント」

計画的(deliberate)攻撃は、悪人が意図的にシステムのセキュリティについて、猛撃を行う場合です。しかし、意図的でないイベントが悪意をもたずに行われても、同様の被害をもたらす事例もあります。設定エラーやソフトウェアのバグは、ネットワーク・インフラストラクチャ上のあらゆる計画的な攻撃と同様に、ネットワークの利用可能性を破壊するものである可能性があります。その攻撃元は、上記のすべての組み合わせである可能性があり、それらのすべては、 あらゆる攻撃がネットワークの利用可能性(availability)と信頼性(reliability)にもたらす可能性がある影響を確認することを試みるとき、考慮される必要があります。「内部者による攻撃」あるいは「意図的でないイベント」を止めることは、ほとんど不可能です。しかし、適切な監視メカニズムがある場合、これらの攻撃も、検知され、他のあらゆる攻撃元についてのように軽減できます。攻撃を識別して追跡するために要する労力の量は、当然ながら、その攻撃者がもつ資源の豊富さの程度に依存します。本書において、さらに検討される、いかなる特定の攻撃も、「外部者」によって発せられ、計画的な攻撃である悪意あるふるまいについて詳述しています。さらなる詳述には、特定のセキュリティ機能の配備の背後にある動機を示す「待ち伏せ攻撃」対「積極的な攻撃」と、「パス上攻撃」対「パス外攻撃」の実行可能性について行われているものもあります。

1.4. 脅威による運用的なセキュリティの影響 English

あらゆる潜在的な攻撃シナリオについての主な関心事は、それが、そのネットワーク・インフラストラクチャに対してもたらす可能性のある影響と被害です。その脅威の結末は、脅威となる活動(すなわち、攻撃)に起因するセキュリティ侵害です。これらは、典型的には、下記のように分類されます。:

(認可されていない)開示

ある主体が、これによって、その主体は認可されていないデータにアクセスできるようになる状況もしくはイベント。

欺き(Deception)

「認可された主体が偽のデータを受け取り、それを正しいと信じてしまうこと」をもたらす可能性がある状況もしくはイベント。

崩壊(Disruption

システムのサービスや機能の正しい運用を中断したり、あるいは、妨げる状況もしくはイベント。 (総称としてサービス妨害攻撃と呼ばれる)広く多様な攻撃は、正規のユーザに対するシステムや帯域の利用可能性を脅かします。多くのそのような攻撃は、マシンの資源を消費するように設計されており、正規のユーザにサービスすることを困難もしくは不可能にします。他の攻撃には、標的となるマシンをクラッシュさせ、ユーザに対するサービスを完全に不能にしてしまうものもあります。

強奪(Usurpation)

認可されていない主体によるシステムのサービスもしくは機能の制御をもたらす状況もしくはイベント。大部分のネットワーク・インフラストラクチャ・システムは、特定の認可された個人が完全にアクセス可能 となることのみが意図されています。認可されていない人が極めて重要なレイヤ 2/レイヤ 3 のインフラストラクチャのデバイスもしくはサービスにアクセスできてしまった場合、それらは、そのネットワークの信頼性と利用可能性に重大な害をもたらす可能性があります。

これらの脅威の結末をもたらす可能性がある脅威となる活動についての完全な記述は、[RFC2828] にあります。典型的には、数多くの異なるネットワーク攻撃が、ひとつ、もしくは、複数の、上述の脅威の結末をもたらすために、組み合わされて使われます。一例は、トラフィック上で盗聴する能力をもつ悪意あるユーザです。まず、彼は、しばらくの間、探索作業や確認を行いながら、IP アドレスが(ルータのような)特定のデバイスに属しているトラフィックを盗聴する可能性があります。この悪人が、平文で送られたルータのパスワードのように、情報を取得しようとした場合、彼は、次に、実際のルータを侵すことに進むことができます。そこから、その悪人は、 トラフィックをリダイレクトするために、偽のルーティングの更新を送ったり、あるいは、他のネットワーク・デバイスを侵すために追加的なトラフィックを捕捉するような様々な積極的な攻撃を放つことができます。本書は、「どの対策を ISP は、今日、配備しているか?」を目録化しますが、実際のバックボーン・インフラストラクチャ攻撃と、その適切な対策の有用な一般的分析は、[RTGWG] にあります。

1.5. 文書レイアウト English

本書は、あらゆる脅威となる活動に影響を受けやすい状態になるリスクを軽減する現在の運用的実践の調査結果です。それゆえ、主な焦点は、攻撃を検知、かつ/または、軽減するために使われる現在実施されているセキュリティ実践にあります。本書における最上段の分類は、ISP についての運用的機能に基づき、一般に、 「何が、防護されるべきか?」に関連します。この次に、「どの攻撃が可能か?」と、現在行われているセキュリティ実践が記述されます。これは、これらの攻撃の緩和を支援するために必要不可欠なセキュリティサービスを提供します。これらのセキュリティサービスは、下記のように分類されます。:

多くの事例において、現在、配備されている特定のプロトコルは、これらのサービスの組み合わせを提供します。例えば、認証(Authentication)、認可(Authorization)および説明責任用(Accounting)の AAA は、ユーザ認証、ユーザ認可、および、監査/記録のサービスを提供できる一方、SSH(Secure SHell)プロトコルは、データ発信元認証、データのインテグリティ、および、データの秘匿性を提供できます。提供されるサービスは、使われる実際のプロトコルより重要です。「アクセス制御とは、基本的に、論理的アクセス制御(すなわち、フィルタリング)を言うこと 」に注意してください。各節は、「なぜ、特定のプロトコルを使ってよいのか、あるいは、使ってはいけないのか?」を説明する追加的な考慮事項の節で締めくくられ、いくつかのバグもしくは「ユーザビリティの欠如」に起因して、現在では、まだ不可能な機能に関する情報も提供します。



2. 防護された運用的機能 English

2.1. デバイスへの物理的アクセス English

デバイスへの物理的アクセスは、その物理的場所の防護と、レイヤ 2 もしくは レイヤ 3 のネットワーク・インフラストラクチャのデバイスへのアクセスに関係します。物理的セキュリティは、調査/実践の対象としても、それ自体としても大きな分野であり、ほぼ間違いなく、セキュリティ分野において最大、最古の、最も良く理解された分野です。ネットワークのデバイスに被害を与える可能性がある自然災害(例:地震や洪水)について非常時対応計画(contingency plan)をもつことは重要ですが、これは、対象範囲外です。ここで、我々は、物理的場所へのアクセスの防護と、「物理的な場所がが侵された場合、どのように、デバイスは、認可されていないアクセスから、さらに防護できるか?(すなわち、コンソール・アクセスを防護すること)」に関心をもちます。これは、概ね、侵入者が物理的にアクセスして、そのデバイスを運用的に制御できるようになることを止めることを目的とします。「攻撃者が、そのデバイスの電源を切ること、あるいは、単に何らかのケーブルを引き抜くことによって、容易に達成可能なサービス妨害攻撃を遂げるために、物理的にアクセスすることを止めるものは無いこと」
に注意してください。

2.1.1. 脅威/攻撃 English

何らかの侵入者が レイヤ 2 もしくはレイヤ 3 デバイスに物理的にアクセスできる場合、そのネットワーク・インフラストラクチャ全体は、侵入者の制御下になる可能性があります。少なくとも、その侵入者は、侵されたデバイスがサービスできないようにすることができ、ネットワーク崩壊をもたらす可能性があり、その程度は、そのネットワークのトポロジに拠ります。より悪いシナリオは、侵入者が、そのコンソールのパスワードをクラックするために、このデバイスを使い、そのデバイスと、そのネットワーク全体を完全に制御できるようになる場合です。(おそらく、誰もそのような侵害を検知することなく、あるいは、別のネットワークのデバイスをポートに取り付け、侵入者がそのネットワーク・トポロジを確認できるデータを吸い上げます。)

物理的にアクセスできることの脅威は、たとえ極めて重要なデバイスが高いセキュリティのもとにある場合でも、多様に実現してしまう可能性があります。攻撃者が、重大な停止時間やプライバシーの侵害を引き起こした、きわめて重要なデバイスに物理的にアクセスできるようにするために、メンテナンス作業者になりすました事例は、なおも起きます。認可された者による内部からの攻撃も、現実の脅威を提起し、適切に理解され、対応されなければなりません 。

2.1.2. セキュリティ実践 English

物理的なデバイスのセキュリティについて、機器は、かなり制限された環境に保たれます。カードキー・バッジをもつ認可されたユーザのみが、極めて重要なネットワーク・インフラストラクチャのデバイスが在る、あらゆる物理的場所にアクセスできます。これらのカードキー・システムは、「誰が、どの場所に、いつ、 アクセスしたか?」を記録します。大部分のカードキー・システムは、そのカード・システムがダウンしている場合の予備(fail-back)の「マスターキー」 をもちます。この「マスターキー」は、通常、アクセスが制限されており、(そのカードキー・システムがオンライン状態でない/機能しない場合にのみ発生する)マスターキーの利用も、慎重に記録されます。

すべてのコンソール・アクセスは、常に、パスワードで防護されており、そのログイン時間は、一定時間の無操作(典型的には、3 分〜 10 分の間)ののちにタイム・アウトするように設定されます。あなたがコンソール・ログインから得る特権の種類は、個々のベンダーのデバイス間で様々です。場合によっては、あなたは、初期の基本的なアクセスができ、より高い特権のアクセス(すなわち、enable もしくは root)を得るために、2 番目の認証ステップを行う必要があります。他のベンダー(のもの)において、あなたは、コンソールに root としてログインするとき、2 番目の認証ステップを要すること無しに、より高い特権のアクセス権を得ます。

「どのように ISP は、このようなログインを管理するか?」は、大幅に多様です。ただし、多くのより大きな ISP は、特権レベルの認可の自動化を支援するために、ある種の AAA メカニズムを採用し、2 番目の認証ステップの必要性を回避するために、その自動化を活用しています。また、多くの ISP は、ユーザについて、コンソールにログオンしている間、分離されたクラスを、異なる特権をもつように定義します。典型的には、すべてのコンソール・アクセスは、本書の 2.2 節において検討される 帯域外 管理インフラストラクチャ経由で提供されます。

2.1.3. セキュリティ・サービス English

下記のセキュリティサービスは、以前の節において述べた実践の利用を通じて提供されています。:

2.1.4. 追加的な考慮事項 English

物理的セキュリティは、本書において述べたように、大部分は、コンソール・アクセスの観点から、運用的セキュリティ実践に関連します。大部分の ISP は、帯域外 管理インフラストラクチャ経由のコンソール・アクセスを提供します。これは、本書の 2.2 節 において検討されます。

物理的・論理的な認証システムや記録システムは、 互いに独立して動作する必要があり、物理的に異なる場所に在る必要があります。これらのシステムは、「侵入者に脆弱な認証や記録の情報を与えかねない、それら自体が侵されないこと」を確保するためにセキュアにされる必要があります。

ソーシャル・エンジニアリングは、多くの物理的アクセス侵害において、大きな役割を果たしています。大部分の ISP は、極めて重要なインフラストラクチャのデバイスに、物理的にアクセスすることを正当に本人認証・認可されていない人々に物理的なアクセスをさせないように、会社の要員を教育するために、トレーニング・クラスや啓発プログラムを設けています。

2.2. デバイス管理(帯域内と帯域外) English

帯域内 管理は、一般に、デバイスへのアクセスであると考えられています。ここでは、制御トラフィックは、そのネットワークを渡っていくデータと同じデータ・パスを通ります。帯域外 管理は、一般に、デバイスへのアクセスであると考えられます。ここでは、制御トラフィックは、そのネットワークを通過するデータ とは分離されたパスを通ります。多くの環境において、レイヤ 2 とレイヤ 3 のインフラストラクチャ・デバイスについてのデバイス管理は、帯域内として配備された、いくつかの事例もありますが、帯域外 管理インフラストラクチャの一部として配備されます。「多くのセキュリティの関心事と実践は、帯域外管理と帯域内管理について、同様ですが、大部分の ISP は、帯域外管理システムを選好すること」に注意してください。なぜならば、この管理ネットワークを構成するデバイスに対するアクセスは、より用心深く防護されており、悪意ある活動がなされにくいと見なされるからです。

コンソールアクセスは、常に、帯域外 ネットワーク経由の構図になります。現在、帯域内 管理か、あるいは、帯域外 のいずれかで使われているメカニズムは、仮想的なターミナル・アクセス(すなわち、Telnet もしくは SSH)、SNMP(Simple Network Management Protocol)、もしくは HTTP 経由です。取材したすべての大きな ISP において、HTTP 管理は、決して使われず、明示的に不能にされていました。ファイル転送プロトコル(TFTP, FTP および SCP)は、本書の 2.5 節において扱われることに注意してください。

2.2.1. 脅威/攻撃 English

デバイス管理について、待ち伏せ攻撃は、誰かがその管理デバイスと管理されるデバイス間のデータを傍受する能力をもつ場合、可能です。その脅威は、あるインフラストラクチャのデバイスが何らかの方法で侵されて、ネットワークスニッファの役割を果たすことができる場合、あるいは、ネットワーク・スニッファとしての役割を果たす新しいデバイスを挿入することが不可能な場合、可能です。

積極的な攻撃は、パス上と、パス外の両方のシナリオについて可能です。パス上の積極的な攻撃について、その状況は、デバイスが 既に侵されているか、あるいは、デバイスが、そのパス中に挿入される可能性がある場合の待ち伏せ攻撃についてと同様です。パス外の積極的な攻撃について、トポロジの破壊(subversion)がトラフィックを再度、経路制御(reroute)することを要求され、要するに、その攻撃者をパス上に連れてくる場合、その攻撃は、一般に、メッセージの挿入あるいは改変に限られます。

2.2.1.1. 秘匿性の侵害 English

秘匿性の侵害は、悪人が平文で、あるいは、弱い暗号化で送られた何らかの管理データを傍受するとき、起きる可能性があります。これは、ユーザ名とパスワードの傍受を含み、これによって、侵入者は、ネットワーク・デバイスへの認可されていないアクセスを得ることができます。これは、運用管理者が遠隔からローカルのログファイルもしくは設定情報を見ている場合、記録情報や設定情報のような他の情報も含めることができます。

2.2.1.2. オフラインの暗号技術的攻撃 English

ユーザ名/パスワード情報が暗号化されているが、その使われている暗号技術的メカニズムについて「データを捕捉し、その暗号化鍵を解読すること」が容易にされている場合、そのデバイス管理トラフィックは、侵される可能性があります。そのトラフィックは、そのネットワーク上の盗聴によるか、あるいは、悪意あるユーザ宛にそらせることができることによるかのいずれかで捕捉される必要があります。

2.2.1.3. 再生攻撃 English

再生攻撃が成功するためには、その管理トラフィックは、まず、パス上か、あるいは、あとで意図された受信者宛に再生されるように、攻撃者宛に変更されるか、のいずれかで捕捉される必要があります。

2.2.1.4. メッセージの挿入/削除/改変 English

データは、中間にあるホストを制御している誰かによって操作される可能性があります。偽のデータは、IP スプーフィング(spoofing:偽装)についても可能です。ここでは、遠隔のホストが、別の信頼されるホストから到来したように見えるパケットを送信します。

2.2.1.5. 中間者 English

中間者(man-in-the-middle)による攻撃は、データストリーム自体ではなく、通信を行うピアの身元を攻撃します。その攻撃者は、管理システムからそのネットワーク・インフラストラクチャのデバイス宛に送られるトラフィックと、そのネットワーク・インフラストラクチャのデバイスから管理システム宛に送られるトラフィックを傍受します。

2.2.2. セキュリティ実践 English

帯域外 管理は、各場所において、ターミナル・サーバー経由で行われます。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 アドレスを追跡でき、原因究明が「なぜ、特定のインフラストラクチャのデバイスにアクセスすることを試みていたか?」に関して、できるように記録されます。

2.2.3. セキュリティ・サービス English

デバイスの帯域外管理のために提供されるセキュリティ・サービスは、ほぼ、デバイスの帯域内管理のセキュリティサービスと同じです。デバイス・アクセスを制御し、制限することの重要性に起因して、多くの ISP は、「管理トラフィックを通常の顧客データのトラフィックから物理的に分離することは、リスク軽減のレベルを上げて提供し、潜在的な攻撃ベクトルを制限する」という感触をもっています。下記のセキュリティ・サービスが、以前の節において述べられた実践の利用を通じて提供されます。:

2.2.4. 追加的な考慮事項 English

使われている、あらゆるデバイス管理プロトコルについて、パスワードの選択は、「そのパスワードが、全数検索(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)であり、それらについて、あらゆる不自然なふるまいを検知するために、より、注意が払われます。その ジャンプ・ホストs 自体は、慎重に制御されたマシンであり、通常、アクセスが制限されています。「Telnet は、特定のジャンプ・ホストからを除いて、インフラストラクチャのデバイスに対して決して許可されないこと」に注意してください。すなわち、パケットフィルタは、コンソール・サーバー、かつ/または、インフラストラクチャ・デバイスにおいて、「Telnet は、特定の IP アドレスからのみ許可されること」を確保するために使われます。

何千もの管理すべきデバイスをもつ ISP には、デバイスを認証するために、自動化されたメカニズムを作成したところがあります。一例として、Kerberos は、Kerberos をサポートするデバイスについて認証プロセスを自動化するために使われてきました。個人は、まず、Kerberos 化された UNIX サーバーに SSH を使ってログインし、Kerberos 「チケット」を生成します。この「チケット」は、通常、10 時間の有効期間をもつように設定され、その個人をそのインフラストラクチャのデバイス宛に自動的に本人認証するために使われます。

SNMP が使われている事例において、legacy デバイスによっては、SNMPv1のみをサポートするものがあり、これは、運用的なシンプルさのために、その ISP にすべてのインフラストラクチャのデバイスに渡って、その利用を必須とすることを要求します。SNMPv2 が、v3 よりも設定が容易であるので、主に配備されています 。

2.3. データ・パス English

この節では、「どのように、そのネットワーク・インフラストラクチャのデバイスを通るトラフィックは、扱われるか?」について述べます。ISP の主要な目標は、顧客のトラフィックを転送することです。しかし、サービス妨害攻撃をもたらし、そのネットワークを利用不能にする可能性がある大量の悪意あるトラフィックに起因して、しばしば、正規の顧客のトラフィックを転送することの可用能性を確保するための特定の手段が配備されます。

2.3.1. 脅威/攻撃 English

あらゆるデータ・トラフィックは、潜在的に、攻撃トラフィックである可能性があり、挑戦することは、「あらゆる悪意あるトラフィックを検知し、潜在的には、転送を止めること」です。計画的に発信された攻撃トラフィックは、偽装された発信元、かつ/または、宛先のアドレスをもつパケット、もしくは、プロトコル関連のセキュリティ問題を引き起こすためにヘッダー・フィールドの部分を台無しにする他の何らかの改変されたパケットから成る可能性があります。(例: 接続のリセット、歓迎されない ICMP リダイレクト、歓迎されない IP オプションの作成、パケットのフラグメント化)

2.3.2. セキュリティ実践 English

フィルタリングと、レート制限 は、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.3.3. セキュリティ・サービス English

2.3.4. 追加的な考慮事項 English

レイヤ 2 デバイスについて、MAC アドレスのフィルタリングや認証は、大規模な配備において使われていません。それは、これがネットワークの論点についてトラブル・シュートするとき、もたらす可能性がある問題に起因します。ポートのセキュリティは、何千ものスイッチが配備されている大規模において、管理不能になります。

Rate limiting は、いくつかの ISP によって、使われています。ただし、他の ISP には、攻撃者は、都合よくふるまってはくれず、これは、何ら複雑性を上まわる運用的な便益を提供しないので、「これは、現実には有用でない」と信じているところがあります。ISP には、「レート制限は、正規のトラフィックを切望する レート制限スキームの一部となるような、より少ないトラフィックを送信することを要求することによって、攻撃者の仕事を、より容易にする可能性もある」という感触をもっているところがあります。レート制限は、フィルタリング hooks をもつフローに基づく レート制限機能を開発することによって、改善される可能性があります。これは、現在の機能を越えて、粒度のみならず、性能も改善します。

フィルタできる機能に関する整合性の欠如は、(特に性能の論点に関して)いくつかの ISP が BCP38BCP84 のイングレス・フィルタリングについてのガイドラインを実施しない事態をもたらします。そのような一例は、ルータに OC-12 (Optical Carrier) uplink で接続する 1000 の T1 を上限とするエッジ・ボックスにおいてです。配備されたデバイスには、フィルタリングについて、顧客のトラフィックを通過させるために、許容できないほど、性能に大きな影響が出る実験結果となったものがありますが、イングレス・フィルタリング(uRPF)は、これらのアグリげーション・ルータを接続しているデバイスにおいて適用可能である可能性があります。性能が論点とならない場合、その ISP は、「管理対リスク」間の二律背反を選択することになります。

2.4. ルーティング面 English

ルーティング面は、ルーティング・プロトコル情報の確立と維持の一部となるすべてのトラフィックを扱います。

2.4.1. 脅威/攻撃 English

ルーティング面上の攻撃は、待ち伏せ攻撃と積極的な攻撃の両方である可能性があります。待ち伏せ攻撃は、誰かが、その通信を行うルーティング・ピア間のデータを傍受する能力をもつ場合、可能です。これは、単一の ルーティング ピアが何らかの方法で侵され、ネットワーク・スニッファとしての役割を果たす可能性がある場合、あるいは、ネットワーク・スニッファの役割をする新しいデバイスを挿入することが可能な場合、完遂される可能性があります。

積極的な攻撃は、パス上と、パス外の両方のシナリオについて可能です。パス上の積極的な攻撃について、その状況は、待ち伏せ攻撃と同様です。ここで、デバイスが既に侵されている必要があるか、あるいは、デバイスが、そのパス中に挿入される可能性があるかのいずれかです。これは、攻撃者が正規の ルーティング ピアになりすまし、ルーティング情報を交換することをもららす可能性があります。意図的ではない積極的な攻撃は、設定エラーに起因して、より卑近です。これは、正規の ルーティング ピアが、他の近隣のピアに不正な ルーティング 情報を与えることをもたらします。

パス外の積極的な攻撃について、この攻撃は、一般に、トラフィックの宛先を不正なものに変更して、トラフィックが意図された宛先には決して到達しないことをもたらす可能性がある、メッセージの挿入もしくは改変に限られます。

2.4.1.1. 秘匿性の侵害 English

秘匿性の侵害は、悪人が何らかのルーティングの更新トラフィックを傍受するとき、起きる可能性があります。これは、多くの ISP がアドレス割り当てスキームとネットワーク・トポロジをプライベートかつ私有の(proprietary)情報と位置づけているので、より関心が高まりつつあります。これは、 そのルーティング・プロトコルのパケットが、ルーティング セッションが偽装されうる、あるいは、ハイジャックされうる方法を示す可能性がある情報を含むゆえの関心事でもあります。これは、かえって、中間者(man-in-the-middle)攻撃をもたらす可能性があります。ここで、その悪人は、自身を、そのトラフィック・パス中に挿入するか、あるいは、そのトラフィック・パスを変更して、ユーザのデータの秘匿性を侵害できます。

2.4.1.2. オフラインの暗号技術的攻撃 English

何らかの暗号技術的なメカニズムがデータのインテグリティや秘匿性を提供するために使われていた場合、オフラインの暗号技術的な攻撃は、潜在的に、そのデータを侵すことができます。そのトラフィックは、ネットワーク上で盗聴することによって、あるいは、トラフィックを悪意あるユーザ宛にそらせることができるによって、捕捉される必要があります。「暗号技術的に防護されたルーティング情報を使うことによって、後者は、その暗号鍵が何らかの方法によって既に侵されていることを要求し、それゆえ、この攻撃は、デバイスが暗号技術的に防護されたルーティング情報を盗聴・捕捉できる場合にのみ現実的であること」に注意してください 。

2.4.1.3. 再生攻撃 English

再生攻撃が成功するためには、ルーティング面のトラフィックは、まず、パス上か、あるいは、あとで意図した受信者宛に再生されるように攻撃者宛に変更するか、のいずれかで捕捉される必要があります。さらに、これらのプロトコルの多くは、再生攻撃を防護するメカニズムを含むので、適用可能な場合、これらも、調査される必要があります。

2.4.1.4. メッセージの挿入/削除/改変 English

ルーティング面のトラフィックは、中間にあるホストを制御している誰かによって操作される可能性があります。さらに、トラフィックは、IP アドレスを偽造することによって挿入される可能性があります。ここで、遠隔のルータは、別の trusted ルータから来るように見えるパケットを送信します。メモリ(の容量)が限られたルータによって、十分過ぎるトラフィックが処理されるように挿入される場合、これは、サービス妨害攻撃(DoS 攻撃)をもたらす可能性があります。

2.4.1.5.中間者 English

中間者(man-in-the-middle)による攻撃は、データ・ストリーム自体ではなく、通信を行うピアの身元を攻撃します。その攻撃者は、一方の ルーティング ピアから他方宛に送信されるトラフィックを傍受し、そのピアの一方に代わって通信します。これは、そのユーザ・トラフィックを認可されていない受信者宛にそらしたり、あるいは、意図した宛先には決して到達しない正規のトラフィックをもたらす可能性があります。

2.4.2. セキュリティ実践 English

ルーティング面をセキュアにすることは、一般的にシステムとして配備されている多くの機能を要します。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 アドレスを宣伝しません。

2.4.3. セキュリティ・サービス English

2.4.4. 追加的な考慮事項 English

これまで、ルーティング面をセキュアにすることについての主要な関心は、その送信側のピアを検証して、「転送中のデータは、書き換えられていないこと」を確認することでした。MD5 ルーティング・プロトコル拡張が、実装されてきましたが、これは、ISP 界において整合的に配備されていない両方のサービスを提供できます。2 つの主要な配備における関心事は、実装の論点でした。ここでは、ソフトウェアのバグと、寛容な re-keying オプションの欠如の両方が、顕著なネットワーク・ダウン時間をもたらしました。また、ISP には、「MD5 認証の配備自体は、より悪いサービス妨害攻撃の標的であり、GTSM(for BGP)や経路フィルタのような、他のリスク軽減メカニズムの組み合わせを使うことを選好する」という関心を表明するところがあります。GTSM についての論点は、「これは、異なるベンダーの製品に渡るすべてのデバイス」においてサポートされていないことです。

IPsec については、相互運用可能性と、信頼できる設定を確保するという運用管理の観点から、あまりに複雑であり、運用上、実現可能となるには時間を要するものであるので、実装されていません。そのルーティング情報の秘匿性についての関心も限られていました。更新のインテグリティと妥当性は、はるかに大きな関心がもたれています。

新しい経路を導入し、ルーティング・ドメイン全体に反映できる手動の活動もしくは自動化された活動について、関心があります。

2.5. ソフトウェアの更新と設定のインテグリティ/検証 English

ソフトウェアの更新や設定変更は、通常、帯域内 か、あるいは、帯域外 管理機能のいずれかの一部として行われます。しかし、追加的に考慮すべき事項があり、それらは、この節で挙げられます。

2.5.1. 脅威/攻撃 English

システム・ソフトウェアや設定について行われる攻撃は、「待ち伏せ攻撃」と「積極的な攻撃」の両方である可能性があります。待ち伏せ攻撃は、誰かがそのネットワーク・インフラストラクチャのデバイスと、ソフトウェアもしくは設定情報をダウンロードする(/アップロードする)システム間のデータを傍受する能力をもつ場合、可能です。これは、単一のインフラストラクチャのデバイスが、何らかの方法で侵され、ネットワーク・スニッファとしての役割をする可能性がある場合、もしくは、ネットワーク・スニッファの役割をする新しいデバイスを挿入することが可能な場合、完遂される可能性があります。

積極的な攻撃は、パス上と、パス外の両方のシナリオについて可能です。パス上の積極的な攻撃について、その状況は、デバイスが既に侵されているか、あるいは、デバイスが、そのパス中に挿入できるか、のいずれかの場合の待ち伏せ攻撃についてと同様です。パス外の積極的な攻撃について、その攻撃は、一般に、メッセージの挿入もしくは改変に制限されます。ここで、その攻撃者は、不法なソフトウェアもしくは設定ファイルをインフラストラクチャのデバイスにロードすることを望む可能性があります。

「同様な論点は、ソフトウェアの更新がソフトウェア更新、かつ/または、設定情報について責任を負うベンダーのサイトから ISP のネットワーク管理システム宛にダウンロードされるとき、関連すること」に注意してください。

2.5.1.1. 秘匿性の侵害 English

秘匿性の侵害は、悪人が何らかのソフトウェアのイメージもしくは設定情報を傍受するとき、起きる可能性があります。そのソフトウェアのイメージは、そのデバイスが脆弱となる攻略法を示す可能性がある一方、設定情報は、不注意に、攻撃者が極めて重要なインフラストラクチャの IP アドレスやパスワードを識別することをもたらす可能性があります。

2.5.1.2. オフラインの暗号技術的攻撃 English

何らかの暗号技術的メカニズムがデータのインテグリティと秘匿性を提供するために使われた場合、オフラインの暗号技術的な攻撃は、潜在的に、そのデータを侵す可能性があります。そのトラフィックは、その通信パス上における盗聴によるか、あるいは、トラフィックの宛先を悪意あるユーザに変更できることのいずれかによって、捕捉される必要があります。

2.5.1.3. 再生攻撃 English

再生攻撃が成功するためには、そのソフトウェアのイメージもしくは設定ファイルは、まず、パス上か、あるいは、あとで意図された受信者宛に再生するために攻撃者に宛先を変更するか、のいずれかで捕捉される必要があります。さらに、多くのプロトコルは、再生攻撃を防護する機能をもっているので、これらも、適用可能な状況において、調査される必要があります。

2.5.1.4. メッセージの挿入/削除/改変 English

ソフトウェアのイメージと設定ファイルは、中間にあるホストを制御している誰かによって作成される可能性があります。IP アドレスを偽装し、ソフトウェアのイメージもしくは設定ファイルをダウンロードできる妥当なホストになりすますことによって、不正なファイルが、インフラストラクチャのデバイスにダウンロードされる可能性があります。これは、侵された信頼されるホストをもっていることが知られていない可能性がある信頼されたベンダーからの場合である可能性があります。不正なソフトウェアのイメージもしくは設定ファイルは、デバイスをハングさせ、運用不能になる可能性があります。偽装された設定ファイルは、検知困難である可能性もあります。特に、唯一の追加コマンドが、悪人が特定のホスト・アクセスを許可するフィルタを入れることと、ローカルのユーザ名/パスワードのデータベース・エントリを、そのデバイスに対する認証用に設定することによって、そのデバイスにアクセスすることを許容しているときです。

2.5.1.5. 中間者 English

中間者(man-in-the-middle)攻撃は、データ・ストリーム自体ではなく、通信を行うピアの身元を攻撃します。その攻撃者は、インフラストラクチャのデバイスと、システムのイメージもしくは設定ファイルをアップロード/ダウンロードするために使われるホスト間を送られたトラフィックを傍受します。次に、彼(/彼女)は、これらのシステムの一方もしくは両方に代わってふるまうことができます。

攻撃者が配備されているソフトウェアのイメージのコピーを攻撃した場合、彼は、潜在的に、既知の脆弱性を攻略して、システムにアクセスする可能性があります。

捕捉された設定ファイルからは、その設定ファイル中の何らかのパスワードが暗号化されていなかった場合、彼は、秘密のネットワーク・トポロジー情報や、より打撃となるような情報さえも得ることができました。

2.5.2. セキュリティ実践 English

イメージや設定は、アクセスが制限された特定のホストに保存されます。すべてのアクセスと、これらのホストに関する活動は、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 を使って行われます。

2.5.3. セキュリティサービス English

2.5.4. 追加的な考慮事項 English

MD5 アルゴリズムがソフトウェアのイメージや設定ファイルのデータ・インテグリティをチェックするために使われていない場合、ISP は、この機能をもつことに興味を表明しました。IPsec は、あまりに扱いにくいものであり、データのインテグリティと秘匿性のために使うことは運用的に困難であると見なされました。

2.6. 記録についての考慮事項 English

記録(logging)は、すべての以前の節の一部ですが、単独の項目として扱われることは、十分に重要です。主な論点は、「何が記録されるか?」、「どれだけの期間、記録は保たれるか?」および 「転送中と、保存中に、どのメカニズムが 記録された情報をセキュアにするために使われたか?」を含みます。

2.6.1. 脅威/攻撃 English

記録されたデータについての攻撃は、待ち伏せ攻撃と積極的攻撃の両方である可能性があります。待ち伏せ攻撃は、誰かが、受信する記録用サーバと、記録されたデータの発信元のデバイス間のデータを傍受する能力をもつ場合、可能です。これは、あるインフラストラクチャのデバイスが、何らかの方法で侵され、ネットワーク・スニッファ役割をすることができる場合、あるいは、ネットワーク・スニッファとしての役割をする新しいデバイスを挿入することが可能な場合、遂行される可能性があります。

積極的攻撃は、パス上と、パス外の両方のシナリオについて可能です。パス上の積極的な攻撃について、その状況は、デバイスが既に侵されてしまっているか、あるいは、デバイスが、そのパス中に挿入される可能性があるか、のいずれかである待ち伏せ攻撃についてと同様です。パス外の積極的な攻撃について、この攻撃は、一般に、何らかの侵害が検知されないように保つため、あるいは、犯罪の訴訟のために使われる可能性がある何らかの証拠を破壊するために、記録されたデータを変更する可能性がある、メッセージの挿入もしくは改変に限られます。

2.6.1.1. 秘匿性の侵害 English

秘匿性の侵害は、悪人がネットワーク上を転送中の何らかの記録用データを傍受するとき、起きる可能性があります。これは、記録されたデータ中に含まれるとプライバシの侵害となる可能性があるようなあらゆるデータを不許可とする分析が行われていない場合、プライバシーの侵害もたらす可能性があります。

2.6.1.2. オフラインの暗号技術的攻撃 English

何らかの暗号技術的なメカニズムがデータのインテグリティと秘匿性を提供するために使われた場合、オフラインの暗号技術的な攻撃は、潜在的に、そのデータを侵すことができます。そのトラフィックは、そのネットワーク上の盗聴によるか、あるいは、トラフィックをの宛先を悪意あるユーザに変更できることによって、捕捉される必要があります。

2.6.1.3. 再生攻撃 English

再生攻撃が成功するためには、その記録しているデータは、まず、パス上か、あるいは、攻撃者に宛先を変更して、あとで受信者宛に再生されるか、のいずれかで捕捉される必要があります。

2.6.1.4. メッセージの挿入/削除/改変 English

データを記録することには、中間にあるホストを制御している誰かによって、挿入、削除あるいは改変される可能性があります。データを記録することには、正規の IP アドレスからの、あるいは、不正な IP アドレスからの偽のパケットによって挿入される可能性もあります。

2.6.1.5. 中間者 English

中間者(man-in-the-middle)による攻撃は、データ・ストリーム自体ではなく、通信を行うピアの身元を攻撃します。その攻撃者は、インフラストラクチャのデバイスと記録サーバー間を送信されるトラフィック、もしくは、記録サーバーと、記録されたデータ保存するために使われているデータベース間を送信されるトラフィックを傍受します。logging 情報に対する、あらゆる認可されていないアクセスは、プライベートかつ特有のネットワーク・トポロジ情報についての知識をもたらす可能性があります。これは、そのネットワークの部分を侵すために使われる可能性があります。追加的な関心事は、何らかのセキュリティ侵害の痕跡を隠すために、削除あるいは改変される可能性がある記録情報にアクセスできるようにすることです。

2.6.2. セキュリティ実践 English

フィルタリングにおいて、記録は、概ね「例外事項を監査する」という基準で行われます。(すなわち、許可されていないトラフィックが、記録されます。)これは、「記録サーバーが、データで圧倒されて、大部分のログが使えなくなってしまうようにはないこと」を確保するためです。典型的には、記録されたデータは、発信元と宛先の 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 する誰かによって、手動で保存されます。

2.6.3. セキュリティサービス English

2.6.4. 追加的な考慮事項 English

syslog について、セキュリティは無く、ISP は、このことをよく認識しています。IPsec は、運用的に、あまりに高価であり、配備するには扱いにくいものであると見なされています。Syslog-ng や stunnel は、より良く認証(authenticate)され、インテグリティが保護された解決策を提供すると見られています。認可されていない要員がログ・メカニズムを不正にいじることを防ぐことは、「誰が、その記録サーバーやファイルにアクセスできるか?」を監査することと考えられています。

ISP は、単なる UDP syslog について以上の要件を表明しました。さらに、彼らは、より粒度が細かく、かつ、柔軟な設備や機器(すなわち、特定のサーバーについての特定のログ)を好みます。また、ベンダーのデバイスもしくはソフトウェアの各更新のあとにパーサを変更できるような、標準イベントを報告するための共通フォーマットは、必要不可欠ではありません。

2.7. フィルタリングについての考慮事項 English

フィルタリングは、以前の節の多くにおいて扱われてきましたが、この節は、現在、考慮されつつあるフィルタリングについての考慮事項に関して、より深い思慮を提供します。フィルタリングは、今や、3 つの特定分野に分類されています。 :

2.7.1. データ面のフィルタリング English

データ面のフィルタは、デバイスを通過するトラフィックを制御し、通過トラフィックに影響を与えます。大部分の ISP は、BCP38BCP84 のガイドラインを使って、この種のフィルタをスプーフィング(spoofing)攻撃を軽減するために、顧客に面したエッジデバイスに配備しています。

2.7.2. 管理面のフィルタリング English

管理フィルタは、デバイス宛のトラフィックとデバイスからのトラフィックを制御します。デバイス管理のために使われるすべてのプロトコルは、この分類となり、下記の事項を含みます。:

この種のトラフィックは、しばしば、インタフェイスごとにフィルタされ、プロトコル、発信元と宛先の IP アドレス、および、発信元と宛先のポート番号のあらゆる組み合わせに基づきます。デバイスには、管理フィルタを、特定のインタフェイス(例: receive ACL もしくは loopback インタフェイス ACL)についてではなく、デバイスに適用する機能をサポートするものがあり、これは、より広く受容されるるあります。「フィルタリングのルールを記録することは、今日、多くのシステムに負荷をかける可能性があり、より細かな粒度が、しばしば、より具体的に要求される例外事項を記録することが要求されること」に注意してください。

具体的に使われていない、あらゆるサービスは、切られます。

IPv6 ネットワークは、正しいプロトコル運用のために、特定の ICMP メッセージの利用を要求します。それゆえ、ICMP は、デバイス宛と、デバイス発のものを完全にはフィルタできません。代わりに、ネットワークのデバイス発/宛の特定の ICMPv6 種別について、より粒度が細かい ICMPv6 フィルタリングが、常に、できるように配備されます。IPv6 フィルタリングについての良いガイドラインは、「ファイアウォールにおける ICMPv6 メッセージのフィルタリングについての推奨事項」 [ICMPv6] にあります。

2.7.3. ルーティング面のフィルタリング English

ルーティング・フィルタは、ルーティング情報のフローを制御するために使われます。IPv6 ネットワークにおいて、ISP には、まだ解決されていないマルチホーミングの論点に起因して、/48 を許容することに寛容なところがある一方、割り当て(allocation)の境界における他のフィルタは、典型的には /32 においてです。IPv6 ルーティング については /48 より長い、そして、IPv4 ルーティングについては /24 より長い、受け取った、あらゆる announcement は、eBGP からフィルタされます。「これは、非顧客用トラフィックであること」に注意してください。大部分の ISP は、その顧客からの、いかなる agreed upon プリフィックスの長さも許容します。

2.8. サービス妨害の追跡(Tracking/Tracing) English

サービス妨害攻撃(DoS 攻撃)は、絶えず増加している問題であり、効果的に闘うためには莫大な資源を要します。大規模 ISP には、帯域において 1G 未満の攻撃ストリームに関心をもたないところがあります。(これは、要するに、1G が与えられた負荷の 5% 未満となる、より太いパイプにおいてです。)これは、概ね、大量のサービス妨害(DoS)トラフィックに起因します。これは、継続的に、原因究明と軽減を要します。

最後に、大規模な分散型 DoS ボットネットを構成するホストの数は、100 万を越えます。

DoS の発信元を検知し、可能な限り迅速に、あらゆる攻撃の影響を軽減するプロセスを自動化するために、継続的に新しいテクニックが、あみ出されています。現在、ISP は、様々な軽減テクニックを使っており、下記の事項を含みます。:

これらのテクニックの各々については、後述されます。

2.8.1. Sinkhole ルーティング English

Sinkhole ルーティング とは、「あらゆる既知の攻撃トラフィックについて、より具体的な経路を挿入すること」を言います。これは、「その悪意あるトラフィックは、それを解析できる妥当なデバイスもしくは特定のシステム宛に転送されること」を確保します。

2.8.2. ブラックホールを狙ったルーティング English

ブラックホールを狙ったルーティング (Remote Triggered ブラックホール・フィルタリング」とも呼ばれる)は、BGP ルーティング・プロトコルが経路を宣伝するために使われるテクニックです。これは、攻撃トラフィックを順番にヌル・インタフェイス宛にリダイレクトし、ここで、攻撃トラフィックは、効果的に棄却されます。このテクニックは、しばしば、ルーティング・インフラストラクチャに扇動する際に使われます。なぜならば、BGP は、数百もしくは数千のルータ上の、あらゆるパケットに基づくフィルタリング・テクニックの利用とは対局となり、速く効果的な作法で、その情報を宣伝できるからです。(より詳細な記述については、右記の NANOG のプレゼンテーションを参照: http://www.nanog.org/mtg-0402/pdf/morrow.pdf)

「このブラックホール化テクニックは、その目的が、『特定のサイトから来たように見えるブラックホール化するトラフィックをけしかけること』であった場合、実際に、その攻撃者の目的を満たす可能性があること」に注意してください。他方、このブラックホール・テクニックは、極めて重要なサービス以外の何かを狙った、あまりに大きな攻撃によって引き起こされた同時多発被害を低減できます。

2.8.3. uRPF English

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 がネットワークの顧客エッジに設置されます。

2.8.4. レート制限 English

レート制限(Rate limiting)とは、「一定の帯域、もしくは、特定のトラフィックの種類についての秒あたりのパケット数を確保すること」を言います。このテクニックは、多数の資源が偽装された TCP トラフィックについて割り当てられる場合、TCP-SYN 攻撃のような、既知のプロトコル攻撃を軽減するために広く使われています。このテクニックは、攻撃を止めませんが、しばしば、特定のサービスについて、被害と影響を低減できます。しかし、これは、その レート制限 が、より正規のトラフィックに影響を与えている場合(すなわち、棄却してしまう場合)、DoS 攻撃の影響を、もっと悪くしてしまう可能性もあります。

2.8.5. 特定の制御面のトラフィックの拡充 English

ISP には、そのフィルタリングと、制御トラフィックのレート制限をシンプルにするために、いくつかのベンダーから入手可能な機能を使い始めているところがあります。ここでは、制御 トラフィックとは、CPU サイクルを要求するルーティング制御面と管理面のトラフィックを言います。それゆえ、あらゆる制御面のトラフィックに対するサービス妨害攻撃は、極めて重要なデバイスに対して、他の種類のトラフィックより、はるかに破壊的である可能性があります。この執筆時点において、この機能の整合的な配備は、見受けられませんでした。

3. セキュリティに関する考慮事項 English

本書全体が、大規模 ISP環境における現在のセキュリティ実践を扱っています。これは、今日の環境において使われている具体的な実践を掲げており、それゆえ、これ自体は、いかなるセキュリティ・ リスクをも提起するものではありません。

4. 謝辞 English

著者は、下記の方々の貢献に大いに感謝しています。: George Jones は、本書について、ガイダンスや方向性を与えてくれて、助けてくれました。Ross Callon, Ron Bonica, Ryan Mcdowell, Gaurab Upadhaya, Warren Kumari, Pekka Savola, Fernando Gont, Chris Morrow, Ted Seely, Donald Smith は、顕著なコメントを寄せてくれました。そして、多数の ISP 運用者が、本書が頼っている情報を提供してくれました。

5. 参考文献

5.1. 規範的参考文献

[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月.

 

5.2. 参考資料

[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月時点.

 

補遺 A. プロトコル固有の攻撃 English

この節では、数年来、悪意をもって作られたパケット 、かつ/または、プロトコル deficiencies の攻略をもたらすことが観測されてきた、多くの従来型のプロトコルに基づく攻撃を挙げます。「それらすべては、実際のプロトコル自体の中の脆弱性を攻略し、しばしば、追加的な認証と監査するメカニズムが、現在、これらの攻撃の影響を検知し、軽減するために使われていること」に注意してください。このリストは、網羅的ではありませんが、「どの種類の攻撃が、多様なプロトコルについて可能か?」についての表現の
断片(fraction)です。

A.1. レイヤ 2 攻撃s English

A.2. IPv4 プロトコルに基づく攻撃 English

A.2.1. 上位レイヤのプロトコルについての攻撃 English

次に、追加的な攻撃を掲げますが、明示的にそれらを詳細に目録化しません。これは、情報提供のためにすぎません。

A.3. IPv6 攻撃 English

上述の、あらゆる 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.