"Code Red"ワームをブロックするためのネットワークベースのアプリケーション認識およびACL の使用方法

はじめに

このドキュメントでは、Ciscoルータ上のCisco IOS®ソフトウェア内のNetwork-Based Application Recognition(NBAR)およびアクセスコントロールリスト(ACL)を使用して、ネットワーク入力ポイントで「Code Red」ワームをブロックする方法について説明します。この解決策は、Microsoft 製 IIS サーバ用推奨パッチと一緒に使用する必要があります。

注：この方式はCisco 1600シリーズルータでは機能しません。

注：一部のP2Pトラフィックは、そのP2Pプロトコルの性質により完全にブロックできません。これらのP2Pプロトコルは、トラフィックを完全にブロックしようとするすべてのDPIエンジンをバイパスするように、シグニチャを動的に変更します。したがって、帯域幅を完全にブロックするのではなく、帯域幅を制限することを推奨します。このトラフィックの帯域幅を調整します。帯域幅を大幅に削減ただし、接続は通過します。

前提条件

要件

次の項目に関する知識が推奨されます。

• Quality of Service(QoS)サービスポリシーは、モジュラQoSコマンドラインインターフェイス(CLI)のコマンドを使用します。

• NBAR

• ACL

• ポリシーベースルーティング

使用するコンポーネント

このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。このドキュメントの設定は、Cisco IOSバージョン12.2(24a)が稼働するCisco 3640でテストされています。

本書の情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。稼働中のネットワークで作業を行う場合、コマンドの影響について十分に理解したうえで作業してください。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

Code Red ワームを阻止する方法

「Code Red」に対処するために最初に行うべきことは、Microsoftから入手できるパッチを適用することです(方法Aのリンクを参照してください。以下のACLを使用してください)。 これにより、脆弱なシステムが保護され、感染したシステムからワームが削除されます。ただし、サーバにパッチを適用しても、ワームがサーバに感染することを防ぐだけで、HTTP GET要求がサーバに到達することを停止することはありません。サーバが大量の感染攻撃にさらされる可能性は、まだ残っています。

このアドバイザリに記載されているソリューションは、Microsoftパッチと連携して、ネットワーク入力ポイントで「Code Red」HTTP GET要求をブロックするように設計されています。

このソリューションは感染をブロックしようとしますが、HTTP GET要求の内容を分析する唯一の方法はTCP接続の確立後であるため、大量のキャッシュエントリ、隣接関係、およびNAT/PATエントリの蓄積による問題は解決しません。次の手順は、ネットワークのスキャンから保護するのに役立ちません。ただし、サイトを外部ネットワークからの感染から保護したり、マシンがサービスを提供する必要がある感染試行回数を減らすことができます。着信フィルタリングと発信フィルタリングを組み合わせることで、感染したクライアントが「Code Red」ワームをグローバルインターネットに拡散するのを防ぎます。

対応プラットフォーム

このドキュメントで説明するソリューションには、Cisco IOSソフトウェアのクラスベースのマーキング機能が必要です。特に、マッチング機能では、NBAR 内の HTTP サブポートクラシフィケーション機能を使用します。サポートされているプラットフォームおよび IOS ソフトウェア最低必要条件を次に要約します。

プラットフォーム	最低限の Cisco IOS ソフトウェア
7200	12.1(5)T
7100	12.1(5)T
3745	12.2(8)T
3725	12.2(8)T
3660	12.1(5)T
3640	12.1(5)T
3620	12.1(5)T
2600	12.1(5)T
1700	12.2(2)T

注：NBARを使用するには、Cisco Express Forwarding(CEF)を有効にする必要があります。

クラスベース マーキングおよび Distributed NBAR（DNBAR）は次のプラットフォームでも使用できます。

プラットフォーム	最低限の Cisco IOS ソフトウェア
7500	12.1(6)E
FlexWAN	12.1(6)E

IIS Web ログでのアタックの形跡の検出

最初の感染の試みは、ターゲットIISサーバに大きなHTTP GET要求を送信します。元の「Code Red」機器シンボルは次のとおりです。

2001-08-04 16:32:23 10.101.17.216 - 10.1.1.75 80 GET /default.ida 
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u
7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a 403

「Code Red」IIのフットプリントを次に示します。

2001-08-04 15:57:35 10.7.35.92 - 10.1.1.75 80 GET /default.ida XXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090
%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%
u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a 403 -

GET要求は常に.ida拡張子を持つファイルを探していることに注意してください。これは、すべての感染の試行で共通の文字列であるため、IOSでクラスベースのマーキングを使用する照合基準として使用できます。GET要求の残りの部分は、バッファオーバーフローを作成しようとしているだけなので、必ずしも一致しているわけではありません。これは、上記の2つのエントリを比較することで確認できます。

この2つのシグニチャの違いは、CodeRed.v3またはCodeRed.Cと呼ばれる「Code Red」ワームの新しい歪みによるものであると、現在報告されています。元の「Code Red」系統にはGET要求に「NNNNNNNN」文字列が含まれ、新しい系統には「XXXXXXXX」が含まれています。 詳細については、Symantecアドバイザリ を参照してください。

2001年8月6日午後6時24分に、新しい機器スペースを記録しました。我々は、これがeEye脆弱性スキャナによって残されたフットプリントであることを知った 。

2001-08-06 22:24:02 10.30.203.202 - 10.1.1.9 80 GET /x.ida AAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=X 403 HTTP/1.1 -

このアドバイザリで説明されている「Code Red」をブロックする技術は、次のセクションに示すようにクラスマップ定義を締めるだけで、これらのスキャン試行をブロックすることもできます。

IOSクラスベース マーキング機能を使った「Code Red」攻撃のマーク

「Code Red」ワームをブロックするには、次の3つの方法のいずれかを使用します。3つの方法はすべて、Cisco IOS MQC機能を使用して悪意のあるトラフィックを分類します。その後、このトラフィックは次のようにドロップされます。

方法A:ACLの使用

この方法では、出力インターフェイス上のACLを使用して、マーキングされた「Code Red」パケットをドロップします。次のネットワークダイアグラムを使用して、この方法の手順を説明します。

この方法を設定する手順を次に示します。

1. 次に示すように、Cisco IOSソフトウェアのクラスベースマーキング機能を使用して、着信「Code Red」ハックを分類します。

   Router(config)#class-map match-any http-hacks
   Router(config-cmap)#match protocol http url "*default.ida*"
   Router(config-cmap)#match protocol http url "*cmd.exe*"
   Router(config-cmap)#match protocol http url "*root.exe*"
   

   上記のクラスマップはHTTP URLの内部を参照し、指定した文字列のいずれかに一致します。「Code Red」のdefault.ida以外にも他のファイル名が含まれていることに注意してください。 このテクニックを使用して、Sadmindウイルスなどの同様のハッキング試行をブロックできます。この攻撃については、次のドキュメントで説明します。

   • http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS00-078.asp

   • http://www.sophos.com/virusinfo/analyses/unixsadmind.html

2. ポリシーを作成し、setコマンドを使用してインバウンドの「Code Red」ハックにポリシーマップをマークします。このドキュメントでは、他のネットワークトラフィックがこの値を伝送している可能性は低いため、DSCP値1（10進数）を使用します。

   ここでは、「mark-inbound-http-hacks」という名前のポリシーマップで着信「Code Red」ハックをマークします。

   Router(config)#policy-map mark-inbound-http-hacks 
   Router(config-pmap)#class http-hacks 
   Router(config-pmap-c)#set ip dscp 1
   

3. 着信「Code Red」パケットをマークするために、ポリシーを入力インターフェイスの着信ポリシーとして適用します。

   Router(config)#interface serial 0/0
   Router(config-if)#service-policy input mark-inbound-http-hacks
   

4. サービスポリシーで設定されているように、DSCP値1に一致するACLを設定します。

   Router(config)#access-list 105 deny ip any any dscp 1 
   Router(config)#access-list 105 permit ip any any
   

   注：Cisco IOSソフトウェアリリース12.2(11)および12.2(11)Tでは、NBARで使用するクラスマップの定義において、ACLのlogキーワードのサポートが導入されています(CSCdv48172)。 以前のリリースを使用している場合は、ACLでlogキーワードを使用しないでください。これにより、すべてのパケットがCEFスイッチングではなくプロセススイッチングされ、NBARはCEFを必要とするため動作しません。

5. ターゲットWebサーバに接続する出力インターフェイスにACLアウトバウンドを適用します。

   Router(config)#interface ethernet 0/1 
   Router(config-if)#ip access-group 105 out
   

6. ソリューションが期待どおりに動作することを確認します。show access-listコマンドを実行し、deny文の「matches」値が増加していることを確認します。

   Router#show access-list 105 
   Extended IP access list 105 
    deny ip any any dscp 1 log (2406 matches) 
    permit ip any any (731764 matches) 

   設定手順では、no ip unreachable interface-levelコマンドを使用してIP unreachableメッセージの送信を無効にして、ルータが過剰なリソースを消費することを回避することもできます。

   この方法は、「方法B」の項で説明されているように、DSCP=1トラフィックをNull 0にポリシールーティングできる場合は推奨されません。

方法B:ポリシーベース ルーティング (PBR)の使用

この方式では、ポリシーベースのルーティングを使用して、「Code Red」とマークされたパケットをブロックします。メソッドAまたはCがすでに設定されている場合は、このメソッドのコマンドを適用する必要はありません。

この方法を実装する手順を次に示します。

1. トラフィックを分類し、マーキングします。メソッドAに示すclass-mapおよびpolicy-mapコマンドを使用します。

2. service-policyコマンドを使用して、着信「Code Red」パケットをマークするために、入力インターフェイスで着信ポリシーとしてポリシーを適用します。方法Aを参照。

3. マークされた「Code Red」パケットに一致する拡張IP ACLを作成します。

   Router(config)#access-list 106 permit ip any any dscp 1
   

4. route-mapコマンドを使用して、ルーティングポリシーを作成します。

   Router(config)#route-map null_policy_route 10 
   Router(config-route-map)#match ip address 106 
   Router(config-route-map)#set interface Null0 

5. ルートマップを入力インターフェイスに適用します。

   Router(config)#interface serial 0/0 
   Router(config-if)#ip policy route-map null_policy_route
   

6. show access-listコマンドを使用して、ソリューションが期待どおりに動作することを確認します。出力ACLを使用していて、ACLロギングを有効にしている場合は、次に示すようにshow logコマンドも使用できます。

   Router#show access-list 106 
   Extended IP access list 106 
    permit ip any any dscp 1 (1506 matches) 
   
   Router#show log 
   Aug 4 13:25:20: %SEC-6-IPACCESSLOGP:
    list 105 denied tcp A.B.C.D.(0) -> 10.1.1.75(0), 6 packets 
   Aug 4 13:26:32: %SEC-6-IPACCESSLOGP:
    list 105 denied tcp A.B.C.D.(0) -> 10.1.1.75(0), 6 packets 

   すべての出力インターフェイスに出力ACLを必要とせずに、ルータの入力インターフェイスで廃棄を決定できます。ここでも、no ip unreachablesコマンドを使用して、IP到達不能メッセージの送信を無効にすることを推奨します。

方法C:クラスベース ポリシングの使用

この方式は通常、PBRまたは出力ACLに依存しないため、最もスケーラブルです。

1. 方法Aに示されているclass-mapコマンドを使用してトラフィックを分類します。

2. policy-mapコマンドを使用してポリシーを作成し、policeコマンドを使用して、このトラフィックの廃棄アクションを指定します。

   Router(config)#policy-map drop-inbound-http-hacks 
   Router(config-pmap)#class http-hacks 
   Router(config-pmap-c)#police 1000000 31250 31250
    conform-action drop exceed-action drop violate-action drop
   

3. service-policyコマンドを使用して、入力インターフェイスにインバウンドポリシーとしてポリシーを適用し、「Code Red」パケットをドロップします。

   Router(config)#interface serial 0/0 
   Router(config-if)#service-policy input drop-inbound-http-hacks
   

4. show policy-map interfaceコマンドを使用して、ソリューションが期待どおりに動作することを確認します。クラスの値と個々の一致基準が増加していることを確認します。

   Router#show policy-map interface serial 0/0 
     
   Serial0/0
   
     Service-policy input: drop-inbound-http-hacks
   
       Class-map: http-hacks (match-any)
         5 packets, 300 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: protocol http url "*default.ida*"
           5 packets, 300 bytes
           5 minute rate 0 bps
         Match: protocol http url "*cmd.exe*"
           0 packets, 0 bytes
           5 minute rate 0 bps
         Match: protocol http url "*root.exe*"
           0 packets, 0 bytes
           5 minute rate 0 bps
         police:
           1000000 bps, 31250 limit, 31250 extended limit
           conformed 5 packets, 300 bytes; action: drop
           exceeded 0 packets, 0 bytes; action: drop
           violated 0 packets, 0 bytes; action: drop
           conformed 0 bps, exceed 0 bps, violate 0 bps
   
       Class-map: class-default (match-any)
         5 packets, 300 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: any 

NBARの制約事項

このドキュメントの方法でNBARを使用する場合、NBARでは次の機能がサポートされていないことに注意してください。

• 24を超える同時URL、ホスト、またはMIMEタイプが一致する

• URLの最初の400バイトを超える照合

• 非IPトラフィック

• マルチキャストおよびその他の非CEFスイッチングモード

• 断片化パケット

• パイプライン型の永続的HTTP要求

• セキュアHTTPによるURL/HOST/MIME/分類

• ステートフルプロトコルによる非対称フロー

• NBARを実行しているルータから発信またはルータ宛てのパケット

次の論理インターフェイスではNBARを設定できません。

• Fast EtherChannel

• トンネリングまたは暗号化を使用するインターフェイス

• VLAN

• ダイヤラインターフェイス

• マルチリンク PPP

注：NBARはCisco IOSリリース12.1(13)EでVLAN上で設定できますが、ソフトウェアスイッチングパスでのみサポートされます。

NBARは、トンネリングや暗号化が使用されるWANリンク上の出力トラフィックの分類には使用できないため、LANインターフェイスなどのルータ上の他のインターフェイスに適用して、トラフィックがWANリンクに切り替わる前に入力分類をします。

NBARの詳細については、「関連情報」のリンクを参照してください。