ネットワーク 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.  既存の BGP-Triggered ブラックホール化テクニック
2.  拡充された BGP-Triggered ブラックホール化テクニック
3.  排水口(sinkhole)トンネル
4.  セキュリティについての考慮事項
5.  謝辞
6.  参考資料
7.  著者のアドレス
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 は、下記のように設定されなければなりません。:

  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)

a. A ポリシー 声明 to permit 経路s
that match the following criteria and apply the following 変更。

i.   Match for a コミュニティ
specific to that ルータ。(すなわち、65001:1, for R1)

ii.  Match the AS-Path to locally generated BGP 広告s。

iii. BGP next hop を RFC 1918 ネットワークに設定する。

iv.  Overwrite the BGP コミュニティ with the well-known コミュニティ。(no-advertise)

b. A ポリシー 声明 to permit 経路s
that match the following criteria and apply the 下記の変更s。

i.   Match for a コミュニティ that covers すべてのルータs。(すなわち、65001:666)

ii.  Match the AS-Path to locally generated BGP 広告s。

iii. Set the BGP next hop to an RFC 1918 ネットワーク。

iv.  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.