GSR: 受信アクセス コントロール リスト - Cisco

GSR: 受信アクセス コントロール リスト
目次
概要
GRP 保護
パフォーマンスへの影響
構文
基本的なテンプレートと ACL の例
rACLS と断片化パケット
リスク評価
付録と注意
受信隣接関係とパケットのパント
配備のためのガイドライン
配備例
注意
関連情報
概要
この文書では、receive access control list(rACL; 受信アクセス コントロール リスト)1 と呼ばれる新しいセキュリティ機
能について説明し、rACL の配備に関する推奨事項およびガイドラインを紹介します。受信 ACL は、弊害を含む可能性のある不必
要なトラフィックからルータの Gigabit Route Processor(GRP; ギガビット ルート プロセッサ)を保護することにより、Cisco
12000 ルータのセキュリティを強化するために使用されます。 受信 ACL は、Cisco IOS(R) ソフトウェア リリース 12.0.21S2
では特別なメンテナンスとして追加されていましたが、12.0(22)S に統合されました。
GRP 保護
gigabit switch router(GSR; ギガビット スイッチ ルータ)で受信されたデータは、2 つの大きなカテゴリに分けられます。 1
つは転送パスを経由してルータを通過するトラフィックであり、もう 1つは、さらに解析するために受信パスを経由して GRP に
送る必要があるトラフィックです。 通常の処理では、トラフィックの大部分は、他の宛先に向かう途中で、GSR を単に通過する
ものです。 しかし、GRP では、あるタイプのデータを処理する必要があります。主なものには、ルーティング プロトコル、リモ
ート ルータ アクセス、およびネットワーク管理トラフィック(Simple Network Management Protocol(SNMP; 簡易ネットワーク
管理プロトコル)などがあります。 また、これらのトラフィックの他に、他のレイヤ 3 パケットでも GRP の柔軟な処理が必要
とされる場合があります。 これには、特定の IP オプションや、Internet Control Message Protocol(ICMP; インターネット制
御メッセージ プロトコル)パケットの特定の形式などが含まれます rACL に関するその他の詳細や、GSR での受信パスのトラフ
ィックについては、「受信隣接関係とパケットのパント」の付録を参照してください。
GSR には複数のデータ パスがあり、それぞれ異なる形式のトラフィックを処理しています。 通過トラフィックは、着信 line
card(LC; ラインカード)からファブリックに転送され、その後、ネクストホップへ送出するために、出力カードへ転送されま
す。 この通過トラフィックのデータ パスの他に、GSR にはローカルでの処理を必要とする 2 つのパスが存在します。 それは、
LC から LC CPU へのものと、LC から LC CPU、ファブリック、GRP の順に経由するものです。 次の表では、一般的に使用される
機能とプロトコルに対するパスを示しています。
トラフィック タイプ
データ パス
通常の(通過)トラフィック
LC からファブリック、LC の順
ルーティング プロトコ
ル/SSH/SNMP
LC から LC CPU、ファブリック、GRP の
順
ICMP エコー(ping)
LC から LC CPU の順
ロギング
GSR 用のルート プロセッサには、LC から GRP 自体に宛てて送られたトラフィックを処理する容量に限界があります。 大量のデ
ータが GRP へのパントを必要とすると、このトラフィックによって GRP に大きな影響が及び、結果的には denial-ofservice(DoS; サービス拒否)攻撃となってしまいます。 入力ホールド キューや Selective Packet Discard(SPD; 選択パケッ
ト廃棄)キュー2 がフラッディングすると、GRP の CPU では、パケットの検査を続けようとして、パケットの廃棄が始まりま
す。GSR では、ルータの GRP への DoS 攻撃により引き起こされる可能性がある次の 3 つのシナリオに対抗する保護が必要で
す。
通常の優先順位のフラッディングによるルーティング プロトコル パケットの喪失
通常の優先順位のフラッディングによる管理セッション(Telnet、Secure Shell(SSH; セキュア シェル)、SNMP)のパケ
ットの喪失
スプーフィングされた高優先順位のフラッディングによるパケットの喪失
通常の優先順位のフラッディングの際に発生し得るルーティング プロトコルのデータ喪失は、現在はスタティックな分類と、LC
から GRP に送られるトラフィックにレート制限をかけることによって緩和されています。 しかし、残念ながらこの方法には限界
があります。 GRP 宛ての通常の優先順位のトラフィックに対するレート制限では、複数の LC 経由での攻撃があった場合の、高
優先順位のルーティング プロトコル データの保護には不十分です。 このような保護を行うために通常の優先順位データが廃棄
されるしきい値を低くすることは、通常の優先順位のフラッディングによる管理トラフィックの喪失を増加させるだけです。
次に示すように、rACL は、パケットが GRP に転送される前に、各 LC で実行されます。
GRP に保護メカニズムが必要なのは明らかです。rACL は、受信隣接関係により、GRP に送られるトラフィックに影響を与えま
す。 受信隣接関係とは、ルータの IP アドレス宛てのトラフィックに関する Cisco Express Forwarding の隣接関係であり、ブ
ロードキャスト アドレスまたはルータのインターフェイスに設定されているアドレスなどがこれに含まれます。3 受信隣接関係
とパケットのパントの詳細については、「付録」のセクションを参照してください。
LC に着信したトラフィックは、最初にその LC のローカル CPU に送られます。そして、GRP による処理が必要なパケットは、ル
ート プロセッサへ転送するためにキューに入れられます。 受信 ACL は GRP 上で作成され、さまざまな LC の CPU に送出され
ます。 LC の CPU から GRP へ送信する前に、トラフィックは rACL と照合されます。その結果、許可されたトラフィックは
GRP へと送られ、それ以外のすべてのトラフィックは拒否されます。 LC から GRP へのレート制限機能よりも先に、rACL が調べ
られます。 rACL はすべての受信隣接関係に対して使用されるので、LC の CPU によって処理される一部のパケット(エコー要求
など)も rACL フィルタリングの対象になります。 rACL のエントリを決める際には、この点を考慮する必要があります。
受信 ACL は、ルータ内のリソースを保護する方式のさまざまな部分で構成されるプログラムの一部分です。 将来的には、rACL
にレート制限のコンポーネントが追加される予定です。
パフォーマンスへの影響
設定エントリ 1 つと、定義されたアクセスリスト自体を保持するため以外のメモリは消費されません。 rACL は各 LC にコピー
されますが、各 LC では、ごくわずかなメモリが使用されるだけです。 特に rACL を配備することによって得られるメリットと
比較すると、全体として、使用するリソースはきわめて少ないものです。
受信 ACL は、転送トラフィックのパフォーマンスには影響を与えません。 rACL は受信隣接関係のトラフィックにだけ適用され
るもので、転送トラフィックは rACL の対象外になります。 通過トラフィックをフィルタリングするのは、インターフェイス
ACL です。 この「通常の」ACL は、指定した方向のインターフェイスに適用されます。 トラフィックは rACL 処理よりも先に
ACL によって処理されます。したがって、インターフェイス ACL によって拒否されたトラフィックは、rACL に届くことはありま
せん。4
実際にフィルタリングを実行する LC(言い換えれば、rACL でフィルタされるトラフィックを受信する LC)では、rACL の処理に
より、CPU の使用率が上がります。 この CPU 使用率の増加は、GRP 宛ての大量のトラフィックによって生じますが、GRP の
rACL による保護のメリットは、LC での CPU 使用率の増加を遙かに上回るものです。 LC での CPU 利用率は、LC エンジンのタ
イプによって異なります。 たとえば、同じ攻撃を仮定したとき、エンジン 3 の LC の CPU 使用率は、エンジン 0 の LC よりも
低くなります。
ターボ ACL を有効にすると(access-list compiled コマンドを使用)、ACL が非常に効率のよいルックアップ テーブルの一連
のエントリに変換されます。 ターボ ACL を有効にすると、rACL の深さによりパフォーマンスが影響を受けることがなくなりま
す。 これは言い換えれば、処理スピードは ACL のエントリ数には無関係であるということになります。 rACL が短い場合は、タ
ーボ ACL を使用してもパフォーマンスが大きく向上することはありませんが、ターボ ACL によりメモリが消費されます。つま
り、rACL が短い場合には、ACL のコンパイルはまず必要ありません。
rACL は、GRP を保護することにより、攻撃を受けた際の、ルータ、そして究極的にはネットワークの安定性確保に役立っていま
す。 上で説明したように、rACL は LC の CPU で処理されるため、ルータに大量のデータが送られたときには各 LC の CPU 使用
率が上昇します。 E0/E1 および一部の E2 のバンドルでは、100 % を超える CPU 使用率によって、ルーティング プロトコルや
リンク層での廃棄が起きる可能性があります。 このような廃棄はカードだけに限定され、GRP のルーティング プロセスは保護さ
れるため、安定性は維持されます。 スロットリングが有効になっているマイクロコードを備えた E2 カード 5 では、負荷が高い
ときにスロットリング モードがアクティブになり、ルーティング プロトコルの優先順位が 6 と 7 のトラフィックだけを転送し
ます。 他のタイプのエンジンでは、マルチキュー方式が採用されています。たとえば、E3 カードには CPU に対するキューが 3
つあり、優先順位 6/7 のルーティング プロトコル パケットは別の高優先キューに置かれます。 LC の CPU 使用率が高い場合で
も、これが高優先順位のパケットによって引き起こされた場合でない限りは、ルーティング プロトコルの廃棄は発生しません。
低優先キューに送られたパケットには、テール ドロップが適用されます。 最後に、E4 ベースのカードには、CPU に対して 8 個
のキューがあり、1 つはルーティング プロトコル パケット専用になっています。
構文
受信 ACL の適用は、次のグローバル設定コマンドによって行います。実行すると、rACL がルータ内の各 LC に配布されます。
[no] ip receive access-list <num>
この構文では、<num> が次のように定義されています。
<1-199> IP access list (standard or extended)
<1300-2699> IP expanded access list (standard or extended)
基本的なテンプレートと ACL の例
このコマンドを使用できるようにするには、ルータとの対話を許可するトラフィックを識別するアクセスリストを定義する必要が
あります。 アクセスリストには、ルーティング プロトコルと管理トラフィック(Border Gateway Protocol(BGP; ボーダーゲー
トウェイ プロトコル)、Open Shortest Path First(OSPF)、SNMP、SSH、Telnet)の両方を含める必要があります。 詳細につ
いては、「配備のためのガイドライン」のセクションを参照してください。
次に示す ACL のサンプルでは、簡単なアウトラインを提供し、特定用途に応用できる設定例を紹介しています。 また、この
ACL では、一般的に必要とされるいくつかのサービスやプロトコルのために必要な設定を説明しています。 SSH、Telnet、および
SNMP の場合は、宛先としてループバック アドレスを使用します。 ルーティング プロトコルの場合は、実際のインターフェイス
アドレスを使用します。 rACL で使用するルータ インターフェイスの選択は、ローカル サイトのポリシーと運用によって決定し
ます。 たとえば、すべての BGP ピアリング セッションにループバックを使用する場合は、BGP に対する permit 文でこれらの
ループバックだけを許可する必要があります。
!--- BGP を許可します。
access-list 110 permit tcp host bgp_peer host loopback eq bgp
!--- OSPF を許可します。
access-list 110 permit ospf host ospf_neighbor host 224.0.0.5
!--- 必要であれば、代表ルータのマルチキャスト アドレスを許可します。
access-list 110 permit ospf host ospf_neighbor host 224.0.0.6
access-list 110 permit ospf host ospf_neighbor host local_ip
!--- Enhanced Interior Gateway Routing Protocol(EIGRP)を許可します。
access-list 110 permit eigrp host eigrp_neighbor host 224.0.0.10
access-list 110 permit eigrp host eigrp_neighbor host local_ip
!--- Telnet および SSH によるリモート アクセスを許可します。
access-list 110 permit tcp management_addresses host loopback eq 22
access-list 110 permit tcp management_addresses host loopback eq telnet
!--- SNMP を許可します。
access-list 110 permit udp host NMS_stations host loopback eq snmp
!--- ネットワーク タイム プロトコル(NTP)を許可します。
access-list 110 permit udp host ntp_server host loopback eq ntp
!--!--!--!--!---
ルータから発信される traceroute:
各ホップから存続可能時間(ttl)を超過したという
メッセージが返ります(タイプ 11、コード 3)。
終点からは、ICMP ポートが到達不可能であるという
メッセージが返ります(タイプ 3、コード 0)。
access-list 110 permit icmp any any ttl-exceeded
access-list 110 permit icmp any any port-unreachable
!--- ルータの認証のための TACACS を許可します。
access-list 110 permit tcp host tacacs_server router_src established
!--- RADIUS を許可します。
access-list 110 permit udp host radius_server router_src log
!--- IOS のアップグレードのための FTP を許可します。
access-list 110 permit tcp host image_server eq ftp host router_ip_address
access-list 110 permit tcp host image_sever eq ftp-data host router_ip_address
シスコのすべての ACL と同様に、アクセスリストの最後には、暗黙の deny 文があります。そのため、ACL 内のエントリに一致
しないトラフィックは、すべて拒否されます。
注: キーワード log は、許可されていない GRP 宛てのトラフィックを分類するために使用できます。 log キーワードは、ACL
のヒットに関する詳細を詳しく表示でき、有用ですが、このキーワードを使用した ACL エントリへのヒットが過剰にあると、LC
の CPU の利用率が上がってしまいます。 ロギングに関連するパフォーマンスへの影響は、LC エンジンのタイプによって異なり
ます。 一般的には、エンジン 0/1/2 では、ロギングを必要な場合にだけ使用します。エンジン 3/4/4+ の場合は、CPU の性能が
向上していることと、マルチキュー方式によって、ロギングによる影響は非常に小さくなっています。
アクセスリストの詳細さのレベルは、ローカルのセキュリティ ポリシーによって決定します(たとえば、OSPF 隣接ルータに必要
なフィルタリングのレベルなど)。
rACLS と断片化パケット
ACL には、断片化パケット処理に特化した動作を可能にするキーワード fragments があります。 一般的には、ACL の L3 文
(L4 情報には無関係)に一致する非先頭フラグメントには、一致したエントリの permit 文または deny 文の影響がおよびま
す。 キーワード fragments を使用すると、ACL では非先頭フラグメントを詳細に拒否または許可することになることに注意して
ください。
rACL の機能上は、フラグメントのフィルタリングによって、非先頭フラグメント(FO > 0 など)だけを使用するような DoS 攻
撃に対して、新しい保護階層が加わることになります。 rACL の先頭で非先頭フラグメントに対する deny 文を使用すると、すべ
ての非先頭フラグメントのルータへの着信が拒否されます。 特殊な環境下では、有効なセッションに断片化が必要とされていま
す、rACL に deny fragment 文があると、これがフィルタされてしまう場合があります。
例として、次に部分的に示した ACL を考えます。
access-list 110 deny tcp any any fragments
access-list 110 deny udp any any fragments
access-list 110 deny icmp any any fragments
<rest of ACL>
これらのエントリを rACL の先頭に追加すると、GRP に対するすべての非先頭フラグメントのアクセスが拒否されますが、断片化
されていないパケットまたは先頭フラグメントは、deny fragment 文の影響を受けずに rACL の次の行まで進みます。 上に示し
た rACL の部分では、Universal Datagram Protocol(UDP)、TCP、ICMP などのプロトコルごとに、ACL の別々のカウンタが増加
するので、攻撃の分類に役立ちます。
この方法の詳細な説明については、『アクセス コントロール リストと IP フラグメント』を参照してください。
リスク評価
rACL が、ルーティング プロトコルまたはルータへの対話型アクセスなどの重要なトラフィックをフィルタリングしないように注
意してください。 必要なトラフィックをフィルタリングすると、ルータへのリモート アクセスができなくなることがあり、これ
によりコンソール接続が必要になります。 この理由から、ラボ環境での設定は、実際の配備環境にできるだけ近づける必要があ
ります。
シスコでは、他の場合と同様に、実際に配備する前に実験的な環境でこの機能をテストすることを推奨しています。
付録と注意
受信隣接関係とパケットのパント
これまでに説明したように、パケットの中には GRP による処理を必要とするものがあります。 これらのパケットは、データ転送
プレーンから GRP へパントされます。 GRP アクセスを必要とするレイヤ 3 データの一般的な形式を次に示します。
ルーティング プロトコル
マルチキャスト制御トラフィック(OSPF、Hot Standby Router Protocol(HSRP; ホットスタンバイ ルータ プロトコル)、
Tag Distribution Protocol(TDP; タグ配布プロトコル)、Protocol Independent Multicast(PIM)など)
断片化を必要とする Multiprotocol Label Switching(MPLS; マルチプロトコル ラベル スイッチング)パケット
ルータのアラートなどの IP オプションを持つパケット
マルチキャスト ストリームの最初のパケット
再組み立てを必要とする断片化された ICMP パケット
ルータ自体を宛先とするすべてのトラフィック(LC で処理されるトラフィックを除く)
rACL は受信隣接関係に適用されるため、rACL は、GRP にパントされない、受信隣接関係のトラフィックをフィルタリングしま
す。 最も一般的な例は、ICMP エコー要求(ping)です。 ルータ宛の ICMP エコー要求は、LC の CPU で処理されます。この要
求は受信隣接関係であるため、rACL によってフィルタリングされます。 したがって、ルータのインターフェイス(またはループ
バック)への ping を許可するためには、rACL で明示的にエコー要求を許可する必要があります。
受信隣接関係は、show ip cef コマンドで表示できます。
12000-1#show ip cef
Prefix
0.0.0.0/0
1.1.1.1/32
2.2.2.2/32
64.0.0.0/30
...
Next Hop
drop
attached
receive
attached
Interface
Null0 (default route handler entry)
Null0
ATM4/3.300
配備のためのガイドライン
シスコでは、堅実な配備方法を推奨します。 rACL の配備を成功させるには、既存のコントロール プレーンや管理プレーンのア
クセス要件をよく理解する必要があります。 ネットワークによっては、フィルタリング リストの構築に必要とされる正確なトラ
フィックのプロファイルの判別が難しい場合があります。 以下のガイドラインでは、トラフィックの識別とフィルタリングのた
めの rACL の設定を段階的に行う、rACL の堅実な配備方法を説明します。
1. 分類 ACL を使用して、ネットワークで使用されているプロトコルを調べます。
GRP にアクセスする既知のプロトコルすべてを許可する rACL を配備します。 この「ディスカバリ」rACL では、発信元と
宛先のアドレスの両方を any と設定する必要があります。 プロトコルの permit 文と一致する発信元アドレスの一覧を作
成するには、ロギングを使用します。 プロトコルに対する permit 文に加えて、rACL の最後にある permit any any log
という行は、rACL によってフィルタリングされていて GRP へのアクセスを必要とする可能性のある他のプロトコルの判別
に使用できます。
目標は、特定のネットワークで使用しているプロトコルを判別することです。 そのルータで「他に何か」が通信を行ってい
るかどうかを判断するための分析には、ロギングを使用する必要があります。
注:キーワード log は、ACL のヒットに関する詳細を詳しく表示でき、有用ですが、このキーワードを使用した ACL エン
トリへのヒットが過剰にあると、大量のログ エントリが生成され、ルータの CPU 使用率が高くなってしまう場合がありま
す。 log キーワードの使用は短時間にとどめ、トラフィックの分類に必要な場合にだけ使用するようにしてください。
2. 判別したパケットをよく調べ、GRP へのアクセスのフィルタリングを開始します。
ステップ 1 の rACL によってフィルタリングされたパケットを判別および検査が終ったら、permit any any 文を含む
rACL を、許可されているプロトコルに対して配備します。 ステップ 1 で説明したように、log キーワードを使用すると、
permit エントリに一致するパケットに関する詳細な情報が出力されます。 最後に deny any any log を使用すると、GRP
宛てに送られた予期しないパケットの判別に役立てることができます。 この rACL では、基本的な保護を行い、ネットワー
ク エンジニアが必要なトラフィックがすべて許可されていることを確認できるようになっています。
目的は、発信元と宛先の IP アドレスの範囲を明示的に指定しないで、ルータとの通信に必要なプロトコルの範囲をテスト
することです。
3. 発信元アドレスの大きな範囲を制限します。
割り当てられた classless interdomain routing(CIDR; クラスレス ドメイン間ルーティング)ブロックの範囲全体が、発
信元アドレスとして許可されるようにします。 たとえば、使用しているネットワークに 171.68.0.0/16 を割り当てている
場合、171.68.0.0/16 からの発信元アドレスだけを許可します。
このステップにより、サービスを中断することなく、リスクを緩和できます。 また、これには、使用している機器にアクセ
スする可能性のある CIDR ブロックの外側からのデバイス/ユーザのデータ ポイントも含まれます。 外側のすべてのアドレ
スは廃棄されます。
外部の BGP ピアでは、このセッションに対して許可されている発信元アドレスは CIDR ブロックの外側にあるので、例外と
して扱う必要があります。
rACL を絞り込む次のフェーズのためのデータを収集するために、このフェーズで数日間そのままにしておきます。
4. rACL の permit 文を、既知の承認済み発信元アドレスだけを許可するように絞り込みます。
徐々に発信元アドレスを制限して、GRP と通信する発信元だけを許可するようにします。
5. rACL 上で宛先アドレスを制限します (オプション)。
Internet service provider(ISP; インターネット サービス プロバイダー)によっては、ルータ上で特定のプロトコルに
よる特定の宛先アドレスの使用を許可することが必要になります。 この最後の段階では、あるプロトコルに対するトラフィ
ックを受け入れる宛先アドレスの範囲を制限します。6
配備例
次の例では、次のアドレスに基づいて、ルータを保護する受信 ACL を示しています。
この ISP のアドレス ブロックは、169.223.0.0/16 です。
この ISP のインフラストラクチャ ブロックは、169.223.252.0/22 です。
ルータのループバックは 169.223.253.1/32 です。
このルータはコア バックボーン ルータであるため、内部 BGP セッションだけがアクティブになっています。
この情報によると、最初の受信 ACL は、次の例のようになります。 インフラストラクチャ アドレスのブロックが分かっている
ため、まずブロック全体を許可します。 次に、ルータへのアクセスを必要とするデバイスの具体的なアドレスが得られたら、よ
り詳細な access control entries(ACE; アクセス コントロール エントリ)を追加します。
!
no access-list 110
!
!--- この ACL は、明示的に許可をする ACL です。
!--- 許可されたトラフィックだけが、明示的な
!--- permit ACE に一致するパケットになります。
!
! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!--!--!--!---
フェーズ 1 - 明示的な許可
宛先アドレスがループバックであり、
発信元アドレスが有効なホストからのものである
アプリケーションだけを許可します。
!
!--- 注: このテンプレートは、使用しているネットワーク固有の発信元アドレス環境
!--- に合わせて書き換える必要があります。 また、テンプレートの
!--- 変数も変更する必要があります。
!
!--- BGP を許可します。
!
access-list 110 permit tcp 169.223.252.0 0.0.3.255 host 169.223.253.1 eq bgp
!
!--- OSPF を許可します。
!
access-list 110 permit ospf 169.223.252.0 0.0.3.255 host 224.0.0.5
!
!--- 必要であれば、代表ルータのマルチキャスト アドレスを許可します。
!
access-list 110 permit ospf 169.223.252.0 0.0.3.255 host 224.0.0.6
access-list 110 permit ospf 169.223.252.0 0.0.3.255 host 169.223.253.1
!
!--- EIGRP を許可します。
!
access-list 110 permit eigrp 169.223.252.0 0.0.3.255 host 224.0.0.10
access-list 110 permit eigrp 169.223.252.0 0.0.3.255 host 169.223.253.1
!
!--- Telnet および SSH によるリモート アクセスを許可します。
!
access-list 110 permit tcp 169.223.252.0 0.0.3.255 host 169.223.253.1 eq 22
access-list 110 permit tcp 169.223.252.0 0.0.3.255 host 169.223.253.1 eq telnet
!
!--- SNMP を許可します。
!
access-list 110 permit udp 169.223.252.0 0.0.3.255 host 169.223.253.1 eq snmp
!
!--- NTP を許可します。
!
access-list 110 permit udp 169.223.252.0 0.0.3.255 host 169.223.253.1 eq ntp
!
!--!--!--!--!---
ルータから発信される traceroute:
各ホップから ttl を超過したという
メッセージが返ります(タイプ 11、コード 3)。
終点からは、ICMP ポートが到達不可能であるという
メッセージが返ります(タイプ 3、コード 0)。
!
access-list 110 permit icmp any 169.223.253.1 ttl-exceeded
access-list 110 permit icmp any 169.223.253.1 port-unreachable
!
!--- ルータの認証のための TACACS を許可します。
!
access-list 110 permit tcp 169.223.252.0 0.0.3.255 host 169.223.253.1 established
!
!--- RADIUS を許可します。
!
!
access-list 110 permit udp 169.223.252.0 0.0.3.255 169.223.253.1 log
!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!--!--!--!---
フェーズ 2 - 明示的な拒否と反応
ACE を追加して、ルータ宛ての具体的なパケット タイプを
停止および追跡します。 これは、
攻撃を追跡および分類するためのカウンタを備えた ACE を使用するフェーズです。
!
!--- SQL ワームの例 - このワームのレートを調べます。
!--- UDP ポート 1434 および 1433 宛てのトラフィックが GRP に送られることを
!--- 拒否します。 !--- これは、SQL ワームです。
!
access-list 110 deny udp any any eq 1433
access-list 110 deny udp any any eq 1434
!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!--- フェーズ 3 - トラッキングの明示的な拒否
!--- 他のトラフィックすべてを拒否しますが、これをトラッキングのためにカウントします。
!
access-list 110 deny udp any any
access-list 110 deny tcp any any range 0 65535
access-list 110 deny ip any any
注意
1. 詳細については、『IP 受信 ACL』の IOS に関する文書を参照してください。
2. DoS への抵抗力を向上するための SPD とホールド キューのガイドラインについては、『選択パケット廃棄(SPD)につい
て』を参照してください。
3. Cisco Express Forwarding と隣接関係の詳細については、『Cisco Express Forwarding の概要』を参照してください。
4. ACL の配備のガイドラインと、関連するコマンドの詳細な説明については、『Cisco 12000 シリーズ インターネット ルー
タでの ACL の設定』を参照してください。
5. これは、Vanilla、Border Gateway Protocol Policy Accounting(BGPPA)、Per Interface Rate Control(PIRC)、および
Frame Relay Traffic Policing(FRTP)のバンドルに言及するものです。
6. 受信パス保護のフェーズ II では、管理インターフェイスの作成と、着信パケットを受信する IP アドレスの自動的な制限
などが行えます。
関連情報
1992 - 2014 Cisco Systems, Inc. All rights reserved.
Updated: 2004 年 8 月 30 日
http://www.cisco.com/cisco/web/support/JP/100/1006/1006440_racl-j.html
Document ID: 43861