MS-DPC上のIDS
MS-DPCでのSYN Cookie保護について
SYN Cookieは、SYNフラッド攻撃に対する他の防御手段と組み合わせて使用できるステートレスSYNプロキシメカニズムです。SYN Cookieは、MS-DPCマルチサービスカードでサポートされています。
従来のSYNプロキシと同様に、SYNフラッド攻撃のしきい値を超えるとSYN Cookieがアクティブになります。ただし、SYN Cookieはステートレスであるため、SYNセグメントの受信時にセッションやポリシーやルートルックアップを設定することはなく、接続要求キューも維持しません。これにより、CPUとメモリの使用量が大幅に削減され、従来のSYNプロキシメカニズムよりもSYN Cookieを使用する主な利点です。
SYN Cookie が Junos OS で有効化され、宛先サーバーの TCP ネゴシエーション プロキシになると、受信する各 SYN セグメントに対して、暗号化された Cookie を初期シーケンス番号(ISN)として含む SYN/ACK で応答します。Cookieは、元のSYNパケットからの元の送信元アドレスとポート番号、宛先アドレスとポート番号、およびISNのMD5ハッシュです。Cookieを送信した後、Junos OSは元のSYNパケットをドロップし、計算されたCookieをメモリから削除します。Cookie を含むパケットに応答がない場合、攻撃はアクティブな SYN攻撃として記録され、効果的に停止されます。
開始側ホストがTCP ACKフィールドにCookie +1を含むTCPパケットで応答した場合、Junos OSはCookieを抽出し、値から1を引き、Cookieを再計算して、それが正当なACKであることを検証します。正当な場合、Junos OSはセッションを設定し、元のSYNからのソース情報を含むSYNをサーバーに送信することで、TCPプロキシプロセスを開始します。Junos OS は、サーバーから SYN/ACK を受信すると、ACK をサーバーと開始ホストに送信します。この時点で接続が確立され、ホストとサーバーが直接通信できるようになります。
SYN CookieまたはSYNプロキシを使用することで、ルーターデバイスは、IPv6フローにおけるSYNフラッド攻撃から背後にあるTCPサーバーを保護することができます。
図1 は、Junos OSでSYN Cookieがアクティブな場合に、開始側ホストとサーバー間で接続がどのように確立されるかを示しています。
との接続の確立
MS-DPC での IDS ルールの設定
MS-DPCで設定されたIDSルールは、ルーターソフトウェアにイベントをカウントさせるトラフィックを識別します。IDS はステートフル ファイアウォール プロパティに基づいているため、少なくとも 1 つのステートフル ファイアウォール ルールを設定し、IDS ルールとともにサービス セットに含める必要があります。詳細については、「 ステートフルファイアウォールルールの設定」を参照してください。
MS-MPC でネットワーク攻撃保護を設定するには、 MS-MPC でのネットワーク攻撃に対する保護の設定を参照してください。
IDSルールを設定するには、[edit services ids]階層レベルでrule rule-nameステートメントを含めます。
[edit services ids] rule rule-name { match-direction (input | output | input-output); term term-name { from { application-sets set-name; applications [ application-names ]; destination-address (address | any-unicast) <except>; destination-address-range low minimum-value high maximum-value <except>; destination-prefix-list list-name <except>; source-address (address | any-unicast) <except>; source-address-range low minimum-value high maximum-value <except>; source-prefix-list list-name <except>; } then { aggregation (IDS) { destination-prefix prefix-value | destination-prefix-ipv6 prefix-value; source-prefix prefix-value | source-prefix-ipv6 prefix-value; } (force-entry | ignore-entry); logging { syslog; threshold rate; } session-limit { by-destination (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } by-pair (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } by-source (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } } syn-cookie { mss value; threshold rate; } } } }
各IDSルールは、 [edit firewall] 階層レベルで設定されたフィルターと同様に、一連の用語で構成されています。用語は以下で構成されています。
fromステートメント—含めたり除外したりする一致条件とアプリケーションを指定します。thenステートメント—ルーターソフトウェアが実行するアクションとアクション修飾子を指定します。
以下のセクションでは、IDSルールの内容について詳しく説明します。
IDSルールの一致方向の設定
各ルールには、インターフェイスの入力側または出力側のどちらに一致を適用するかを指定するmatch-directionステートメントを含める必要があります。一致を適用する場所を設定するには、[edit services ids rule rule-name]階層レベルでmatch-direction (input | input-output | output)ステートメントを含めます。
[edit services ids rule rule-name] match-direction (input | output | input-output);
match-direction input-output を設定した場合、双方向ルールの作成は です。
一致方向は、ASまたはマルチサービスPICを介するトラフィックフローに関して使用されます。パケットがPICに送信されると、方向情報も一緒に伝送されます。
インターフェイスサービスセットでは、パケットの方向は、パケットがサービスセットが適用されているインターフェイスに出入りするかどうかによって決定されます。
ネクストホップサービスセットでは、パケットの方向は、パケットをASまたはマルチサービスPICにルーティングするために使用されるインターフェイスによって決定されます。内部インターフェイスを使用してパケットをルーティングする場合は、パケットの方向が入力されます。外部インターフェイスを使用してパケットをPICに送信する場合は、パケットの方向が出力されます。内部インターフェイスと外部インターフェイスの詳細については、 サービスインターフェイスに適用するサービスセットの設定を参照してください。
ASまたはマルチサービスPICで、フロールックアップが実行されます。フローが見つからない場合は、ルール処理が実行されます。サービスセット内のすべてのルールが考慮されます。ルール処理中、パケットの方向がルールの方向と比較されます。パケットの方向に一致する方向情報を持つルールのみが考慮されます。
IDSルールでの一致条件の設定
IDS一致条件を設定するには、[edit services ids rule rule-name term term-name]階層レベルでfromステートメントを含めます。
[edit services ids rule rule-name term term-name] from { application-sets set-name; applications [ application-names ]; destination-address (address | any-unicast) <except>; destination-address-range low minimum-value high maximum-value <except>; destination-prefix-list list-name <except>; source-address (address | any-unicast) <except>; source-address-range low minimum-value high maximum-value <except>; source-prefix-list list-name <except>; }
fromステートメントを省略すると、ソフトウェアはすべてのイベントを受け入れ、処理のためにIDSキャッシュに配置します。
送信元アドレスと宛先アドレスは、IPv4またはIPv6のいずれかです。ファイアウォールフィルターを設定するのと同じ方法で、宛先アドレス、宛先アドレスの範囲、送信元アドレス、または送信元アドレスの範囲を一致条件として使用できます。詳細については、 『ルーティングポリシー、ファイアウォールフィルター、およびトラフィックポリサーユーザーガイド』を参照してください。
または、[edit policy-options]階層レベルでprefix-listステートメントを含め、IDSルールにdestination-prefix-listまたはsource-prefix-listステートメントを含めることで、送信元または宛先のプレフィックスのリストを指定することができます。例については、「例:ステートフルファイアウォールルールの設定」を参照してください。
また、 [edit applications] 階層レベルで設定したアプリケーションプロトコル定義を含めることもできます。詳細については、 アプリケーションのプロパティの設定を参照してください。
1つ以上の特定のアプリケーションプロトコル定義を適用するには、
[edit services ids rule rule-name term term-name from]階層レベルでapplicationsステートメントを含めます。定義したアプリケーションプロトコル定義の1つ以上のセットを適用するには、
[edit services ids rule rule-name term term-name from]階層レベルでapplication-setsステートメントを含めます。注:アプリケーションプロトコルを指定するステートメントの1つを含めると、ルーターは
[edit applications]階層レベルの対応する設定からポートとプロトコルの情報を導き出します。これらのプロパティを一致条件として指定することはできません。
アプリケーションで一致が発生した場合、アプリケーションプロトコルは show services ids コマンド出力に別途表示されます。詳細については、 CLIエクスプローラを参照してください。
IDSルールでのアクションの設定
IDSアクションを設定するには、[edit services ids rule rule-name term term-name]階層レベルでthenステートメントを含めます。
[edit services ids rule rule-name term term-name] then { aggregation (IDS) { destination-prefix prefix-value | destination-prefix-ipv6 prefix-value; source-prefix prefix-value | source-prefix-ipv6 prefix-value; } (force-entry | ignore-entry); logging { syslog; threshold rate; } session-limit { by-destination (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } by-pair (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } by-source (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } } syn-cookie { mss value; threshold rate; } }
以下の可能なアクションを設定できます。
aggregation—ルーターは、イベントをIDS処理に渡す前に、指定された送信元または宛先プレフィックスでラベル付けされたトラフィックを集約します。これは、特定の送信元または宛先ホストに接続されているすべてのトラフィックを調べる場合に役立ちます。特定のアプリケーションやポートなど、他のマーカーでトラフィックを収集するには、一致条件でその値を設定します。アグリゲーションプレフィックスを設定するには、
[edit services ids rule rule-name term term-name then]階層レベルでaggregationステートメントを含め、source-prefix、destination-prefix source-prefix-ipv6、またはdestination-prefix-ipv6の値を指定します。[edit services ids rule rule-name term term-name then] aggregation (IDS) { destination-prefix prefix-value | destination-prefix-ipv6 prefix-value; source-prefix prefix-value | source-prefix-ipv6 prefix-value; }
source-prefixとdestination-prefixの値は、1から32までの整数である必要があります。source-prefix-ipv6とdestination-prefix-ipv6の値は、1から128までの整数である必要があります。(force-entry | ignore-entry)—force-entryは、1つのイベントが登録された後、後続のイベント用にIDSキャッシュに恒久的なスポットを提供します。デフォルトでは、IDSソフトウェアは、疑わしい動作を示さない「良好な」パケットに関する情報を記録しません。force-entryステートメントを使用して、疑わしいホストからのすべてのトラフィックを記録できます。他の方法ではカウントされないトラフィックも含めます。ignore-entryすべての IDS イベントが無視されるようにします。このステートメントを使用すると、IDSがイベントとしてカウントする一時的な異常も含めて、信頼できるホストからのすべてのトラフィックを無視できます。デフォルトとは異なるエントリ動作を設定するには、
[edit services ids rule rule-name term term-name then]階層レベルでforce-entryまたはignore-entryステートメントを含めます。[edit services ids rule rule-name term term-name then] (force-entry | ignore-entry);
logging—イベントはシステムログファイルに記録されます。ロギングを設定するには、
[edit services ids rule rule-name term term-name then]階層レベルでloggingステートメントを含めます。[edit services ids rule rule-name term term-name then] logging { syslog; threshold rate; }
オプションで、システムログメッセージの生成をトリガーするしきい値レートを含めることができます。しきい値レートは、1秒あたりのイベント数で指定されます。IDSログは、報告された異常ごとに60秒ごとに1回生成されます。ログは、イベントが続く限り生成されます。
session-limit—指定されたしきい値に達した場合、ルーターはオープンセッションを制限します。閾値を設定するには、
[edit services ids rule rule-name term term-name then]階層レベルでsession-limitステートメントを含めます。[edit services ids rule rule-name term term-name then] session-limit { by-destination (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } by-pair (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } by-source (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } }
トラフィックの方向に基づいてフロー制限のしきい値を設定します。
1つの内部ホストまたはサブネットからの発信セッション数を制限するには、
by-sourceステートメントを設定します。IPアドレス、サブネット、またはアプリケーションのペア間のセッション数を制限するには、
by-pairステートメントを設定します。受信セッションの数を1つの外部パブリックIPアドレスまたはサブネットに制限するには、
by-destinationステートメントを設定します。
各方向に対して、以下のしきい値を設定できます。
hold-time seconds—rateまたはpackets測定がしきい値に達したら、指定された秒数だけすべての新しいフローを停止します。hold-timeが有効になると、レートが指定された制限を下回っても、指定された時間トラフィックがブロックされます。デフォルトでは、hold-timeの値は0で、範囲は0〜60秒です。maximum number—アプリケーションごとのIPアドレスまたはサブネットあたりのオープンセッションの最大数。範囲は 1 から 32,767 です。packets number—アプリケーションごとのIPアドレスまたはサブネットあたりの最大パケット数(pps)。範囲は4から2,147,483,647です。rate number—アプリケーションごとのIPアドレスまたはサブネットあたりの1秒あたりの最大セッション数。範囲は 4 から 32,767 です。[edit services ids rule rule-name term term-name from]階層レベルで設定された一致条件に複数の送信元アドレスを含めると、各送信元アドレスに個別に制限が適用されます。例えば、以下の設定では、各送信元アドレス(10.1.1.1および10.1.1.2)からの接続が許可されますが、合計 20 個の接続ではなく、20 個の接続が許可されます。同じロジックがapplicationsとdestination-addressの一致条件にも適用されます。[edit services ids rule rule-name term term-name] from { source-address 10.1.1.1; source-address 10.1.1.2; } then { session-limit by-source { maximum 20; } }注:IDS 制限は、ステートフル ファイアウォール ルールによって受け入れられるパケットに適用されます。ステートフルファイアウォールルールによって破棄または拒否されたパケットには適用されません。例えば、ステートフルファイアウォールが受信トラフィックの75%を受け入れ、残りの25%が拒否または破棄された場合、IDS制限はトラフィックの75%にのみ適用されます。
syn-cookie—ルーターはSYN-cookie防御メカニズムをアクティブにします。SYN-cookie値を設定するには、
[edit services ids rule rule-name term term-name then]階層レベルでsyn-cookieステートメントを含めます。[edit services ids rule rule-name term term-name then] syn-cookie { mss value; threshold rate; }
SYN-Cookie防御を有効にする場合、SYN-Cookieアクティビティをトリガーするしきい値レートと、TCP遅延バインディングの伝送制御プロトコル(TCP)最大セグメントサイズ(MSS)値の両方を含める必要があります。しきい値レートは、1秒あたりのSYN攻撃で指定されます。デフォルトでは、TCP MSS値は1500です。範囲は128から8192です。
SYNフラッド攻撃の処理とSYN Cookie保護
SYNフラッド攻撃の主な目的は、サイトの新しいネットワーク接続をすべて消費し、承認された正当なユーザーがネットワークリソースに接続できないようにすることです。SYN(シーケンス番号の同期)パケットは、システムに送信される最初の接続要求です。SYNパケットには、受信者が応答する必要があるIDが含まれています。パケットに不正なIDが含まれている場合、受信システムは意図した接続開始側に応答するときに接続確認応答を受信します。最終的に、このハーフオープン接続がタイムアウトし、受信側の着信チャネルが別の要求を通常どおり処理できるようになります。SYNフラッド攻撃は、このようなリクエストを非常に多く送信するため、すべての着信接続は受信されない確認応答を待ち続けて拘束されます。この状態により、合法的なユーザーはサーバーを使用できなくなります (ただし、ユーザー セッションが確立された場合、ちょうど拘束された接続の 1 つがタイムアウトした瞬間です)。SYNフラッド攻撃は、コネクションレス攻撃です。実際の送信元IPアドレスは必要なく、正当な宛先IPまたはポートアドレスを使用するため、正規のパケットと区別することは事実上不可能です。そのため、フィルターやステートフルファイアウォールルールのみを使用して、このタイプの攻撃を防ぐことは非常に困難です。基本的に、このタイプの攻撃から保護する方法は 3 つだけです。
インターセプト(遅延バインディング)—ファイアウォールは受信したTCP同期リクエストを傍受し、サーバーに代わってクライアントとの接続を、クライアントに代わってサーバーとの接続を確立します。両方の接続が成功した場合、ファイアウォールは 2 つの接続を透過的にマージします。ファイアウォールは通常、SYN攻撃によって自身のリソースが消費されるのを防ぐために、積極的なタイムアウトを設定します。これは、処理とメモリの要件に関して最も集中的なソリューションです。
監視(SYN防御)—ファイアウォールはハーフオープン接続を受動的に監視し、設定可能な時間後にサーバー上の接続をアクティブに閉じます。
SYN Cookie—SYN Cookie は、TCP サーバーによって選択された最初の TCP シーケンス番号に対して特定された選択肢です。接続を要求するホストは、SYN-floodがIDSによって進行中として検出されている間、オープンTCPソケットに接続するためにCookieで応答する必要があります。
ジュニパーネットワークスのルーターは、ステートフルファイアウォールとIDSメカニズムの組み合わせをサポートし、SYN Cookieと監視(SYN防御)メソッドをサポートします。SYNフラッド攻撃の鍵となるのは、被害者または攻撃されたネットワーク要素のSYNキューを埋めることです。SYN Cookie 防御方法では、SYN キューがいっぱいになったとき、またはファイアウォールや IDS アプリケーションの場合は特定のしきい値に達したときに、被害者は接続要求の受け入れを継続できます。しきい値に達すると、SYNセグメントの情報から暗号化Cookie(32ビット数)が作成され、SYNセグメントが削除されます。このCookieは、クライアントに送信されるSYN-ACKの初期シーケンス番号として使用されます。Cookie(プラス1)は、正規のクライアントからのACKの確認番号としてファイアウォールまたはIDSアプリケーションに返されます。返されたCookieを検証し、SYNセグメントの最も重要な部分をCookieから再構築して、接続を確立できます。SYN フラッドのなりすましクライアントは ACK を送信しないため、SYN Cookie が使用されている場合は、いかなる状態でもリソースが割り当てられません。SYNフラッド対策は、攻撃を受けているホストに対してのみ使用することが推奨されます。異常テーブルは、信頼性の高い攻撃認識に使用することも、ステートフルファイアウォール内で有効にすることもできます。このようなタイプの設定は、攻撃が発生した場合のシステムリソース(特にフローテーブル)の枯渇を防ぐのにも役立ちます。
複数のサービスを組み合わせる場合、一般的なパスは順方向と逆方向で考慮すべき重要な要素です。これは、ルールに一致させるために NAT 前または NAT 後のどちらのアドレスを使用する必要があるかを判断するために NAT が導入されている場合に特に当てはまります。LANインターフェイスからWANインターフェイスへの転送パスでは、最初にIDSとステートフルファイアウォールが実行され、次にNAT、最後にIPSecが実行されます。この一連のサービス処理は、ステートフルファイアウォールがプレNATアドレスで一致する必要があるのに対し、IPSecトンネルがポストNATアドレスで一致する必要があることを示しています。リターンパスでは、最初にIPSecパケットが処理され、次にNAT、最後にステートフルファイアウォールが処理されます。この処理順序により、IPSecはパブリックアドレスを照合し、ステートフルファイアウォールはプライベートアドレスと照合することができます。ファイアウォール、NAT、IDSサービスを個別に設定する必要があります。IPSec over GREが他のサービスをオンにしたルーターに実装されている場合、パケットの処理ははるかに複雑になります。この動作は、Junos OSがGREカプセル化後にGRE パケットを独自の方法で処理するために発生します。パケットがGREパケットにカプセル化された後、入力インターフェイスでネクストホップ発信インターフェイスとしてマークされます。このマーキング方法では、入力フィルターまたは入力サービスが許可されていない場合、GRE パケットがブロックされます。
Junos OSサービスは、ポートスキャンやトラフィックパターンの異常などの攻撃の検出に役立つ、限られたIDSルールセットをサポートします。また、フロー数、セッション数、レートを制限することで、一部の攻撃防御にも対応しています。さらに、SYN Cookieメカニズムを実装することで、SYN攻撃から保護します。侵入検出および防止(IDP)サービスは上位レイヤーのアプリケーションシグネチャをサポートしていないため、攻撃に対する効果的なアプローチは、SYN攻撃に対する保護を設定することです。IDPソリューションは主に監視ツールであり、不可欠な予防ツールではありません。SYN攻撃を防ぐために、ルーターは一種のSYN「プロキシ」として動作し、Cookie値を使用します。この機能を有効にすると、ルーターは最初のSYNパケットに、シーケンス番号フィールドに固有のCookie値を含むSYN-ACKパケットを返します。イニシエーターがシーケンスフィールドに同じCookieで応答した場合、TCPフローが受け入れられます。レスポンダが応答しない場合、または間違った Cookie で応答した場合、フローは破棄されます。この防御をトリガーするには、SYN Cookieのしきい値を設定する必要があります。SYN Cookie 防御を有効にするには、IDS ルールアクションに、この機能を有効にするタイミングを示すしきい値と、SYN プロキシとして動作するときにルーターにセグメント化されたフラグメントが管理されないようにするための MSS 値が含まれている必要があります。
[edit] user@host# set services ids rule simple-ids term 1 then syn-cookie
MS-DPCでのIDSルールセットの設定
rule-setステートメントを使用して、ルーターソフトウェアがデータストリーム内のパケットに対して実行するアクションを決定するIDSルールの集合を定義できます。これは、MS-DPCマルチサービスカードでサポートされています。(MS-MPCでネットワーク攻撃保護を設定するには、MS-MPCでのネットワーク攻撃に対する保護の設定を参照してください)。
各ルールを定義するには、ルール名を指定し、条件を設定します。次に、各ルールのruleステートメントとともに、[edit services ids]階層レベルでrule-setステートメントを含めて、ルールの順序を指定します。
[edit services ids] rule-set rule-set-name { rule rule-name; }
ルーターソフトウェアは、設定で指定した順序でルールを処理します。ルール内の条件がパケットに一致する場合、ルーターは対応するアクションを実行し、ルール処理は停止します。ルール内のパケットに一致する条件がない場合、処理はルールセット内の次のルールに進みます。どのルールもパケットに一致しない場合、パケットはデフォルトで破棄されます。
例:MS-DPC での IDS ルールの設定
以下の設定では、宛先アドレスが 10.410.6.2 のフローに遭遇した場合に、IDS 異常テーブルに永続的なエントリーを追加します。この例は、MS-DPCマルチサービスカードでサポートされています。(MS-MPCでネットワーク攻撃保護を設定するには、 MS-MPCでのネットワーク攻撃に対する保護の設定を参照してください)。
[edit services ids]
rule simple_ids {
term 1 {
from {
destination-address 10.410.6.2/32;
}
then {
force-entry;
logging {
threshold 1;
syslog;
}
}
}
term default {
then {
aggregation {
source-prefix 24;
}
}
}
match-direction input;
}
IDS設定はステートフルファイアウォールメカニズムと連携して機能し、ステートフルファイアウォールから報告される異常に大きく依存します。以下の設定例は、この関係を示しています。
[edit services ids]
rule simple_ids {
term 1 {
from {
source-address 10.30.20.2/32;
destination-address {
10.30.10.2/32;
10.30.1.2/32 except;
}
applications appl-ftp;
}
then {
force-entry;
logging {
threshold 5;
syslog;
}
syn-cookie {
threshold 10;
}
}
}
match-direction input;
}
[edit services stateful-firewall]
rule my-firewall-rule {
match-direction input-output;
term term1 {
from {
source-address 10.30.20.2/32;
applications appl-ftp ;
destination-address {
10.30.10.2/32;
10.30.1.2/32 except;
}
}
then {
accept;
syslog;
}
}
}
ステートフルファイアウォールまたはNATサービスを使用して、IDSアプリケーションの入力データを生成します。IDSサービスを有効にして設定する場合、少なくとも1つのルール(すべてのトラフィックを受け入れるまたは破棄)でステートフルファイアウォールを有効にする必要があります。システムが攻撃を受けると、ステートフルファイアウォールは攻撃イベントの正確で完全なリストをIDSシステムに送信します。お使いのネットワーク環境では、IDS システムがそのような攻撃をすべて報告するように、あらゆる攻撃からシステムを完全に保護することができます。システムが処理するトラフィック帯域幅に負担がかからないように、すべての攻撃や認証されていないアクセスシナリオからシステムを保護するように設定する際には注意が必要です。また、攻撃に対応するファイアウォールsyslogメッセージとIDSテーブルとの相関関係を検証することも重要です。IDSテーブルは、ファイアウォールベースのsyslogメッセージと比較して、異常またはエラーの数がわずかに少ない必要があります。適切なshowコマンドを使用して、IDSテーブルを表示できます。
デフォルトのステートフルファイアウォールルールは、内部インターフェイスから外部インターフェイスへの接続開始のみを許可し、それ以外のパケットはすべて破棄するというシンプルなものにすることができます。しかし、実際のネットワーク環境では、特定のトリビュタリユニットポートのみを開く設定、複雑なプロトコルにはアプリケーション層ゲートウェイ(ALG)を使用する、発信接続とHTTPサーバーなどの内部ホストの両方にNATを使用するなど、ルールは一般的により複雑になります。そのため、必要に応じてシステムを構成し、単純なルールと複雑なルールを連携させる必要があります。例えば、SYN攻撃が、単に破棄される内部アドレスに向けられている場合、IDSシステムに異常を報告する必要はありません。しかし、SYN攻撃が実際のHTTPサーバーに向けられている場合は、異常を報告する必要があります。IDSシステムは、TCP SYN Cookie防御機能を使用してSYN攻撃を緩和できます。特定のホストの1秒あたりSYN数のしきい値と最大セグメントサイズ(MSS)を設定することで、SYN Cookie保護方法を有効にできます。IDSシステムはステートフルファイアウォールを使用するため、ファイアウォールルールはサービスセットで定義する必要があります。ステートフルファイアウォール(ルール条件一致条件)で[edit services service-set service-set-name stateful-firewall-rules rule-name term term-name]階層レベルでfromステートメントを設定しない場合、すべてのイベントがIDSキャッシュに配置されることを意味します。
以下の例は、フロー制限の設定を示しています。
[edit services ids]
rule ids-all {
match-direction input;
term t1 {
from {
application-sets alg-set;
}
then {
aggregation {
destination-prefix 30; /* IDS action aggregation */
}
logging {
threshold 10;
}
session-limit {
by-destination {
hold-time 0;
maximum 10;
packets 200;
rate 100;
}
by-pair {
hold-time 0;
maximum 10;
packets 200;
rate 100;
}
by-source {
hold-time 5;
maximum 10;
packets 200;
rate 100;
}
}
}
}
}