Control Plane Policing (CoPP)


Control Plane Policing (CoPP)とControl Plane Protection (CPPr)は、ネットワーク機器のCPUを守る機能です。何も対策を立てない状況ですと、フラグメントされたパケットを大量に送付する等の方法を用いて、ネットワーク機器のCPU使用率を上昇させるDOS攻撃を行なう事ができます。このような攻撃に対する防御策として、CPU処理するパケットに対してポリシング(流量制限)をかける事によってCPUを守る事ができます。

このページでは、Control Plane Policing (CoPP)の使い方と設定例について紹介します。

Control Plane Policing (CoPP)とは

Control Plane Policing (CoPP)とは、ネットワーク機器のCPUを守る機能です。多くのネットワーク機器は、データ転送を行なう「データプレーン」とルーティングなどのソフトウェア処理を行なう「コントロールプレーン」の2層に分かれます。この構造を図で表すと以下の通りです ( 画像は「Cisco LANスイッチ教科書」より引用 ) 。

control_plane_data_plane_001

ルータ宛パケットや非IPはコントロールプレーンで処理されます(図中では「制御フレーム」と表記されています)。そのため、コントロールプレーン宛のパケットを大量に送付すれば、ルータのCPU使用率を上昇させDOS攻撃が可能になってしまいます。この攻撃に対する防御策がControl Plane Policing (CoPP)です。コントロールプレーン宛のパケットをポリシング(流量制限)する事で、ルータのCPUを守る事ができます。

Control Plane Policing (CoPP)の設定

アクセスリスト(ACL)の作成

Control Plane Policingを実装するには、policy-mapを作成する必要があります。policy-mapを作るにはclass-mapの定義が必要です。class-mapを定義するにはアクセスリスト(ACL)の定義が必要です。

まずは、以下のようなコマンドでアクセスリストを定義しましょう。構文および設定例は以下の通りです。

作成したアクセスリスト(ACL)を確認するには、”show ip access-lists”コマンドなどを使用します。

上記は名前つき拡張アクセスリストの構文ですが、名前なしでも標準アクセスリストでも差し支えございません。

class-map (クラスマップ) の作成

アクセスリスト(ACL)を元に、class-map(クラスマップ)を作成します。構文および設定例は以下の通りです。

作成したclass-map (クラスマップ)を確認するには、”show class-map”コマンドなどを使用します。

なお、以下のようなCBAC指定のclass-map(クラスマップ)を用いた設定はできません。

CBAC指定でControl Plane Policing (CoPP)を設定しようとすると、”Unsupported protocol in”とのエラーメッセージが出力されます。

policy-map (ポリシーマップ) の作成

class-map(クラスマップ)を元に、policy-map(ポリシーマップ)を作成します。構文および設定例は以下の通りです。

作成したpolicy-map(ポリシーマップ)を確認するには”show policy-map”コマンドを使用します。

policy-map (ポリシーマップ) の適用

最後にpolicy-map (ポリシーマップ)をcontrol-planeに対して適用します。Interfaceに対するCBWFQと同じようにservice-policyコマンドを用いて適用します。 構文および設定例は以下の通りです。

適用したポリシーマップを確認するには”show policy-map control-plane”コマンドを使用します。

Control Plane Policing (CoPP)の動作確認

ネットワーク構成図

以下の環境で動作確認を行います。

20150117_control_plane_policing

初期設定

初期設定はIPアドレスのみです。特別な設定はございません。

初期設定全文は以下の通りです。

TELNETに対するポリシング設定

TELNETのトラフィックについて、コントロールプレーンに対するポリシングを実装します。R2に対して、以下のような設定を投入して下さい。

動作確認のため、R1からR2へのTELNETトラフィックを発生させます。

R2で”show policy-map control-plane”コマンドを実行します。”conformed 9 packets”と表示されている事から、想定通りの分類(classsify)がなされ、Control Plane Policingの設定が効いている事を推測する事ができます。

PING(ICMP)に対するポリシング設定

前述のTELNETを用いた動作確認では、超過トラフィックが本当に破棄されているかどうかが動作確認できませんでした。そこで、大量のトラフィックを容易に発生させる事ができるPING (ICMP)を用いた動作確認を行ってみましょう。

PING (ICMP)のトラフィックについて、コントロールプレーンに対するポリシングを実装します。R2に対して、以下のような設定を投入して下さい。

R1からR2へのpingを送信します。pingを送信する際は、トラフィック超過を発生しやすくするようpingのsizeを適宜指定します。pingが数発に1度の割合でtimeoutが発生していることから、パケットの破棄が行なわれている事が推測できます。

R2で”show policy-map control-plane”の出力を確認します。Class-map: CMAP_ICMPについて”exceeded 4 packets”と書かれている事からも、トラフィック超過分が破棄されている事が読み取れます。

class-default(クラスデフォルト)に対するポリシング設定

全てのトラフィックについてコントロールプレーンに対するポリシングを実装するには、class-default(クラスデフォルト)を使用します。class-defaultに含まれるのはIPだけでなく非IPも含まれます。非IPの代表的な例は以下の通りです。

  • Layer 2 トラフィック ( 例 : ARP, LACP, PAgP )
  • 非IPのLayer 3 トラフィック ( 例 : IPX, Apple Talk )

非IPも含め、ポリシングが実装可能な事を確認します。R2に対して、以下のような設定を投入して下さい。

非IPに関する動作を確認するため、R1,R2間でIPXによるルーティングを設定します。R1, R2の両方に以下のような設定を投入します。

R2のIPXアドレスを調べるために、”show ipx interface”コマンドを出力させます。すると、R2のIPXアドレスは”12.ca02.0bc8.0008″である事が分かります。

R1からR2へのIPX pingを送信します。size, timeoutなどを適宜指定したIPX pingを使用するには、拡張ping(対話形式のping)を使用して下さい。IPX pingが数発に1度の割合でtimeoutが発生していることから、パケットの破棄が行なわれている事が推測できます。

R2で”show policy-map control-plane”の出力を確認します。Class-map: class-defaultについて”exceeded 5 packets”と書かれている事からも、トラフィック超過分が破棄されている事が読み取れます。

以上、ここまでの設定は以下の通りになります。

非IPのみに対するポリシング設定

CCIE Lab試験では、「思いつくか、思いつかないか」発想力勝負の問題が出題される事があります。例えば、

  • R2に接続されたサーバではネットワークプログラミングのテストを行っています。
  • テストの何らかの手違いにより、サーバ機器が大量のARP repuestを発生させ、R2のCPUリソースを枯渇させています。
  • R2に対するARP requestについて、秒間10,000パケットを超過したものを破棄して下さい。
  • ただし、この設定はIPパケット(TELNET, BGPなど)に影響を与えてはいけません。

のような問題が出題されます。回答例は以下URLを参照ください。

思いついてしまえば難しい設定ではありませんので、解説と動作確認は割愛します。

動作確認環境

動作確認を行った環境は以下の通りです。

  • 動作確認日 : 2015/01/17
  • GNS version 1.2.3
  • Cisco IOS version 15.0

シェアする

  • このエントリーをはてなブックマークに追加

フォローする