シグニチャの設定
ここでは、シグニチャのパラメータの設定方法について説明します。内容は次のとおりです。
• 「シグニチャ定義オプション」
• 「アラート頻度の設定」
• 「アラート重大度の設定」
• 「イベント カウンタの設定」
• 「シグニチャの忠実度評価の設定」
• 「シグニチャのステータスの設定」
• 「シグニチャ関して脆弱な OS の設定」
• 「シグニチャへのアクションの割り当て」
• 「AIC シグニチャの設定」
• 「IP フラグメント再構成の設定」
• 「TCP ストリーム再構成の設定」
• 「IP ロギングの設定」
シグニチャ定義オプション
特定のシグニチャの一般パラメータの設定では、次のオプションが適用されます。
• alert-frequency :アラートをグループ化するためのサマリー オプションを設定します。
• alert-severity :アラートの重大度を設定します。
• engine :シグニチャ エンジンを指定します。エンジン サブモードでは、アクションを割り当てることができます。
• event-counter :イベント カウントを設定します。
• promisc-delta :アラートの重大度を決定するために使用されるデルタ値。
注意 シグニチャの Promiscuous Delta の設定を変更することは推奨しません。
無差別モードでは、Promiscuous Delta によって特定のアラートのリスク レーティングが低下します。センサーはターゲット システムの属性を認識せず、また無差別モードではパケットを拒否できないため、無差別アラートの優先順位を(優先順位の低いリスク レーティングに基づいて)低く設定しておくと役立ちます。そうすることで、管理者は優先順位の高いリスク レーティング アラートの調査に集中できます。
インライン モードでは、センサーが違反パケットを拒否することができます。その場合、違反パケットがターゲット ホストに到達することはないので、ターゲットが脆弱であっても問題になりません。ネットワーク上での攻撃が許可されなかったため、リスク レーティング値は差し引かれません。
サービス、OS、およびアプリケーションに固有のシグニチャ以外では、Promiscuous Delta は 0 です。OS、サービス、またはアプリケーションに固有のシグニチャの場合、5、10、または 15 の Promiscuous Delta がカテゴリごとに 5 つのポイントから計算されます。
• sig-description :シグニチャについての説明。
• sig-fidelity-rating :シグニチャの忠実度の評価。
• status :シグニチャのステータスをイネーブルまたは廃棄に設定します。
• vulnerable-os :この攻撃シグニチャに対して脆弱な OS タイプのリスト。
詳細情報
• アラート頻度を設定する手順については、「アラート頻度の設定」を参照してください。
• シグニチャ エンジンの詳細については、 付録 B「シグニチャ エンジン」 を参照してください。
• アクションを割り当てる手順については、「シグニチャへのアクションの割り当て」を参照してください。
• イベント カウント設定する手順については、「イベント カウンタの設定」を参照してください。
• シグニチャの忠実度評価を設定する手順については、「シグニチャの忠実度評価の設定」を参照してください。
• シグニチャをイネーブルまたはディセーブルにする手順については、「シグニチャのステータスの設定」を参照してください。
• 脆弱な OS を設定する手順については、「シグニチャ関して脆弱な OS の設定」を参照してください。
アラート頻度の設定
シグニチャのアラート頻度を設定するには、シグニチャ定義サブモードで alert-frequency コマンドを使用します。 alert-frequency コマンドは、このシグニチャが起動された場合にセンサーがアラートする頻度を指定します。
次のオプションが適用されます。
• sig_id :このシグニチャに割り当てられた一意の数値を示します。この値により、センサーは特定のシグニチャを識別します。値は 1000 ~ 65000 です。
• subsig_id :このサブシグニチャに割り当てられた一意の数値を示します。サブシグニチャ ID は、広範なシグニチャをより詳細に識別するために使用します。値は 0 ~ 255 です。
• summary-mode :センサーでアラートをグループ化する方法を指定します。
– fire-all :すべてのイベントに対してアラートを起動します。
– fire-once :1 回だけアラートを起動します。
– global-summarize :攻撃者や攻撃対象の数に関係なく 1 回だけアラートが起動されるようにアラートをサマライズします。
– summarize :すべてのアラートをサマライズします。
• specify-summary-threshold {yes | no}:サマリーしきい値モードをイネーブルにします。
– summary-threshold :センサーが、このシグニチャに対するサマリー アラートを送信するまでに受信する、最小ヒット数を 指定 します。値は 0 ~ 65535 です。
– summary-interval :各サマリー アラートで使用される時間(秒数)を 指定 します。値は 1 ~ 1000 です。
• summary-key :シグニチャのサマライズに使用するストレージ タイプを 指定 します。
– Axxx: 攻撃者のアドレス。
– Axxb: 攻撃者のアドレスと攻撃対象のポート。
– AxBx :攻撃者と攻撃対象のアドレス。
– AaBb :攻撃者と攻撃対象のアドレスおよびポート。
– xxBx :攻撃対象のアドレス。
• specify-global-summary-threshold {yes | no}:(任意)グローバル サマリーしきい値モードをイネーブルにします。
– global-summary-threshold :アラートをグローバル サマリーにサマライズする、イベント数のしきい値を 指定 します。値は 1 ~ 65535 です。
シグニチャのアラート頻度パラメータを設定するには、次の手順に従います。
ステップ 1
管理者権限またはオペレータ権限を持つアカウントを使用して CLI にログインします。
ステップ 2 シグニチャ定義サブモードを開始します。
sensor# configure terminal
sensor(config)# service signature-definition sig1
ステップ 3 設定するシグニチャを指定します。
sensor(config-sig)# signatures 9000 0
ステップ 4 アラート頻度サブモードを開始します。
sensor(config-sig-sig)# alert-frequency
ステップ 5 このシグニチャのアラート頻度を指定します。
a. サマリー モードを fire-once などに設定します。
sensor(config-sig-sig-ale)# summary-mode fire-once
sensor(config-sig-sig-ale-fir)# specify-global-summary-threshold yes
sensor(config-sig-sig-ale-fir-yes)# global-summary-threshold 3000
sensor(config-sig-sig-ale-fir-yes)# summary-interval 5000
b. サマリー キーを指定します。
sensor(config-sig-sig-ale-fir-yes)# exit
sensor(config-sig-sig-ale-fir)# summary-key AxBx
c. 設定を確認できます。
sensor(config-sig-sig-ale-fir)# show settings
-----------------------------------------------
summary-key: AxBx default: Axxx
specify-global-summary-threshold
-----------------------------------------------
-----------------------------------------------
global-summary-threshold: 3000 default: 120
summary-interval: 5000 default: 15
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
sensor(config-sig-sig-ale-fir)#
ステップ 6 アラート頻度サブモードを終了します。
sensor(config-sig-sig-ale-fir)# exit
sensor(config-sig-sig-ale)# exit
sensor(config-sig-sig)# exit
ステップ 7 Enter を押して変更を適用するか、 no と入力して変更を破棄します。
アラート重大度の設定
シグニチャの重大度を設定するには、シグニチャ定義サブモードで alert-severity コマンドを使用します。
次のオプションが適用されます。
• sig_id :このシグニチャに割り当てられた一意の数値を示します。この値により、センサーは特定のシグニチャを識別します。値は 1000 ~ 65000 です。
• subsig_id :このサブシグニチャに割り当てられた一意の数値を示します。サブシグニチャ ID は、広範なシグニチャをより詳細に識別するために使用します。値は 0 ~ 255 です。
• alert-severity :アラートの重大度を指定します。
– high :危険なアラート。
– medium :中レベルのアラート(デフォルト)。
– low :低レベルのアラート。
– informational :情報アラート。
アラートの重大度を設定するには、次の手順に従います。
ステップ 1
管理者権限またはオペレータ権限を持つアカウントを使用して CLI にログインします。
ステップ 2 シグニチャ定義サブモードを開始します。
sensor# configure terminal
sensor(config)# service signature-definition sig1
ステップ 3 設定するシグニチャを指定します。
sensor(config-sig)# signatures 9000 0
ステップ 4 アラートの重大度を割り当てます。
sensor(config-sig-sig)# alert-severity medium
ステップ 5 設定を確認できます。
sensor(config-sig-sig)# show settings
-----------------------------------------------
alert-severity: medium default: medium
sig-fidelity-rating: 75 <defaulted>
promisc-delta: 0 <defaulted>
-----------------------------------------------
sig-name: Back Door Probe (TCP 12345) <defaulted>
sig-string-info: SYN to TCP 12345 <defaulted>
alert-traits: 0 <defaulted>
-----------------------------------------------
vulnerable-os: general-os <defaulted>
-----------------------------------------------
-----------------------------------------------
event-action: produce-alert <defaulted>
fragment-status: any <defaulted>
-----------------------------------------------
ステップ 6 シグニチャ サブモードを終了します。
sensor(config-sig-sig)# exit
ステップ 7 Enter を押して変更を適用するか、 no と入力して変更を破棄します。
イベント カウンタの設定
センサーでのイベントのカウント方法を設定するには、シグニチャ定義サブモードで event-counter コマンドを使用します。たとえば、センサーが、同じシグニチャが同じアドレス セットに対して 5 回起動した場合にだけアラートを送信するように指定できます。
次のオプションが適用されます。
• event-count :アラートを生成するまでのイベントの発生回数を指定します。有効な範囲は 1 ~ 65535 です。デフォルトは 1 です。
• event-count-key:このシグニチャのイベントのカウントに使用するストレージ タイプを指定します。
– Axxx :攻撃者のアドレス
– AxBx :攻撃者と攻撃対象のアドレス
– Axxb :攻撃者のアドレスと攻撃対象のポート
– xxBx :攻撃対象のアドレス
– AaBb :攻撃者と攻撃対象のアドレスおよびポート
• specify-alert-interval {yes | no} : アラートの間隔をイネーブルにします。
– alert-interval :イベント カウントをリセットするまでの時間(秒数)を指定します。デフォルトは 60 です。
イベント カウンタを設定するには、次の手順に従います。
ステップ 1
管理者権限またはオペレータ権限を持つアカウントを使用して CLI にログインします。
ステップ 2 シグニチャ定義サブモードを開始します。
sensor# configure terminal
sensor(config)# service signature-definition sig1
ステップ 3 イベント カウンタを設定するシグニチャを指定します。
sensor(config-sig)# signatures 9000 0
ステップ 4 イベント カウンタ サブモードを開始します。
sensor(config-sig-sig)# event-counter
ステップ 5 アラートを生成するまでのイベントの発生する回数を指定します。
sensor(config-sig-sig-eve)# event-count 2
ステップ 6 このシグニチャのイベントのカウントに使用するストレージ タイプを指定します。
sensor(config-sig-sig-eve)# event-count-key AxBx
ステップ 7 (任意)アラート間隔をイネーブルにします。
sensor(config-sig-sig-eve)# specify-alert-interval yes
ステップ 8 (任意)イベント カウントをリセットするまでの時間(秒数)を指定します。
sensor(config-sig-sig-eve-yes)# alert-interval 30
ステップ 9 設定を確認できます。
sensor(config-sig-sig-eve-yes)# exit
sensor(config-sig-sig-eve)# show settings
-----------------------------------------------
event-count: 2 default: 1
event-count-key: AxBx default: Axxx
-----------------------------------------------
-----------------------------------------------
alert-interval: 30 default: 60
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
sensor(config-sig-sig-eve)#
ステップ 10 シグニチャ サブモードを終了します。
sensor(config-sig-sig-eve)# exit
sensor(config-sig-sig)# exit
ステップ 11 Enter を押して変更を適用するか、 no と入力して変更を破棄します。
シグニチャの忠実度評価の設定
シグニチャのシグニチャ忠実度評価を設定するには、シグニチャ定義サブモードで sig-fidelity-rating コマンドを使用します。
次のオプションが適用されます。
• sig-fidelity-rating :ターゲットに関する具体的な情報がない場合に、このシグニチャをどの程度忠実に実行するかに関連付ける重みを示します。有効な値は 0 ~ 100 です。
シグニチャのシグニチャ忠実度評価を設定するには、次の手順に従います。
ステップ 1
管理者権限またはオペレータ権限を持つアカウントを使用して CLI にログインします。
ステップ 2 シグニチャ定義サブモードを開始します。
sensor# configure terminal
sensor(config)# service signature-definition sig0
ステップ 3 設定するシグニチャを指定します。
sensor(config-sig)# signatures 12000 0
ステップ 4 このシグニチャのシグニチャ忠実度評価を指定します。
sensor(config-sig-sig)# sig-fidelity-rating 50
ステップ 5 設定を確認できます。
sensor(config-sig-sig)# show settings
-----------------------------------------------
alert-severity: low <defaulted>
sig-fidelity-rating: 50 default: 85
promisc-delta: 15 <defaulted>
-----------------------------------------------
sig-name: Gator Spyware Beacon <defaulted>
sig-string-info: /download/ User-Agent: Gator <defaulted>
alert-traits: 0 <defaulted>
-----------------------------------------------
ステップ 6 シグニチャ サブモードを終了します。
sensor(config-sig-sig)# exit
ステップ 7 Enter を押して変更を適用するか、 no と入力して変更を破棄します。
シグニチャのステータスの設定
注意 シグニチャのアクティブ化と廃棄には 30 分以上かかる場合があります。
特定のシグニチャのステータスを指定するには、シグニチャ定義サブモードで status コマンドを使用します。
次のオプションが適用されます。
• status :シグニチャが、イネーブル、ディセーブル、または破棄のどの状態であるかを指定します。
– enabled {true | false} :シグニチャをイネーブルにします。
– retired {true | false} :シグニチャを破棄します。
– obsoletes signature_ID :このシグニチャによって廃止されたその他のシグニチャを示します。
シグニチャのステータスを変更するには、次の手順に従います。
ステップ 1
管理者権限またはオペレータ権限を持つアカウントを使用して CLI にログインします。
ステップ 2 シグニチャ定義サブモードを開始します。
sensor# configure terminal
sensor(config)# service signature-definition sig1
ステップ 3 設定するシグニチャを選択します。
sensor(config-sig)# signatures 12000 0
ステップ 4 このシグニチャのステータスを変更します。
sensor(config-sig-sig)# status
sensor(config-sig-sig-sta)# enabled true
ステップ 5 設定を確認できます。
sensor(config-sig-sig-sta)# show settings
-----------------------------------------------
enabled: true default: false
retired: false <defaulted>
-----------------------------------------------
sensor(config-sig-sig-sta)#
ステップ 6 シグニチャ サブモードを終了します。
sensor(config-sig-sig-sta)# exit
sensor(config-sig-sig)# exit
ステップ 7 Enter を押して変更を適用するか、 no と入力して変更を破棄します。
シグニチャ関して脆弱な OS の設定
シグニチャに関して脆弱な OS のリストを設定するには、シグニチャ定義サブモードで vulnerable-os コマンドを使用します。
次のオプションが適用されます。
• general-os :すべての OS タイプ
• ios :Cisco IOS のバリアント
• mac-os :Macintosh OS のバリアント
• netware :Netware
• other :その他の OS
• unix :UNIX のバリアント
• aix :AIX のバリアント
• bsd :BSD のバリアント
• hp-ux :HP-UX のバリアント
• irix :IRIX のバリアント
• linux :Linux のバリアント
• solaris :Solaris のバリアント
• windows :Microsoft Windows のバリアント
• windows-nt-2k-xp :Microsoft NT、2000、および XP のバリアント
• win-nt :Windows NT の特定のバリアント
シグニチャに関して脆弱な OS を設定するには、次の手順に従います。
ステップ 1
管理者権限またはオペレータ権限を持つアカウントを使用して CLI にログインします。
ステップ 2 シグニチャ定義サブモードを開始します。
sensor# configure terminal
sensor(config)# service signature-definition sig1
ステップ 3 設定するシグニチャを指定します。
sensor(config-sig)# signatures 6000 0
ステップ 4 このシグニチャに関して脆弱な OS を指定します。
sensor(config-sig-sig)# vulnerable-os linux|aix
ステップ 5 設定を確認できます。
sensor(config-sig-sig)# show settings
-----------------------------------------------
alert-severity: medium <defaulted>
sig-fidelity-rating: 75 <defaulted>
promisc-delta: 0 <defaulted>
-----------------------------------------------
sig-name: My Sig <defaulted>
sig-string-info: My Sig Info <defaulted>
sig-comment: Sig Comment <defaulted>
alert-traits: 0 <defaulted>
release: custom <defaulted>
-----------------------------------------------
vulnerable-os: aix|linux default: general-os
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
event-count: 1 <defaulted>
event-count-key: Axxx <defaulted>
-----------------------------------------------
ステップ 6 シグニチャ サブモードを終了します。
sensor(config-sig-sig)# exit
ステップ 7 Enter を押して変更を適用するか、 no と入力して変更を破棄します。
シグニチャへのアクションの割り当て
シグニチャが起動するときにセンサーが実行するアクションを設定するには、シグニチャ定義サブモードで event-action コマンドを使用します。
次のオプションが適用されます。
• event-action :アラートがトリガーされた場合に実行するアクションを指定します。
– deny-attacker-inline :(インライン モードのみ)指定された期間、攻撃者のアドレスからの、現在のパケットおよび将来のパケットを送信しません。
– deny-attacker-service-pair-inline: (インライン モードのみ) 指定された期間、この攻撃者のアドレスと攻撃対象のポートのペアについては、現在のパケットおよび将来のパケットを送信しません。
– deny-attacker-victim-pair-inline: (インライン モードのみ) 指定された期間、この攻撃者と攻撃対象のアドレスのペアについては、現在のパケットおよび将来のパケットを送信しません。
– deny-connection-inline :(インライン モードのみ)TCP フローで、現在のパケットおよび将来のパケットを送信しません。
– deny-packet-inline :(インライン モードのみ)このパケットを送信しません。
– log-attacker-packets :攻撃者のアドレスが含まれているパケットに対する IP ロギングを開始します。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。
– log-pair-packets :攻撃者と攻撃対象のアドレスのペアが含まれているパケットに対する IP ロギングを開始します。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。
– log-victim-packets :攻撃対象のアドレスが含まれているパケットに対する IP ロギングを開始します。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。
– produce-alert :イベントをアラートとしてイベント ストアに書き込みます。
– produce-verbose-alert :攻撃パケットの符号化されたダンプ(切り捨てられている可能性あり)をアラートに組み込みます。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。
– request-block-connection :この接続をブロックする要求を ARC に送信します ブロッキング デバイスは、このアクションを実行するように設定されている必要があります。
– request-block-host :この攻撃者のホストをブロックする要求を ARC に送信します。ブロッキング デバイスは、このアクションを実行するように設定されている必要があります。
– request-rate-limit :レート制限を実行するレート制限要求を ARC に送信します。レート制限デバイスは、このアクションを実行するように設定されている必要があります。
– request-snmp-trap :SNMP 通知を実行する要求をセンサーの通知アプリケーション コンポーネントに送信します。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。SNMP は、このアクションを実装するようにセンサーで設定されている必要があります。
– reset-tcp-connection :TCP リセットを送信し、TCP フローをハイジャックして終了します。 Reset TCP Connection は、単一の接続を分析する TCP シグニチャでのみ機能します。スイープまたはフラッドに対しては機能しません。
– modify-packet-inline :パケット データを変更して、エンドポイントによるパケットの処理に関して、あいまいな部分を取り除きます。
• event-action-settings :次の external-rate-limit-type を設定します。
– none :レート制限は設定されません。
– percentage :トラフィック比率( external-rate-limit-percentage )によってレート制限を設定します。
パケットのインライン拒否について
deny-packet-inline をアクションとして設定されたシグニチャ、または deny-packet-inline をアクションとして追加するイベント アクション オーバーライドに対しては、次のアクションを実行できます。
• droppedPacket
• deniedFlow
• tcpOneWayResetSent
Deny Packet Inline アクションは、アラート内で破棄されたパケット アクションとして表されます。TCP 接続に対して Deny Packet Inline を実行すると、自動的に Deny Connection Inline にアップグレードされ、アラート内で拒否されたフローとして見なされます。IPS がパケットを 1 つだけ拒否すると、TCP は同じパケットの送信を繰り返し試みます。そのため、IPS は接続全体を拒否して、パケットが再送信されないようにします。
Deny Connection Inline を実行すると、IPS は、TCP 一方向リセットも自動的に送信します。これは、アラート内で送信された TCP 一方向リセットとして表示されます。IPS が接続を拒否すると、クライアント(通常は攻撃者)とサーバ(通常は攻撃対象)の両方で接続が開いたままになります。開いた接続が多すぎると、攻撃対象でリソースの問題が発生する可能性があります。そのため、IPS は TCP リセットを攻撃対象に送信して攻撃対象側(通常はサーバ)の接続を閉じ、攻撃対象のリソースを保護します。また、フェールオーバーも防止することで、接続が別のネットワーク パスにフェールオーバーして攻撃対象に到達するのを防ぎます。IPS は、攻撃者側が開いたままとなり、攻撃者側からのすべてのトラフィックを拒否します。
シグニチャのイベント アクションを設定するには、次の手順に従います。
ステップ 1
管理者権限を持つアカウントを使用して CLI にログインします。
ステップ 2 シグニチャ定義モードを開始します。
sensor# configure terminal
sensor(config)# service signature-definition sig0
ステップ 3 設定するシグニチャを指定します。
sensor(config-sig)# signatures 1200 0
ステップ 4 シグニチャ エンジンを指定します(シグニチャ 1200 の場合は Normalizer エンジンを指定)。
sensor(config-sig-sig)# engine normalizer
ステップ 5 イベント アクションを設定します。
sensor(config-sig-sig-nor)# event-action produce-alert|request-snmp-trap
(注) シグニチャのイベント アクションを設定するたびに、以前の設定が上書きされます。たとえば、シグニチャを起動するたびにアラートを生成する場合、その他の必要なイベント アクションとともにそのアクションを設定する必要があります。複数のイベント アクションを追加する場合は、| 記号を使用して、product-alert|deny-packet-inline|request-snmp-trap のようにします。
ステップ 6 設定を確認できます。
sensor(config-sig-sig-nor)# show settings
-----------------------------------------------
event-action: produce-alert|request-snmp-trap default: produce-alert|deny-packet-inline
ステップ 7 レート制限の割合を指定します。
sensor(config-sig-sig-nor)# event-action-settings
sensor(config-sig-sig-nor-eve)# external-rate-limit-type percentage
sensor(config-sig-sig-nor-eve-per)# external-rate-limit-percentage 50
ステップ 8 設定を確認できます。
sensor(config-sig-sig-nor-eve-per)# show settings
-----------------------------------------------
external-rate-limit-percentage: 50 default: 100
-----------------------------------------------
ステップ 9 イベント アクション サブモードを終了します。
sensor(config-sig-sig-nor-eve-per)# exit
sensor(config-sig-sig-nor-eve)# exit
sensor(config-sig-sig-nor)# exit
sensor(config-sig-sig)# exit
ステップ 10 Enter を押して変更を適用するか、 no と入力して変更を破棄します。
詳細情報
イベント アクションの詳細については、「イベント アクション」を参照してください。
AIC エンジンについて
(注) AIC エンジンは、HTTP トラフィックが AIC Web ポートで受信された場合に実行されます。トラフィックが Web トラフィックであっても AIC Web ポートで受信されない場合は、Service HTTP エンジンが実行されます。AIC 検査は、ポートが AIC Web ポートとして設定されており、検査されるトラフィックが HTTP トラフィックである場合に実行できます。
AIC は、Web トラフィックの詳細な分析を行います。HTTP セッションに対してより細かな制御を実行して、HTTP プロトコルの悪用を防ぎます。また、インスタント メッセージングや GotoMyPC など、特定のポートを介してトンネリングを試みるアプリケーションに対する管理制御を行います 。 これらのアプリケーションが HTTP で実行されている場合は、P2P およびインスタント メッセージングの検査とポリシー チェックを実行できます。
AIC は、FTP トラフィックを検査し、発行されるコマンドを制御する方法も提供します。事前定義済みシグニチャをイネーブルまたはディセーブルにするか、カスタム シグニチャを使用してポリシーを作成することができます。
AIC には、次のシグニチャのカテゴリがあります。
• HTTP 要求メソッド
– 定義要求メソッド
– 認識済み要求メソッド
• MIME タイプ
– 定義コンテンツ タイプ
– 認識済みコンテンツ タイプ
• 定義 Web トラフィック ポリシー
12674 という事前定義済みシグニチャが 1 つあり、非準拠の HTTP トラフィックが確認された場合に実行するアクションを指定します。パラメータ Alarm on Non HTTP Traffic は、シグニチャをイネーブルにします。デフォルトでは、このシグニチャはイネーブルになっています。
• 転送符号化
– アクションを各メソッドと関連付けます。
– センサーによって認識されるメソッドのリストを表示します。
– チャンク符号化エラーが発生した場合に実行する必要のあるアクションを指定します。
• FTP コマンド
– アクションを FTP コマンドに関連付けます。
詳細情報
• シグニチャ ID のリストおよびそれらについての詳細は、「AIC 要求メソッド シグニチャ」、「AIC MIME 定義コンテンツ タイプ シグニチャ」、「AIC 転送符号化シグニチャ」、および「AIC FTP コマンド シグニチャ」を参照してください。
• カスタム MIME シグニチャを作成する手順については、「AIC シグニチャの作成」を参照してください。
AIC エンジンとセンサーのパフォーマンス
アプリケーション ポリシーの実施は、固有のセンサー機能です。AIC ポリシーの実施は、不正利用、脆弱性、および異常を検査する従来のテクノロジーに基づいて行うのではなく、HTTP サービス ポリシーと FTP サービス ポリシーを実施するように設計されています。このポリシーの実施に必要な検査作業は、従来の IPS の検査作業とは大きく異なります。この機能を使用すると、パフォーマンスが大きく低下します。AIC をイネーブルにすると、センサー帯域幅の全体容量が減少します。
AIC ポリシーの実施は、IPS のデフォルト設定でディセーブルになっています。AIC ポリシーの実施をアクティブにする場合、必要なポリシーのみを注意深く選択し、不要なポリシーをディセーブルにすることを強く推奨します。また、センサーの検査負荷容量が最大値に近い場合、センサーをオーバーサブスクライブする可能性があるため、この機能を使用しないことを推奨します。このタイプのポリシーの実施を処理するには、適応型セキュリティ アプライアンス ファイアウォールを使用することを推奨します。
アプリケーション ポリシーの設定
Web AIC 機能をイネーブルにするには、シグニチャ定義サブモードで application-policy コマンドを使用します。レイヤ 4 からレイヤ 7 のパケット検査を提供するようにセンサーを設定して、Web サービスおよび FTP サービスに関連する悪意のある攻撃を防ぐことができます。
次のオプションが適用されます。
• ftp-enable {true | false} :FTP サービスの保護をイネーブルにします。センサーで FTP トラフィックの検査を要求する場合は true に設定します。デフォルトは false です。
• http-policy :HTTP トラフィックの検査をイネーブルにします。
– aic-web-ports:AIC トラフィックを検索するポートの変数を指定します。 有効な範囲は 0 ~ 65535 です。0 ~ 65535 の範囲で a-b[,c-d] 形式で指定された整数の、カンマ区切りリストです。範囲の 2 番目の数は、最初の数以上である必要があります。デフォルトは、80-80,3128-3128,8000-8000,8010-8010,8080-8080,8888-8888,24326-24326 です。
– http-enable {true | false} :Web サービスの保護をイネーブルにします。HTTP トラフィックが RFC に準拠しているかどうかの検査をセンサーに要求する場合は true に設定します。デフォルトは false です。
– max-outstanding-http-requests-per-connection :接続ごとに許可される HTTP 要求の最大数を指定します。有効な値は 1 ~ 16 です。デフォルトは 10 です。
アプリケーション ポリシーを設定するには、次の手順に従います。
ステップ 1
管理者権限またはオペレータ権限を持つアカウントを使用して CLI にログインします。
ステップ 2 アプリケーション ポリシー サブモードを開始します。
sensor# configure terminal
sensor(config)# service signature-definition sig1
sensor(config-sig)# application-policy
ステップ 3 FTP トラフィックの検査をイネーブルにします。
sensor(config-sig-app)# ftp-enable true
ステップ 4 HTTP アプリケーション ポリシーを設定します。
a. HTTP アプリケーション ポリシー サブモードを開始します。
sensor(config-sig-app)# http-policy
b. HTTP アプリケーション ポリシーの実施をイネーブルにします。
sensor(config-sig-app-htt)# http-enable true
c. 各接続で、サーバからの応答を受信していない状態が可能な未処理 HTTP 要求の数を指定します。
sensor(config-sig-app-htt)# max-outstanding-http-requests-per-connection 5
d. AIC ポートを編集します。
sensor(config-sig-app-htt)# aic-web-ports 80-80,3128-3128
ステップ 5 設定を確認します。
sensor(config-sig-app-htt)# exit
sensor(config-sig-app)# show settings
-----------------------------------------------
-----------------------------------------------
http-enable: true default: false
max-outstanding-http-requests-per-connection: 5 default: 10
aic-web-ports: 80-80,3128-3128 default: 80-80,3128-3128,8000-8000,8010-
8010,8080-8080,8888-8888,24326-24326
-----------------------------------------------
ftp-enable: true default: false
-----------------------------------------------
ステップ 6 シグニチャ定義サブモードを終了します。
sensor(config-sig-app)# exit
ステップ 7 Enter を押して変更を適用するか、 no と入力して変更を破棄します。
AIC 要求メソッド シグニチャ
HTTP 要求メソッドには、2 つのシグニチャのカテゴリがあります。
• 定義要求メソッド:アクションと要求メソッドの関連付けを可能にします。シグニチャを拡張および変更することができます(Define Request Method)。
• 認識済み要求メソッド:センサーによって認識されるメソッドのリストを表示します(Recognized Request Methods)。
表 8-1 に、事前定義済みの定義要求メソッド シグニチャを示します。必要とする事前定義済みのメソッドを持つシグニチャをイネーブルにします。
表 8-1 要求メソッド シグニチャ
|
|
12676 |
要求メソッドは認識されない |
12677 |
定義要求メソッド PUT |
12678 |
定義要求メソッド CONNECT |
12679 |
定義要求メソッド DELETE |
12680 |
定義要求メソッド GET |
12681 |
定義要求メソッド HEAD |
12682 |
定義要求メソッド OPTIONS |
12683 |
定義要求メソッド POST |
12685 |
定義要求メソッド TRACE |
12695 |
定義要求メソッド INDEX |
12696 |
定義要求メソッド MOVE |
12697 |
定義要求メソッド MKDIR |
12698 |
定義要求メソッド COPY |
12699 |
定義要求メソッド EDIT |
12700 |
定義要求メソッド UNEDIT |
12701 |
定義要求メソッド SAVE |
12702 |
定義要求メソッド LOCK |
12703 |
定義要求メソッド UNLOCK |
12704 |
定義要求メソッド REVLABEL |
12705 |
定義要求メソッド REVLOG |
12706 |
定義要求メソッド REVADD |
12707 |
定義要求メソッド REVNUM |
12708 |
定義要求メソッド SETATTRIBUTE |
12709 |
定義要求メソッド GETATTRIBUTENAME |
12710 |
定義要求メソッド GETPROPERTIES |
12711 |
定義要求メソッド STARTENV |
12712 |
定義要求メソッド STOPREV |
詳細情報
シグニチャをイネーブルにする手順については、「シグニチャのステータスの設定」を参照してください。
AIC MIME 定義コンテンツ タイプ シグニチャ
MIME タイプには、次の 2 つのポリシーが関連付けられています。
• 定義コンテンツ タイプ:次の場合に特定のアクションを関連付けます(Define Content Type)。
– image/jpeg などの特定の MIME タイプを拒否する場合
– メッセージ サイズ違反がある場合
– ヘッダーと本体に記述された MIME タイプが一致しない場合
• 認識済みコンテンツ タイプ(Recognized Content Type)
表 8-2 に、事前定義済みの定義コンテンツタイプ シグニチャを示します。必要とする事前定義済みのコンテンツ タイプを持つシグニチャをイネーブルにします。また、カスタム定義コンテンツ タイプ シグニチャを作成することもできます。
表 8-2 定義コンテンツ タイプ シグニチャ
|
|
12621 |
コンテンツ タイプ image/gif のメッセージ長が無効 |
12622 2 |
コンテンツ タイプ image/png の検証失敗 |
12623 0 12623 1 12623 2 |
コンテンツ タイプ image/tiff のヘッダー チェック コンテンツ タイプ image/tiff のメッセージ長が無効 コンテンツ タイプ image/tiff の検証失敗 |
12624 0 12624 1 12624 2 |
コンテンツ タイプ image/x-3ds のヘッダー チェック コンテンツ タイプ image/x-3ds のメッセージ長が無効 コンテンツ タイプ image/x-3ds の検証失敗 |
12626 0 12626 1 12626 2 |
コンテンツ タイプ image/x-portable-bitmap のヘッダー チェック コンテンツ タイプ image/x-portable-bitmap のメッセージ長が無効 コンテンツ タイプ image/x-portable-bitmap の検証失敗 |
12627 0 12627 1 12627 2 |
コンテンツ タイプ image/x-portable-graymap のヘッダー チェック コンテンツ タイプ image/x-portable-graymap のメッセージ長が無効 コンテンツ タイプ image/x-portable-graymap の検証失敗 |
12628 0 12628 1 12628 2 |
コンテンツ タイプ image/jpeg のヘッダー チェック コンテンツ タイプ image/jpeg のメッセージ長が無効 コンテンツ タイプ image/jpeg の検証失敗 |
12629 0 12629 1 |
コンテンツ タイプ image/cgf のヘッダー チェック コンテンツ タイプ image/cgf のメッセージ長が無効 |
12631 0 12631 1 |
コンテンツ タイプ image/x-xpm のヘッダー チェック コンテンツ タイプ image/x-xpm のメッセージ長が無効 |
12633 0 12633 1 12633 2 |
コンテンツ タイプ audio/midi のヘッダー チェック コンテンツ タイプ audio/midi のメッセージ長が無効 コンテンツ タイプ audio/midi の検証失敗 |
12634 0 12634 1 12634 2 |
コンテンツ タイプ audio/basic のヘッダー チェック コンテンツ タイプ audio/basic のメッセージ長が無効 コンテンツ タイプ audio/basic の検証失敗 |
12635 0 12635 1 12635 2 |
コンテンツ タイプ audio/mpeg のヘッダー チェック コンテンツ タイプ audio/mpeg のメッセージ長が無効 コンテンツ タイプ audio/mpeg の検証失敗 |
12636 0 12636 1 12636 2 |
コンテンツ タイプ audio/x-adpcm のヘッダー チェック コンテンツ タイプ audio/x-adpcm のメッセージ長が無効 コンテンツ タイプ audio/x-adpcm の検証失敗 |
12637 0 12637 1 12637 2 |
コンテンツ タイプ audio/x-aiff のヘッダー チェック コンテンツ タイプ audio/x-aiff のメッセージ長が無効 コンテンツ タイプ audio/x-aiff の検証失敗 |
12638 0 12638 1 12638 2 |
コンテンツ タイプ audio/x-ogg のヘッダー チェック コンテンツ タイプ audio/x-ogg のメッセージ長が無効 コンテンツ タイプ audio/x-ogg の検証失敗 |
12639 0 12639 1 12639 2 |
コンテンツ タイプ audio/x-wav のヘッダー チェック コンテンツ タイプ audio/x-wav のメッセージ長が無効 コンテンツ タイプ audio/x-wav の検証失敗 |
12641 0 12641 1 12641 2 |
コンテンツ タイプ text/html のヘッダー チェック コンテンツ タイプ text/html のメッセージ長が無効 コンテンツ タイプ text/html の検証失敗 |
12642 0 12642 1 |
コンテンツ タイプ text/css のヘッダー チェック コンテンツ タイプ text/css のメッセージ長が無効 |
12643 0 12643 1 |
コンテンツ タイプ text/plain のヘッダー チェック コンテンツ タイプ text/plain のメッセージ長が無効 |
12644 0 12644 1 |
コンテンツ タイプ text/richtext のヘッダー チェック コンテンツ タイプ text/richtext のメッセージ長が無効 |
12645 0 12645 1 12645 2 |
コンテンツ タイプ text/sgml のヘッダー チェック コンテンツ タイプ text/sgml のメッセージ長が無効 コンテンツ タイプ text/sgml の検証失敗 |
12646 0 12646 1 12646 2 |
コンテンツ タイプ text/xml のヘッダー チェック コンテンツ タイプ text/xml のメッセージ長が無効 コンテンツ タイプ text/xml の検証失敗 |
12648 0 12648 1 12648 2 |
コンテンツ タイプ video/flc のヘッダー チェック コンテンツ タイプ video/flc のメッセージ長が無効 コンテンツ タイプ video/flc の検証失敗 |
12649 0 12649 1 12649 2 |
コンテンツ タイプ video/mpeg のヘッダー チェック コンテンツ タイプ video/mpeg のメッセージ長が無効 コンテンツ タイプ video/mpeg の検証失敗 |
12650 0 12650 1 |
コンテンツ タイプ text/xmcd のヘッダー チェック コンテンツ タイプ text/xmcd のメッセージ長が無効 |
12651 0 12651 1 12651 2 |
コンテンツ タイプ video/quicktime のヘッダー チェック コンテンツ タイプ video/quicktime のメッセージ長が無効 コンテンツ タイプ video/quicktime の検証失敗 |
12652 0 12652 1 |
コンテンツ タイプ video/sgi のヘッダー チェック コンテンツ タイプ video/sgi の検証失敗 |
12653 0 12653 1 |
コンテンツ タイプ video/x-avi のヘッダー チェック コンテンツ タイプ video/x-avi のメッセージ長が無効 |
12654 0 12654 1 12654 2 |
コンテンツ タイプ video/x-fli のヘッダー チェック コンテンツ タイプ video/x-fli のメッセージ長が無効 コンテンツ タイプ video/x-fli の検証失敗 |
12655 0 12655 1 12655 2 |
コンテンツ タイプ video/x-mng のヘッダー チェック コンテンツ タイプ video/x-mng のメッセージ長が無効 コンテンツ タイプ video/x-mng の検証失敗 |
12656 0 12656 1 12656 2 |
コンテンツ タイプ application/x-msvideo のヘッダー チェック コンテンツ タイプ application/x-msvideo のメッセージ長が無効 コンテンツ タイプ application/x-msvideo の検証失敗 |
12658 0 12658 1 |
コンテンツ タイプ application/ms-word のヘッダー チェック コンテンツ タイプ application/ms-word のメッセージ長が無効 |
12659 0 12659 1 |
コンテンツ タイプ application/octet-stream のヘッダー チェック コンテンツ タイプ application/octet-stream のメッセージ長が無効 |
12660 0 12660 1 12660 2 |
コンテンツ タイプ application/postscript のヘッダー チェック コンテンツ タイプ application/postscript のメッセージ長が無効 コンテンツ タイプ application/postscript の検証失敗 |
12661 0 12661 1 |
コンテンツ タイプ application/vnd.ms-excel のヘッダー チェック コンテンツ タイプ application/vnd.ms-excel のメッセージ長が無効 |
12662 0 12662 1 |
コンテンツ タイプ application/vnd.ms-powerpoint のヘッダー チェック コンテンツ タイプ application/vnd.ms-powerpoint のメッセージ長が無効 |
12663 0 12663 1 12663 2 |
コンテンツ タイプ application/zip のヘッダー チェック コンテンツ タイプ application/zip のメッセージ長が無効 コンテンツ タイプ application/zip の検証失敗 |
12664 0 12664 1 12664 2 |
コンテンツ タイプ application/x-gzip のヘッダー チェック コンテンツ タイプ application/x-gzip のメッセージ長が無効 コンテンツ タイプ application/x-gzip の検証失敗 |
12665 0 12665 1 |
コンテンツ タイプ application/x-java-archive のヘッダー チェック コンテンツ タイプ application/x-java-archive のメッセージ長が無効 |
12666 0 12666 1 |
コンテンツ タイプ application/x-java-vm のヘッダー チェック コンテンツ タイプ application/x-java-vm のメッセージ長が無効 |
12667 0 12667 1 12667 2 |
コンテンツ タイプ application/pdf のヘッダー チェック コンテンツ タイプ application/pdf のメッセージ長が無効 コンテンツ タイプ application/pdf の検証失敗 |
12668 0 12668 1 |
コンテンツ タイプ unknown のヘッダー チェック コンテンツ タイプ unknown のメッセージ長が無効 |
12669 0 12669 1 |
コンテンツ タイプ image/x-bitmap のヘッダー チェック コンテンツ タイプ image/x-bitmap のメッセージ長が無効 |
12673 0 |
認識済みコンテンツ タイプ |
詳細情報
• シグニチャをイネーブルにする手順については、「シグニチャのステータスの設定」を参照してください。
• AIC シグニチャを作成する手順については、「AIC シグニチャの作成」を参照してください。
AIC 転送符号化シグニチャ
転送符号化には、次の 3 つポリシーが関連します。
• アクションを各メソッドと関連付けます(Define Transfer Encoding)。
• センサーによって認識されるメソッドのリストを表示します(Recognized Transfer Encoding)。
• チャンク符号化エラーが発生した場合に実行する必要のあるアクションを指定します(Chunked Transfer Encoding Error)。
表 8-3 に、事前定義済みの転送符号化シグニチャを示します。必要とする事前定義済み転送符号化メソッドを持つシグニチャをイネーブルにします。
表 8-3 転送符号化シグニチャ
|
|
12686 |
認識済み転送符号化 |
12687 |
転送符号化 Deflate の定義 |
12688 |
転送符号化 Identity の定義 |
12689 |
転送符号化 Compress の定義 |
12690 |
転送符号化 GZIP の定義 |
12693 |
転送符号化 Chunked の定義 |
12694 |
チャンク転送符号化エラー |
詳細情報
シグニチャをイネーブルにする手順については、「シグニチャのステータスの設定」を参照してください。
AIC FTP コマンド シグニチャ
表 8-4 に、事前定義済みの FTP コマンド シグニチャを示します。必要とする事前定義済みの FTP コマンドを持つシグニチャをイネーブルにします。
表 8-4 FTP コマンド シグニチャ
|
|
12900 |
認識されていない FTP コマンド |
12901 |
FTP コマンド abor の定義 |
12902 |
FTP コマンド acct の定義 |
12903 |
FTP コマンド allo の定義 |
12904 |
FTP コマンド appe の定義 |
12905 |
FTP コマンド cdup の定義 |
12906 |
FTP コマンド cwd の定義 |
12907 |
FTP コマンド dele の定義 |
12908 |
FTP コマンド help の定義 |
12909 |
FTP コマンド list の定義 |
12910 |
FTP コマンド mkd の定義 |
12911 |
FTP コマンド mode の定義 |
12912 |
FTP コマンド nlst の定義 |
12913 |
FTP コマンド noop の定義 |
12914 |
FTP コマンド pass の定義 |
12915 |
FTP コマンド pasv の定義 |
12916 |
FTP コマンド port の定義 |
12917 |
FTP コマンド pwd の定義 |
12918 |
FTP コマンド quit の定義 |
12919 |
FTP コマンド rein の定義 |
12920 |
FTP コマンド rest の定義 |
12921 |
FTP コマンド retr の定義 |
12922 |
FTP コマンド rmd の定義 |
12923 |
FTP コマンド rnfr の定義 |
12924 |
FTP コマンド rnto の定義 |
12925 |
FTP コマンド site の定義 |
12926 |
FTP コマンド smnt の定義 |
12927 |
FTP コマンド stat の定義 |
12928 |
FTP コマンド stor の定義 |
12929 |
FTP コマンド stou の定義 |
12930 |
FTP コマンド stru の定義 |
12931 |
FTP コマンド syst の定義 |
12932 |
FTP コマンド type の定義 |
12933 |
FTP コマンド user の定義 |
詳細情報
シグニチャをイネーブルにする手順については、「シグニチャのステータスの設定」を参照してください。
AIC シグニチャの作成
次の例では、AIC エンジンに基づいて MIME タイプのシグニチャを作成する方法を示します。
次のオプションが適用されます。
• event-action :アラートがトリガーされた場合に実行するアクションを指定します。
– deny-attacker-inline :(インラインのみ)指定された期間、攻撃者のアドレスからの、現在のパケットおよび将来のパケットを送信しません。
– deny-attacker-service-pair-inline: (インラインのみ) 指定された期間、この攻撃者のアドレスと攻撃対象のポートのペアについては、現在のパケットおよび将来のパケットを送信しません。
– deny-attacker-victim-pair-inline: (インラインのみ) 指定された期間、この攻撃者と攻撃対象のアドレスのペアについては、現在のパケットおよび将来のパケットを送信しません。
– deny-connection-inline :(インラインのみ)TCP フローで、現在のパケットおよび将来のパケットを送信しません。
– deny-packet-inline :(インラインのみ)このパケットを送信しません。
– log-attacker-packets :攻撃者のアドレスが含まれているパケットに対する IP ロギングを開始します。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。
– log-pair-packets :攻撃者と攻撃対象のアドレスのペアが含まれているパケットに対する IP ロギングを開始します。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。
– log-victim-packets :攻撃対象のアドレスが含まれているパケットに対する IP ロギングを開始します。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。
– produce-alert :イベントをアラートとしてイベント ストアに書き込みます。
– produce-verbose-alert :攻撃パケットの符号化されたダンプ(切り捨てられている可能性あり)をアラートに組み込みます。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。
– request-block-connection :この接続をブロックする要求を ARC に送信します ブロッキング デバイスは、このアクションを実行するように設定されている必要があります。
– request-block-host :この攻撃者のホストをブロックする要求を ARC に送信します。ブロッキング デバイスは、このアクションを実行するように設定されている必要があります。
– request-rate-limit :レート制限を実行するレート制限要求を ARC に送信します。レート制限デバイスは、このアクションを実行するように設定されている必要があります。
– request-snmp-trap :SNMP 通知を実行する要求をセンサーの通知アプリケーション コンポーネントに送信します。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。SNMP は、このアクションを実装するようにセンサーで設定されている必要があります。
– reset-tcp-connection :TCP リセットを送信し、TCP フローをハイジャックして終了します。 Reset TCP Connection は、単一の接続を分析する TCP シグニチャでのみ機能します。スイープまたはフラッドに対しては機能しません。
– modify-packet-inline :パケット データを変更して、エンドポイントによるパケットの処理に関して、あいまいな部分を取り除きます。
• no :エントリまたは選択設定を削除します。
• signature-type :目的のシグニチャのタイプを指定します。
– content-types :コンテンツ タイプ
– define-web-traffic-policy :Web トラフィック ポリシーを定義
– max-outstanding-requests-overrun :多数の未処理 HTTP 要求を検査
– msg-body-pattern :メッセージ本文のパターン
– request-methods :要求メソッドを処理するシグニチャ タイプ
– transfer-encodings :転送符号化を処理するシグニチャ タイプ
MIME タイプ ポリシーのシグニチャを定義するには、次の手順に従います。
ステップ 1
管理者権限またはオペレータ権限を持つアカウントを使用して CLI にログインします。
ステップ 2 アプリケーション ポリシー実施サブモードを開始します。
sensor# configure terminal
sensor(config)# service signature-definition sig1
sensor(config-sig)# signatures 60001 0
sensor(config-sig-sig)# engine application-policy-enforcement-http
ステップ 3 イベント アクションを指定します。
sensor(config-sig-sig-app)# event-action produce-alert|log-pair-packets
ステップ 4 シグニチャ タイプを定義します。
sensor(config-sig-sig-app)# signature-type content-type define-content-type
ステップ 5 コンテンツ タイプを定義します。
sensor(config-sig-sig-app-def)# name MyContent
ステップ 6 設定を確認します。
sensor(config-sig-sig-app-def)# show settings
-----------------------------------------------
*---> content-type-details
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
sensor(config-sig-sig-app-def)#
ステップ 7 シグニチャ サブモードを終了します。
sensor(config-sig-sig-app-def)# exit
sensor(config-sig-sig-app)# exit
sensor(config-sig-sig)# exit
ステップ 8 Enter を押して変更を適用するか、 no と入力して変更を破棄します。
IP フラグメント再構成について
(注) IP フラグメント再構成は、シグニチャごとに設定します。
センサーは、複数のパケットにわたってフラグメント化されたデータグラムを再構成するように設定できます。このとき、再構成するデータグラム フラグメントの数と、データグラムについてさらにフラグメントが届くのを待つ時間を判断するために、センサーが使用する境界値を指定できます。これは、センサーがフレーム送信を受信できなかったことや、無作為にフラグメント化されたデータグラムを生成する攻撃が仕掛けられていることが原因で再構成が不十分なデータグラムに対し、センサーのリソースをすべて割り当ててしまわないようにするためのものです。
IP フラグメント再構成シグニチャと設定可能なパラメータ
表 8-5 に、IP フラグメント再構成シグニチャと、IP フラグメント再構成に設定可能なパラメータを示します。IP フラグメント再構成シグニチャは、Normalizer エンジンの一部です。
表 8-5 IP フラグメント再構成シグニチャ
|
|
|
|
1200 IP Fragmentation Buffer Full |
システム内のフラグメントの合計数が、最大フラグメントによって設定されたしきい値を超えた場合に起動されます。 |
最大フラグメントを 10000 に指定 (0 ~ 42000) |
Deny Packet Inline Produce Alert |
1201 Fragment Overlap |
データグラムにキューイングされたフラグメントが互いに重複した場合に起動されます。 |
なし |
|
1202 Datagram Too Long |
フラグメント データ(オフセットとサイズ)が、最大データグラム サイズで設定されたしきい値を超えた場合に起動されます。 |
最大データグラム サイズを 65536 に指定(2000 ~ 65536) |
Deny Packet Inline Produce Alert |
1203 Fragment Overwrite |
データグラムにキューイングされたフラグメントが互いに重複し、重複しているデータが異なる場合に起動されます。 |
なし |
Deny Packet Inline Produce Alert |
1204 No Initial Fragment |
データグラムが不完全であり、初期フラグメントが欠落している場合に起動されます。 |
なし |
Deny Packet Inline Produce Alert |
1205 Too Many Datagrams |
システム内の部分データグラムの合計数が最大部分データグラムによって設定されたしきい値を超えた場合に起動されます。 |
最大部分データグラムを 1000 に指定(0 ~ 10000) |
Deny Packet Inline Produce Alert |
1206 Fragment Too Small |
1 つのデータグラムで、サイズが Max Small Frags を上回り、Min Fragment Size よりも小さい場合に起動されます。 |
Max Small Frags 2 を指定(8 ~ 1500) Min Fragment Size 400 を指定(1 ~ 8) |
Deny Packet Inline Produce Alert |
1207 Too Many Fragments |
1 つのデータグラムで、データグラムごとの最大フラグメントを上回る場合に起動されます。 |
データグラムごとの最大フラグメントを 170 に指定(0 ~ 8192) |
Deny Packet Inline Produce Alert |
1208 Incomplete Datagram |
フラグメント再構成タイムアウトの期間中に、データグラムのすべてのフラグメントが到達していない場合に起動されます。 |
フラグメント再構成タイムアウトを 60 に指定(0 ~ 360) |
Deny Packet Inline Produce Alert |
1220 Jolt2 Fragment Reassembly DoS attack |
複数のフラグメントを受信し、それらがすべて IP データグラムの最終フラグメントになることを要求する場合に起動されます。 |
最大最終フラグメントを 4 に指定(1 ~ 50) |
Deny Packet Inline Produce Alert |
1225 Fragment Flags Invalid |
フラグメント フラグの不適切な組み合わせを検出した場合に起動されます。 |
なし |
|
詳細情報
Normalizer エンジンの詳細については、「Normalizer エンジン」を参照してください。
IP フラグメント再構成パラメータの設定
特定のシグニチャの IP フラグメント再構成パラメータを設定するには、次の手順に従います。
ステップ 1
管理者権限またはオペレータ権限を持つアカウントを使用して CLI にログインします。
ステップ 2 シグニチャ定義サブモードを開始します。
sensor# configure terminal
sensor(config)# service signature-definition sig1
ステップ 3 IP フラグメント再構成シグニチャ ID とサブシグニチャ ID を指定します。
sensor(config-sig)# signatures 1200 0
ステップ 4 エンジンを指定します。
sensor(config-sig-sig)# engine normalizer
ステップ 5 デフォルト シグニチャ編集サブモードを開始します。
sensor(config-sig-sig-nor)# edit-default-sigs-only default-signatures-only
ステップ 6 任意の IP フラグメント再構成パラメータをイネーブルにし、(必要に応じて)デフォルト設定を変更します。たとえば、シグニチャ 1200 の最大フラグメント数を指定します。
sensor(config-sig-sig-nor-def)# specify-max-fragments yes
sensor(config-sig-sig-nor-def-yes)# max-fragments 20000
ステップ 7 設定を確認できます。
sensor(config-sig-sig-nor-def-yes)# show settings
-----------------------------------------------
max-fragments: 20000 default: 10000
-----------------------------------------------
sensor(config-sig-sig-nor-def-yes)#
ステップ 8 シグニチャ定義サブモードを終了します。
sensor(config-sig-sig-nor-def-yes)# exit
sensor(config-sig-sig-nor-def)# exit
sensor(config-sig-sig-nor)# exit
sensor(config-sig-sig)# exit
ステップ 9 Enter を押して変更を適用するか、 no と入力して変更を破棄します。
IP フラグメント再構成方法の設定
センサーがフラグメントの再構成に使用する方法を設定するには、シグニチャ定義サブモードで fragment-reassembly コマンドを使用します。このオプションは、センサーが無差別モードで動作している場合に設定できます。センサーがインライン モードで動作している場合、この方法は NT 専用です。
次のオプションが適用されます。
• ip-reassemble-mode :オペレーティング システムに基づいて、センサーがフラグメントの再構築に使用する方法を示します。
– nt :Windows システム(デフォルト)。
– solaris :Solaris システム。
– linux :GNU/Linux システム。
– bsd :BSD UNIX システム。
IP フラグメント再構成方法を設定するには、次の手順に従います。
ステップ 1
管理者権限またはオペレータ権限を持つアカウントを使用して CLI にログインします。
ステップ 2 フラグメント再構成サブモードを開始します。
sensor# configure terminal
sensor(config)# service signature-definition sig1
sensor(config-sig)# fragment-reassembly
ステップ 3 センサーが IP フラグメントの再構成に使用するオペレーティングシステムを設定します。
sensor(config-sig-fra)# ip-reassemble-mode linux
ステップ 4 設定を確認します。
sensor(config-sig-fra)# show settings
-----------------------------------------------
ip-reassemble-mode: linux default: nt
-----------------------------------------------
ステップ 5 シグニチャ定義サブモードを終了します。
sensor(config-sig-fra)# exit
ステップ 6 Enter を押して変更を適用するか、 no と入力して変更を破棄します。
TCP ストリーム再構成について
センサーは、完了した 3 ウェイ ハンドシェイクによって確立された TCP セッションだけをモニタするように設定できます。また、ハンドシェイクの完了まで待つ時間の最大値と、パケットがない場合に接続をモニタし続ける時間も設定できます。これは、有効な TCP セッションが確立していないときにセンサーがアラートを生成しないようにするためのものです。センサーに対する攻撃には、単純に攻撃を繰り返すだけでセンサーにアラートを生成させようとするものがあります。TCP セッションの再構成機能は、センサーに対するこの種の攻撃の緩和に役立ちます。
TCP ストリーム再構成パラメータは、シグニチャごとに設定します。TCP ストリーム再構成のモードを設定できます。
TCP ストリーム再構成シグニチャと設定可能なパラメータ
表 8-6 に、TCP ストリーム再構成シグニチャと、TCP ストリーム再構成に設定可能なパラメータを示します。TCP ストリーム再構成シグニチャは、Normalizer エンジンの一部です。
表 8-6 TCP ストリーム再構成シグニチャ
|
|
|
|
1300 TCP Segment Overwrite |
重複している TCP セグメントのデータ(再送信など)が、このセッションですでに確認されているデータとは異なるデータを送信する場合に起動されます。 |
-- |
Deny Connection Inline Product Alert |
1301 TCP Inactive Timeout |
TCP セッションが TCP Idle Timeout の期間、アイドル状態となっている場合に起動されます。 |
TCP Idle Timeout 3600(15 ~ 3600) |
なし |
1302 TCP Embryonic Timeout |
TCP セッションがTCP 初期接続タイムアウト時間(秒数)内にスリーウェイ ハンドシェイクを完了していない場合に起動されます。 |
TCP Embryonic Timeout 15 (3 ~ 300) |
なし |
1303 TCP Closing Timeout |
TCP セッションが最初の FIN の後、TCP Closed Timeout 時間(秒数)内に完全に終了していない場合に起動されます。 |
TCP Closed Timeout 5(1 ~ 60) |
なし |
1304 TCP Max Segments Queued Per Session |
セッションでキューイングされた順序が正しくないセグメント数が TCP Max Queue を超えた場合に起動されます。予想されるシーケンスから最も離れたシーケンスを含んでいるセグメントがドロップされます。 |
TCP Max Queue 32 (0 ~ 128) |
Deny Packet Inline Product Alert |
1305 TCP Urgent Flag |
TCP 緊急フラグが確認された場合に起動されます。 |
-- |
Modify Packet Inline はディセーブルです。 |
1306 0 TCP Option Other |
TCP Option Number の範囲内で TCP オプションが確認された場合に起動されます。 |
TCP Option Number 6 ~ 7、9 ~ 255 (整数範囲 0 ~ 255 で複数の制約が許可される) |
Modify Packet Inline Produce Alert |
1306 1 TCP SACK Allowed Option |
TCP 選択的 ACK によって許可されたオプションが確認された場合に起動されます。 |
-- |
Modify Packet Inline はディセーブルです。 |
1306 2 TCP SACK Data Option |
TCP 選択的 ACK データ オプションが確認された場合に起動されます。 |
-- |
Modify Packet Inline はディセーブルです。 |
1306 3 TCP Timestamp Option |
TCP タイムスタンプ オプションが確認された場合に起動されます。 |
-- |
Modify Packet Inline はディセーブルです。 |
1306 4 TCP Window Scale Option |
TCP ウィンドウ スケール オプションが確認された場合に起動されます。 |
-- |
Modify Packet Inline はディセーブルです。 |
1307 TCP Window Size Variation |
TCP の recv ウィンドウの右端が右に移動(減少)する場合に起動されます。 |
-- |
Deny Connection Inline Produce Alert はディセーブルです。 |
1308 TTL Varies |
セッションの 1 つの方向で確認された TTL が、検出されている最小の TTL よりも大きい場合に起動されます。 |
-- |
Modify Packet Inline |
1309 TCP Reserved Bits Set |
予約ビット(ECN で使用されるビットを含む)が TCP ヘッダーで設定された場合に起動されます。 |
-- |
Modify Packet Inline Produce Alert はディセーブルです。 |
1310 TCP Retransmit Protection |
再送信されたセグメントに、元のセグメントとは異なるデータがあることをセンサーが検出した場合に起動されます。 |
-- |
Deny Connection Inline Produce Alert |
1311 TCP Packet Exceeds MSS |
パケットがスリーウェイ ハンドシェイク中に交換された MSS を超えた場合に起動されます。 |
-- |
Deny Connection Inline Produce Alert |
1312 TCP Min MSS |
SYN フラグを含むパケットの MSS 値が TCP Min MSS よりも小さい場合に起動されます。 |
TCP Min MSS 400 (0 ~ 16000) |
Modify Packet Inline はディセーブルです。 |
1313 TCP Max MSS |
SYN フラグを含むパケットの MSS 値が TCP Max MSS を超える場合に起動されます。 |
TCP Max MSS1460 (0 ~ 16000) |
Modify Packet Inline はディセーブルです。 |
1314 TCP Data SYN |
TCP ペイロードが SYN パケットで送信された場合に起動されます。 |
-- |
Deny Packet Inline はディセーブルです。 |
1315 ACK Without TCP Stream |
ストリームに属さない ACK パケットが送信された場合に起動されます。 |
-- |
Produce Alert はディセーブルです。 |
1317 Zero Window Probe |
ゼロ ウィンドウ プローブ パケットが検出された場合に起動されます。 |
Modify Packet Inline は、ゼロ ウィンドウ プローブ パケットのデータを削除します。 |
Modify Packet Inline |
1330 0 TCP Drop - Bad Checksum |
TCP パケットに不正なチェックサムがある場合に起動されます。 |
Modify Packet Inline は、チェックサムを修正します。 |
Deny Packet Inline |
1330 1 TCP Drop - Bad TCP Flags |
TCP パケットに不正なフラグの組み合わせがある場合に起動されます。 |
-- |
Deny Packet Inline |
1330 2 TCP Drop - Urgent Pointer With No Flag |
TCP パケットに URG ポインタがあり、URG フラグがない場合に起動されます。 |
Modify Packet Inline は、ポインタをクリアします。 |
Modify Packet Inline はディセーブルです。 |
1330 3 TCP Drop - Bad Option List |
TCP パケットに不正なオプション リストがある場合に起動されます。 |
-- |
Deny Packet Inline |
1330 4 TCP Drop - Bad Option Length |
TCP パケットに不正なオプション長がある場合に起動されます。 |
-- |
Deny Packet Inline |
1330 5 TCP Drop - MSS Option Without SYN |
SYN フラグが設定されていないパケットで TCP MSS オプションが確認された場合に起動されます。 |
Modify Packet Inline は、MSS オプションをクリアします。 |
Modify Packet Inline |
1330 6 TCP Drop - WinScale Option Without SYN |
SYN フラグが設定されていないパケットで TCP ウィンドウ スケール オプションが確認された場合に起動されます。 |
Modify Packet Inline は、ウィンドウ スケール オプションをクリアします。 |
Modify Packet Inline |
1330 7 TCP Drop - Bad WinScale Option Value |
TCP パケットに不正なウィンドウ スケール値がある場合に起動されます。 |
Modify Packet Inline は、制限値に最も近い値を設定します。 |
Modify Packet Inline |
1330 8 TCP Drop - SACK Allow Without SYN |
SYN フラグが設定されていないパケットで TCP SACK 許可オプションが確認された場合に起動されます。 |
Modify Packet Inline は、SACK 許可オプションをクリアします。 |
Modify Packet Inline |
1330 9 TCP Drop - Data in SYN|ACK |
SYN フラグおよび ACK フラグが設定された TCP パケットにもデータが含まれる場合に起動されます。 |
-- |
Deny Packet Inline |
1330 10 TCP Drop - Data Past FIN |
TCP データが FIN の後に順序設定された場合に起動されます。 |
-- |
Deny Packet Inline |
1330 11 TCP Drop - Timestamp not Allowed |
タイムスタンプ オプションが許可されていない場合に、TCP パケットにタイムスタンプ オプションがあると起動されます。 |
-- |
Deny Packet Inline |
1330 12 TCP Drop - Segment Out of Order |
TCP セグメントの順番が正しくないため、キューイングを実行できない場合に起動されます。 |
-- |
Deny Packet Inline |
1330 13 TCP Drop - Invalid TCP Packet |
TCP パケットに無効なヘッダーがある場合に起動されます。 |
-- |
Deny Packet Inline |
1330 14 TCP Drop - RST or SYN in window |
RST フラグまたは SYN フラグのある TCP パケットがシーケンス ウィンドウで送信されたが、次のシーケンスではなかった場合に起動されます。 |
-- |
Deny Packet Inline |
1330 15 TCP Drop - Segment Already ACKed |
TCP パケット シーケンスがピアによってすでに ACK されている場合に起動されます(キープアライブを除く)。 |
-- |
Deny Packet Inline |
1330 16 TCP Drop - PAWS Failed |
TCP パケットが PAWS チェックに失敗した場合に起動されます。 |
-- |
Deny Packet Inline |
1330 17 TCP Drop - Segment out of State Order |
TCP パケットが TCP セッション状態に対して不適切な場合に起動されます。 |
-- |
Deny Packet Inline |
1330 18 TCP Drop - Segment out of Window |
TCP パケットのシーケンス番号が許容範囲外である場合に起動されます。 |
-- |
Deny Packet Inline |
3050 Half Open SYN Attack |
|
syn-flood-max-embryonic 5000 |
|
3250 TCP Hijack |
|
max-old-ack 200 |
|
3251 TCP Hijack Simplex Mode |
|
max-old-ack 100 |
|
詳細情報
Normalizer エンジンの詳細については、「Normalizer エンジン」を参照してください。
TCP ストリーム再構成シグニチャの設定
特定のシグニチャに TCP ストリーム再構成を設定するには、次の手順に従います。
ステップ 1
管理者権限またはオペレータ権限を持つアカウントを使用して CLI にログインします。
ステップ 2 シグニチャ定義サブモードを開始します。
sensor# configure terminal
sensor(config)# service signature-definition sig1
ステップ 3 TCP ストリーム再構成シグニチャの ID とサブシグニチャの ID を指定します。
sensor(config-sig)# signatures 1313 0
ステップ 4 エンジンを指定します。
sensor(config-sig-sig)# engine normalizer
ステップ 5 デフォルト シグニチャ編集サブモードを開始します。
sensor(config-sig-sig-nor)# edit-default-sigs-only default-signatures-only
ステップ 6 シグニチャ 1313 の最大 MSS パラメータをイネーブルにし、(必要に応じて)デフォルト設定を変更します。
sensor(config-sig-sig-nor-def)# specify-tcp-max-mss yes
sensor(config-sig-sig-nor-def-yes)# tcp-max-mss 1380
(注) このパラメータをデフォルトの 1460 から 1380 に変更すると、VPN トンネルを通過するトラフィックのフラグメント化を防ぐことができます。
ステップ 7 設定を確認できます。
sensor(config-sig-sig-nor-def-yes)# show settings
-----------------------------------------------
tcp-max-mss: 1380 default: 1460
-----------------------------------------------
sensor(config-sig-sig-nor-def-yes)#
ステップ 8 シグニチャ定義サブモードを終了します。
sensor(config-sig-sig-nor-def-yes)# exit
sensor(config-sig-sig-nor-def)# exit
sensor(config-sig-sig-nor)# exit
sensor(config-sig-sig)# exit
ステップ 9 Enter を押して変更を適用するか、 no と入力して変更を破棄します。
TCP ストリーム再構成のモードの設定
センサーが TCP セッションの再構成に使用するモードを設定するには、シグニチャ定義サブモードで stream-reassembly コマンドを使用します。
(注) tcp-3-way-handshake-required パラメータと tcp-reassembly-mode パラメータは、インライン モードではなく、無差別モードのトラフィックを検査するセンサーにのみ影響を与えます。インライン トラフィックを検査するセンサーの非対称オプションを設定するには、inline-TCP-evasion-protection-mode パラメータを使用します。
次のオプションが適用されます。
• tcp-3-way-handshake-required {true | false} :センサーがスリーウェイ ハンドシェイクの完了したセッションのみ追跡するように指定します。デフォルトは true です。
• tcp-reassembly-mode :センサーが TCP セッションの再構成に使用するモードを指定します。
– strict :シーケンスで次に予想されるものだけを許可します(デフォルト)。
– loose :シーケンスに途切れがあっても許可します。
– asym :非対称トラフィックの再構成を許可します。
注意 非対称オプションを使用すると、TCP ウィンドウの回避チェックがディセーブルになります。
TCP ストリームの再構成パラメータを設定するには、次の手順に従います。
ステップ 1
管理者権限またはオペレータ権限を持つアカウントを使用して CLI にログインします。
ステップ 2 TCP ストリーム再構成サブモードを開始します。
sensor# configure terminal
sensor(config)# service signature-definition sig1
sensor(config-sig)# stream-reassembly
ステップ 3 センサーが、スリーウェイ ハンドシェイクが完了したセッションだけを追跡するよう指定します。
sensor(config-sig-str)# tcp-3-way-handshake-required true
ステップ 4 センサーが TCP セッションの再構成に使用するモードを指定します。
sensor(config-sig-str)# tcp-reassembly-mode strict
ステップ 5 設定を確認できます。
sensor(config-sig-str)# show settings
-----------------------------------------------
tcp-3-way-handshake-required: true default: true
tcp-reassembly-mode: strict default: strict
-----------------------------------------------
ステップ 6 シグニチャ定義サブモードを終了します。
sensor(config-sig-str)# exit
ステップ 7 Enter を押して変更を適用するか、 no と入力して変更を破棄します。
詳細情報
インライン モードで設定されるセンサーの非対称検査オプションの詳細については、「Inline TCP Session Tracking Mode」および「仮想センサーの追加、編集、および削除」を参照してください。
IP ロギングの設定
センサーが攻撃を検出したときに、IP セッション ログを生成するように設定できます。シグニチャの応答アクションとして IP ロギングが設定されているときにシグニチャがトリガーされると、アラートの送信元アドレスとの間で送受信されるすべてのパケットが指定された時間の間ログに記録されます。
IP ロギングを設定するには、シグニチャ定義サブモードで ip-log コマンドを使用します。
次のオプションが適用されます。
• ip-log-bytes :記録する最大バイト数を示します。有効な値は 0 ~ 2147483647 です。デフォルトは 0 です。
• ip-log-packets :記録するパケット数を示します。有効な値は 0 ~ 65535 です。デフォルトは 0 です。
• ip-log-time :センサーで記録する期間を示します。有効な値は、30 ~ 300 秒です。デフォルトは 30 秒です。
(注) センサーは、いずれかの IP ロギング条件を検出すると、IP ロギングを停止します。
IP ロギング パラメータを設定するには、次の手順に従います。
ステップ 1
管理者権限またはオペレータ権限を持つアカウントを使用して CLI にログインします。
ステップ 2 IP ログ サブモードを開始します。
sensor# configure terminal
sensor(config)# service signature-definition sig1
sensor(config-sig)# ip-log
ステップ 3 IP ロギング パラメータを指定します。
a. 記録する最大バイト数を指定します。
sensor(config-sig-ip)# ip-log-bytes 200000
b. 記録するパケット数を指定します。
sensor(config-sig-ip)# ip-log-packets 150
c. センサーで記録する期間を指定します。
sensor(config-sig-ip)# ip-log-time 60
ステップ 4 設定を確認できます。
sensor(config-sig-ip)# show settings
-----------------------------------------------
ip-log-packets: 150 default: 0
ip-log-time: 60 default: 30
ip-log-bytes: 200000 default: 0
-----------------------------------------------
ステップ 5 シグニチャ定義サブモードを終了します。
sensor(config-sig-ip)# exit
ステップ 6 Enter を押して変更を適用するか、 no と入力して変更を破棄します。
カスタム シグニチャの作成
ここでは、カスタム シグニチャの作成方法について説明します。内容は次のとおりです。
• 「カスタム シグニチャの作成手順」
• 「String TCP シグニチャの例」
• 「Service HTTP シグニチャの例」
• 「Meta シグニチャの例」
• 「IPv6 シグニチャの例」
カスタム シグニチャの作成手順
カスタム シグニチャを作成するには、次の手順に従います。
ステップ 1
シグニチャ エンジンを選択します。
ステップ 2 シグニチャ ID を割り当てます。
• シグニチャ ID
• サブシグニチャ ID
• シグニチャ名
• アラートの注釈 (任意)
• ユーザ コメント (任意)
ステップ 3 エンジン固有のパラメータを割り当てます。各エンジンに適用されるマスター パラメータのグループがありますが、パラメータはシグニチャ エンジンごとに異なります。
ステップ 4 アラート応答を割り当てます。
• シグニチャの忠実度評価
• アラートの重大度
ステップ 5 アラート動作を割り当てます。
ステップ 6 変更を適用します。
String TCP シグニチャの例
(注) この手順は、String UDP シグニチャおよび String ICMP シグニチャにも適用されます。
String エンジンは、TCP、UDP および ICMP の各プロトコルを対象とした、汎用のパターン マッチング インスペクション エンジンです。String エンジンでは、複数のパターンを 1 つのパターン マッチング テーブルにまとめることでデータ内の検索を一度に実行できる新しい正規表現エンジンが使用されます。String ICMP、String TCP、および String UDP の 3 つの String エンジンがあります。次の例は、カスタム String TCP シグニチャの作成方法を示しています。
次のオプションが適用されます。
• default :値をシステム デフォルト設定に戻します。
• direction :トラフィックの方向を指定します。
– from-service :サービス ポートからクライアント ポート宛のトラフィック。
– to-service :クライアント ポートからサービス ポート宛のトラフィック。
• event-action :アラートがトリガーされた場合に実行するアクションを指定します。
– deny-attacker-inline :(インラインのみ)指定された期間、攻撃者のアドレスからの、現在のパケットおよび将来のパケットを送信しません。
– deny-attacker-service-pair-inline: (インラインのみ) 指定された期間、この攻撃者のアドレスと攻撃対象のポートのペアについては、現在のパケットおよび将来のパケットを送信しません。
– deny-attacker-victim-pair-inline: (インラインのみ) 指定された期間、この攻撃者と攻撃対象のアドレスのペアについては、現在のパケットおよび将来のパケットを送信しません。
– deny-connection-inline :(インラインのみ)TCP フローで、現在のパケットおよび将来のパケットを送信しません。
– deny-packet-inline :(インラインのみ)このパケットを送信しません。
– log-attacker-packets :攻撃者のアドレスが含まれているパケットに対する IP ロギングを開始します。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。
– log-pair-packets :攻撃者と攻撃対象のアドレスのペアが含まれているパケットに対する IP ロギングを開始します。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。
– log-victim-packets :攻撃対象のアドレスが含まれているパケットに対する IP ロギングを開始します。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。
– produce-alert :イベントをアラートとしてイベント ストアに書き込みます。
– produce-verbose-alert :攻撃パケットの符号化されたダンプ(切り捨てられている可能性あり)をアラートに組み込みます。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。
– request-block-connection :この接続をブロックする要求を ARC に送信します ブロッキング デバイスは、このアクションを実行するように設定されている必要があります。
– request-block-host :この攻撃者のホストをブロックする要求を ARC に送信します。ブロッキング デバイスは、このアクションを実行するように設定されている必要があります。
– request-rate-limit :レート制限を実行するレート制限要求を ARC に送信します。レート制限デバイスは、このアクションを実行するように設定されている必要があります。
– request-snmp-trap :SNMP 通知を実行する要求をセンサーの通知アプリケーション コンポーネントに送信します。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。SNMP は、このアクションを実装するようにセンサーで設定されている必要があります。
– reset-tcp-connection :TCP リセットを送信し、TCP フローをハイジャックして終了します。 Reset TCP Connection は、単一の接続を分析する TCP シグニチャでのみ機能します。スイープまたはフラッドに対しては機能しません。
– modify-packet-inline :パケット データを変更して、エンドポイントによるパケットの処理に関して、あいまいな部分を取り除きます。
• no :エントリまたは選択設定を削除します。
• regex-string :単一の TCP パケット内で検索する正規表現を指定します。
• service-ports :ターゲット サービスが常駐するポートまたはポート範囲を指定します。有効な範囲は 0 ~ 65535 です。0 ~ 65535 の範囲で a-b[,c-d] 形式で指定された整数の、カンマ区切りリストです。範囲の 2 番目の数は、最初の数以上である必要があります。
• specify-exact-match-offset {yes | no} :(任意)exact-match-offset をイネーブルにします。
– exact-match-offset :一致を有効にするために正規表現文字列がレポートする必要がある正確なストリーム オフセットを指定します。有効な範囲は 0 ~ 65535 です。
• specify-min-match-length {yes | no} :(任意)min-match-length をイネーブルにします。
– min-match-length :正規表現文字列が一致する必要があるバイトの最小数を指定します。有効な範囲は 0 ~ 65535 です。
• strip-telnet-options {true | false} :検索の前にデータから Telnet オプション文字を削除します。
• swap-attacker-victim {true | false} :アラーム メッセージ内および実行される任意のアクションで、攻撃者と攻撃対象のアドレスおよびポート(送信元と宛先)をスワップします。デフォルトは、スワッピングを行わない false に設定されています。
String TCP エンジンに基づいてシグニチャを作成するには、次の手順に従います。
ステップ 1
管理者権限またはオペレータ権限を持つアカウントを使用して CLI にログインします。
ステップ 2 シグニチャ定義サブモードを開始します。
sensor# configure terminal
sensor(config)# service signature-definition sig1
ステップ 3 シグニチャのシグニチャ ID とサブシグニチャ ID を指定します。カスタム シグニチャの範囲は、60000 ~ 65000 です。
sensor(config-sig)# signatures 60025 0
ステップ 4 シグニチャ記述サブモードを開始します。
sensor(config-sig-sig)# sig-description
ステップ 5 新しいシグニチャの名前を指定します。また、 sig-comment コマンドを使用して sig に関する追加コメントを指定したり、 sig-string-info コマンドを使用してシグニチャに関する追加情報を指定することもできます。
sensor(config-sig-sig-sig)# sig-name This is my new name
ステップ 6 シグニチャ記述サブモードを終了します。
sensor(config-sig-sig-sig)# exit
ステップ 7 String TCP エンジンを指定します。
sensor(config-sig-sig)# engine string-tcp
ステップ 8 サービス ポートを指定します。
sensor(config-sig-sig-str)# service-ports 23
ステップ 9 方向を指定します。
sensor(config-sig-sig-str)# direction to-service
ステップ 10 TCP パケット内で検索する正規表現文字列を指定します。必要に応じて event-action コマンドを使用し、セキュリティ ポリシーに従ってイベント アクションを変更することができます。デフォルトのイベント アクションは produce-alert です。
sensor(config-sig-sig-str)# regex-string This-is-my-new-Sig-regex
ステップ 11 このカスタム String TCP シグニチャでは、次のオプション パラメータも変更することができます。
• specify-exact-match-offset
• specify-min-match-length
• strip-telnet-options
• swap-attacker-victim
ステップ 12 設定を確認できます。
sensor(config-sig-sig-str)# show settings
-----------------------------------------------
event-action: produce-alert <defaulted>
strip-telnet-options: false <defaulted>
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
regex-string: This-is-my-new-Sig-regex
direction: to-service default: to-service
specify-exact-match-offset
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
swap-attacker-victim: false <defaulted>
-----------------------------------------------
sensor(config-sig-sig-str)#
ステップ 13 シグニチャ定義サブモードを終了します。
sensor(config-sig-sig-str)# exit
sensor(config-sig-sig)# exit
ステップ 14 Enter を押して変更を適用するか、 no と入力して変更を破棄します。
Service HTTP シグニチャの例
Service HTTP エンジンは、サービス固有の文字列ベースのパターン マッチング インスペクション エンジンです。HTTP プロトコルは、現代のネットワークで最もよく使用されているプロトコルです。さらに、これには最も長い前処理時間が必要であり、検査を必要とする最大数のシグニチャを持つため、システムのパフォーマンス全体に対して重大な影響を及ぼします。
Service HTTP エンジンでは、複数のパターンを 1 つのパターン マッチング テーブルにまとめることでデータ内の検索を一度に実行できる新しい正規表現ライブラリが使用されます。このエンジンは Web サービスに送られるトラフィックの、Web サービスだけに対するもの、または HTTP 要求を検索します。このエンジンを使用してリターン トラフィックを検査することはできません。このエンジンの各シグニチャで、該当する個別の Web ポートを指定できます。
HTTP 解読とは、符号化された文字を ASCII 対応文字に正規化することによって、HTTP メッセージをデコードするプロセスです。このプロセスは、ASCII 正規化と呼ばれることもあります。
HTTP パケットを検査するには、あらかじめそのデータを、ターゲット システムでのデータ処理時に表示されるものと同じデータ表現として解読または正規化しておく必要があります。また、ホスト ターゲット タイプごとにカスタマイズされたデコード方式を用意することが推奨されます。そのためには、ターゲット上で動作しているオペレーティング システムおよび Web サーバのバージョンを確認する必要があります。Service HTTP エンジンは、Microsoft IIS Web サーバ用としてデフォルトの解読処理機能を備えています。
次のオプションが適用されます。
• de-obfuscate {true | false} :検索の前に反回避解読を適用します。
• default :値をシステム デフォルト設定に戻します。
• event-action :アラートがトリガーされた場合に実行するアクションを指定します。
– deny-attacker-inline :(インラインのみ)指定された期間、攻撃者のアドレスからの、現在のパケットおよび将来のパケットを送信しません。
– deny-attacker-service-pair-inline: (インラインのみ) 指定された期間、この攻撃者のアドレスと攻撃対象のポートのペアについては、現在のパケットおよび将来のパケットを送信しません。
– deny-attacker-victim-pair-inline: (インラインのみ) 指定された期間、この攻撃者と攻撃対象のアドレスのペアについては、現在のパケットおよび将来のパケットを送信しません。
– deny-connection-inline :(インラインのみ)TCP フローで、現在のパケットおよび将来のパケットを送信しません。
– deny-packet-inline :(インラインのみ)このパケットを送信しません。
– log-attacker-packets :攻撃者のアドレスが含まれているパケットに対する IP ロギングを開始します。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。
– log-pair-packets :攻撃者と攻撃対象のアドレスのペアが含まれているパケットに対する IP ロギングを開始します。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。
– log-victim-packets :攻撃対象のアドレスが含まれているパケットに対する IP ロギングを開始します。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。
– produce-alert :イベントをアラートとしてイベント ストアに書き込みます。
– produce-verbose-alert :攻撃パケットの符号化されたダンプ(切り捨てられている可能性あり)をアラートに組み込みます。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。
– request-block-connection :この接続をブロックする要求を ARC に送信します ブロッキング デバイスは、このアクションを実行するように設定されている必要があります。
– request-block-host :この攻撃者のホストをブロックする要求を ARC に送信します。ブロッキング デバイスは、このアクションを実行するように設定されている必要があります。
– request-rate-limit :レート制限を実行するレート制限要求を ARC に送信します。レート制限デバイスは、このアクションを実行するように設定されている必要があります。
– request-snmp-trap :SNMP 通知を実行する要求をセンサーの通知アプリケーション コンポーネントに送信します。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。SNMP は、このアクションを実装するようにセンサーで設定されている必要があります。
– reset-tcp-connection :TCP リセットを送信し、TCP フローをハイジャックして終了します。 Reset TCP Connection は、単一の接続を分析する TCP シグニチャでのみ機能します。スイープまたはフラッドに対しては機能しません。
– modify-packet-inline :パケット データを変更して、エンドポイントによるパケットの処理に関して、あいまいな部分を取り除きます。
• max-field-sizes :最大フィールド サイズのグループ化をイネーブルにします。
– specify-max-arg-field-length {yes | no} :max-arg-field-length をイネーブルにします(任意)。
– specify-max-header-field-length {yes | no} :max-header-field-length をイネーブルにします(任意)。
– specify-max-request-length {yes | no} :max-request-length をイネーブルにします(任意)。
– specify-max-uri-field-length {yes | no} :max-uri-field-length をイネーブルにします(任意)。
• no :エントリまたは選択設定を削除します。
• regex :正規表現のグループ化をイネーブルにします。
– specify-arg-name-regex :(任意)arg-name-regex をイネーブルにします。
– specify-header-regex :(任意)header-regex をイネーブルにします。
– specify-request-regex :(任意)request-regex をイネーブルにします。
– specify-uri-regex :(任意)uri-regex をイネーブルにします。
• service-ports :ターゲット サービスが常駐するポートまたはポート範囲のカンマ区切りのリストを指定します。
• swap-attacker-victim {true | false} :アラーム メッセージ内および実行される任意のアクションで、攻撃者と攻撃対象のアドレスおよびポート(送信元と宛先)をスワップします。デフォルトは、スワッピングを行わない false に設定されています。
Service HTTP エンジンに基づいてカスタム シグニチャを作成するには、次の手順に従います。
ステップ 1
管理者権限またはオペレータ権限を持つアカウントを使用して CLI にログインします。
ステップ 2 シグニチャ定義サブモードを開始します。
sensor# configure terminal
sensor(config)# service signature-definition sig1
ステップ 3 シグニチャのシグニチャ ID とサブシグニチャ ID を指定します。
sensor(config-sig)# signatures 63000 0
カスタム シグニチャの範囲は、60000 ~ 65000 です。
ステップ 4 シグニチャ記述モードを開始します。
sensor(config-sig-sig)# sig-description
ステップ 5 シグニチャ名を指定します。
sensor(config-sig-sig-sig)# sig-name myWebSig
ステップ 6 アラートの特性を指定します。有効な範囲は 0 ~ 65535 です。
sensor(config-sig-sig-sig)# alert-traits 2
ステップ 7 シグニチャ記述サブモードを終了します。
sensor(config-sig-sig-sig)# exit
ステップ 8 アラート頻度を指定します。
sensor(config-sig-sig)# alert-frequency
sensor(config-sig-sig-ale)# summary-mode fire-all
sensor(config-sig-sig-ale-fir)# summary-key Axxx
sensor(config-sig-sig-ale-fir)# specify-summary-threshold yes
sensor(config-sig-sig-ale-fir-yes)# summary-threshold 200
ステップ 9 アラート頻度サブモードを終了します。
sensor(config-sig-sig-ale-fir-yes)# exit
sensor(config-sig-sig-ale-fir)# exit
sensor(config-sig-sig-ale)# exit
ステップ 10 検索の前に反回避解読を適用するようにシグニチャを設定します。
sensor(config-sig-sig)# engine service-http
sensor(config-sig-sig-ser)# de-obfuscate true
ステップ 11 正規表現パラメータを設定します。
sensor(config-sig-sig)# engine service-http
sensor(config-sig-sig-ser)# regex
sensor(config-sig-sig-ser-reg)# specify-uri-regex yes
sensor(config-sig-sig-ser-reg-yes)# uri-regex [Mm][Yy][Ff][Oo][Oo]
ステップ 12 正規表現サブモードを終了します。
sensor(config-sig-sig-ser-reg-yes)# exit
sensor(config-sig-sig-ser-reg-)# exit
ステップ 13 シグニチャ変数 WEBPORTS を使用してサービス ポートを設定します。
sensor(config-sig-sig-ser)# service-ports $WEBPORTS
ステップ 14 シグニチャ定義サブモードを終了します。
sensor(config-sig-sig-ser)# exit
sensor(config-sig-sig)# exit
ステップ 15 Enter を押して変更を適用するか、 no と入力して変更を破棄します。
Meta シグニチャの例
注意 多数の Meta シグニチャがあると、センサー パフォーマンス全体に影響を及ぼす可能性があります。
(注) Meta エンジンは、ほとんどのエンジンがパケットを入力としているにもかかわらず、アラートを入力としている点が他のエンジンとは異なります。
Meta エンジンでは、スライディング時間間隔内に、関連した方法で発生するイベントを定義します。このエンジンは、パケットではなくイベントを処理します。シグネチャ イベントが生成されると、Meta エンジンはシグネチャ イベントを検査して、1 つ以上の Meta 定義に一致するかどうかを判定します。Meta エンジンは、すべてのイベント要件が満たされるとシグネチャ イベントを生成します。
すべてのシグネチャ イベントは、シグニチャ イベント アクション プロセッサによって Meta エンジンに渡されます。シグニチャ イベント アクション プロセッサは、最小ヒット数オプションを処理してからイベントを渡します。Meta エンジンがコンポーネント イベントを処理してから、サマライズおよびイベント アクションは処理されます。
次のオプションが適用されます。
• component-list :Meta コンポーネントのリスト。
– edit :リスト内の既存のエントリを編集します。
– insert name1 :リストに新しいエントリを挿入します。
– move :リスト内のエントリを移動します。
– begin :エントリをアクティブ リストの先頭に配置します。
– end :エントリをアクティブリストの終わりに配置します。
– inactive :エントリを非アクティブ リストに配置します。
– before :エントリを、指定したエントリの前に配置します。
– after :エントリを、指定したエントリの後ろに配置します。
• component-count :このコンポーネントが満たされるまでに、コンポーネントを起動する回数を指定します。
• component-sig-id :このコンポーネントを照合するシグニチャのシグニチャ ID を指定します。
• component-subsig-id :このコンポーネントを照合するシグニチャのサブシグニチャ ID を指定します。
• component-list-in-order {true | false} :コンポーネント リストの順序で起動するかどうか。
• event-action :アラートがトリガーされた場合に実行するアクションを指定します。
– deny-attacker-inline :(インラインのみ)指定された期間、攻撃者のアドレスからの、現在のパケットおよび将来のパケットを送信しません。
– deny-attacker-service-pair-inline: (インラインのみ) 指定された期間、この攻撃者のアドレスと攻撃対象のポートのペアについては、現在のパケットおよび将来のパケットを送信しません。
– deny-attacker-victim-pair-inline: (インラインのみ) 指定された期間、この攻撃者と攻撃対象のアドレスのペアについては、現在のパケットおよび将来のパケットを送信しません。
– deny-connection-inline :(インラインのみ)TCP フローで、現在のパケットおよび将来のパケットを送信しません。
– deny-packet-inline :(インラインのみ)このパケットを送信しません。
– log-attacker-packets :攻撃者のアドレスが含まれているパケットに対する IP ロギングを開始します。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。
– log-pair-packets :攻撃者と攻撃対象のアドレスのペアが含まれているパケットに対する IP ロギングを開始します。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。
– log-victim-packets :攻撃対象のアドレスが含まれているパケットに対する IP ロギングを開始します。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。
– produce-alert :イベントをアラートとしてイベント ストアに書き込みます。
– produce-verbose-alert :攻撃パケットの符号化されたダンプ(切り捨てられている可能性あり)をアラートに組み込みます。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。
– request-block-connection :この接続をブロックする要求を ARC に送信します ブロッキング デバイスは、このアクションを実行するように設定されている必要があります。
– request-block-host :この攻撃者のホストをブロックする要求を ARC に送信します。ブロッキング デバイスは、このアクションを実行するように設定されている必要があります。
– request-rate-limit :レート制限を実行するレート制限要求を ARC に送信します。レート制限デバイスは、このアクションを実行するように設定されている必要があります。
– request-snmp-trap :SNMP 通知を実行する要求をセンサーの通知アプリケーション コンポーネントに送信します。このアクションを実行すると、 produce-alert が選択されていない場合でも、イベント ストアにアラートが書き込まれます。SNMP は、このアクションを実装するようにセンサーで設定されている必要があります。
– reset-tcp-connection :TCP リセットを送信し、TCP フローをハイジャックして終了します。 Reset TCP Connection は、単一の接続を分析する TCP シグニチャでのみ機能します。スイープまたはフラッドに対しては機能しません。
– modify-packet-inline :パケット データを変更して、エンドポイントによるパケットの処理に関して、あいまいな部分を取り除きます。
• meta-key :Meta シグニチャのストレージ タイプを指定します。
– AaBb :攻撃者と攻撃対象のアドレスおよびポート。
– AxBx :攻撃者と攻撃対象のアドレス。
– Axxx :攻撃者のアドレス。
– xxBx :攻撃対象のアドレス。
• meta-reset-interval :Meta シグニチャをリセットする時間(秒単位)を指定します。有効な値の範囲は 0 ~ 3600 秒です。デフォルトは 60 秒です。
(注) シグニチャ 64000 のサブシグニチャ 0 は、同じ送信元アドレスのシグニチャ 2000 のサブシグニチャ 0 およびシグニチャ 3000 のサブシグニチャ 0 からのアラートを認識すると起動されます。送信元アドレス選択は、Meta キーのデフォルト値 Axxx の結果です。たとえば、Meta キー設定を xxBx(宛先アドレス)に変更することによって、動作を変更できます。
次の例では、Meta エンジンに基づいてシグニチャを作成する方法を示します。
Meta エンジンに基づいてシグニチャを作成するには、次の手順に従います。
ステップ 1
管理者権限またはオペレータ権限を持つアカウントを使用して CLI にログインします。
ステップ 2 シグニチャ定義サブモードを開始します。
sensor# configure terminal
sensor(config)# service signature-definition sig1
ステップ 3 シグニチャのシグニチャ ID とサブシグニチャ ID を指定します。カスタム シグニチャの範囲は、60000 ~ 65000 です。
sensor(config-sig)# signatures 64000 0
ステップ 4 シグニチャ エンジンを指定します。
sensor(config-sig-sig)# engine meta
ステップ 5 リストの先頭に c1 という名前のシグニチャを挿入します。
sensor(config-sig-sig-met)# component-list insert c1 begin
ステップ 6 このコンポーネントを照合するシグニチャのシグニチャ ID を指定します。
sensor(config-sig-sig-met-com)# component-sig-id 2000
ステップ 7 コンポーネント リスト サブモードを終了します。
sensor(config-sig-sig-met-com)# exit
ステップ 8 リストの最後に c2 という名前の別のシグニチャを挿入します。
sensor(config-sig-sig-met)# component-list insert c2 end
ステップ 9 このコンポーネントを照合するシグニチャのシグニチャ ID を指定します。
sensor(config-sig-sig-met-com)# component-sig-id 3000
ステップ 10 設定を確認できます。
sensor(config-sig-sig-met-com)# exit
sensor(config-sig-sig-met)# show settings
-----------------------------------------------
event-action: produce-alert <defaulted>
meta-reset-interval: 60 <defaulted>
component-list (min: 1, max: 8, current: 2 - 2 active, 0 inactive)
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
component-subsig-id: 0 <defaulted>
component-count: 1 <defaulted>
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
component-subsig-id: 0 <defaulted>
component-count: 1 <defaulted>
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
unique-victims: 1 <defaulted>
-----------------------------------------------
-----------------------------------------------
component-list-in-order: false <defaulted>
-----------------------------------------------
sensor(config-sig-sig-met)#
ステップ 11 シグニチャ定義サブモードを終了します。
sensor(config-sig-sig-met)# exit
sensor(config-sig-sig)# exit
ステップ 12 Enter を押して変更を適用するか、 no と入力して変更を破棄します。
詳細情報
• シグニチャ イベント アクション プロセッサの詳細については、「シグニチャ イベント アクション プロセッサ」を参照してください。
• Meta エンジンの詳細については、「Meta エンジン」を参照してください。
• Meta エンジン シグニチャの一部であるコンポーネント シグニチャの詳細については、「コンポーネント シグニチャと Meta エンジン」を参照してください。
IPv6 シグニチャの例
次の例では、Atomic IP Advanced カスタム シグニチャが IPv6 でプロトコル ID 88 を禁止する方法を示します。
Atomic IP Advanced シグニチャ エンジンに基づいてシグニチャを作成するには、次の手順に従います。
ステップ 1
管理者権限またはオペレータ権限を持つアカウントを使用して CLI にログインします。
ステップ 2 シグニチャ定義サブモードを開始します。
sensor# configure terminal
sensor(config)# service signature-definition sig0
ステップ 3 シグニチャのシグニチャ ID とサブシグニチャ ID を指定します。カスタム シグニチャの範囲は、60000 ~ 65000 です。
sensor(config-sig)# signatures 60000 0
ステップ 4 シグニチャ エンジンを指定します。
sensor(config-sig-sig)# engine atomic-ip-advanced
ステップ 5 IP バージョンを指定します。
sensor(config-sig-sig-ato)# specify-ip-version yes
ステップ 6 IPv6 を指定します。
sensor(config-sig-sig-ato-yes)# version ipv6
ステップ 7 L4 プロトコルを指定します。
sensor(config-sig-sig-ato-yes-ipv)# exit
sensor(config-sig-sig-ato-yes)# exit
sensor(config-sig-sig-ato)# specify-l4-protocol yes
ステップ 8 プロトコル ID 88 を指定します。
sensor(config-sig-sig-ato-yes)# l4-protocol other-protocol
sensor(config-sig-sig-ato-yes-oth)# other-ip-protocol-id 88
ステップ 9 設定を確認できます。
sensor(config-sig-sig-ato-yes-oth)# show settings
-----------------------------------------------
-----------------------------------------------
sensor(config-sig-sig-ato-yes-oth)#
ステップ 10 シグニチャ定義サブモードを終了します。
sensor(config-sig-sig-ato-yes-oth)# exit
sensor(config-sig-sig-ato-yes)# exit
sensor(config-sig-sig-ato)# exit
sensor(config-sig-sig)# exit
ステップ 11 Enter を押して変更を適用するか、 no と入力して変更を破棄します。
詳細情報
• Atomic IP Advanced エンジンおよびパラメータのリストの詳細については、「Atomic IP Advanced エンジン」を参照してください。
• Atomic エンジンの詳細については、「Atomic エンジン」を参照してください。