|
ネットワーク WG Request for Comments： 3882 分類： 情報提供 |
D. Turk Bell Canada 2004年9月 |
(作業中)
このメモは、インターネットコミュニティに情報を提供するものです。 これは、いかなるインターネット標準をも定めるものではありません。 このメモの配布には制限はありません。
Copyright (C) The Internet Society (2004).
本書は、サービス妨害攻撃をブロックするために、 遠隔から特定の宛先のネットワークのブラックホール化(Black-holing)の引き金を引くBGPコミュニティsを使う運用的テクニックについて、記述します。 ブラックホール化は、 そのネットワーク中のすべてのBGP-speakingルータではなく、 ルータの選択に適用できます。 本書は、分析のためにトラフィックを排水口(sinkhole)ルータ中に引き込むためにBGPコミュニティとトンネルを使う排水口(sinkhole)トンネル・テクニックについても記述します。
(作業中)
現在のBGP-triggeredブラックホール化テクニックは、
iBGPネットワークのいたるところで攻撃によって標的とされたネットワークのBGP next hopアドレスを改変することに依拠しています。
カスタマイズされたiBGP広告は、
その宛先／攻撃されたASに参画しているルータから生成されます。
そこでは、
the next hop
アドレス for the 標的とされた ネットワーク or ホスト
は、RFC 1918アドレス(プライベート・インターネット・アドレス)
[RFC1918]
を指すように改変されます。
インターネット上の大部分のルータ(特にエッジ・ルータ)は、
ヌル・インタフェイス宛のRFC
1918アドレスを指す固定的経路をもちます。
それらの固定的経路は、攻撃されているネットワークを宛先とする、
すべてのトラフィックをヌル・インタフェイスに運びます。
宛先のAS内のiBGPを話すルータが、そのiBGP更新を受信するとき、
そのadvertised prefixは、
RFC 1918の掲載されているネットワークのひとつのnext hopと共に、
そのルーティング・テーブルに追加されます。
そのルータは、次に、その経路を問い合わせ、
derive a forwarding
インタフェイス
ために、RFC 1918のnext-hopを解決することを試みます。
このプロセスは、
妥当なnext hopをヌル・インタフェイスとして返します。
「そのルータは、
to direct RFC 1918の宛先トラフィック to a ヌル・インタフェイス
正しく設定されている」と想定すると、
攻撃されたネットワークを宛先とするトラフィックは、棄却され、
攻撃されたネットワークを、
攻撃者と他のすべての者宛に到達不能にします。
このテクニックは、
内部インフラストラクチャを攻撃からシールドして、
多数のデバイスを防護する一方、これは、
of rendering the 標的とされた/攻撃されたネットワーク unreachable
throughout the 宛先 AS 全体
望まれない副作用も、もちます。
たとえRFC 1918アドレスをヌル・インタフェイス宛に指す固定的経路が、
その宛先AS内のすべてのルータ上に設定されていない場合でも、
その改変されたnext hopは、そのトラフィックを、
その正規の宛先に経路制御することをできなくします。
ネットワーク運用者は、通常は短期間、 BGP-triggeredブラックホールを使います。 このテクニックは、 攻撃されたネットワークを宛先とするトラフィックについて、 ASのすべての入り口において、トラフィックの棄却をもたらします。 デフォルトで、 トラフィックをヌル・インタフェイスに棄却するルータは、 「ICMP到達不能」のメッセージを、 そのorigin/攻撃しているASに属する発信元アドレス宛に送る必要があります。
手順がこの点に達したら、
攻撃トラフィックの発信元アドレスのひとつは、
introducing a デバイス with 同一の発信元 IP アドレス
into the BGP ドメイン of the 宛先／攻撃されたAS
によってハイジャックされます。
発信元アドレスをハイジャックするデバイスは、
ICMPの到達不能パケットを収集します。
これらのICMPの到達不能パケットの発信元アドレスは、
「宛先／攻撃されたAS内のどのエッジ・ルータから、その攻撃は、
来ているか？」を示します。
そのネットワーク運用者は、次に、
opt to manually stop the トラフィック on the ルータs from
which 攻撃トラフィック is entering
可能性があります。
(作業中)
本書は、
a selected set of ルータs to alter the next hop アドレス of
a 特定の prefix by use of the BGP プロトコル
指図するために開発されたテクニックについて記述します。
そのnext hopは、ヌル・インタフェイスか、あるいは、
(本書において後で検討されるように) sinkholeトンネル・インタフェイスのいずれかである可能性があります。
このテクニックは、
invoke an アクセス・リスト、もしくは、レート制限 声明 to
treat 攻撃トラフィック
しませんし、攻撃されたprefix next hopアドレスのネットワーク全域にわたる変更を伴いません。
next hopは、
with the aid of BGP コミュニティs within the 宛先／攻撃された
AS
ルータの選択において変更されるのみです。
このテクニックについて、ネットワークの準備をするために、
そのネットワーク運用者は、
各宛先AS (Autonomous System)の境界ルータについて
that could
potentially drive 攻撃トラフィック to the
被害者
固有のコミュニティの値を規定する必要があります。
例えば、BGP AS番号として65001をもつネットワークは、
2つの境界ルータ(R1とR2)をもちます。
コミュニティ 値65001:1は、
R1を識別するために割り当てられます。
コミュニティ値65001:2は、
R2を識別するために割り当てられます。
コミュニティ値65001:666は、
R1とR2の両方を識別するために割り当てられます。
このBGPコミュニティの割り当てのあと、R1とR2は、 下記のように設定されなければなりません。： l
そのポリシーがR1およびR2において設定されたあと、
そのネットワーク運用者は、(攻撃された場合、)
one or more /32 「ホスト」経路s into iBGP of
the 宛先/攻撃されたAS
である可能性がある標的とされたネットワークを広告できます。
その広告は、
そのルータと関連づけられたコミュニティ値を含まなければなりません。
ここでは、その攻撃は、
in addition to the well-known コミュニティ
(no-export)
到来します。
BGPコミュニティの利用は、
特別な経路ポリシー設定が存在していないすべてのルータ上の標的とされたネットワークのoriginal next hopアドレスを確保します。
iBGPは、次に、そのprefix広告を、
その宛先／攻撃されたAS中のすべてのルータ宛に運びます。
宛先AS内のすべてのルータは、
(the コミュニティ stamped on the prefix
と一致するものを除いて、)
will be oblivious to the コミュニティ値 and
正規のnest hopアドレスをもつネットワーク経路を導入します。
そのコミュニティと一致するルータは、
ネットワーク経路をそのルーティング・テーブル中に挿入もしますが、
will alter the 次の hop
アドレス to an RFC 1918 ネットワーク and
then to a ヌル・インタフェイス as per the 経路ポリシー設定
and 再帰的経路 lookup。
for matching locally announced ネットワークs
理由は、「eBGP ピアは、この コミュニティを
to drive anyネットワーク to a ヌル・インタフェイス
濫用できないこと」を確認することにあります。
標的とされた／攻撃されたホストをブラックホール化することは、
推奨されますが、
not the アドレス・ブロック全体 they belong to so that
the ブラックホール効果
は、
攻撃されたネットワーク上で最小限の影響を受けるにとどまります。
このテクニックは、
from getting forwarded to the 正規の宛先 on ルータs identified
as transit ルータs for 攻撃トラフィック and
that have 経路マップ matches for the コミュニティ 値
associated with the ネットワーク広告
トラフィックを止めます。
そのネットワーク上の他のすべてのトラフィックは、なおも、
正規の宛先に転送され続け、それゆえ、
標的とされたネットワーク上の影響を最小化します。
(作業中)
「拡充された BGP-Triggered ブラックホール化テクニック」に従って、
さらなる分析のために、
その攻撃トラフィックを見ることが要件となる可能性があります。
この要件は、そのexerciseの複雑性を増します。
通常、ブロードキャスト・インタフェイスについて、
ネットワーク運用者は、
ネットワーク・スニッファをトラフィック分析用のスイッチの分離されたポート上に導入します。
別の手法は、
that covers the 攻撃ホストのアドレス into iBGP,
altering the next hop into a 排水口(sinkhole)デバイス
that can log トラフィック for 分析
ネットワークprefixをアナウンスすることです。
後者のテクニックは、
taking down the サービスs offered on the
標的とされた／攻撃されたIPアドレス
に帰結します。
AS間トラフィックは、AS内トラフィックと共に、
その排水口(sinkhole)に吸い込まれます。
パケットレベルの分析は、トラフィックを宛先ホストから、
スニッファもしくはルータ宛にリダイレクトすることを含みます。
結果として、
試験されているトラフィックが正規のトラフィックを含む場合、
その正規のトラフィックは、決して、
make it to その宛先ホスト
ません。
これは、正規のトラフィックについて、サービス妨害をもたらします。
より良い代替案は、排水口(sinkhole)トンネルの利用でしょう。
排水口(sinkhole)トンネルは、
攻撃を宛先/攻撃されるASにパスする可能性がある、
すべての可能性のあるエントリ・ポイントに実装されます。
そのBGPコミュニティ・テクニックを使うことによって、
その攻撃された／標的とされたホストを宛先とするトラフィックは、
スニッファがそのトラフィックを分析のために捕捉する可能性がある特別なパス(トンネル)宛に、
再度、経路制御される可能性があります。
解析された後に、トラフィックは、そのトンネルを抜け、
その宛先ホストに普通に経路制御されます。
換言すれば、そのトラフィックは、
to a スニッファ without altering the next hop 情報 of
the 宛先ネットワーク
そのネットワークを通過します。
宛先／攻撃されたAS iBGPドメイン内のすべてのルータは、
正しいnext hopアドレスをもちます。
エントリ・ポイントのルータのみが、
変更されたnext hop情報をもちます。
この手順を詳解すると、
with an オプションとしてのスニッファ attached
to そのインタフェイス
排水口(sinkhole)ルータが、
攻撃されたASのIGPおよびiBGP中に参画するように導入・設定されます。
次に、例えば、
MPLSトラフィック・エンジニアリングを使って、潜在的に攻撃が
from (AS 間トラフィック)to the 排水口(sinkhole)ルータ
入る可能性がある、
すべての境界ルータからトンネルが作られます。
ホストもしくはネットワークが攻撃されているとき、
カスタマイズされた iBGP 広告は、
of the 攻撃されたホスト(s) with the proper next hop that
insures トラフィック will reach それらのホストs or
ネットワークs
ネットワーク・アドレスをアナウンスするために送信されます。
カスタマイズされた広告は、2節において記述されているように、
その攻撃が入ってくる境界ルータの集合と一致するコミュニティstring値も、
もちます。
すべての境界ルータの経路ポリシーのセクション内に設定された新しいnest
hopアドレスは、その排水口(sinkhole)
IPアドレスである必要があります。
このIPアドレスは、
その境界ルータを排水口(sinkhole)ルータ宛に接続するトンネルに割り当てられた/30 subnetに属します。
そのコミュニティstringと一致するものをもたないルータは、 regularルーティングを行います。 これらのルータ上のコミュニティstringの一致の欠如は、 「特別な経路ポリシーは、そのnext hopアドレスを変更しないこと」を保証します。 特別なコミュニティとの一致をもたない境界ルータから入るトラフィックは、 正規の宛先へのregularルータのインタフェイスを通過します。 そのトラフィックが捕捉された後に、 その宛先に到達することを許容することも要求される可能性があります。 この場合、デフォルトのネットワーク経路は、 そのiBGPネットワークに接するように設定された、 あらゆるインタフェイスを指すように設定されます。 これは、 そのトンネルが築かれているのと同一の物理的なインタフェイスも含みます。 そのnext hopアドレスは、 その排水口(sinkhole)デバイス上で変更されないので、 そのトンネルから、このデバイスに入るトラフィックは、 デフォルト経路の存在に起因して、 そのネットワーク宛に返送されます。 そして、ルーティング・プロトコルは、そのトラフィックを、 そのoriginal宛先(攻撃されたネットワーク)宛に正しくルーティングすることに留意します。
「このテクニックは、
攻撃トラフィックの分析以外の目的にも使えること」が明らかになります。
正規のトラフィックは、
be pulled out of 通常のルーティング into a トンネル
可能性もあり、次に、
throughout the iBGP ネットワーク
the next hop addressingスキームを改変すること無しに、
バックボーンに再注入されます。
MPLSトラフィック・エンジニアリングは、その多くの機能と共に、
トラフィックをその排水口(sinkhole)デバイス宛にずらす良い手法です。
QoSポリシーのような機能は、攻撃トラフィック上に適用でき、
それゆえ、それを
competing on 資源s with 正規のトラフィック
から予防します。
境界ルータにおいて、そのnext hopを変更できるように、 RFC 1918ネットワークのサブネットは、 トンネル・インタフェイス宛に固定的に経路制御されます。 その固定的経路の一例は、下記のとおり。：
ip route 192.168.0.12 255.255.255.255 Tunnel0
標的IPアドレスのnext hopを192.168.0.12/32に設定することは、 トラフィックに、そのトンネルを通ることを強います。
トラフィックは、
TEトンネル経由で排水口(sinkhole)インタフェイスにおいて受信されます。
したがって、3つの手法(レート制限ポリシー、
QoSポリシーおよびアクセスリスト)が、
導入される可能性があります。
これらのポリシーは、レート制限でき、あるいは、
攻撃トラフィックと分類されたトラフィックを棄却できます。
このプロセスは、
そのsinkholeデバイスのインタフェイス上で完結します。
排水口(sinkhole)ルータについて、別の有用なアプリケーションは、
トンネル経由でトラフィックをinboundインタフェイス宛に引き込み、
そのトラフィックをイーサネット・インタフェイスの外に転送するデフォルトの経路声明をもつことです。
そのイーサネット・インタフェイスは、
そのiBGPネットワークに接続され、
トラフィックの正しい配信を保証しますが、これは、まだ、
その攻撃トラフィックをさらに解析するパケット・スニッファの利用を許可してしまいます。
これは、ハードウェアあるいはソフトウェアの制約に起因して、
攻撃されたホストもしくはネットワークの前のBGP境界ルータもしくはlast
hopルータ上にアクセス・リストもしくはレート制限声明を適用することが現実的でないとき、
とても有用になります。
それゆえ、
攻撃トラフィックの投入点におけるインタフェイスをアップグレードする代わりに、
後者は、その排水口(sinkhole)に引き込まれ、
そのデバイス上で扱われる可能性があります。
運用にかかるコストは、
そのsinkhole ルータが強力なデバイスである場合、
be rendered 最小限
可能性があります。
本書に記述されたテクニックを実装する前に、 eBGP peering pointsに渡って、きつめの制御を施すことは、 とても重要です。 eBGPの顧客は、ブラックホール。 コミュニティを使って特定のサブネットをブラックホール化できる可能性があります。 このリスクを根絶するためには、 特別な経路ポリシーにおいてローカルに生成されたBGP広告についての一致は、 無視される必要があります。
本書の著者は、 遠隔から引き金を引くブラックホール化テクニックの開発者と、 backscatterトラフィックを集めてくれたbackscatterテクニックの開発者に感謝しています。 著者は、多様な、 このテクニックの機能性を支援してくれたIP Engineering departmentのすべてのメンバにも感謝しています。
| [RFC1918] |
Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear,
"Address Allocation for Private Internets", BCP 5, RFC 1918, 1996年2月. |
Doughan Turk
Bell Canada
100 Wynford Drive
EMail： doughan.turk＠bell.ca
独立行政法人 情報処理推進機構
セキュリティセンター
(作業中)
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org, 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/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 ISOC's procedures with respect to rights in ISOC Documents can be found inBCP 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.