ネットワーク WG
Request for Comments: 3882
分類: 情報提供
D. Turk
Bell Canada
2004年9月

English

(作業中)

サービス妨害攻撃を防ぐようにBGPを設定する
(Configuring BGP to Block Denial-of-Service Attacks)

このメモの位置づけ

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

著作権表記

Copyright (C) The Internet Society (2004).

要旨

本書は、サービス妨害攻撃をブロックするために、 遠隔から特定の宛先のネットワークのブラックホール化(Black-holing)の引き金を引くBGPコミュニティsを使う運用的テクニックについて、記述します。 ブラックホール化は、 そのネットワーク中のすべてのBGP-speakingルータではなく、 ルータの選択に適用できます。 本書は、分析のためにトラフィックを排水口(sinkhole)ルータ中に引き込むためにBGPコミュニティとトンネルを使う排水口(sinkhole)トンネル・テクニックについても記述します。

目次

  1. 1. 既存のBGP-Triggeredブラックホール化テクニック
  2. 2. 拡充されたBGP-Triggeredブラックホール化テクニック
  3. 3. 排水口(sinkhole)トンネル
  4. 4. セキュリティについての考慮事項
  5. 5. 謝辞
  6. 6. 参考資料
  7. 7. 著者のアドレス
  8. 8. 著作権表記全文

1. 既存のBGP-Triggeredブラックホール化テクニック English

(作業中)

現在の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
可能性があります。

2. 拡充されたBGP-Triggeredブラックホール化テクニック English

(作業中)

本書は、
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

  1. 固定的経路pointing an RFC 1918ネットワーク to a ヌル・インタフェイス。
  2. ローカルBGP prefix広告と一致するAS-Pathアクセス・リスト。
  3. BGPコミュニティ・アクセス・リストを、 特定のルータについてのネットワーク運用者によって割り当てられたコミュニティ値と一致するようにする。 (すなわち、65001:1 for R1)
  4. BGPコミュニティ・アクセス・リストを、 すべてのルータについてのネットワーク運用者によって割り当てられたコミュニティ値と一致するようにする。 (すなわち、65001:666 for R1 and R2)
  5. Under the BGP process,
    an iBGP import 経路 ポリシーは、
    should be applied on received iBGP 広告s to do the 下記のロジック。
    (声明s are in a logical AND order)
  1. A ポリシー 声明 to permit 経路s
    that match the following criteria and apply the following 変更。
    1. Match for aコミュニティ
      specific to that ルータ。(すなわち、65001:1, for R1)
    2. Match the AS-Path to locally generated BGP広告s。
    3. BGP next hopをRFC 1918ネットワークに設定する。
    4. Overwrite the BGPコミュニティwith the well-known コミュニティ。(no-advertise)
  2. A ポリシー 声明 to permit 経路s
    that match the following criteria and apply the 下記の変更s。
    1. Match for a コミュニティ that covers すべてのルータs。 (すなわち、65001:666)
    2. Match the AS-Path to locally generated BGP 広告s。
    3. Set the BGP next hop to an RFC 1918ネットワーク。
    4. Overwrite the BGP コミュニティ with the well-known コミュニティ。(no-advertise)

そのポリシーが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 ネットワーク広告
トラフィックを止めます。 そのネットワーク上の他のすべてのトラフィックは、なおも、 正規の宛先に転送され続け、それゆえ、 標的とされたネットワーク上の影響を最小化します。

3. 排水口(sinkhole)トンネル English

(作業中)

「拡充された 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 最小限
可能性があります。

4. セキュリティについての考慮事項 English

本書に記述されたテクニックを実装する前に、 eBGP peering pointsに渡って、きつめの制御を施すことは、 とても重要です。 eBGPの顧客は、ブラックホール。 コミュニティを使って特定のサブネットをブラックホール化できる可能性があります。 このリスクを根絶するためには、 特別な経路ポリシーにおいてローカルに生成されたBGP広告についての一致は、 無視される必要があります。

5. 謝辞 English

本書の著者は、 遠隔から引き金を引くブラックホール化テクニックの開発者と、 backscatterトラフィックを集めてくれたbackscatterテクニックの開発者に感謝しています。 著者は、多様な、 このテクニックの機能性を支援してくれたIP Engineering departmentのすべてのメンバにも感謝しています。

6. 参考資料

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear,
"Address Allocation for Private Internets",
BCP 5, RFC 1918, 1996年2月.

7. 著者のアドレス

Doughan Turk
Bell Canada
100 Wynford Drive

EMail: doughan.turk@bell.ca

翻訳者のアドレス

独立行政法人 情報処理推進機構
セキュリティセンター

(作業中)

8. 著作権表記全文

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.