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ステートメントを含めます。手記：アプリケーション プロトコルを指定するステートメントのいずれかを含めると、ルーターは
[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 秒ごとに生成されます。イベントが続く限り、ログは生成されます。
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]階層レベルで設定された一致条件に複数の送信元アドレスを含める場合、制限は送信元アドレスごとに個別に適用されます。例えば、次の設定では、合計 20 接続ではなく、各送信元アドレス(10.1.1.1と10.1.1.2)から 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 フラッドが 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 でのネットワーク攻撃に対する保護の設定を参照してください)。
各ルールを定義するには、ルール名を指定し、条件を設定します。次に、[edit services ids]階層レベルでrule-setステートメントと各ルールのruleステートメントを含めることで、ルールの順序を指定します。
[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 攻撃を軽減できます。特定のホストの 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;
}
}
}
}
}