IP : IP アドレッシング サービス

コアの保護:インフラストラクチャ保護 ACL

2005 年 1 月 24 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2008 年 10 月 21 日) | フィードバック

目次

概要
インフラストラクチャの保護
      背景説明
      方法
ACL の例
保護 ACL の作成
ACL と断片化パケット
リスク評価
付録
      Cisco IOS ソフトウェアでサポートされている IP プロトコル
      配備のためのガイドライン
      配備例
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

この文書では、インフラストラクチャ保護 access control list(ACL; アクセス コントロール リスト)についてのガイドラインと、推奨する配備方法について説明します。インフラストラクチャ保護 ACL は、認証されたトラフィックだけをインフラストラクチャ機器で明示的に許可し、他の通過トラフィックをすべて許可することで、直接的なインフラストラクチャ攻撃の危険性を最小限に抑えるために使用されます。

インフラストラクチャの保護

背景説明

ルータを、さまざまなリスク(偶発的なもの、悪意のある人為的なものの両方)から保護するためには、ネットワークの入口にインフラストラクチャ保護 ACL を配備しておく必要があります。 このような IPv4 および IPv6 ACL では、ルータ インターフェイスなどのすべてのインフラストラクチャに宛てられた外部発信元からのアクセスを拒否すると同時に、通常の通過トラフィックは中断しないで流れるよう許可し、基本的な RFC 1918 leavingcisco.comRFC 3330 leavingcisco.com、およびアンチスプーフ フィルタリングの機能を提供します。

ルータに着信したデータは、2 つの大きなカテゴリに分けられます。 1 つはフォワーティング パスを経由してルータを通過するトラフィックであり、もう 1 つはルート プロセッサの処理のために受信パスを経由してこのルータを宛先とするトラフィックです。 通常の処理では、トラフィックの大部分は、最終的な宛先に向かう途中で、このルータを単に通過するものです。 しかし、route processor(RP; ルート プロセッサ)では、あるタイプのデータを直接処理する必要があります。主なルーティング プロトコル、リモート ルータ アクセス(Secure Shell(SSH; セキュア シェル)など)、およびネットワーク管理トラフィック(Simple Network Management Protocol(SNMP; 簡易ネットワーク管理プロトコル)などがその対象です。 さらに、Internet Control Message Protocol(ICMP; インターネット制御メッセージ プロトコル)などのプロトコルや、IP オプションも、RP による直接処理が必要になります。 ほとんどの場合、インフラストラクチャ ルータへの直接のアクセスを必要とするのは、内部の発信元だけです。 いくつかの主な例外には、外部の Border Gateway Protocol(BGP; ボーダーゲートウェイ プロトコル)によるピアリング、このルータで終端するプロトコル(generic routing encapsulation(GRE; 総称ルーティング カプセル化)、IPv6 over IPv4 トンネル)などがあります。また、エコー要求や、traceroute コマンドに対する ICMP 到達不能および time to live(TTL; 生存可能時間)の時間切れメッセージなど、接続性のテストのための一部の ICMP パケットなども例外として挙げられます。 ICMP は、しばしば単純な denial-of-service(DoS; サービス拒否)攻撃で使用されることがあり、必要な場合に外部の発信元からだけ許可されるものです。

すべての RP には、RP が動作するパフォーマンス エンベロープがあります。 RP を宛先とする過剰なトラフィックによって、ルータの処理に悪影響が及ぶことがあります。CPU の使用率が高くなり、最終的にはパケットやルーティング プロトコルの廃棄が発生し、サービス拒否の状態になります。 外部送信元からのインフラストラクチャ ルータへのアクセスをフィルタリングすることにより、ルータへの直接攻撃に関する外部からのリスクは緩和されます。 外部送信元からの攻撃は、もはやインフラストラクチャ機器へアクセスできなくなります。攻撃は、autonomous system(AS; 自律システム)への入力側インターフェイスで単純に廃棄されます。

この文書で説明するフィルタリング方式は、ネットワーク インフラストラクチャ機器宛てのデータのフィルタリングが目的です。 インフラストラクチャのフィルタリングを一般的なフィルタリングと混同しないでください。インフラストラクチャ保護 ACL には、重要なインフラストラクチャ機器にアクセスできるプロトコルと発信元を詳細なレベルで制限するという、単一の目的があります。

ネットワーク インフラストラクチャ機器には、次のものが含まれます。

  • ルータとスイッチの全管理アドレス。ループバック インターフェイスを含む。

  • すべての内部リンク(つまりルータ間リンク)のアドレス(ポイントツーポイントおよび複数アクセス)

  • 外部ソースからアクセスされてはならない内部サーバやサービス

この文書では、インフラストラクチャを宛先とはしないすべてのトラフィックを、通常は通過トラフィックと呼びます。

方法

インフラストラクチャの保護には、さまざまな方法があります。

  • 受信 ACL(rACL)

    Cisco 12000 および 7500 プラットフォームでは、RP 宛ての全トラフィックをフィルタリングし、通過トラフィックには影響を与えない rACL をサポートしています。 許可するトラフィックは、明示的に示す必要があり、また、その rACL を各ルータに配備する必要があります。 詳細については、『GSR:受信アクセス コントロール リスト』を参照してください。

  • ホップバイホップ ルータ ACL

    ルータのインターフェイスで認証済のトラフィックだけを許可する ACL を定義することでも、ルータを保護できます。この ACL では、通過トラフィック以外のすべてを拒否します。通過トラフィックは明示的に許可する必要があります。 この ACL は、論理的に rACL と似ていますが、通過トラフィックに影響がおよびます。したがって、ルータの転送レートに悪影響を与えることがあります。

  • インフラストラクチャ ACL を使用したエッジ フィルタリング

    ACL は、ネットワークのエッジに適用できます。service provider(SP; サービス プロバイダー)の場合は、AS のエッジになります。 この ACL では、インフラストラクチャのアドレス空間宛てのトラフィックを明示的にフィルタします。 エッジ インフラストラクチャ ACL の配備には、使用しているインフラストラクチャ空間と、この空間にアクセスするために必要または許可するプロトコルを明示的に定義する必要があります。 この ACL は、ネットワークの入口で、外部に対するすべての接続(ピア接続、顧客向け接続など)に適用します。

    この文書では、エッジ インフラストラクチャ保護 ACL の作成と配備に重点を置いて説明します。

ACL の例

次の IPv4 および IPv6 アクセス リストでは、保護 ACL に必要な一般的なエントリの簡単で実際的な例を示しています。 これら基本的な ACL は、ローカルなサイト特有の設定事項を反映するようにカスタマイズする必要があります。 IPv4 と IPv6 のデュアル環境では、両方のアクセスリストを配備する必要があります。

IPv4 の例

  
  !--- アンチスプーフィングのエントリを次に示します。
  
  
  !--- 特定用途のアドレス ソースを拒否します。
  !--- 他の特定用途のアドレスについては、RFC 3330 を参照してください。
  
  access-list 110 deny ip host 0.0.0.0 any
  access-list 110 deny ip 127.0.0.0 0.255.255.255 any
  access-list 110 deny ip 192.0.2.0 0.0.0.255 any
  access-list 110 deny ip 224.0.0.0 31.255.255.255 any
  
  !--- RFC 1918 空間をフィルタリングします。
  
  access-list 110 deny ip 10.0.0.0 0.255.255.255 any
  access-list 110 deny ip 172.16.0.0 0.15.255.255 any
  access-list 110 deny ip 192.168.0.0 0.0.255.255 any
  
  !--- AS で、自身のアドレス空間が発信元になっている着信を拒否します。
  !--- AS のエッジにだけ配備します。
  
  
  access-list 110 deny ip YOUR_CIDR_BLOCK any
  
  !--- BGP を許可します。
  
  access-list 110 permit tcp host bgp_peer host router_ip eq bgp 
  access-list 110 permit tcp host bgp_peer eq bgp host router_ip
  
  !--- 内部のインフラストラクチャ アドレスへのアクセスを拒否します。
  
  access-list 110 deny ip any INTERNAL_INFRASTRUCTURE_ADDRESSES
  
  !--- 通過トラフィックを許可します。
  
  access-list 110 permit ip any any

IPv6 の例

IPv6 アクセスリストは、拡張および名前付きアクセスリストとして適用する必要があります。

  
  !--- アクセスリストを設定します。
  ipv6 access-list iacl
  
  !--- AS で、自身のアドレス空間が発信元になっている着信を拒否します。
  !--- AS のエッジにだけ配備します。
  
   deny ipv6 YOUR_CIDR_BLOCK_IPV6 any
  
  !--- マルチプロトコル BGP を許可します。
  
   permit tcp host bgp_peer_ipv6 host router_ipv6 eq bgp
   permit tcp host bgp_peer_ipv6 eq bgp host router_ipv6
  
  !--- 内部のインフラストラクチャ アドレスへのアクセスを拒否します。
   deny ipv6 any INTERNAL_INFRASTRUCTURE_ADDRESSES_IPV6
  
  !--- 通過トラフィックを許可します。
  
   permit ipv6 any any
  

注: キーワード log は、あるプロトコルの発信元と宛先に関する詳細を表示するために使用できます。 このキーワードは、ACL のヒットに関する詳細を詳しく表示でき、有用ですが、log キーワードを使用した ACL エントリへのヒットが過剰にあると、CPU の利用率が上がってしまいます。 ロギングに関連したパフォーマンスへの影響は、プラットフォームによって異なります。 また、log キーワードを使用すると、アクセスリストの文に一致するパケットに対する Cisco Express Forwarding(CEF)スイッチングは無効になります。 これらのパケットは、代わりにファースト スイッチングされます。

保護 ACL の作成

通常、インフラストラクチャ ACL は、次の 4 つのセクションで構成されます。

  • 特定用途のアドレスとアンチスプーフィングのエントリで、これは不正な発信元や、自身の AS に属する発信元アドレスを持ったパケットが、外部発信元から AS 内に入ることを拒否します。

    注:RFC 3330 では、フィルタリングが必要となる可能性のある IPv4 の特定用途アドレスを定義しています。 RFC 1918 では、インターネット上で無効とするソース アドレスを IPv4 予約アドレスとして定義しています。 RFC 3513 では、IPv6 アドレッシング アーキテクチャを定義しています。 RFC 2827 leavingcisco.comでは、入力フィルタリングのガイドラインが提供されています。

  • インフラストラクチャ アドレスを宛先とする外部発信元からの、明示的に許可されたトラフィック

  • 他のすべての外部発信元からのインフラストラクチャ アドレスへのトラフィックを拒否する deny

  • インフラストラクチャ以外の宛先へ向かう途中の、「通常の」バックボーン トラフィック宛ての他のすべてのトラフィックに対する permit

インフラストラクチャ ACL の最後の行では、通過トラフィックを明示的に許可します。 IPv4 の場合は permit ip any any、IPv6 の場合は permit ipv6 any any と記述します。 このエントリによって、すべての IP プロトコルがコア全体にわたって許可され、顧客がアプリケーションを問題なく実行できるようになります。

インフラストラクチャ保護 ACL を配備する最初のステップは、必要なプロトコルを理解することです。 各サイトには固有の要件がありますが、特定のプロトコルは共通に使用され、よく知られています。 たとえば、外部 BGP から外部ピアへの通信は、明示的に許可される必要があります。 また、インフラストラクチャ ルータへの直接アクセスを必要とする他のすべてのプロトコルも、明示的に許可する必要があります。 たとえば、GRE トンネルをコア インフラストラクチャ ルータで終端する場合は、プロトコル 47(GRE)も明示的に許可する必要があります。 同様に、IPv6 over IPv4 トンネルをコア インフラストラクチャ ルータで終端する場合は、プロトコル 41(IPv6 over IPv4)も明示的に許可する必要があります。

必要なプロトコルを判別するには、分類 ACL を使用します。 分類 ACL は、インフラストラクチャ ルータ宛てに使用される可能性のある各種のプロトコルに対する permit 文で構成されます (完全なリストについては、付録「Cisco IOS(R) ソフトウェアでサポートされている IP プロトコル」を参照してください)。 access control entries(ACE; アクセス コントロール エントリ)のヒット数を表示する show access-list コマンドを使用すると、必要なプロトコルを判別できます。 疑わしい、あるいは、あり得ないような結果が出た場合は調査が必要で、予期しないプロトコルに対して permit 文を作成する前に、よく検討してください。

たとえば、次の IPv4 の ACL は、GRE、IPSec(ESP)、および IPv6 トンネリング(IP プロトコル 41)を許可する必要があるかどうかの判別に役立ちます。

access-list 101 permit GRE any infrastructure_ips
  access-list 101 permit ESP any infrastructure_ips
  access-list 101 permit 41 an infrastructure_ips
  access-list 101 permit ip any infrastructure_ips log
  
  !--- キーワード log により、明示的に許可されていない他の
  !--- プロトコルに関する詳細が表示されます。
  
  access-list 101 permit ip any any
  interface <int>
   ip access-group 101 in

この IPv6 ACL は、GRE および IPSec(ESP)を許可する必要があるかどうかの判別に使用できます。

ipv6 access-list determine_protocols 
   permit GRE any infrastructure_ips_ipv6
   permit ESP any infrastructure_ips_ipv6
   permit ipv6 any infrastructure_ips_ipv6 log
  
  !--- キーワード  log により、明示的に許可されていない他の
  !--- プロトコルに関する詳細が表示されます。
  
   permit ipv6 any any	interface <int>
   ipv6 traffic-filter determine_protocols in
  

必要なプロトコルの他に、インフラストラクチャのアドレス空間を判別する必要があります。これは ACL が保護する空間になります。 インフラストラクチャのアドレス空間には、内部ネットワークに使用されるあらゆるアドレスが含まれます。これは、ルータ インターフェイス、ポイントツーポイント リンクのアドレス、および重要なインフラストラクチャ サービスなどの外部ソースからは、まずアクセスされることがないものです。 これらのアドレスは、インフラストラクチャ ACL の宛先部分として使用されるため、要約が重要で、さらに可能であれば、これらのアドレスを classless interdomain routing(CIDR; クラスレスドメイン間ルーティング)ブロックにグループ分けする必要があります。

識別されたプロトコルとアドレスを使用してインフラストラクチャ ACL を構築すると、これらのプロトコルの許可とアドレスの保護が可能になります。 ACL は、直接的な保護の他に、インターネット上のあるタイプの不正トラフィックに対する防御の第一線として機能します。

  • RFC 1918 の空間を拒否。

  • RFC 3330 で定義されているような特殊用途のアドレス空間の範疇にある発信元アドレスを持つパケットを拒否。

  • アンチスプーフィング フィルタを適用 (自分のアドレス空間が、自身の AS の外部から到達するパケットの発信元になることはありません)。

この新しく構築された ACL を、入力側インターフェイスへの着信に適用する必要があります。 詳細については、「配備のためのガイドライン」および「配備例」のセクションを参照してください。

iacl-01.gif

ACL と断片化パケット

ACL には、断片化パケット処理に特化した動作を可能にするキーワード fragments があります。 一般的には、ACL の L3 文(L4 情報には無関係)に一致する非初期フラグメントは、一致したエントリの permit 文または deny 文の影響を受けます。 キーワード fragments を使用すると、ACL では非初期フラグメントを詳細に拒否または許可することになることに注意してください。 この動作は、IPv4 と IPv6 のどちらのアクセスリストでも同じです。

フラグメントのフィルタリングによって、非初期フラグメント(FO > 0 など)だけを使用するような DoS 攻撃に対する新しい保護階層が加わることになります。 非初期フラグメントに対して ACL の先頭で deny 文を使用すると、すべての非初期フラグメントのルータへの着信を拒否します。 特殊な環境下では、有効なセッションに断片化が必要とされています、ACL に deny fragment 文があると、これがフィルタされてしまう場合があります。

例として、次に部分的に示した IPv4ACL を考えます。

  access-list 110 deny tcp any infrastructure_IP fragments
  access-list 110 deny udp any infrastructure_IP fragments
  access-list 110 deny icmp any infrastructure_IP fragments
  <rest of ACL>

これらのエントリを ACL の先頭に追加すると、コア ルータに対するすべての非初期フラグメントのアクセスが拒否されますが、断片化されていないパケットまたは初期フラグメントの場合は、deny fragment 文の影響を受けずに ACL の次の行まで進みます。 上に示した ACL の部分は、Universal Datagram Protocol(UDP)、TCP、ICMP などのプロトコルごとに別々にカウンタが増加するため、攻撃の分類に役立ちます。

攻撃の多くは、断片化パケットによってコア ルータをフラッディングさせることに依存しているため、コア インフラストラクチャ宛てに着信するフラグメントをフィルタリングすることにより、保護手段が追加され、単にインフラストラクチャ ACL のレイヤ 3 ルールと照合するだけでフラグメントを送信する攻撃を阻止します。

この方法の詳細な説明については、『アクセス コントロール リストと IP フラグメント』を参照してください。

リスク評価

インフラストラクチャ保護 ACL を配備する際には、次に示す主な 2 つのリスクについて考慮する必要があります。

  • 適切な permit 文および deny 文が記述されていること。 ACL を活用するには、必要なプロトコルをすべて許可し、deny 文で適切なアドレス空間を保護する必要があります。

  • ACL のパフォーマンスは、プラットフォームによって変化します。 ACL を配備する前に、使用しているハードウェアのパフォーマンス特性について調べてください。

シスコでは、他の場合と同様に、実際に配備する前に実験的な環境でテストすることを推奨しています。

付録

Cisco IOS ソフトウェアでサポートされている IP プロトコル

Cisco IOS ソフトウェアでサポートされている IP プロトコルは、次のとおりです。

  • 1 - ICMP

  • 2 - IGMP

  • 3 - GGP

  • 4 - IP in IP カプセル化

  • 6 - TCP

  • 8 - EGP

  • 9 - IGRP

  • 17 - UDP

  • 20 - HMP

  • 27 - RDP

  • 41 - IPv6 in IPv4 トンネリング

  • 46 - RSVP

  • 47 - GRE

  • 50 - ESP

  • 51 - AH

  • 53 - SWIPE

  • 54 - NARP

  • 55 - IP モビリティ

  • 63 - すべてのローカル ネットワーク

  • 77 - Sun ND

  • 80 - ISO IP

  • 88 - EIGRP

  • 89 - OSPF

  • 90 - スプライト RPC

  • 91 - LARP

  • 94 - KA9Q/NOS 互換 IP over IP

  • 103 - PIM

  • 108 - IP compression

  • 112 - VRRP

  • 113 - PGM

  • 115 - L2TP

  • 120 - UTI

  • 132 - SCTP

配備のためのガイドライン

シスコでは、堅実な配備方法を推奨します。 インフラストラクチャ ACL の配備を成功させるには、必要なプロトコルについて十分に理解し、アドレス空間を明確に識別し、定義する必要があります。 以降のガイドラインでは、反復的な方法を使用して保護 ACL を配備する非常に堅実な方法について説明します。

  1. 分類 ACL を使用して、ネットワークで使用されているプロトコルを調べます。

    インフラストラクチャ機器にアクセスする既知のプロトコルすべてを許可する ACL を配備します。 この「ディスカバリ」ACL では、発信元アドレスとして any を、またインフラストラクチャの IP 空間を包含する宛先を指定します。 プロトコルの permit 文と一致する発信元アドレスの一覧を作成するには、ロギングを使用します。 最後の行の ip any any(IPv4)、または ipv6 any any(IPv6)に対する許可は、トラフィック フローを許可するために必要です。

    目標は、特定のネットワークで使用しているプロトコルを判別することです。 そのルータで「他に何か」が通信を行っているかどうかを判断するための分析には、ロギングを使用する必要があります。

    注:キーワード log は、ACL のヒットに関する詳細を詳しく表示でき、有用ですが、このキーワードを使用した ACL エントリへのヒットが過剰にあると、大量のログ エントリが生成され、ルータの CPU 使用率が高くなってしまう場合があります。  また、log キーワードを使用すると、アクセスリストの文に一致するパケットに対する Cisco Express Forwarding(CEF)スイッチングは無効になります。 これらのパケットは、代わりにファースト スイッチングされます。 log キーワードの使用は短時間にとどめ、トラフィックの分類に必要な場合にだけ使用するようにしてください。

  2. 判別したパケットをよく調べ、ルート プロセッサ RP へのアクセスのフィルタリングを開始します。

    ステップ 1 で ACL によってフィルタリングされたパケットの判別と検査が終ったら、permit any source という指定を含む ACL を、許可されたプロトコルについてインフラストラクチャ アドレスに配備します。 ステップ 1 で説明したように、log キーワードを使用すると、permit エントリに一致するパケットに関する詳細な情報が出力されます。 最後に deny any を使用すると、ルータ宛てに送られた予期しないパケットの判別に役立てることができます。 この ACL の最後の行は、permit ip any any(IPv4)または permit ipv6 any any(IPv6)という文にして、通過トラフィックのフローを許可するようにする必要があります。 この ACL では、基本的な保護を行い、ネットワーク エンジニアが必要なトラフィックがすべて許可されていることを確認できるようになっています。

  3. 発信元アドレスを制限します。

    許可する必要のあるプロトコルが明らかになったら、さらにフィルタリングを実行して、それらのプロトコルについて承認された発信元だけを許可できます。 たとえば、外部 BGP 隣接ルータまたは特定の GRE ピアのアドレスを明示的に許可できます。

    このステップにより、サービスを停止させずにリスクを軽減でき、また、インフラストラクチャ機器にアクセスする発信元を細かく制御できるようになります。

  4. ACL で宛先アドレスを制限します (オプション)。

    Internet service provider(ISP; インターネット サービス プロバイダー)によっては、ルータ上で特定のプロトコルによる特定の宛先アドレスの使用を許可することが必要になります。 この最後の段階では、あるプロトコルに対するトラフィックを受け入れる宛先アドレスの範囲を制限します。

配備例

IPv4 の例

次の IPv4 の例では、次のアドレスに基づいて、ルータを保護するインフラストラクチャ ACL を示しています。

  • この ISP のアドレス ブロックは、169.223.0.0/16 です。

  • この ISP のインフラストラクチャ ブロックは、169.223.252.0/22 です。

  • ルータのループバックは 169.223.253.1/32 です。

  • このルータはピアリング ルータであり、169.254.254.1 とピア関係を結んでいます(アドレス 169.223.252.1)。

以下に示すインフラストラクチャ保護 ACL は、これらの情報を基にして作成されています。 この ACL では、外部ピアに対する外部 BGP ピアリングを許可し、アンチスプーフィング フィルタリングを実行し、インフラストラクチャを外部アクセスから保護しています。

!
  no access-list 110
  !
  ! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  
  !--- フェーズ 1 - アンチスプーフィングによる拒否
  !--- これらの ACE では、フラグメント、RFC 1918 空間、
  !--- 不正な発信元アドレス、および内部空間のスプーフィング
  !--- (内部空間を外部発信元とする)を拒否します。
  
  !
  
  !--- 内部のインフラストラクチャ ブロックへのフラグメントを拒否します。
  
  access-list 110 deny tcp any 169.223.252.0 0.0.3.255 fragments
  access-list 110 deny udp any 169.223.252.0 0.0.3.255 fragments
  access-list 110 deny icmp any 169.223.252.0 0.0.3.255 fragments
  
  !--- 特定用途のアドレス ソースを拒否します。
  !--- 他の特定用途のアドレスについては、RFC 3330 を参照してください。
  
  access-list 110 deny ip host 0.0.0.0 any
  access-list 110 deny ip 127.0.0.0 0.255.255.255 any
  access-list 110 deny ip 192.0.2.0 0.0.0.255 any
  access-list 110 deny ip 224.0.0.0 31.255.255.255 any
  
  !--- RFC 1918 空間をフィルタリングします。
  
  access-list 110 deny ip 10.0.0.0 0.255.255.255 any
  access-list 110 deny ip 172.16.0.0 0.15.255.255 any
  access-list 110 deny ip 192.168.0.0 0.0.255.255 any
  
  !--- 内部空間を外部発信元としているものを拒否します。
  !--- これは AS のエッジにだけ配備します。
  
  access-list 110 deny ip 169.223.0.0 0.0.255.255 any
  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  
  
  !--- フェーズ 2 - 明示的な許可
  !--- 宛先アドレスがインフラストラクチャ IP ブロックに含まれる
  !--- アプリケーションおよびプロトコルだけを許可します。
  !--- トラフィックの発信元は、既知であり、承認されている必要があります。 
  !
  
  !--- 注: このテンプレートは、使用しているネットワーク固有の発信元アドレス環境
  !--- に合わせて書き換える必要があります。 また、テンプレート内の
  !---  変数も変更する必要があります。
  
  
  !--- 外部 BGP を許可します。
  
  access-list 110 permit tcp host 169.254.254.1  host 169.223.252.1  eq bgp
  access-list 110 permit tcp host 169.254.254.1  eq bgp host 169.223.252.1
  !
  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  
  !--- フェーズ 3 - インフラストラクチャを保護するための明示的な拒否
  
  
  access-list 110 deny ip any 169.223.252.0 0.0.3.255
  !
  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  
  !--- フェーズ 4 - 通過トラフィックに対する明示的な許可
  
  
  access-list 110 permit ip any any

IPv6 の例

次の IPv6 の例では、下記のアドレスに基づいて、ルータを保護するインフラストラクチャ ACL を示しています。

  • この ISP のアドレス ブロックは、3FFE:B00:C18:::/48 です。

  • この ISP のインフラストラクチャ ブロックは、3FFE:B00:C18:3::/64 です。

  • このルータはピアリング ルータであり、3FFE:B00:C19:2:1::F とピア関係を結んでいます(アドレス 3FFE:B00:C18:2:1::1)。

以下に示すインフラストラクチャ保護 ACL は、これらの情報を基にして作成されています。 この ACL では、外部ピアに対する外部マルチプロトコル BGP ピアリングを許可し、アンチスプーフィング フィルタリングを実行し、インフラストラクチャを外部アクセスから保護しています。

no ipv6 access-list iacl
  ipv6 access-list iacl
  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  
  !--- フェーズ 1 - アンチスプーフィングとフラグメント化の拒否
  !--- これらの ACE では、フラグメント、内部スペースを
  !--- 外部発信元とするスプーフィングを拒否します。
  !--- 内部のインフラストラクチャ ブロックへに向けたフラグメントを拒否します。
  
   deny tcp any 3FFE:B00:C18:3::/64 fragments
   deny udp any 3FFE:B00:C18:3::/64 fragments
   deny icmp any 3FFE:B00:C18:3::/64 fragments
  
  !--- 内部空間を外部発信元としているものを拒否します。
  !--- これは AS のエッジにだけ配備します。
  
   deny ipv6 3FFE:B00:C18:::/48 any
  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  
  !--- フェーズ 2 - 明示的な許可
  !--- 宛先アドレスがインフラストラクチャ IP ブロックに含まれる
  !--- アプリケーションおよびプロトコルだけを許可します。
  !--- トラフィックの発信元は、既知であり、承認されている必要があります。
  
  
  !--- 注: このテンプレートは、使用しているネットワーク固有の発信元アドレス環境
  !--- に合わせて書き換える必要があります。 また、テンプレートの
  !---  変数も変更する必要があります。
  
  
  !--- マルチプロトコル BGP を許可します。
  
   permit tcp host 3FFE:B00:C19:2:1::F host 3FFE:B00:C18:2:1::1 eq bgp
   permit tcp host 3FFE:B00:C19:2:1::F eq bgp host 3FFE:B00:C18:2:1::1
  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  
  !--- フェーズ 3 - インフラストラクチャを保護するための明示的な拒否
  
   deny ipv6 any 3FFE:B00:C18:3::/64
  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  
  !--- フェーズ 4 - 通過トラフィックに対する明示的な許可
  
   permit ipv6 any any
  

関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 43920