コアの保護：インフラストラクチャ保護 ACL
目次
概要
インフラストラクチャの保護
背景説明
方法
ACL の例
保護 ACL の作成
ACL と断片化パケット
リスク評価
付録
Cisco IOS ソフトウェアでサポートされている IP プロトコル
配備のためのガイドライン
配備例
関連情報
概要
この文書では、インフラストラクチャ保護 access control list（ACL; アクセス コントロール リスト）についてのガイドライ
ンと、推奨する配備方法について説明します。インフラストラクチャ保護 ACL は、認証されたトラフィックだけをインフラスト
ラクチャ機器で明示的に許可し、他の通過トラフィックをすべて許可することで、直接的なインフラストラクチャ攻撃の危険性を
最小限に抑えるために使用されます。
インフラストラクチャの保護
背景説明
ルータを、さまざまなリスク（偶発的なもの、悪意のある人為的なものの両方）から保護するためには、ネットワークの入口にイ
ンフラストラクチャ保護 ACL を配備しておく必要があります。 このような IPv4 および IPv6 ACL では、ルータ インターフェ
イスなどのすべてのインフラストラクチャに宛てられた外部発信元からのアクセスを拒否すると同時に、通常の通過トラフィック
は中断しないで流れるよう許可し、基本的な RFC 1918 、RFC 3330 、およびアンチスプーフ フィルタリングの機能を提供しま
す。
ルータに着信したデータは、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
access-list
access-list
access-list
110
110
110
110
deny
deny
deny
deny
ip
ip
ip
ip
host 0.0.0.0 any
127.0.0.0 0.255.255.255 any
192.0.2.0 0.0.0.255 any
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 では、入力フィルタリングのガイドラインが提供されていま
す。
インフラストラクチャ アドレスを宛先とする外部発信元からの、明示的に許可されたトラフィック
他のすべての外部発信元からのインフラストラクチャ アドレスへのトラフィックを拒否する 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 を、入力側インターフェイスへの着信に適用する必要があります。 詳細については、「配備のための
ガイドライン」および「配備例」のセクションを参照してください。
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
access-list
access-list
access-list
110
110
110
110
deny
deny
deny
deny
ip
ip
ip
ip
host 0.0.0.0 any
127.0.0.0 0.255.255.255 any
192.0.2.0 0.0.0.255 any
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
関連情報
Requests for Comments（RFC）
1992 - 2014 Cisco Systems, Inc. All rights reserved.
Updated: 2005 年 1 月 24 日
http://www.cisco.com/cisco/web/support/JP/100/1006/1006441_iacl-j.html
Document ID: 43920