- はじめに
- はじめに
- デバイス リストの設定
- ダッシュボードの設定
- RSS フィードの設定
- Startup Wizard の使用
- センサーのセットアップ
- インターフェイスの設定
- ポリシーの設定
- シグニチャの定義
- Custom Signature Wizard の使用
- イベント アクション規則の設定
- 異常検出の設定
- グローバル相関の設定
- SSH および証明書の設定
- Attack Response Controller でのブロッキングとレート制限の設定
- SNMP の設定
- 外部製品インターフェイスの設定
- センサーの管理
- センサーのモニタリング
- イベント モニタリングの設定
- レポートの設定と生成
- センサーへのログイン
- センサーの初期化
- Cisco IPS ソフトウェアについて
- システム イメージのアップグレード、ダウン グレード、およびインストール
- システム アーキテクチャの概要
- シグニチャ エンジンについて
- トラブルシューティングのヒントと手順
- Cisco IPS 7.1 で使用されるオープン ソース ライセンス ファイル
- 用語集
- 索引
Cisco Intrusion Prevention System Manager Express コンフィギュレーション ガイド for IPS 7.1
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年5月28日
章のタイトル： シグニチャ エンジンについて
シグニチャ エンジンについて
（注） IPS SSP を搭載した Cisco ASA 5585-X は、現在、Cisco IPS 7.1 をサポートする唯一のプラットフォームです。他の Cisco IPS センサーは、いずれも現在 IPS 7.1 をサポートしていません。
（注） IPS SSP を搭載した Cisco ASA 5585-X は、ASA 8.2(4.4) 以降および ASA 8.4(2) 以降でサポートされています。ASA 8.3(x) ではサポートされていません。
シグニチャ エンジンについて
シグニチャ エンジンは、Cisco IPS のコンポーネントの 1 つで、特定のカテゴリに属する数多くのシグニチャをサポートするように設計されています。エンジンは、パーサーとインスペクタで構成されています。各エンジンには複数のパラメータがあり、許可される範囲や値が設定されます。
（注） Cisco IPS エンジンで、標準化された正規表現がサポートされています。
Cisco IPS には次のシグニチャ エンジンが含まれています。
•
AIC：Web トラフィックの包括的な分析を行います。AIC エンジンは、HTTP セッションに対してより細かな制御を実行して、HTTP プロトコルの悪用を防ぎます。インスタント メッセージングや GotoMyPC など、指定したポート上でトンネリングを行おうとするアプリケーションに対する管理制御も可能です。また、AIC を使用して FTP トラフィックを調査し、実行中のコマンドを制御することもできます。AIC エンジンには、AIC FTP と AIC HTTP の 2 つがあります。
• Atomic：Atomic エンジンは、複数レベルの選択を使用して 4 つのエンジンに結合されます。1 つのシグニチャの中で、IP + TCP のように、レイヤ 3 とレイヤ 4 の属性を組み合わせることができます。Atomic エンジンでは、標準化された正規表現がサポートされています。Atomic エンジンは次の種類で構成されます。
– Atomic ARP：レイヤ 2 ARP プロトコルを検査します。大半のエンジンはレイヤ 3 IP プロトコルに基づいているため、Atomic ARP エンジンはこの点で異なります。
– Atomic IP Advanced：IPv6 レイヤ 3 および ICMPv6 レイヤ 4 トラフィックを検査します。
– Atomic IP：IP プロトコル パケット、および関連付けられているレイヤ 4 トランスポート プロトコルを検査します。
このエンジンでは、IP ヘッダーおよびレイヤ 4 ヘッダーのフィールドに一致する値を指定でき、正規表現を使用してレイヤ 4 のペイロードを検査できます。
（注） すべての IP パケットは Atomic IP エンジンによって検査されます。このエンジンは、4.x Atomic ICMP、Atomic IP Options、Atomic L3 IP、Atomic TCP、および Atomic UDP エンジンに置き換わります。
– Atomic IPv6：不正な形式の IPv6 トラフィックによって引き起こされる、IOS の 2 つの脆弱性を検出します。
• Fixed：固定の深さまで並行して正規表現一致を実行し、1 つの正規表現テーブルを使用して検査を停止します。Fixed エンジンには、CMP、TCP、および UDP の 3 つの種類があります。
• Flood：ホストおよびネットワークに向けられた ICMP および UDP フラッドを検出します。Flood エンジンには、Flood Host と Flood Net の 2 つの種類があります。
• Meta：スライディング時間間隔内に、関連した方法で発生するイベントを定義します。このエンジンは、パケットではなくイベントを処理します。
• Multi String：1 つのシグニチャに対して複数の文字列を照合することで、レイヤ 4 トランスポート プロトコルとペイロードを検査します。このエンジンは、ストリームベースの TCP と、単一の UDP および ICMP パケットを検査します。
• Normalizer：IP および TCP Normalizer が機能する方法を設定し、IP および TCP Normalizer に関連するシグニチャ イベントに設定を提供します。RFC 準拠を強制できます。
• Service：特定のプロトコルを扱います。Service エンジンは次のプロトコル タイプに分かれています。
– DNS：DNS（TCP および UDP）トラフィックを検査します。
このシグニチャ エンジンには、IOS IPS 用に調整されたプロトコル デコード エンジンが備わっています。このエンジンを使用しようとすると、エラー メッセージが表示されます。
– Generic：カスタム サービスおよびペイロードをデコードし、ネットワーク プロトコルを汎用的に分析します。
– H225：VoIP トラフィックを検査します。ネットワーク管理者が、VoIP ネットワーク宛の SETUP メッセージが有効であり、ポリシーで指定されている範囲内にあることを確認するために役立ちます。また、url-ids、email-ids、および表示情報などのアドレスおよび Q.931 文字列フィールドが特定の長さに準拠し、潜在的な攻撃パターンが含まれていないことを確認するためにも役立ちます。
– HTTP：HTTP トラフィックを検査します。WEBPORTS 変数では、HTTP トラフィックの検査ポートを定義します。
このシグニチャ エンジンには、IOS IPS 用に調整されたプロトコル デコード エンジンが備わっています。このエンジンを使用しようとすると、エラー メッセージが表示されます。
– IDENT：IDENT（クライアントおよびサーバ）トラフィックを検査します。
– MSSQL：Microsoft SQL トラフィックを検査します。
– SMB Advanced：Microsoft SMB パケットと Microsoft DCE/RPC（MSRPC）over SMB パケットを処理します。
（注） SMB エンジンは、SMB Advanced エンジンで置き換えられました。SMB エンジンが IDM、IME、CLI で表示される場合でも、そのシグニチャは廃止されています。つまり、新しいシグニチャには、対応する古いシグニチャの ID を使用して設定された古いパラメータがあります。SMB エンジンで使用していたカスタム シグニチャは、新しい SMB Advanced エンジンを使用して書き直してください。
このシグニチャ エンジンには、IOS IPS 用に調整されたプロトコル デコード エンジンが備わっています。このエンジンを使用しようとすると、エラー メッセージが表示されます。
• State：SMTP などのプロトコル内の文字列のステートフル検索を実行します。State エンジンには、状態遷移を定義するために使用される隠れたコンフィギュレーション ファイルがあるため、シグニチャの更新で新しい状態定義を提供できます。
• String：ICMP、TCP、または UDP プロトコルに基づいて、正規表現文字列を検索します。3 つの String エンジン、String ICMP、String TCP、および String UDP があります。
• String XL：ICMP、TCP、または UDP プロトコルに基づいて、正規表現文字列を検索します。String XL エンジンでは、正規表現アクセラレータ カード向けの最適化された操作が可能です。String エンジンには、String ICMP XL、String TCP XL、String UDP XL の 3 つの種類があります。
（注） 現時点で String XL エンジンと正規表現アクセラレータ カードをサポートしているのは、Cisco ASA 5585-X のみです。
（注） 正規表現アクセラレータ カードは、標準の String エンジンと新しい String XL エンジンの両方で使用されます。ほとんどの標準の String エンジンのシグニチャは、変更することなく、正規表現アクセラレータ カードでコンパイルおよび解析できます。ただし、標準の String エンジンのシグニチャを正規表現アクセラレータ カード向けにコンパイルできない特殊な状況があります。そのような状況では、新しいシグニチャは、正規表現アクセラレータ カードでコンパイルできない String XL エンジンの特定のパラメータを使用して、String XL エンジンで記述されます。String XL エンジンの新しいシグニチャにより、標準の String エンジンの元のシグニチャが廃止されます。
• Sweep：1 つのホスト（ICMP と TCP）、宛先ポート（TCP と UDP）、および 2 つのノード間で RPC 要求を送受信する複数のポートからのスイープを分析します。Sweep エンジンには Sweep と Sweep Other TCP の 2 つの種類があります。
• Traffic Anomaly：TCP、UDP、およびその他のトラフィックのワームを検査します。
• Traffic ICMP：TFN2K、LOKI、DDOS などの非標準プロトコルを分析します。パラメータを設定できるのは 2 つのシグニチャだけです。
• Trojan：BO2K や TFN2K などの標準的でないプロトコルのトラフィックを分析します。Trojan エンジンには、Bo2k、Tfn2k、および UDP の 3 つの種類があります。これらのエンジンには、ユーザが設定できるパラメータはありません。
Master エンジン
Master エンジンは、他のエンジンに対して構造体とメソッドを提供し、設定からの入力とアラート出力を処理します。ここでは、Master エンジンについて説明します。内容は次のとおりです。
• 「アラート頻度」
一般的なパラメータ
次のパラメータは、Master エンジンの一部であり、すべてのシグニチャに適用されます（そのシグニチャ エンジンで意味を持つ場合）。
表 B-1 に、Master エンジンの一般的なパラメータの一覧を示します。
|
|
|
|
|---|---|---|
| （注） エンジン固有のパラメータは、Engine カテゴリの下に表示されます。 | ||
パッシブ OS フィンガープリントと組み合わせることにより、IPS は、指定された攻撃がターゲット システムに該当する可能性が高いかどうかを判定します。 |
AIX |
|
シグニチャを MARS 攻撃カテゴリにマッピングします。1 |
| 1.これは、コンフィギュレーションに設定しアラートで表示できる静的な情報カテゴリです。詳細は MARS のドキュメントを参照してください。 |
無差別モードの特定のアラートのリスク レーティングは、無差別デルタによって引き下げられます。センサーはターゲット システムの属性を認識せず、無差別モードではパケットを拒否できないため、無差別アラートの優先順位を下げ（低いリスク レーティングに基づきます）、よりリスク レーティングが高いアラートに管理者が注目できるようにすることは有用です。インライン モードでは、センサーで攻撃パケットを拒否し、ターゲット ホストに攻撃パケットが到達しないようにできるため、ターゲットに脆弱性があるかどうかは問題になりません。攻撃はネットワーク上で許可されなかったため、IPS によりリスク レーティングから差し引かれません。サービス、OS、またはアプリケーション固有でないシグニチャの無差別デルタは 0 になります。シグニチャが OS、サービス、またはアプリケーション固有である場合、無差別デルタは、各カテゴリの 5 ポイントから計算された 5、10、または 15 になります。
シスコのシグニチャ チームは、obsoletes フィールドを使用して、新しくより適切なシグニチャで置き換えられた、廃止された古いシグニチャを示したり、エンジンのより優れたインスタンスが利用可能になったときに、エンジン内のディセーブルになったシグニチャを示します。たとえば、一部の String XL ハードウェア アクセラレーション シグニチャにより、String エンジンで定義されていた相当するシグニチャが置き換えられています。
シグニチャの脆弱 OS 設定とパッシブ OS フィンガープリントを組み合わせることで、IPS により特定の攻撃がターゲット システムに該当するかどうかを判定できます。攻撃が該当することがわかった場合、得られたアラートのリスク レーティング値が引き上げられます。一般にパッシブ OS フィンガープリント リストにエントリがないことが原因で、該当するかどうかが不明な場合、リスク レーティングは変更されません。パッシブ OS フィンガープリント エントリがあり、シグニチャの脆弱 OS 設定に一致しない場合、リスク レーティング値は引き下げられます。リスク レーティングの引き上げまたは引き下げ幅のデフォルト値は、+/- 10 ポイントです。
• 無差別モードの詳細については、「無差別モード」を参照してください。
• パッシブ OS フィンガープリントの詳細については、「OS ID の設定」を参照してください。
アラート頻度
アラート頻度パラメータの目的は、stick などの IDS DoS ツールに対抗するために、イベント ストアに書き込まれるアラートの量を削減することです。Fire All、Fire Once、Summarize、および Global Summarize という 4 つのモードがあります。サマリー モードは、現在のアラート量に応じて動的に変わります。たとえば、シグニチャを [Fire All] に設定できますが、一定のしきい値に達するとサマライズが開始されます。
表 B-2 にアラート頻度パラメータの一覧を示します。
|
|
|
|
|---|---|---|
イベント アクション
（注） 以下のイベント アクションのほとんどは、特定のエンジンに適していない場合を除き、各シグニチャ エンジンに属します。
以下のイベント アクション パラメータは、各シグニチャ エンジンに属します（そのシグニチャ エンジンにとって意味がある場合）。
– Product Alert：アラートをイベント ストアに書き込みます。
– Produce Verbose Alert：エンコード ダンプ（切り捨てられている可能性あり）を、アラートに含めます。
– Log Attacker Packets：攻撃者のアドレスが格納されたパケットの IP ロギングを開始し、アラートを送信します。
– Log Victim Packets：攻撃対象のアドレスが格納されたパケットの IP ロギングを開始し、アラートを送信します。
– Log Attacker/Victim Pair Packets：（インライン モードのみ）攻撃者と攻撃対象のアドレス ペアが格納されたパケットの IP ロギングを開始します。
– Request SNMP Trap：NotificationApp に、SNMP 通知を実行するための要求を送信します。
– Deny Packet Inline：（インライン モードのみ）このパケットを送信しません。
（注） Deny Packet Inline のイベント アクション オーバーライドは、保護されているため削除できません。そのオーバーライドを使用しない場合は、ディセーブルにします。
– Deny Connection Inline：（インライン モードのみ）このパケットと将来のパケットを TCP フロー上で送信しません。
– Deny Attacker Victim Pair Inline：（インライン モードのみ）指定された期間、この攻撃者と攻撃対象のアドレスのペアについては、現在のパケットおよび将来のパケットを送信しません。
– Deny Attacker Service Pair Inline：（インライン モードのみ）指定された期間、この攻撃者のアドレスと攻撃対象のポートのペアについては、現在のパケットおよび将来のパケットを送信しません。
– Deny Attacker Inline：（インライン モードのみ）指定された期間、この攻撃者のアドレスからの現在のパケットおよび将来のパケットを送信しません。
（注） これは最も厳しい拒否アクションです。単一の攻撃者アドレスからの現在および将来のパケットが拒否されます。各拒否アドレスは、拒否が開始される原因となった最初のイベントから X 秒間でタイムアウトします。X は管理者が設定した秒数です。すべての拒否攻撃者エントリをクリアするには、[Monitoring] > [Properties] > [Denied Attackers] > [Clear List] の順に選択します。これにより、そのアドレスがネットワーク上で元のとおり許可されます。
– Modify Packet Inline：（インライン モードのみ）エンドポイントによるパケットの処理に関するあいまいさを取り除くために、パケット データを変更します。
（注） Modify Packet Inline は、Normalizer Engine の一部です。これは、パケットをスクラブし、不正チェックサム、範囲外の値、その他の RFC 違反など、不規則な問題を修正します。
（注） IPv6 は、イベント アクション[Request Block Host]、[Request Block Connection]、[Request Rate Limit] をサポートしません。
– [Request Block Connection]：ARC に対してこの接続をブロックするよう要求します。
– [Request Block Host]：ARC に対してこの攻撃者ホストをブロックするよう要求します。
– [Request Rate Limit]：ARC に対してレート制限を実行するよう要求します。
– [Reset TCP Connection]：TCP リセットを送信し、TCP フローを乗っ取って終了させます。
Deny Packet Inline がアクションとして設定されているシグニチャや、Deny Packet Inline をアクションとして追加するイベント アクション オーバーライドでは、次のアクションを実行できます。
Deny Packet Inline アクションは、アラート内のドロップされたパケット アクションとして表現されます。Deny Packet Inline が TCP 接続に対して発生した場合、Deny Connection Inline アクションに自動的にアップグレードされ、アラート内で拒否されたフローとして認識されます。IPS により 1 個のパケットのみが拒否された場合、TCP はその同じパケットを何度も送信しようとするため、IPS は接続全体を拒否して、再送により成功しないようにします。
また、Deny Connection Inline が発生した場合、IPS は自動的に TCP の一方向リセットを送信します。これは、アラート内に TCP 一方向リセットが送信されたものとして現れます。IPS が接続を拒否するとき、クライアント（一般に攻撃者）とサーバ（一般に攻撃対象）の両方で接続が開かれたままになります。開かれた状態の接続が多すぎると、攻撃対象でリソースの問題が発生します。そのため、IPS は TCP リセットを攻撃対象に送信し、攻撃対象の側（通常はサーバ）で接続を閉じ、攻撃対象のリソースを保護します。また、フェールオーバーを防ぎ、他のネットワーク パスに接続がフェールオーバーして攻撃対象に到達するのを許してしまわないようにします。攻撃者の側は開かれたままになり、そこからのすべてのトラフィックが拒否されます。
正規表現の構文
正規表現（Regex）は、テキストを記述する手段として、強力で柔軟性のある表記言語です。パターン マッチングでは、正規表現によりあらゆる任意のパターンを簡潔に表記できます。
表 B-3 に、IPS シグニチャの正規表現構文の一覧を示します。
|
|
|
|
|---|---|---|
繰り返し演算子ではいずれの場合も、該当する文字列のうち最も短いものが一致対象となります。一方、それ以外の演算子では、その適用範囲に最大限多くの文字が取り込まれるため、該当する文字列のうち最も長いものが一致対象となります。
表 B-4 は、正規表現のパターンの例を示したものです。
|
|
|
|---|---|
特殊文字
表 B-5 に、正規表現アクセラレータ カードの特殊文字とその 16 進表現の一覧を示します。リテラル文字は正規表現のメタ文字です。これらの文字を検査対象のトラフィックと照合するためには、文字の 16 進表現を使用します。
|
|
|
|---|---|
これらの特殊文字を使用する String XL エンジンの詳細については、「String XL エンジン」を参照してください。
AIC エンジン
Application Inspection and Control（AIC）エンジンは、HTTP Web トラフィックを検査し、FTP コマンドを強制します。ここでは、AIC エンジンとそのパラメータについて説明します。内容は次のとおりです。
AIC エンジンについて
AIC は、Web トラフィックの包括的な分析を行います。HTTP セッションに対してより細かな制御を実行して、HTTP プロトコルの悪用を防ぎます。インスタント メッセージングや GotoMyPC など、指定したポート上でトンネリングを行おうとするアプリケーションに対する管理制御も可能です。P2P やインスタント メッセージの検査とポリシー チェックは、これらのアプリケーションが HTTP 上で動作している場合に可能です。また、AIC は、FTP トラフィックを調査し、実行中のコマンドを制御するための手段も備えています。定義済みのシグニチャをイネーブルまたはディセーブルにしたり、カスタム シグニチャを通じてポリシーを作成できます。
（注） AIC エンジンは、AIC Web ポートで HTTP トラフィックを受信したときに実行されます。トラフィックが Web トラフィックであるものの、AIC Web ポートで受信されなかった場合は、Service HTTP エンジンが実行されます。AIC の検査は、ポートが AIC Web ポートとして設定されており、検査対象のトラフィックが HTTP トラフィックであれば、任意のポートで実行できます。
AIC エンジンのセンサーのパフォーマンス
アプリケーション ポリシー強制は、センサー固有の機能です。悪用、脆弱性、および異常を検査する従来の IPS テクノロジーを基にするのではなく、AIC ポリシー強制は、HTTP および FTP サービス ポリシーを強制するように設計されています。このポリシー強制に必要な検査作業は、従来の IPS 検査作業と比べると非常に負荷が高いものになります。この機能を使用すると、大幅なパフォーマンス低下を招きます。AIC をイネーブルにした場合、センサーの全体的な帯域幅キャパシティが下がります。
AIC ポリシー強制は、IPS のデフォルト設定ではディセーブルになっています。AIC ポリシー強制をアクティブにする場合、関心がある正確なポリシーを慎重に選び、不要なポリシーをディセーブルにすることを強くお勧めします。また、センサーが最大検査容量に達している場合は、センサーがオーバーサブスクライブされるおそれがあるため、この機能を使用しないことをお勧めします。この種のポリシー強制を扱うには、適応型セキュリティ アプライアンス ファイアウォールを使用することをお勧めします。
AIC エンジンのパラメータ
AIC エンジンでは、Web トラフィックを詳細に検査するためのシグニチャが定義されています。また、FTP コマンドを認証および強制するためのシグニチャも定義されています。AIC エンジンには、AIC HTTP と AIC FTP の 2 つがあります。
– メッセージ コンテンツと転送データの種類に基づくコンテンツ制御
– 設定されたポリシーとヘッダーに従ったメッセージ サイズ強制
– トンネリング、P2P、およびインスタント メッセージ強制。
この強制は、正規表現を通じて実行されます。定義済みのシグニチャがありますが、ユーザがリストを拡張できます。
表 B-6 に、AIC HTTP エンジンに固有のパラメータを示します。
表 B-7 に、AIC FTP エンジンに固有のパラメータを示します。
|
|
|
|---|---|
• AIC エンジンのシグニチャの設定手順については、「Application Policy シグニチャの設定」を参照してください。
• カスタム AIC シグニチャの例については、「AIC シグニチャの調整」を参照してください。
• すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
• シグニチャの正規表現構文の一覧については、「正規表現の構文」を参照してください。
Atomic エンジン
Atomic エンジンには、アラートを発生する、単純な単一 パケット条件のシグニチャが含まれています。ここでは、Atomic エンジンについて説明します。内容は次のとおりです。
Atomic ARP エンジン
Atomic ARP エンジンは、レイヤ 2 の基本的な ARP シグニチャを定義し、ARP スプーフィング ツールである dsniff と ettercap に対して高度な検出を実行します。
表 B-8 に、Atomic ARP エンジンに固有のパラメータを示します。
すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Atomic IP Advanced エンジン
ここでは、Atomic IP Advanced エンジンについて説明します。内容は次のとおりです。
• 「Atomic IP Advanced エンジンについて」
Atomic IP Advanced エンジンについて
Atomic IP Advanced エンジンは、IPv6 ヘッダーとその拡張、IPv4 ヘッダーとそのオプション、ICMP、ICMPv6、TCP、および UDP を解析および解釈し、通常でないアクティビティを示す異常を探します。
Atomic IP Advanced エンジンのシグニチャは次のことを実行します。
• 偽造された IP アドレスなど、IP アドレスの異常を検査します
• 限定的な既知の脆弱性についての重大度が高いアラートの起動
• Engine Atomic IP における、IPv6 にも適用可能な IPv6 固有のシグニチャの複製
• IP アドレス、ポート、プロトコル、パケット データからの限定的なデータに基づく、トンネリングされたトラフィックを識別するためのデフォルト シグニチャの提供
最も外側の IP トンネルのみが認識されます。IPv4 トンネルの内部に IPv6 トンネルまたは IPv6 トラフィックが検出された場合、シグニチャによりアラートが起動されます。埋め込みトンネルの中の他のすべての IPv6 トラフィックは検査されません。次のトンネリング方法がサポートされていますが、個別には検出されません。たとえば、ISATAP、6to4、および手動 IPv6 RFC 4213 トンネルは、すべて IPv4 の中の IPv6 として認識され、シグニチャ 1007 によって検出されます。
• 送信元 IP アドレス、宛先 IP アドレス、または IP アドレスのペアによる拒否
• カスタム Atomic IP Advanced シグニチャの例については、「Atomic IP Advanced エンジンのシグニチャの例」を参照してください。
• Atomic IP Advanced エンジンの制限事項の一覧については、「Atomic IP Advanced エンジンの制限事項」を参照してください。
• Atomic IP Advanced エンジンのパラメータの一覧については、「Atomic IP Advanced エンジンのパラメータ」を参照してください。
• すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Atomic IP Advanced エンジンの制限事項
Atomic IP Advanced エンジンには次の制限があります。
• パケットがフラグメント化されており、レイヤ 4 ID が最初のパケットに現れない場合、パケットのレイヤ 4 フィールドを検出できません。
• フラグメントの組み立てがないため、IPv6 によってフラグメント化されたパケットを使用したフロー中のレイヤ 4 攻撃を検出できません。
• トンネリングされたフローを使用した攻撃を検出できません。
• フラグメンテーション ヘッダーについては限定的なチェックが行われます。
• AIM IPS および NME IPS では、IPv6 の機能がサポートされていません。これは、それらがインストールされているルータにより IPv6 データが送信されないためです。IPv6 検査は、IDSM2 上で動作する可能性がありますが、正式にはサポートされていません。管理（コマンドおよび制御）インターフェイス上では IPv6 がサポートされていません。ASA 8.2(1) では、AIP SSM および AIP SSC-5 で IPv6 の機能がサポートされています。ASA 8.2(4) では、IPS SSP により IPv6 の機能がサポートされています。
• 不正な重複ヘッダーがある場合、シグニチャが起動されますが、個々のヘッダーは個別に検査されません。
• 異常検出では IPv6 トラフィックがサポートされておらず、IPv4 トラフィックのみが異常検出プロセッサに渡されます。
• レート制限およびブロッキングは、IPv6 トラフィックではサポートされていません。ブロック アクションまたはレート制限アクションが設定されているシグニチャが IPv6 トラフィックによってトリガーされると、アラートが生成されますが、アクションは実行されません。
• カスタム Atomic IP Advanced シグニチャの例については、「Atomic IP Advanced エンジンのシグニチャの例」を参照してください。
• Atomic IP Advanced エンジンのパラメータの一覧については、「Atomic IP Advanced エンジンのパラメータ」を参照してください。
• すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Atomic IP Advanced エンジンのパラメータ
（注） 各範囲の 2 番目の数は、最初の数と同じかそれより大きいことが必要です。
表 B-9 に、Atomic IP Advanced エンジン固有のパラメータを示します。
|
|
|
|
|---|---|---|
|
|
||
（任意）パケットの L3 の開始前にカプセル化を指定します。2 |
||
攻撃者と攻撃対象のアドレスとポート（送信元および宛先）を、アラート メッセージとアクションで入れ替える場合は [Yes]。入れ替えない場合は [No]（デフォルト）。 |
||
|
|
||
| • |
||
| • |
||
| • |
||
| • |
||
|
|
||
| • |
||
（任意）宛先オプション ヘッダーの検査をイネーブルにします。 • – – – |
||
（任意）IPv6 アドレス オプションをイネーブルにします。 • – – – – – – – |
||
|
|
||
| • |
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
（任意）L4 UDP の長さの不一致の検査をイネーブルにします。 • |
| 2.パケットが GRE、IPIP、IPv4inIPv6、または MPL である場合、センサーは L3 カプセル化ヘッダーとカプセル化ヘッダーをスキップし、すべての検査は 2 番目の L3 から開始されます。カプセル化列挙機能により、エンジンは前の情報を参照し、問題の L3 の前にカプセル化ヘッダーがあるかどうかを確認します。 |
• カスタム Atomic IP Advanced シグニチャの例については、「Atomic IP Advanced エンジンのシグニチャの例」を参照してください。
• Atomic IP Advanced エンジンの制限事項の一覧については、「Atomic IP Advanced エンジンの制限事項」を参照してください。
• すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
• シグニチャの正規表現構文の一覧については、「正規表現の構文」を参照してください。
Atomic IP エンジン
Atomic IP エンジンでは、IP プロトコル ヘッダーおよび関連付けられたレイヤ 4 トランスポート プロトコル（TCP、UDP、および ICMP）とペイロードを検査するシグニチャを定義します。Atomic エンジンでは、複数のパケットにまたがる固定データは保存されません。その代わりに、1 つのパケットの解析を基にしてアラートを起動できます。
表 B-10 に、Atomic IP エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
| • |
||
（任意）L4 UDP の長さの不一致の検査をイネーブルにします。 • |
すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Atomic IPv6 エンジン
Atomic IPv6 エンジンは、不正な形式の IPv6 トラフィックによって引き起こされる IOS の 2 つの脆弱性を検出します。これらの脆弱性は、ルータのクラッシュやその他のセキュリティ上の問題につながることがあります。IOS の脆弱性の 1 つは、複数の先頭フラグメントを処理し、バッファ オーバーフローを引き起こします。もう 1 つの脆弱性は、不正な ICMPv6 ネイバー探索オプションを処理し、これもバッファ オーバーフローを引き起こします。
（注） IPv6 では、IP アドレスのサイズが 32 ビットから 128 ビットに拡大されました。これにより、サポートされるアドレッシング階層が増大し、より多くのノードにアドレスを割り当てることができ、アドレスの自動設定が可能になりました。
8 個の Atomic IPv6 シグニチャがあります。Atomic IPv6 は、次の種類の ネイバー探索プロトコルを検査します。
（注） ホストとルータは、ネイバー探索を使用して、アタッチされたリンクに常駐することがわかっているネイバーのリンク層アドレスを判断し、無効になったキャッシュ値をすばやくパージします。また、ホストはネイバー探索を使用して、ホストに代わってパケットを転送する隣接ルータを検出します。
各ネイバー探索タイプには、1 つ以上の Neighborhood Discovery オプションを設定できます。Atomic IPv6 エンジンは、各オプションの長さが、RFC 2461 で規定されている正規の値に準拠しているかどうかを検査します。オプション結果の長さの違反がある場合、異常な長さが見つかったオプション タイプに対応するアラートが発生します（シグニチャ 1601 ～ 1605）。
（注） Atomic IPv6 シグニチャには、設定すべき固有のパラメータがありません。
表 B-11 に Atomic IPv6 のシグニチャの一覧を示します。
|
|
ID |
|
|
|---|---|---|---|
すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Fixed エンジン
Fixed エンジンでは、複数の正規表現パターンを 1 つのパターン マッチング テーブルに組み合わせ、データ全体で単一の検索が可能です。ICMP、TCP、および UDP プロトコルがサポートされています。最低検査深度に達した場合（1 ～ 100 バイト）、検査が停止します。Fixed エンジンには、Fixed ICMP、Fixed TCP、および Fixed UDP の 3 つの種類があります。
（注） Fixed TCP と Fixed UDP では、Service Ports パラメータが除外ポートとして使用されます。Fixed ICMP では Service Ports パラメータが除外 ICMP タイプとして使用されます。
表 B-12 に、Fixed ICMP エンジンに固有のパラメータを示します。
表 B-13 に、Fixed TCP エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
| • |
||
| • |
||
0 ～ 655353 |
||
攻撃者と攻撃対象のアドレスとポート（送信元および宛先）を、アラート メッセージとアクションで入れ替える場合は [Yes]。入れ替えない場合は [No]（デフォルト）。 |
表 B-14 に、Fixed UDP エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
| • |
||
| • |
||
0 ～ 655354 |
||
攻撃者と攻撃対象のアドレスとポート（送信元および宛先）を、アラート メッセージとアクションで入れ替える場合は [Yes]。入れ替えない場合は [No]（デフォルト）。 |
• シグニチャの正規表現構文の一覧については、「正規表現の構文」を参照してください。
• すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Flood エンジン
Flood エンジンは、複数のパケットを単一のホストまたはネットワークに送信しているホストまたはネットワークをモニタするシグニチャを定義します。たとえば、攻撃対象ホスト宛に、秒あたり 150 個以上のパケット（特定の種類）が検出された場合にアラートを起動するシグニチャを作成できます。Flood エンジンには、Flood Host と Flood Net の 2 つの種類があります。
表 B-15 に、Flood Host エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
0 ～ 655355 |
||
0 ～ 655356 |
||
0 ～ 655357 |
| 5.レートがこの数値（パケット/秒）よりも大きい場合にアラートが起動されます。 |
表 B-16 に、Flood Net エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
0 ～ 655358 |
||
すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Meta エンジン
Meta エンジンでは、スライディング時間間隔内に、関連した方法で発生するイベントを定義します。このエンジンは、パケットではなくイベントを処理します。シグニチャ イベントが生成されると、Meta エンジンはシグニチャ イベントを検査して、1 つ以上の Meta 定義に一致するかどうかを判定します。Meta エンジンは、すべてのイベント要件が満たされるとシグニチャ イベントを生成します。
すべてのシグニチャ イベントは、シグニチャ イベント アクション プロセッサによって Meta エンジンに渡されます。シグニチャ イベント アクション プロセッサは、最小ヒット数オプションを処理してからイベントを渡します。Meta エンジンがコンポーネント イベントを処理してから、サマライズおよびイベント アクションは処理されます。
表 B-17 に、Meta エンジンに固有のパラメータを示します。
• カスタム Meta エンジンのシグニチャの例については、「Meta エンジンのシグニチャの例」を参照してください。
• すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Multi String エンジン
Multi String エンジンでは、レイヤ 4 トランスポート プロトコル（ICMP、TCP、および UDP）のペイロードを検査するシグニチャを定義します。この検査は、1 つのシグニチャに対して複数の文字列を照合して行います。シグニチャを起動するために一致する必要がある一連の正規表現パターンを指定できます。たとえば、UDP サービスで regex 1 とそれに続く regex 2 を検索するシグニチャを定義できます。UDP および TCP の場合は、ポート番号と方向を指定できます。1 つの送信元ポート、1 つの宛先ポート、または両方のポートを指定できます。文字列の照合は両方向で実行されます。
Multi String エンジンは、複数の正規表現パターンを指定する必要がある場合に使用します。それ以外の場合は、String ICMP、String TCP、または String UDP エンジンを使用して、これらのプロトコルのいずれかに対応した単一の正規表現パターンを指定できます。
表 B-18 に、Multi String エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
| • |
||
| • • • |
0 ～ 65535 10 |
|
この正規表現文字列と直前の正規表現文字列との間、またはストリームやパケットの先頭から（リスト内の最初のエントリである場合）、空ける必要のあるバイト数。 |
||
この正規表現文字列と直前の正規表現文字列との間、またはストリームやパケットの先頭から（リスト内の最初のエントリである場合）、空ける必要のある最小バイト数。 |
||
攻撃者と攻撃対象のアドレスとポート（送信元および宛先）を、アラート メッセージとアクションで入れ替える場合は [Yes]。入れ替えない場合は [No]（デフォルト）。 |
• シグニチャの正規表現構文の一覧については、「正規表現の構文」を参照してください。
• すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Normalizer エンジン
Normalizer エンジンは、IP フラグメンテーションと TCP 正規化を扱います。ここでは、Normalizer エンジンについて説明します。内容は次のとおりです。
Normalizer エンジンについて
（注） IPS SSP を搭載した Cisco ASA 5585-X では、正規化がサポートされていません。
（注） Normalizer エンジンには、カスタム シグニチャを追加できません。既存のシグニチャを調整することはできます。
Normalizer エンジンは IP フラグメントの再構築と TCP ストリームの再構築を扱います。Normalizer エンジンを使用すると、センサーが同時に追跡を試みるフラグメントの最大数など、システム リソースの使用量について制限を設定できます。無差別モードのセンサーは、違反時にアラートを報告します。インライン モードのセンサーは、Produce Alert、Deny Packet Inline、および Modify Packet Inline など、イベント アクション パラメータで指定されたアクションを実行します。
IP データグラムの意図的または意図しないフラグメンテーションにより、悪用が隠れてしまい、検出が困難になったり不可能になったりすることがあります。フラグメンテーションは、ファイアウォールやルータで実行されるアクセス コントロール ポリシーを回避するために使用されることもあります。オペレーティング システムごとに、異なる方法を使用してフラグメント化されたデータグラムをキューに格納してディスパッチします。エンド ホストがデータグラムを再構築できる、考えられるすべての方法をセンサーで確認する必要がある場合、センサーは DoS 攻撃に脆弱になります。フラグメント化されたすべてのデータグラムをインラインで再構築し、完成したパケットのみを転送し、必要に応じてデータグラムを再度フラグメント化することで、これを避けることができます。IP Fragmentation Normalization ユニットはこの機能を実行します。
意図的または自然の TCP セッションのセグメント化を通じて、一部の攻撃クラスが隠れることがあります。ポリシーの強制が、偽陽性または偽陰性なく行われるようにするため、2 つの TCP エンドポイントの状態を追跡し、実際のホスト エンドポイントで実際に処理されるデータのみを通過させる必要があります。TCP ストリームの重なりが起きる可能性がありますが、TCP セグメントの再送以外では非常にまれです。TCP セッションの上書きが起こらないことが必要です。上書きが起きる場合、誰かが意図的にセキュリティ ポリシーを回避しようとしているか、TCP スタックの実装が壊れています。両方のエンドポイントの状態に関する完全な情報を維持することは、センサーが TCP プロキシとして動作しない限り不可能です。センサーが TCP プロキシとして動作する代わりに、セグメントが適切に順序付けされ、Normalizer エンジンは回避や攻撃に関連する異常なパケットを探します。
Normalizer エンジンは、IPv6 フラグメントを再構築し、他のエンジンやプロセッサでの検査やアクション用に、再構築したバッファを転送することができます。IPv4 と IPv6 では次の違いがあります。
• Normalizer エンジンのシグニチャの Modify Packet Inline は、IPv6 データグラムに対しては適用されません。
• シグニチャ 1206（IP Fragment Too Small）は、IPv6 データグラムに対しては起動されません。Atomic IP Advanced エンジンのシグニチャ 1741 は、小さすぎる IPv6 フラグメントに対して起動されます。
• シグニチャ 1202 は、IPv6 で、Maximum Datagram Size を超えた追加の 48 バイトを許可します。これは、IPv6 ヘッダー フィールドが長いためです。
Normalizer エンジンのシグニチャの設定手順については、「IP フラグメント再構成のシグニチャの設定」および「TCP ストリーム再構成シグニチャの設定」を参照してください。
Normalizer エンジンのパラメータ
表 B-19 に、Normalizer エンジンに固有のパラメータを示します。
|
|
|
|---|---|
すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Service エンジン
ここでは、Service エンジンについて説明します。内容は次のとおりです。
Service エンジンについて
Service エンジンでは、2 つのホスト間のレイヤ 5+ トラフィックの解析が行われます。永続的データを追跡する 1 対 1 のシグニチャがあります。エンジンは、ライブ サービスと類似の方法でレイヤ 5+ ペイロードを解析します。
各 Service エンジンには共通した特性がある一方、個々のエンジンには検査対象のサービスに関する固有の情報が保持されます。String エンジンの使用が不適切であるか望ましくない場合には、Service エンジンによって、アルゴリズムに特化した汎用文字列エンジンの機能が補完されます。
Service DNS エンジン
Service DNS エンジンは、高度な DNS デコードを行います。これには、反回避技術（複数のジャンプの追跡など）が含まれます。長さ、命令コード、文字列などの多数のパラメータがあります。Service DNS エンジンは、2 つのプロトコルに対応するインスペクタであり、TCP ポート 53 と UDP ポート 53 の両方で稼動します。TCP の場合はストリームを使用し、UDP の場合はクワッドを使用します。
表 B-20 に、Service DNS エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Service FTP エンジン
Service FTP エンジンは、FTP の port コマンドのデコードに特化しており、無効な port コマンドと PASV ポートのスプーフィングを捕捉します。このエンジンは、String エンジンが検出に適していない場合のギャップを埋めます。パラメータはいずれも Boolean 型で、 port コマンドのデコードおけるさまざまなエラー トラップ条件へのマッピングに使用します。Service FTP エンジンは、TCP ポート 20 および 21 で稼動します。ポート 20 はデータ用であり、Service FTP エンジンはこのポートに対して検査を行いません。Service FTP エンジンは、ポート 21 の制御トランザクションを検査します。
表 B-21 に、Service FTP エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
| • |
Invalid Address in PORT Command |
|
0 ～ 6553511 |
||
攻撃者と攻撃対象のアドレスとポート（送信元および宛先）を、アラート メッセージとアクションで入れ替える場合は [Yes]。入れ替えない場合は [No]（デフォルト）。 |
すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Service Generic エンジン
Service Generic エンジンを使用すると、設定ファイルでシグニチャを更新するだけで、プログラム シグニチャを発行できます。このエンジンには、設定ファイルで定義されている簡易マシンおよびアセンブリ言語が含まれています。このエンジンは、仮想マシンを介して（アセンブリ言語から導出された）マシン コードを実行します。仮想マシンは、命令を処理し、パケットから重要な情報を引き出して、マシン コードに指定されている比較および演算を実行します。このエンジンは、String エンジンと State エンジンを補足する迅速なシグニチャ応答エンジンとして設計されています。
新機能により、Service Generic エンジンと拡張命令に正規表現パラメータが追加されます。Service Generic エンジンでは、パケットを解析するために作成されたミニプログラムに基づいてトラフィックを解析できます。これらのミニプログラムは、パケットを分析し特定の条件を探すコマンドで構成されます。
（注） Service Generic エンジンを使用してカスタム シグニチャを作成することはできません。
表 B-22 に、Service Generic エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
攻撃者と攻撃対象のアドレスとポート（送信元および宛先）を、アラート メッセージとアクションで入れ替える場合は [Yes]。入れ替えない場合は [No]（デフォルト）。 |
• シグニチャの正規表現構文の一覧については、「正規表現の構文」を参照してください。
• すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Service H225 エンジン
Service H225 エンジンは、多数のサブプロトコルで構成され H.323 スイートに含まれている H225.0 プロトコルを分析します。H.323 はプロトコルと他の標準を集めたものであり、パケットベース ネットワーク上での会議が可能になります。
H.225.0 コール シグナリングおよびステータス メッセージは H.323 コール セットアップの一部です。ゲートキーパーやエンドポイント ターミナルなど、ネットワーク内のさまざまな H.323 エンティティが H.225.0 プロトコル スタックの実装を実行します。Service H225 エンジンは H225.0 プロトコルを分析し、複数の H.323 ゲートキーパー、VoIP ゲートウェイ、およびエンドポイント ターミナルに対する攻撃を検査します。また、TCP PDU 上で交換されるコール シグナリング メッセージのディープ パケット インスペクション機能が提供されます。Service H225 エンジンは、H.225.0 プロトコルを分析し、無効な H.255.0 メッセージや、これらのメッセージ内のさまざまなプロトコルフ ィールド上の悪用およびオーバーフロー攻撃を検査します。
H.225.0 コール シグナリング メッセージは Q.931 プロトコルを基にしています。コール元エンドポイントは、コール先のエンドポイントに Q.931 セットアップ メッセージを送信します。そのアドレスは、アドミッション手順や何らかの検索手段で取得されます。コール先エンドポイントは、Q.931 接続メッセージを送信して接続を受け付けるか、接続を拒否します。H.225.0 の接続が確立されると、コール元またはコール先のエンドポイントが H.245 アドレスを渡します。このアドレスは、制御プロトコル（H.245）チャネルを確立するために使用されます。
特に重要なのは、SETUP コール シグナリング メッセージです。これは、このメッセージがコール セットアップの中で H.323 エンティティ間で交換される最初のメッセージであるためです。SETUP メッセージは、コール シグナリング メッセージの一般的なフィールドの多くを使用しており、確度の高い攻撃にさらされた実装は、ほとんど SETUP メッセージのセキュリティ チェックに失敗します。そのため、H.225.0 SETUP メッセージの正当性をチェックし、ネットワークの境界でチェックを強制することはきわめて重要です。
Service H225 エンジンには、H225 SETUP セットアップ メッセージの TPKT の検証、Q.931 プロトコルの検証、および ASN.1PER 検証のための組み込みシグニチャがあります。ASN.1 はデータ構造を記述するための表記法です。PER では異なるスタイルの符号化が使用されます。PER は、データ タイプに基づく符号化に特化して、はるかにコンパクトな表現を生成します。
Q.931 および TPKT の長さシグニチャの調整、H.225 プロトコル フィールドに対するより詳細なシグニチャの追加と適用、Q.931 または H.225 プロトコルの単一のフィールドの複数パターン検索シグニチャの適用を行うことができます。
Service H225 エンジンでは次の機能がサポートされています。
• Q.931 情報要素におけるテキスト フィールドの正規表現シグニチャ
• 正規表現と長さの両方について、ULR-ID、E-mail-ID、h323-id などの設定シグニチャ。
TPKT シグニチャと ASN.1 シグニチャの数は固定です。これらのタイプについてはカスタム シグニチャを作成できません。TPKT シグニチャでは、長さシグニチャの値の範囲のみを変更します。ASN.1 のパラメータは変更できません。Q.931 シグニチャでは、テキスト フィールドに対する新しい正規表現を追加できます。SETUP シグニチャでは、SETUP メッセージのさまざまなフィールドに対する長さおよび正規表現チェックのシグニチャを追加できます。
表 B-23 に、Service H225 エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
（任意）フィールド名の使用をイネーブルにします。SETUP および Q.931 メッセージ タイプのみで有効です。このシグニチャを適用するフィールド名のドット付き表記を指定します。 |
||
（任意）ASN と TPKT 固有のエラー、および固定マッピングを持つその他のエラーで使用する無効なパケット インデックスをイネーブルにします。 |
||
0 ～ 6553512 |
||
攻撃者と攻撃対象のアドレスとポート（送信元および宛先）を、アラート メッセージとアクションで入れ替える場合は [Yes]。入れ替えない場合は [No]（デフォルト）。 |
• シグニチャの正規表現構文の一覧については、「正規表現の構文」を参照してください。
• すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Service HTTP エンジン
Service HTTP エンジンは、サービス固有文字列に基づくパターン照合インスペクション エンジンです。HTTP プロトコルは、今日のネットワークで最もよく使用されているプロトコルの 1 つです。また、最も長い前処理時間を必要とし、システムの全体的なパフォーマンスにとって必須の検査を必要とするシグニチャの数も最も多くあります。
Service HTTP エンジンでは、複数のパターンを 1 つのパターン マッチング テーブルにまとめることでデータ内の検索を一度に実行できる正規表現ライブラリが使用されます。このエンジンは、Web サービスのみに向けられたトラフィック、つまり HTTP 要求を検索します。このエンジンでリターン トラフィックを検査することはできません。このエンジンでは、各シグニチャが対象とする個別の Web ポートを指定できます。
HTTP 解読とは、符号化された文字を ASCII 対応文字に正規化することによって、HTTP メッセージをデコードするプロセスです。このプロセスは、ASCII 正規化と呼ばれることもあります。
HTTP パケットを検査するには、あらかじめそのデータを、ターゲット システムでのデータ処理時に表示されるものと同じデータ表現として解読または正規化しておく必要があります。また、ホスト ターゲット タイプごとにカスタマイズされたデコード方式を用意することが推奨されます。そのためには、ターゲット上で動作しているオペレーティング システムおよび Web サーバのバージョンを確認する必要があります。Service HTTP エンジンには、Microsoft IIS Web サーバ用のデフォルトの解読動作が用意されています。
表 B-24 に、Service HTTP エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
（任意）特定の正規表現の [Arguments] フィールドの検索をイネーブルにします。 • |
||
（任意）特定の正規表現の [Header] フィールドの検索をイネーブルにします。 |
||
（任意）特定の正規表現の [Request] フィールドの検索をイネーブルにします。 • |
||
（任意）[HTTP URI] フィールドで検索する正規表現。[URI] フィールドは、HTTP メソッド（たとえば、GET）の後ろで、最初の CRLF の前まで定義されます。正規表現は保護されています。つまり、値は変更できません。 |
[/¥¥][a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z][.]jpeg |
|
0 ～ 6553513 |
||
攻撃者と攻撃対象のアドレスとポート（送信元および宛先）を、アラート メッセージとアクションで入れ替える場合は [Yes]。入れ替えない場合は [No]（デフォルト）。 |
• Service HTTP のカスタム シグニチャの例については、「Service HTTP エンジンのシグニチャの例」を参照してください。
• すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
• シグニチャの正規表現構文の一覧については、「正規表現の構文」を参照してください。
Service IDENT エンジン
Service IDENT エンジンでは、TCP ポート 113 のトラフィックの検査が行われます。このエンジンは、基本的なデコードを実行できるほか、データ長のオーバーフローを指定するためのパラメータを備えています。たとえば、コンピュータ A のユーザまたはプログラムがコンピュータ B のアイデンティティ要求を実行する場合、A と B の間の接続のユーザのアイデンティティのみを問い合わせることができます。B 上の ident サーバは、TCP ポート 113 上で接続をリッスンします。A 上のクライアントは接続を確立し、接続で使用されている A および B 上のポート番号を送信することで、識別情報が必要な接続を指定します。B 上のサーバはその接続を使用しているユーザを特定し、そのユーザの名前を示す文字列を A に応答します。Service IDENT エンジンでは、TCP ポート 113 で ident の悪用が検査されます。
表 B-25 に、Service IDENT エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
| • |
||
0 ～ 6553514 |
||
すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Service MSRPC エンジン
Service MSRPC エンジンは、MSRPC パケットを処理します。MSRPC は、ネットワーク環境での複数のコンピュータ間の連携処理と、使用されるアプリケーション ソフトウェアに対応しています。MSRPC はトランザクションベースのプロトコルです。チャネルを確立し、処理要求および応答を受け渡す一連の通信が発生します。
MSRPC は、ISO レイヤ 5 および 6 のプロトコルで、UDP、TCP、SMB などの他のトランスポート プロトコルの上の階層となります。MSRPC エンジンには、MSRPC PDU のフラグメンテーションと再構成を処理する機能も含まれます。
この通信チャネルは、最近の Windows NT、Windows 2000、および Window XP のセキュリティ脆弱性の原因となっています。Service MSRPC エンジンは、最も一般的なトランザクション タイプについて DCE および RPC プロトコルをデコードするだけです。
表 B-26 に、Service MSRPC エンジンに固有のパラメータを示します。
• シグニチャの正規表現構文の一覧については、「正規表現の構文」を参照してください。
• すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Service MSSQL エンジン
Service MSSQL エンジンは、Microsoft SQL サーバによって使用されるプロトコルを検査します。このエンジンには 1 つの MSSQL シグニチャが含まれています。MSSQL サーバへのデフォルトの sa アカウントでのログインの試みを検出した場合にアラートを起動します。ログイン ユーザ名や、パスワードが使用されたかどうかなど、MSSQL プロトコル値に基づいてカスタム シグニチャを追加できます。
表 B-27 に、Service MSSQL エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Service NTP エンジン
Service NTP エンジンは、NTP プロトコルを検査します。このエンジンには、1 つの NTP シグニチャ（NTP readvar オーバーフロー シグニチャ）が含まれます。このシグニチャは、サイズが大きいため NTP サービスでキャプチャできない NTP データが、readvar コマンドに指定されていることを検出した場合に、アラートを起動します。NTP プロトコルの値（モードや制御パケットのサイズなど）に基づいて、シグニチャを調整したり、カスタム シグニチャを作成したりできます。
表 B-28 に、Service NTP エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
| • |
||
すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Service P2P
P2P ネットワークでは、ファイル共有の目的で、同時にクライアントとサーバの両方の機能を果たすノードが使用されます。P2P ネットワークには、著作権が設定された資料が含まれることが多く、企業で使用することは企業ポリシーに違反する場合があります。Service P2P エンジンはそのようなネットワークをモニタし、最適化された TCP および UDP P2P プロトコル識別機能を提供します。Service P2P エンジンには次の特性があります。
• 正規表現ではなくハードコーディングされたシグニチャを通じた高いパフォーマンス
• P2P プロトコルが認識されるか、P2P プロトコルが認識されずに 10 個のパケットが検出された後はトラフィックを無視
P2P シグニチャはハードコーディングされているため、編集可能な唯一のパラメータは Master エンジン パラメータです。
すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Service RPC エンジン
Service RPC エンジンは、RPC プロトコル専用で、反回避戦略としてフル デコードを行います。これにより、フラグメント化されたメッセージ（複数パケット内の 1 つのメッセージ）およびバッチ メッセージ（1 つのパケット内の複数メッセージ）を処理できます。
RPC ポート マッパーは、ポート 111 上で動作します。通常の RPC メッセージは、550 より上位であれば任意のポートで送受信できます。RPC スイープは、TCP ポート スイープと似ていますが、有効な RPC メッセージが送信された場合に一意のポートだけをカウントするという点が異なります。RPC は UDP でも動作します。
表 B-29 に、Service RPC エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
0 ～ 6553515 |
||
| • – |
||
| • |
||
攻撃者と攻撃対象のアドレスとポート（送信元および宛先）を、アラート メッセージとアクションで入れ替える場合は [Yes]。入れ替えない場合は [No]（デフォルト）。 |
• シグニチャの正規表現構文の一覧については、「正規表現の構文」を参照してください。
• すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Service SMB Advanced エンジン
（注） SMB エンジンは、SMB Advanced エンジンで置き換えられました。SMB エンジンが IDM、IME、CLI で表示される場合でも、そのシグニチャは廃止されています。つまり、新しいシグニチャには、対応する古いシグニチャの ID を使用して設定された古いパラメータがあります。SMB エンジンで使用していたカスタム シグニチャは、新しい SMB Advanced エンジンを使用して書き直してください。
Service SMB Advanced エンジンは、Microsoft SMB パケットと Microsoft RPC over SMB パケットを処理します。Service SMB Advanced エンジンは、コネクション型の MSRPC に対し、MSRPC エンジンと同じデコード方法を使用します。ただし、MSRPC パケットは SMB プロトコル上でやりとりされる必要があります。Service SMB Advanced エンジンは、TCP ポート 139 および 445 上での MSRPC over SMB をサポートしています。MSRPC エンジンの、コネクション型 DCS/RPC コードのコピーを使用しています。
表 B-30 に、Service SMB Advanced エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
0 ～ 65535 |
||
| • |
||
| • |
||
（任意）MSRPC over SMB をイネーブルにします。 • |
||
| • |
||
| • |
||
| • |
||
攻撃者と攻撃対象のアドレスとポート（送信元および宛先）を、アラート メッセージとアクションで入れ替える場合は [Yes]。入れ替えない場合は [No]（デフォルト）。 |
• シグニチャの正規表現構文の一覧については、「正規表現の構文」を参照してください。
• すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Service SNMP エンジン
Service SNMP エンジンは、ポート 161 宛のすべての SNMP パケットを検査します。特定のコミュニティ名とオブジェクト ID に基づいて、SNMP シグニチャを調整したり、カスタム SNMP シグニチャを作成したりできます。
コミュニティ名とオブジェクト ID を照合するために、文字列比較や正規表現演算を使用する代わりに、整数を使用してすべての比較を実行し、プロトコル デコードを高速化しストレージ要件を削減します。
表 B-31 に、Service SNMP エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
| • – |
すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Service SSH エンジン
Service SSH エンジンは、ポート 22 の SSH トラフィックに対して使用します。SSH セッションのセットアップを除いてすべてが暗号化されるため、Service SSH エンジンではセットアップのフィールドだけがモニタされます。SSH には 2 つのデフォルト シグニチャがあります。これらのシグニチャを調整することはできますが、カスタム シグニチャは作成できません。
表 B-32 に、Service SSH エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
| • |
||
0 ～ 6553519 |
||
すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Service TNS エンジン
Service TNS エンジンでは、TNS プロトコルが検査されます。TNS では、データベース アプリケーションに対し、すべての業界標準ネットワーク プロトコルに対する単一かつ共通のインターフェイスが提供されます。TNS により、アプリケーションは、異なるプロトコルを使用して他のデータベース アプリケーションにネットワークから接続できます。デフォルトの TNS リスナー ポートは TCP 1521 です。TNS では、クライアントを別のホストまたは別の TCP ポートにリダイレクトするための REDIRECT フレームもサポートされています。REDIRECT パケットをサポートするため、TNS エンジンはすべての TCP ポート上でリッスンを行い、高速な TNS フレーム ヘッダー検証ルーチンを使用して非 TNS ストリームを無視します。
表 B-33 に、Service TNS エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
| • – |
||
• シグニチャの正規表現構文の一覧については、「正規表現の構文」を参照してください。
• すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
State エンジン
State エンジンは、TCP ストリームのステートベースおよび正規表現ベースのパターン検査を行います。State エンジンは何かの状態を保存するデバイスで、入力があるたびに、その内容に基づいてある状態から別の状態に移行したり、処理や出力を行ったりできます。ステート マシンは、出力やアラートを発生させる特定のイベントを記述するために使用されます。State エンジンには、SMTP、シスコ ログイン、および LPR フォーマット ストリングの 3 つのステート マシンがあります。
表 B-34 に、State エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
LPR フォーマット ストリングの脆弱性を検査するステート マシンを指定します。 |
||
0 ～ 6553520 |
||
| • |
||
| • |
||
| • |
||
攻撃者と攻撃対象のアドレスとポート（送信元および宛先）を、アラート メッセージとアクションで入れ替える場合は [Yes]。入れ替えない場合は [No]（デフォルト）。 |
すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
String エンジン
String エンジンは、ICMP、TCP、および UDP の各プロトコルを対象とした、汎用ベースのパターン マッチング インスペクション エンジンです。String エンジンでは、複数のパターンを 1 つのパターン マッチング テーブルにまとめることでデータ内の検索を一度に実行できる正規表現エンジンが使用されます。3 つの String エンジン、String ICMP、String TCP、および String UDP があります。
表 B-35 に、String ICMP エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
0 ～ 1821 |
||
| • |
||
攻撃者と攻撃対象のアドレスとポート（送信元および宛先）を、アラート メッセージとアクションで入れ替える場合は [Yes]。入れ替えない場合は [No]（デフォルト）。 |
表 B-36 に、String TCP エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
0 ～ 6553522 |
||
| • |
||
パターンを検索する前に、データから Telnet オプション文字を削除します。23 |
||
攻撃者と攻撃対象のアドレスとポート（送信元および宛先）を、アラート メッセージとアクションで入れ替える場合は [Yes]。入れ替えない場合は [No]（デフォルト）。 |
表 B-37 に、String UDP エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
0 ～ 6553524 |
||
| • |
||
攻撃者と攻撃対象のアドレスとポート（送信元および宛先）を、アラート メッセージとアクションで入れ替える場合は [Yes]。入れ替えない場合は [No]（デフォルト）。 |
• カスタム String エンジン シグニチャの例については、「String TCP エンジンのシグニチャの例」を参照してください。
• すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
String XL エンジン
String XL エンジンは、他の String エンジンと同様に、シグニチャあたり 1 つの文字列のマッチング機能を備えていますが、異なる正規表現構文が使用されます。String TCP XL エンジンはストリームベースであり、クロスパケット インスペクション（XPI）が使用されます。パケットは適切な順番に並んでいる必要があります。UDP と ICMP はどちらもステートレスであるため、String UDP XL および String ICMP XL シグニチャ エンジンはセッション状態を割り当てる必要がなく、各パケットは個別に検索されます。
正規表現アクセラレータ カードは、標準の String エンジンと新しい String XL エンジンの両方で使用されます。ほとんどの標準の String エンジンのシグニチャは、変更することなく、正規表現アクセラレータ カードでコンパイルおよび解析できます。ただし、標準の String エンジンのシグニチャを正規表現アクセラレータ カード向けにコンパイルできない特殊な状況があります。そのような状況では、新しいシグニチャは、正規表現アクセラレータ カードでコンパイルできない String XL エンジンの特定のパラメータを使用して、String XL エンジンで記述されます。String XL エンジンの新しいシグニチャにより、標準の String エンジンの元のシグニチャが廃止されます。
正規表現構文または raw 表現構文を使用できますが、raw 表現構文はエキスパート ユーザ専用です。String XL シグニチャを設定するときは、raw 表現構文を使用するのでない限り、[Regex String] パラメータが必要です。
（注） Raw Regex は raw モードの処理で使用される正規表現構文です。これはエキスパート モード専用であり、Cisco IPS シグニチャ開発チームや、Cisco IPS シグニチャ開発チームの監督下にある人のみが使用することを目的としています。String XL シグニチャは通常の正規表現または raw 正規表現のどちらかで設定できます。
表 B-38 に、String XL エンジン（TCP、ICMP、および UDP）に固有のパラメータを示します。
|
|
|
|
|---|---|---|
[Yes] に設定すると、¥n を含む [¥x00-¥xFF] をマッチングされます。[No] に設定すると、¥n を除く範囲 [¥x00-¥xFF] のすべてにマッチングされます。 |
||
パケットの最後で他のすべての条件が満たされているものの、パケットの最後が見つからない場合、最小を超えた場合に一致が報告されます。 |
||
0 ～ 1825 |
||
[Yes] に設定された場合、Min Match Length、Max Match Length、Min Whole Length、Max Whole Length、Dot All、UTF8、No Case、Stingy、およびEnd Optional は、正規表現文字列を再フォーマットするために使用されません。 （注） [Raw Regex] を使用すると、raw 構文で正規表現文字列を入力でき、変換されることはありません。 |
||
| （注） このパラメータは、[Max Stream Length] が設定されている場合は必須です。[Max Stream Length] が設定されている場合は、[Regex String] を設定しないでください。 | ||
（必須）ターゲット サービスが常駐する、カンマ区切りのポートのリストまたはポート範囲。 （注） このパラメータは、String XL TCP および String XL UDP シグニチャ エンジンでは必須です。String XL ICMP シグニチャ エンジンでは使用できません。 |
0 ～ 6553526 |
|
| • |
||
| • |
||
| • |
||
| • |
||
| • |
||
| • |
||
| （注） [Stingy] は必ず [Min Match Length] と組み合わせて使用します。単独で使用した場合は無視されます。 | ||
パターンを検索する前に、データから Telnet オプション文字を削除します。27 |
||
攻撃者と攻撃対象のアドレスとポート（送信元および宛先）を、アラート メッセージとアクションで入れ替える場合は [Yes]。入れ替えない場合は [No]（デフォルト）。 |
||
| 25.範囲の 2 番目の数は、最初の数以上である必要があります。 |
String XL エンジンには [End Optional] および [Specify Max Stream Length] パラメータがありますが、IPS 7.1(1)E4 ではディセーブルになっています。これらのパラメータを設定しようとするとエラー メッセージが表示されます。たとえば、[Specify Max Stream Length] を使用してシグニチャを作成し、保存しようとすると、次のエラー メッセージが表示されます。
• シグニチャの正規表現構文の一覧については、「正規表現の構文」を参照してください。
• すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
• String XL エンジンの一致オフセット シグニチャの例については、「String XL エンジンの Match Offset シグニチャの例」を参照してください。
• String XL エンジンの最小一致長シグニチャの例については、「String XL エンジンの最小一致長シグニチャの例」を参照してください。
Sweep エンジン
ここでは、Sweep エンジンについて説明します。内容は次のとおりです。
Sweep エンジン
Sweep エンジンでは、2 つのホスト間または 1 つのホストから多数のホストへのトラフィックを分析します。既存のシグニチャを調整したり、カスタム シグニチャを作成したりすることができます。Sweep エンジンには、ICMP、UDP、および TCP のプロトコル固有パラメータがあります。
Sweep エンジンのアラート条件は、最終的に一意のパラメータのカウントに依存します。一意のパラメータは、スイープのタイプに応じた、個別ホストまたはポートの数のしきい値です。一意のパラメータは、期間内に一意のポート数またはホスト数がアドレス セット上に存在するとアラートをトリガーします。一意のポートおよびホストのトラッキング処理をカウンティングと言います。
Sweep エンジンのすべてのシグニチャに一意のパラメータを指定する必要があります。スイープでは、2 ～ 40（それぞれの値を含む）の制限値が強制されます。スイープの絶対最小値は 2 です。それ以外は（1 つのホストまたはポートの）スイープではありません。40 は、スイープによってメモリが過剰に消費されないように強制する必要がある場合の実際的な最大値です。一意の範囲の現実的な値は、5 ～ 15 です。
個別接続をカウントするスイープ インスペクタ スロットを判断するために、TCP スイープでは TCP フラグとマスクを指定する必要があります。さまざまなタイプの ICMP パケットを区別するために、ICMP スイープでは ICMP タイプを指定する必要があります。
Sweep エンジン シグニチャに関連するアクティビティが検出されると、IPS は DataNode を使用して、そのホストのモニタリングをいつ停止するかを決定します。DataNode には、複数パケットにわたるストリームの再構成と、ストリーム単位、ソース単位、宛先単位で検査状態を追跡するためのさまざまな永続カウンタと変数が含まれています。スイープを含む DataNode は、スイープをいつ失効させるかを決定します。DataNode は、その DataNode で x 秒間（プロトコルに依存）トラフィックが発生しないと、スイープを停止します。
DataNode には、複数の適応型タイムアウトがあります。DataNode は、含まれているすべてのオブジェクトが取り除かれてから、アドレス セットでアイドル時間が 30 秒経過すると失効します。含まれている各オブジェクトには、さまざまなタイムアウトがあります。たとえば、TCP ストリームの場合、確立した接続には 1 時間のタイムアウトがあります。他のほとんどのオブジェクトの有効期限は非常に短く、5 秒や 60 秒などです。
表 B-39 に、Sweep エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
攻撃者と攻撃対象のアドレスとポート（送信元および宛先）を、アラート メッセージとアクションで入れ替える場合は [Yes]。入れ替えない場合は [No]（デフォルト）。 |
||
すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Sweep Other TCP エンジン
Sweep Other TCP エンジンは、2 台のホスト間のトラフィックを分析し、一般に攻撃対象を特定するために使用する異常なパケットを探します。既存のシグニチャを調整したり、カスタム シグニチャを作成したりすることができます。
TCP スイープには、TCP フラグとマスクが指定されている必要があります。TCP フラグのセット中で、複数のエントリを指定できます。また、特定のパケットを除外するためのポート範囲を必要に応じて指定できます。
表 B-40 に、Sweep Other TCP エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Traffic Anomaly エンジン
（注） 異常検出シグニチャを編集または調整できますが、カスタム異常検出シグニチャは作成できません。
Traffic Anomaly エンジンには、3 つのプロトコル（TCP、UDP、およびその他）をカバーする 9 つの異常検出シグニチャが含まれます。各シグニチャには 2 つのサブシグニチャがあります。一方はスキャナ用で、もう一方はワームに感染したホスト（またはワーム攻撃されているスキャナ）用です。異常検出は、異常を検出すると、これらのシグニチャのアラートをトリガーします。すべての異常検出シグニチャは、デフォルトでイネーブルになり、各シグニチャのアラート重大度は高く設定されます。
スキャナが検出されても、ヒストグラム異常が発生しない場合、スキャナ シグニチャはその攻撃者（スキャナ）の IP アドレスをファイルに保存します。ヒストグラム シグニチャがトリガーされた場合は、スキャンを行っている攻撃者のアドレスによってそれぞれ（スキャナ シグニチャではなく）ワーム シグニチャがトリガーされます。ヒストグラムがトリガーされているので、アラートの詳細には、ワーム検出に使用されたしきい値が表示されます。その時点から、すべてのスキャナがワーム感染ホストとして検出されます。
• [Product Alert]：イベント ストアにイベントを書き込みます。
• [Deny Attacker Inline]：指定された期間、この攻撃者のアドレスから発生した現在のパケットおよび将来のパケットを送信しません。
• [Log Attacker Packets]：攻撃者のアドレスが含まれているパケットに対する IP ロギングを開始します。
• [Log Attacker/Victim Pair Packets]：攻撃者と攻撃対象のアドレス ペアが含まれているパケットに対する IP ロギングを開始します。
• [Deny Attacker Service Pair Inline]：送信元 IP アドレスと宛先ポートをブロックします。
• [Request SNMP Trap]：NotificationApp に、SNMP 通知を実行するための要求を送信します。
• [Request Block Host]：このホスト（攻撃者）をブロックする要求を ARC に送信します。
表 41 に、異常検出ワーム シグニチャを示します。
すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Traffic ICMP エンジン
Traffic ICMP エンジンは、TFN2K、LOKI、DDoS などの非標準プロトコルを分析します。このエンジンには、ユーザが設定可能なパラメータを持つ 2 つのシグニチャ（LOKI プロトコルに基づく）だけが含まれます。
TFN2K は、TFN の新しいバージョンです。TFN2K は DDoS エージェントの一種であり、感染した複数のコンピュータ（ゾンビ）による協調した攻撃（何百または何千もの未知の攻撃ホストから 1 つのコンピュータまたはドメインに向けて偽のトラフィック フラッドを送信する攻撃）を制御します。TFN2K はランダムに抽出されたパケット ヘッダー情報を送信しますが、それにはシグニチャの定義に使用できる 2 つの識別子が付いています。1 つは L3 チェックサムが不正かどうかを示し、もう 1 つはペイロードの末尾に文字 64「A」が検出されたかどうかを示します。TFN2K は、任意のポートで実行可能であり、ICMP、TCP、UDP、またはこれらのプロトコルの組み合わせを使用して通信できます。
LOKI は、バック ドア型トロイの木馬タイプです コンピュータが感染すると、悪意のあるコードにより ICMP トンネルが作成されます。この ICMP トンネルは、ICMP 応答内での小さなペイロードの送信に使用されるおそれがあります（ICMP をブロックするように設定していないと、ICMP 応答はファイアウォールを通過することがあります）。LOKI シグニチャは、ICMP エコーの要求と応答のアンバランス、簡易 ICMP コード、およびペイロード識別子をモニタします。
（TFN2K を除く）DDOS カテゴリは、ICMP ベースの DDOS エージェントを対象とします。ここで使用する主なツールは、TFN と Stacheldraht です。これらは TFN2K と同様に動作しますが、ICMP だけに依存し、固定コマンド（整数および文字列）を備えています。
表 B-42 に、Traffic ICMP エンジンに固有のパラメータを示します。
|
|
|
|
|---|---|---|
すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
Trojan エンジン
Trojan エンジンは、BO2K や TFN2K などの非標準プロトコルを分析します。Trojan エンジンには、Trojan BO2K、TrojanTFN2K、および Trojan UDP の 3 つの種類があります。
BO は、Windows を標的とした最初のバック ドア型トロイの木馬です。この BO は UDP 上でのみ実行されます。BO は、まもなく BO2K で置き換えられました。BO2K は、基本的な XOR 暗号を利用する UDP と TCP のどちらにも対応していました。特定のクロスパケット特性を持つプレーン BO ヘッダーが使用されています。
BO2K には、BO ヘッダーを暗号化し、クロスパケット パターンをほぼ認識不能にする、隠蔽用の TCP モジュールも含まれています。BO と BO2K の UDP モードは、Trojan UDP エンジンによって処理されます。TCP モードは Trojan BO2K エンジンによって処理されます。
（注） Trojan エンジンには、Trojan UDP エンジンの [Swap Attacker Victim] を除き、固有のパラメータはありません。
すべてのシグニチャ エンジンに共通のパラメータの詳細については、「Master エンジン」を参照してください。
フィードバック