セキュリティと VPN : 認証プロトコル

Cisco ルータを使用したパケット フラッドの識別とトレース

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

目次

概要
前提条件
      要件
      使用するコンポーネント
      表記法
最も一般的な DoS 攻撃
DoS 識別アクセス リスト
      smurf 攻撃の最終的なターゲット
      smurf 攻撃のリフレクタ
      fraggle
      SYN フラッド
      その他の攻撃
      ロギングおよびカウンタに関する注意
トレース
      「log-input」によるトレース
      SYN フラッド
      smurf 攻撃の Stimulus
      「log-input」によらないトレース
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

Denial of Service(DoS; サービス拒絶)攻撃は、インターネットで一般的な攻撃です。このような攻撃に対する最初のステップは、攻撃の種類を正確に見分けることです。一般的に使用される DoS 攻撃の多くは、高帯域幅のパケット フラッドや、その他の反復的なパケット ストリームによるものです。

多くの DoS 攻撃ストリームでのパケットは Cisco IOS(R) ソフトウェア アクセス リストのエントリと照合することにより識別できます。 これは攻撃をフィルタリングするのに有効ですが、未知の攻撃を識別したり、「なりすまし」パケット ストリームを実際の送信元にトレースするのにも役立ちます。

同様の目的のために、Cisco ルータのデバッグ ロギングや IP アカウンティングなどの機能が役立つ場合もあります(特に新しいまたはまれな攻撃に対して)。しかし、Cisco IOS ソフトウェアの最近のバージョンでは、一般的な攻撃の識別とトレースには、主にアクセス リストとアクセス リスト ロギングが役立ちます。

前提条件

要件

この文書に関する特別な要件はありません。

使用するコンポーネント

この文書は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

表記法

文書表記の詳細は、『Cisco テクニカル ティップスの表記法』を参照してください。

最も一般的な DoS 攻撃

DoS 攻撃にはさまざまなタイプがあります。ソフトウェアの Bug を利用して比較的わずかなトラフィックでシステムをシャット ダウンする攻撃は無視するとしても、ネットワークを横断して送信できる IP パケットは、すべてフラッディング DoS 攻撃の実行に使用され得る事実に変わりはありません。 攻撃にさらされている場合、現在発生していることが通常のカテゴリにあてはまらないものである可能性を常に考慮する必要があります。

しかし、注意点として、多くの攻撃は類似のものであると考えることも有効です。攻撃者は、一般的な手法を選択するものです。これは、こうした手法が特に効果的であったり、トレースが特に困難であったり、ツールが入手できたりするためです。多くの DoS 攻撃者は、独自のツールを作成する技術も動機もなく、インターネット上で見つかるプログラムを利用します。こうしたツールには流行があります。

この稿が書かれている 1999 年 7 月の時点では、シスコへの問い合せのほとんどは「smurf」攻撃に関するものです。 この攻撃には 2 つの対象があります。 1 つは「最終的なターゲット」で、もう 1 つは「リフレクタ」です。この攻撃では、リフレクタ サブネットのブロードキャスト アドレスに ICMP エコー要求(「ping」)が大量に流されます。これらのパケットの送信元アドレスは、最終的なターゲットのアドレスに偽装されています。攻撃者が送信するパケットのそれぞれに対してリフレクタ サブネット上の多くのホストが反応する結果、最終的なターゲットにフラッドが発生し、両方の被害者の帯域幅が浪費されます。

「fraggle」と呼ばれる類似の攻撃では、同じ方法でダイレクト ブロードキャストが使用されますが、Internet Control Message Protocol(ICMP)エコー要求の替わりに UDP エコー要求が使用されます。通常 fraggle は smurf に比べて増幅要素が小さく、それほど一般的ではありません。

smurf 攻撃は、通常はネットワーク リンクが過負荷になることによって発見されます。 これらの攻撃の総括的な説明と防御手段は、『サービス拒絶攻撃についての情報ページleavingcisco.com』に記載されています。

他の一般的な攻撃として、SYN フラッドがあります。この攻撃は、ターゲット マシンを TCP 接続要求で氾濫させます。接続要求パケットの送信元アドレスと送信元 TCP ポートはランダム化されます。これは、ターゲット ホストに多数の接続のステート情報を維持させ続けるためです。

SYN フラッド攻撃は、通常はターゲット ホスト(一般的に HTTP または SMTP サーバ)の極端な速度低下、クラッシュ、または停止によって明らかになります。 ターゲット ホストから返されるトラフィックによりルータに問題が発生する可能性もあります。この理由は、このリターン トラフィックが元のパケットのランダム化された発信元アドレスに送られ、これには「実」IP トラフィックの位置プロパティがないので、ルート キャッシュをオーバーフローさせることがあるためです。シスコのルータでは、この問題はルータがメモリを使い果たすことにより露見することがよくあります。

シスコに報告されるフラッディング DoS 攻撃の大部分は、smurf と SYN フラッド攻撃で説明がつきます。これらの攻撃をすばやく認識することは、非常に重要です。幸いにも、どちらの攻撃も(ping フラッドのようないくつかの「第 2 層」攻撃を含めて)Cisco アクセス リストを使用して容易に認識できます。

DoS 識別アクセス リスト

2 つのインターフェイスを持つルータを考えてください。Ethernet 0 は商用 ISP または小規模 ISP で内部 LAN に接続されています。Serial 0 は上流 ISP 経由でインターネット接続を提供します。Serial 0 の入力パケット レートはフル リンク帯域幅に固定されてしまっており、LAN 上のホストでは速度低下、クラッシュ、停止、またはその他の DoS 攻撃の兆候が現れています。ルータが接続されている小規模サイトにはネットワーク アナライザがなく、このサイトの人々は、アナライザ トレースが入手できた場合でもそれを読んだ経験がほとんどないか、まったくありません。

22a.gif

次に、アクセス リストを次のように適用すると仮定します。

access-list 169 permit icmp any any echo
    access-list 169 permit icmp any any echo-reply
    access-list 169 permit udp any any eq echo
    access-list 169 permit udp any eq echo any
    access-list 169 permit tcp any any established
    access-list 169 permit tcp any any
    access-list 169 permit ip any any
    interface serial 0
    ip access-group 169 in

このリストがトラフィックにフィルタをかけることはなく、すべてのエントリが許可されます。 しかし、このリストは便利な方法でパケットを分類するので、3 種の攻撃すべてに対する当面の診断に利用できます。 この 3 種類の攻撃とは、smurf、SYN flood、fraggle です

smurf 攻撃の最終的なターゲット

show access-list コマンドを発行すると、次のような出力が表示されます。

Extended IP access list 169
        permit icmp any any echo (2 matches)
        permit icmp any any echo-reply (21374 matches)
        permit udp any any eq echo
        permit udp any eq echo any
        permit tcp any any established (150 matches)
        permit tcp any any (15 matches)
        permit ip any any (45 matches)

このシリアル インターフェイスに到着しているトラフィックのほとんどは ICMP エコー応答のパケットです。これはおそらく smurf 攻撃のサインです。このサイトは、リフレクタではなく最終的なターゲットになっています。アクセス リストを次のように変更することにより、この攻撃に関するさらに詳しい情報が容易に得られます。

interface serial 0
    no ip access-group 169 in
    no access-list 169
    access-list 169 permit icmp any any echo
    access-list 169 permit icmp any any echo-reply log-input
    access-list 169 permit udp any any eq echo
    access-list 169 permit udp any eq echo any
    access-list 169 permit tcp any any established
    access-list 169 permit tcp any any
    access-list 169 permit ip any any
    interface serial 0
    ip access-group 169 in

この変更では、容疑トラフィックに該当するアクセス リストのエントリに log-input キーワードが追加されています。 (バージョン 11.2 よりも前の Cisco IOS ソフトウェアにはこのキーワードがなく、代わりにキーワード「log」を使用します。)これにより、このリスト エントリに一致するパケットに関する情報がルータにログされます。 logging buffered が設定されていると仮定して、show log コマンドの結果メッセージを見ることができます(転送レートの制限によりメッセージが蓄積されるのにはしばらく時間を要します)。次のようなメッセージが表示されます。

%SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.142 
    (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
    %SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.113 
    (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
    %SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.72 
    (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
    %SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.154 
    (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
    %SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.15 
    (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
    %SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.142 
    (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
    %SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.47 
    (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
    %SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.35 
    (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
    %SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.113 
    (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
    %SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.59 
    (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
    %SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.82 
    (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
    %SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.56 
    (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
    %SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.84 
    (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
    %SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.47 
    (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
    %SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.45.35 
    (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
    %SEC-6-IPACCESSLOGDP: list 169 denied icmp 192.168.212.15 
    (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet
    %SEC-6-IPACCESSLOGDP: list 169 denied icmp 172.16.132.33 
    (Serial0 *HDLC*) -> 10.2.3.7 (0/0), 1 packet

エコー応答パケットの送信元アドレスが少数のアドレス プレフィックスにクラスタ化されています。 このアドレス プレフィックスは 192.168.212.0/24、192.168.45.0/24、および 172.16.132.0/24 です。(192.168.x.x と 172.16.x.x ネットワークのプライベート アドレスはインターネットには実在しません。これは実験環境での説明です。)これは典型的な smurf 攻撃です。送信元アドレスは smurf リフレクタのアドレスです。適切なインターネット「whois」データベースでこれらのアドレス ブロックを参照することにより、これらのネットワークの管理者を見つけ、攻撃への対処への協力を求めることができます。

この時点での重要な点ですが、smurf 例では、これらのリフレクタは攻撃者ではなく被害者であることを思い出してください。 DoS フラッドで攻撃者が IP パケットに自分の送信元アドレスを使うことはめったになく、実際の smurf 攻撃ではこれは不可能です。フラッド パケット内のどのアドレスも、完全に偽装されているか、または何らかの被害者のアドレスと考える必要があります。smurf 攻撃の最終的なターゲットにとって最も生産的なアプローチは、リフレクタに連絡を取り、ネットワークを再設定して攻撃を遮断するよう依頼するか、攻撃的なストリームのトレースへの協力を依頼することです。

smurf 攻撃による最終的なターゲットへの被害は、通常はインターネットからの到着リンクの過負荷で引き起こされるので、多くの場合、リフレクタへの連絡以外には対応策はありません。ターゲット管理のマシンにパケットが到着するときまでには、ほとんどの被害は発生してしまっています。

急場をしのぐための対応策の 1 つとしては、上流のネットワーク プロバイダーに、すべての ICMP エコー応答、または特定のリフレクタからのすべての ICMP エコー応答を、フィルタ アウトするように依頼する方法があります。 この種のフィルタは通常、恒久的に有効にしておくものではありません。 一時的なフィルタとしても、エコー応答だけをフィルタすべきで、すべての ICMP パケットをフィルタするべきではありません。 他の可能性としては、上流プロバイダーに QOS と、エコー応答に利用できる帯域幅を制限するレート制限機能を使用させることがあります。適切な帯域幅制限ならば無期限に有効にできます。これらのアプローチは、上流プロバイダーの機器に必要な機能があることが前提になりますが、この機能がない場合もあります。

smurf 攻撃のリフレクタ

着信トラフィックがエコー応答ではなくエコー要求で占められているならば(言い換えると、2 番目ではなく 1 番目のアクセス リスト エントリが適切な値とみなされる以上の一致件数をカウントしている場合)、ネットワークがリフレクタとして利用されている smurf 攻撃が疑われますが、単なる ping フラッドの可能性もあります。どらちのケースでも、攻撃が成功していた場合は、シリアル回線の着信側だけでなく発信側でも氾濫が発生していることが疑われます。実際、増幅要素のために、発信側では着信側よりもさらに過大な負荷が発生していると考えられます。

smurf 攻撃と単なる ping フラッドを見分けるには、次の方法があります。

  • smurf 攻撃のパケットは、ユニキャスト アドレスではなくダイレクト ブロードキャスト アドレスに送信されます。これに対して通常の ping フラッドは、ほぼ 100 % ユニキャストを使用します。アドレスを見るには、前のセクションの説明に従い、適切なアクセス リスト エントリに log-input キーワードを使用します。

  • smurf リフレクタとして使用されている場合は、システムのイーサネット側の show interface 表示に異状な数の出力ブロードキャストが現れます。また、通常は show ip traffic 表示に異状な数の送信ブロードキャストが現れます。通常の ping フラッドでは、バックグラウンド ブロードキャスト トラフィックは増加しません。

  • smurf リフレクタとして使用されている場合は、インターネットからの着信トラフィックよりもインターネットへの発信トラフィックの方が多くなります。一般的に、シリアル インターフェイスでは入力パケットよりも出力パケットの方が多くなります。攻撃的なストリームによって入力インターフェイスが完全に満たされている場合でも、応答ストリームは攻撃ストリームよりも大きく、パケット廃棄はカウントされます。

smurf リフレクタには、smurf 攻撃の最終的なターゲットよりも多くの選択肢があります。リフレクタが攻撃を排除することを選択する場合は、通常 no ip directed-broadcast(または同等の非 IOS コマンド)が役に立ちます。これらのコマンドはあらゆる設定で使用されており、アクティブな攻撃が存在しない場合でも使用できます。Cisco 機器が smurf 攻撃に使用されるのを防ぐ方法の詳細は、『シスコ ルータでのセキュリティ向上』を参照してください。 一般的な smurf 攻撃に関する詳細な情報、およびシスコ以外の機器の防御に関しては、『サービス拒絶攻撃の情報ページleavingcisco.com』を参照してください。

smurf リフレクタは最終的なターゲットよりも攻撃者に 1 段階近いため、攻撃をよりトレースしやすい位置にいます。攻撃をトレースすることを選択する場合は、関連する ISP との協力が必要です。トレースの完了後に何らかの行動を起こす場合は、適切な捜査機関との連携が必要です。攻撃のトレースを追求する場合は、できるだけ早い段階で捜査機関の協力を要請してください。 フラッディング攻撃をトレースする上での技術情報は「トレース」セクションをご覧ください。

fraggle

fraggle 攻撃は、攻撃ストリームに ICMP エコー要求ではなく UDP エコー要求が使用される点を除いては、smurf に類似しています。fraggle 攻撃は、アクセス リストの 3 行目および 4 行目から識別されます。ほとんどのネットワークでは UDP エコーは ICMP エコーほど重要なサービスではないため、完全に無効にしてもマイナスの影響は少ない点を除けば、被害者に対する適切な対応も同一です。

SYN フラッド

アクセス リストの 5 行目と 6 行目が次のようになりました。

access-list 169 permit tcp any any established
    access-list 169 permit tcp any any

これらのうち最初の行では、TCP パケットを ACK ビット セットと照合します。 目的としては、これは TCP SYN ではないパケットと照合するということを意味しています。 このため 2 番目の行は TCP SYN のパケットにだけ照合することになります。SYN フラッドは、これらのリスト エントリのカウンタから容易に識別できます。正常なトラフィックでは、少なくとも 2 つ、通常は約 4 から 5 の要素のために、非 SYN TCP パケットの数が SYN の数を超えます。SYN フラッドでは、SYN の数が非 SYN TCP パケットの数を何度も超えるのが特徴です。

攻撃以外の条件でこのような現象が発生するのは、大量の正常な接続要求による過負荷の場合に限られます。一般的に、このような過負荷は突然発生し、真の SYN フラッドほど多くの SYN パケットを伴いません。 さらに、SYN フラッドにはしばしば、まったく無効な送信元アドレスが含まれています。log-input キーワードを使用すると、接続要求がこのようなアドレスから来ているのが観察できます。

SYN フラッドに似た攻撃に、「プロセス テーブル攻撃」と呼ばれる攻撃があります。プロセス テーブル攻撃では、TCP 接続が実際に完了した後、それ以上プロトコル トラフィックがない状態でタイムアウトまで放置されます。これに対して SYN フラッドでは、最初の接続要求だけが送信されます。プロセス テーブル攻撃では TCP 初期ハンドシェイクを完了する必要があるため、一般に、攻撃者がアクセス(通常は不正アクセス)するマシンの実際の IP アドレスを使用する必要があります。したがってプロセス テーブル攻撃は、パケット ロギングを使用して SYN フラッドと容易に区別できます。プロセス テーブル攻撃の SYN は、すべて 1 つまたは少数のアドレス、あるいはせいぜい 1 つまたは少数のサブネットから送信されます。

残念ながら、SYN フラッドの被害者が取ることができる対応は非常に限られています。一般に攻撃を受けるシステムは重要なサービスであるため、システムへのアクセスをブロックすることは攻撃者の思うつぼです。Cisco 製品を含む多くのルータやファイアウォール製品には、SYN フラッドの影響を抑えるための機能がありますが、その効果は環境に依存します。詳細は、Cisco IOS Firewall 機能セットに関する文書、Cisco IOS TCP Intercept 機能に関する文書、および『シスコ ルータでのセキュリティ向上』を参照してください。

SYN フラッドのトレースは可能ですが、トレースのプロセスでは、攻撃者から被害者までの経路における各 ISP の協力が必要です。SYN フラッドのトレースを試みる場合は、早い段階で捜査機関に連絡し、アップストリーム サービス プロバイダーの協力を仰いでください。 シスコの機器によるトレースの詳細は、この文書の「トレース」セクションをご覧ください。

その他の攻撃

攻撃を受けていると考えられ、かつ送信元および宛先の IP アドレス、プロトコル番号、およびポート番号を使用してその攻撃を識別できる場合は、アクセス リストを使用して仮説を検証できます。疑わしいトラフィックに一致するアクセス リスト エントリを作成し、適切なインターフェイスに適用し、一致カウンタを検討するか、トラフィックをログしてください。

ロギングおよびカウンタに関する注意

あるアクセス リスト エントリに関するカウンタは、そのエントリに対するすべての一致をカウントする点に注意してください。 アクセス リストを 2 つのインターフェイスに適用すると、表示されるカウントは集約されたカウントになります。

アクセス リスト ロギングでは、あるエントリに一致するすべてのパケットが表示されるわけではありません。ロギングは、CPU への過負荷を避けるためにレートが制限されます。ロギングで表示されるのは十分に代表的と呼べるサンプルですが、完全なパケット トレースではありません。 ここに表示されていないパケットがあることを憶えていてください。

一部のソフトウェア バージョンでは、アクセス リスト ロギングが一部のスイッチング モードでしか動作しません。あるアクセス リスト エントリで、多数の一致がカウントされるにもかかわらず何もログされない場合は、ルート キャッシュをクリアしてパケットを強制的にプロセススイッチしてみてください。多くのインターフェイスを持つ負荷の大きいルータにこれを行う場合は、注意が必要です。キャッシュが再構築される間に大量のトラフィックが廃棄される可能性があります。可能な場合は CEF を使用してください。

アクセス リストとロギングはパフォーマンスに影響を与えますが、大きな影響ではありません。ルータの CPU 負荷がおよそ 80 % を超えている場合や、アクセス リストを非常に高速のインターフェイスに適用する場合は、注意が必要です。

トレース

DoS パケットの送信元アドレスは、攻撃者自身とは無関係な値に設定されている場合がほとんどなので、攻撃者の識別には役立ちません。攻撃の発信元を識別するために役立つ唯一の方法は、ネットワークをホップバイホップでトレースしていくことです。このプロセスには、ルータの再設定とログ情報の検査が含まれるため、攻撃者から被害者までの経路に関わるすべてのネットワーク オペレータの協力が必要です。こうした協力を確保するためには、通常は捜査機関の関与が必要です。また、攻撃者に対して何らかの行動を起こすためにも、捜査機関の関与は必要です。

DoS フラッドのトレース プロセスは、比較的シンプルです。 フラッド トラフィックを送受信していると思われるルータ(名前を「A」とします)から開始して、「A」がトラフィックを受信しているルータ(名前を「B」とします)を識別します。 「B」でログを行い、「B」がトラフィックを受信しているルータ(名前を「C」とします)を発見します。最終的な送信元が発見されるまでこれを続けます。

この方法には、次のような困難があります。

  • 「最終的な送信元」が、確かに攻撃者が構成したコンピュータであっても、実際には他の被害者によって所有され操作されているコンピュータである場合があります。この場合、DoS フラッドのトレースは第 1 段階に過ぎません。

  • 攻撃者はトレースされる可能性があることを知っており、通常は限られた時間しか攻撃を続けないため、フラッドをトレースするために十分な時間がない場合があります。

  • 特に攻撃者が比較的高度な技術を持つ場合、複数の送信元から攻撃が来る場合があります。 できるだけ多くの送信元で識別を試行することが重要です。

  • コミュニケーションに問題があると、すばやいトレース プロセスが不可能になります。関与するネットワーク オペレータによっては、十分な技術力を持つスタッフがいない場合がしばしばあります。

  • 攻撃者が発見された場合でも、法的および政治的問題のために攻撃者に対する措置が困難になる場合があります。

実際には、DoS 攻撃のトレースのほとんどは失敗に終わります。このため多くのネットワーク オペレータは、強制されない限り攻撃のトレースを試みることさえしません。「重大な」攻撃だけをトレースするネットワーク オペレータも多くありますが、何が「重大」かの定義はさまざまです。捜査機関が関与した場合にだけトレースに協力するネットワーク オペレータもあります。

「log-input」によるトレース

Cisco ルータを通過する攻撃をトレースする場合、最も効果的な方法は攻撃トラフィックに一致するアクセス リストエントリを構築し、log-input キーワードを指定し、攻撃ストリームが最終的なターゲットに送信される経路になっているインターフェイスの発信側に、そのアクセス リストを適用することです。 アクセス リストが作成したログ エントリにより到着トラフィックが通過するルータ インターフェイスが識別され、さらに、そのインターフェイスがマルチポイント接続されていれば、これにより受信している先のデバイスのレイヤ 2 アドレスがわかります。 このレイヤ 2 アドレスを使って、チェーンの次のルータを識別できます。たとえば、show ip arp mac-address コマンドをこれに使用できます。

SYN フラッド

SYN フラッドをトレースする場合は、次のようなアクセス リストを作成します。

access-list 169 permit tcp any any established
    access-list 169 permit tcp any host victim-host log-input
    access-list 169 permit ip any any

これにより、ターゲット ホスト宛ての SYN が、正当な SYN を含めてすべてログされます。攻撃者への実際の経路として最も可能性が高い経路を識別するには、ログ エントリを詳細に検査します。一般的に、最も多くの一致パケットを送信しているのがフラッドの送信元です。 送信元 IP アドレスにはまったく意味がない点を思い出してください。現在探しているのは、送信元インターフェイスと送信元 MAC アドレスです。 フラッド パケットには無効な送信元アドレスが含まれているので、場合によってはフラッド パケットを正当なパケットから識別することが可能です。送信元アドレスが無効なパケットは、いずれもフラッドの一部である可能性が高くなります。

SYN フラッドに関しては比較的まれですが、フラッドが複数の送信元を持つ場合もある点に注意してください。

smurf 攻撃

smurf 攻撃ストリームをトレースするには、次のようなアクセス リストを使用します。

access-list 169 permit icmp any any echo log-input
    access-list 169 permit ip any any

最初のエントリはリフレクタのアドレスを指すパケットだけに限定されているわけではない点に注意してください。これは、ほとんどの smurf 攻撃は複数のリフレクタ ネットワークを使用するためです。 最終的なターゲットが割り出されていないと、すべてのリフレクタ アドレスはわからない可能性があります。トレースが攻撃の発信元に近づくにつれ、より多くの宛先に向かうエコー要求が現れることがあります。これはよい兆候です。

しかし、膨大な ICMP トラフィックを取り扱っている場合には、あまりに大量のログ情報が生成されて、簡単には読み取れない可能性があります。 この状態になった場合は、利用されているとわかっているリフレクタの 1 つに宛先アドレスを限定できます。その他に、255.255.255.0 のネットマスクは、インターネット内で非常に一般的であるという事実を利用したエントリを使用する方法もあります。攻撃者が smurf リフレクタを発見する方法上の理由で、smurf 攻撃に実際に使用されるリフレクタ アドレスは、非常に高い確率でこのマスクに一致します。.0 または .255 で終わるホスト アドレスは、インターネット内で非常にまれであるため、たとえば次のようにして、smurf 攻撃ストリームを比較的特定して認識できます。

access-list 169 permit icmp any host known-reflector echo log-input
    access-list 169 permit icmp any 0.0.0.255 255.255.255.0 echo log-input
    access-list 169 permit icmp any 0.0.0.0 255.255.255.0 echo log-input
    access-list 169 permit ip any any

このリストでは、ログから多数の「ノイズ」パケットを排除できる一方、攻撃者に近づくにつれてさらに多くの攻撃ストリームを発見できる可能性があります。

「log-input」によらないトレース

log-input キーワードが存在するのは、Cisco IOS ソフトウェア リリース 11.2 以降と、サービス プロバイダー市場向け限定で作成された Cisco IOS ソフトウェア リリース 11.1 ベースのソフトウェアです。古いソフトウェアでは、このキーワードがサポートされません。 もっと古いソフトウェアでルータを使っている場合は、利用可能な 3 つのオプションがあります。

  • ロギングを含まないが、疑わしいトラフィックに一致するエントリを含むアクセス リストを作成します。各インターフェイスの入力側にこのリストを適用し、カウンタを調べます。一致率の高いインターフェイスを探します。この方法はパフォーマンス オーバーヘッドが非常に小さく、発信元インターフェイスを識別するために優れています。 この最大の欠点はリンクレイヤの送信元アドレスが提供されないことなので、通常はポイントツーポイントの回線で有効です。

  • log-input ではなく、log キーワードを含むアクセス リスト エントリを作成します。再び、各インターフェイスの着信側にこのリストを適用します。 この方法でも送信元 MAC アドレスは提供されませんが、たとえば、あるパケット ストリームがほんとうに攻撃の一部なのかを確認する場合のように、IP データを観察するのには有効です。パフォーマンスへの影響は中〜大です。古いソフトウェアよりも新しいソフトウェアの方が高いパフォーマンスを発揮します。

  • debug ip packet detail を使用して、パケットに関する情報を収集します。この方法では MAC アドレスが得られますが、パフォーマンスに大きな影響が発生する可能性があります。 この方法では失敗を犯し易く、ルータが使えなくなります。この方法を使用する場合は、ルータが攻撃トラフィックをファースト、自律、または最適のいずれかのモードでスイッチングしていることを確認してください。アクセス リストを使用して、デバッグをほんとうに必要な情報だけに制限します。ローカル ログ バッファにデバッグ情報をログしますが、Telnet セッションとコンソールに対してはデバッグ情報のロギングをオフにします。可能であれば、必要に応じて電源のオン→オフができるように、ルータに物理的に近い位置に人を配置します。

    debug ip packet では、ファースト スイッチングされるパケットに関する情報は表示されない点に注意してください。この情報の取得には clear ip cache の実行が必要です。各 clear コマンドからは、デバッグ出力の 1 つまたは 2 つのパケットが得られます。


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

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


関連情報


Document ID: 13609