セキュリティ ポリシーの設定

セキュリティポリシーとは、指定されたサービスを使用して、指定された送信元から特定の宛先へのトラフィックを制御する一連のステートメントです。ポリシーは、2 つのポイント間で特定のタイプのトラフィックを一方方向に許可、拒否、またはトンネリングします。

各ポリシーは、次のもので構成されます。

• ポリシーの一意の名前。

• from-zone と to-zone (例: user@host)#set security policies from-zone untrust to-zone untrust

• ポリシー ルールを適用するために満たす必要のある条件を定義する一致条件のセット。一致条件は、送信元 IP アドレス、IP アドレス、およびアプリケーションに基づいています。ユーザー・アイデンティティ・ファイアウォールは、ポリシー・ステートメントの一部として追加のタプルsource-identityを含めることで、より細分性を提供します。

• 一致した場合に実行する一連のアクション (許可、拒否、または拒否)。

• アカウンティングおよび監査の要素 - カウント、ログ記録、または構造化システム ログ記録。

デバイスは、これらの仕様に一致するパケットを受信すると、ポリシーで指定されたアクションを実行します。

セキュリティ ポリシーは、トランジット トラフィックに一連のルールを適用し、ファイアウォールを通過できるトラフィックと、ファイアウォールを通過するトラフィックに対して実行されるアクションを特定します。指定した基準に一致するトラフィックに対するアクションには、許可、拒否、拒否、ログ、カウントなどがあります。

セキュリティポリシーは、セキュリティルールをコンテキスト内のトランジットトラフィック(from-zone から to-zone)に適用します。各ポリシーは、その名前によって一意に識別されます。トラフィックは、送信元ゾーンと宛先ゾーン、送信元アドレスと宛先アドレス、およびトラフィックがプロトコルヘッダーで伝送するアプリケーションをデータプレーンのポリシーデータベースと照合することによって分類されます。

各ポリシーは、次の特性に関連付けられています。

• 送信元ゾーン

• 宛先ゾーン

• 1 つまたは複数の送信元アドレス名またはアドレス セット名

• 1 つまたは複数の宛先アドレス名またはアドレス セット名

• 1つまたは複数のアプリケーション名またはアプリケーション・セット名

これらの特性を 一致条件と呼びます。各ポリシーには、許可、拒否、拒否、カウント、ログ、VPNトンネルなどのアクションも関連付けられています。一致条件の引数は、ポリシー、送信元アドレス、宛先アドレス、アプリケーション名を設定するときに指定する必要があります。

を指定して、ワイルドカードエントリー anyを使用して IPv4 または IPv6 アドレスでポリシーを設定できます。IPv6 トラフィックのフロー サポートが有効になっていない場合、 any は IPv4 アドレスを照合します。IPv6 トラフィックのフロー サポートが有効になっている場合、 any は IPv4 アドレスと IPv6 アドレスの両方を照合します。IPv6 トラフィックのフローベース転送を有効にするには、 set security forwarding-options family inet6 mode flow-based コマンドを使用します。また、送信元アドレスと宛先アドレスの一致条件にワイルドカード any-ipv4 または any-ipv6 を指定して、IPv4 アドレスのみまたは IPv6 アドレスのみを含めるようにすることもできます。

IPv6 トラフィックのフロー サポートが有効になっている場合、セキュリティ ポリシーで設定できる IPv4 または IPv6 アドレスの最大数は、次の一致条件に基づきます。

• Number_of_src_IPv4_addresses + number_of_src_IPv6_addresses * 4 <= 1024

• Number_of_dst_IPv4_addresses + number_of_dst_IPv6_addresses * 4 <= 1024

一致条件の理由は、IPv6 アドレスが IPv4 アドレスの 4 倍のメモリ空間を使用するからです。

手記：

IPv6 アドレスでセキュリティ ポリシーを設定できるのは、IPv6 トラフィックのフロー サポートがデバイスで有効になっている場合のみです。

特定のアプリケーションを指定しない場合は、デフォルトのアプリケーションとして any を入力します。デフォルトのアプリケーションを検索するには、設定モードから「 show groups junos-defaults | find applications (predefined applications)」と入力します。たとえば、アプリケーション名を指定しない場合、ポリシーはアプリケーションをワイルドカード(デフォルト)としてインストールされます。したがって、特定のポリシーの残りのパラメータに一致するデータトラフィックは、データトラフィックのアプリケーションタイプに関係なく、ポリシーと一致します。

手記：

ポリシーが複数のアプリケーションで設定され、そのうちの複数のアプリケーションがトラフィックに一致する場合、一致条件に最も適したアプリケーションが選択されます。

トラフィックが一致する最初のポリシーのアクションがパケットに適用されます。一致するポリシーがない場合、パケットは破棄されます。ポリシーは上から下に検索されるため、より具体的なポリシーをリストの一番上に配置することをお勧めします。また、最上部付近に IPSec VPN トンネル ポリシーを配置する必要があります。特定のユーザーにすべてのインターネットアプリケーションへのアクセスを許可するポリシーなど、より一般的なポリシーをリストの一番下に配置します。たとえば、特定のポリシーがすべて解析され、正当なトラフィックが許可/カウント/ログに記録された後、すべて拒否またはすべて拒否のポリシーを最下部に配置します。

手記：

IPv6 アドレスのサポートは、Junos OS リリース 10.2 で追加されました。Junos OS リリース 10.4 では、アクティブ/アクティブ シャーシ クラスター構成での IPv6 アドレスのサポート(アクティブ/パッシブ シャーシ クラスター設定の既存のサポートに加えて)が追加されています。

ポリシールックアップにより、宛先ゾーン、宛先アドレス、エグレスインターフェイスが特定されます。

ポリシーを作成するときは、次のポリシー・ルールが適用されます:

• セキュリティポリシーは、to-zone方向にfrom-zoneに設定されます。特定のゾーン方向の下で、各セキュリティ ポリシーには、名前、一致条件、アクション、およびその他のオプションが含まれます。

• ポリシー名、一致条件、およびアクションは必須です。

• ポリシー名はキーワードです。

• 一致条件の送信元アドレスは、 from-zone内の 1 つ以上のアドレス名またはアドレス セット名で構成されます。

• 一致条件の宛先アドレスは、 to-zone内の 1 つ以上のアドレス名またはアドレス セット名で構成されます。

• 一致条件のアプリケーション名は、1つ以上のアプリケーションまたはアプリケーションセットの名前で構成されます。

• 許可、拒否、または拒否のいずれかのアクションが必要です。

• アカウンティング要素と監査要素 (count と log) を指定できます。

• セッションの最後に session-close コマンドを使用して、またはセッションの開始時に session-init コマンドを使用して、ロギングを有効にできます。

• カウントアラームがオンになっている場合は、アラームしきい値をバイト/秒またはキロバイト/分で指定します。

• 以下の条件がない限り、 global を from-zone または to-zone として指定することはできません。

  to-zoneを大域ゾーンとして構成したポリシーには、静的 NAT または受信 NAT がポリシーで構成されていることを示す宛先アドレスが 1 つ必要です。

• NAT のポリシー許可オプションが簡素化されました。各ポリシーは、オプションでNAT変換を許可するか、許可しないか、または気にしないかを示します。

• アドレス名の先頭に以下の予約済みプレフィックスを使用することはできません。これらは、アドレス NAT 設定にのみ使用されます。

  • static_nat_

  • incoming_nat_

  • junos_

• アプリケーション名を junos_ 予約済みプレフィックスで始めることはできません。

ポリシー設定同期メカニズムの強化により、ルーティングエンジン(RE)とパケット転送エンジン(PFE)間のデバイスからも削除されます方法が改善され、システムの信頼性とセキュリティが向上します。このメカニズムにより、ポリシーが自動的かつ正確に同期されます。さらに、システムはセキュリティ ポリシーの設定変更プロセス中のフロー ドロップを効果的に防止します。

• ファイルのシリアル化
• ポリシー設定変更時のフローセッション中断の防止

• メモリとエラー処理
• 論理システムとテナントシステムのサポート

セルフトラフィックのセキュリティポリシーを設定して、セルフトラフィックにサービスを適用できます。ホストアウトバウンドポリシーは、ホストデバイスから発信されたパケットがフローを通過し、このパケットの着信インターフェイスがローカルに設定されている場合にのみ機能します。

セルフトラフィックを使用する利点は、以下のとおりです。

• トランジット トラフィックに使用される既存のポリシーまたはフロー インフラストラクチャのほとんどを活用できます。

• サービスを有効にするために個別のIPアドレスは必要ありません。

• デバイス上の任意のインターフェイスのIP アドレスを使用して、任意のホストインバウンドトラフィックにサービスまたはポリシーを適用できます。

手記：

デフォルトのセキュリティ ポリシー ルールは、セルフ トラフィックに影響しません。

手記：

セキュリティポリシーは、関連するサービスのみによるセルフトラフィックに対して設定できます。たとえば、ホスト送信トラフィックで fwauth サービスを設定することは関係がなく、gprs-gtp サービスはセルフ トラフィックのセキュリティ ポリシーとは関係ありません。

セルフトラフィックのセキュリティポリシーは、 junos-host ゾーンと呼ばれる新しいデフォルトセキュリティゾーンで設定されます。junos-hostゾーンはjunos-defaults設定の一部となるため、ユーザーはこれを削除できません。interfaces、screen、tcp-rst、host-inbound-traffic オプションなどの既存のゾーン設定は、junos-host ゾーンにとって意味がありません。そのため、junos-hostゾーンに専用の設定はありません。

手記：

host-inbound-traffic を使用して、デバイスへの着信接続を制御できます。ただし、デバイスから送信されるトラフィックは制限されません。一方、junos-host-zoneでは、選択したアプリケーションを選択し、送信トラフィックを制限することもできます。たとえば、NAT、IDP、コンテンツセキュリティなどのサービスを、junos-host-zoneを使用してデバイスを通過するトラフィックに対して有効にできるようになりました。

セキュリティポリシーを作成するには、以下のタスクを完了する必要があります。

1. ゾーンを作成します。 例: セキュリティ ゾーンの作成を参照してください。

2. ポリシーのアドレスを使用してアドレス帳を設定します。 例:アドレスブックとアドレスセットの設定を参照してください。

3. そのタイプのトラフィックにポリシーを適用することを示すアプリケーション(またはアプリケーション セット)を作成します。 例:セキュリティポリシーアプリケーションおよびアプリケーションセットの設定を参照してください。

4. ポリシーを作成します。 例:すべてのトラフィックを許可または拒否するセキュリティポリシーの設定、 例:選択したトラフィックを許可または拒否するセキュリティポリシーの設定、および 例:ワイルドカードアドレストラフィックを許可または拒否するセキュリティポリシーの設定を参照してください。

5. スケジューラをポリシーに使用する予定がある場合は、スケジューラを作成します。 例:1 日を除く日次スケジュールのスケジューラの設定を参照してください。

ファイアウォールポリシーウィザードでは、基本的なセキュリティポリシーの設定を行うことができます。より高度な設定を行うには、J-Web インターフェイスまたは CLI を使用します。

セキュアなネットワークはビジネスに不可欠です。ネットワークを保護するには、ネットワーク管理者が、そのビジネス内のすべてのネットワークリソースと、それらのリソースに必要なセキュリティレベルの概要を示すセキュリティポリシーを作成する必要があります。セキュリティポリシーは、セキュリティルールをコンテキスト(from-zone からto-zone)内のトランジットトラフィックに適用し、各ポリシーはその名前によって一意に識別されます。トラフィックは、送信元と宛先のゾーン、送信元と宛先のアドレス、トラフィックがプロトコルヘッダーで伝送するアプリケーションをデータプレーンのポリシーデータベースと照合することによって分類されます。

プラットフォームのサポートは、インストールされた Junos OS のリリースによって異なります。

各ルールのアドレスとアプリケーションの数を増やすと、ポリシー定義で使用されるメモリ量が増加し、ポリシーが 80,000 未満でシステムのメモリが不足する場合があります。

パケット転送エンジン(PFE)およびルーティングエンジン(RE)上のポリシーの実際のメモリ使用率を取得するには、メモリツリーのさまざまなコンポーネントを考慮する必要があります。メモリ ツリーには、次の 2 つのコンポーネントが含まれます。

• ポリシーコンテキスト:このコンテキストですべてのポリシーを整理するために使用されます。ポリシーコンテキストには、送信元ゾーンや宛先ゾーンなどの変数が含まれます。

• ポリシーエンティティ - ポリシーデータを保持するために使用されます。ポリシーエンティティは、ポリシー名、IPアドレス、アドレス数、アプリケーション、ファイアウォール認証、WebAuth、IPsec、数、アプリケーションサービス、Junos Services Framework(JSF)などのパラメータを使用してメモリを計算します。

さらに、ポリシー、ルールセット、およびその他のコンポーネントの保存に使用されるデータ構造は、パケット転送エンジンとルーティングエンジンで異なるメモリを使用します。例えば、ポリシー内の各アドレスのアドレス名はルーティングエンジンに保存されますが、パケット転送エンジンレベルではメモリは割り当てられません。同様に、ポート範囲はプレフィックスとマスクのペアに拡張され、パケット転送エンジンに保存されますが、そのようなメモリはルーティングエンジンに割り当てられません。

したがって、ポリシーの構成に応じて、ルーティングエンジンへのポリシー寄与者はパケット転送エンジンに対するポリシー寄与者と異なり、メモリは動的に割り当てられます。

メモリは、「遅延削除」状態によっても消費されます。遅延削除状態では、デバイスがポリシー変更を適用すると、一時的なピーク使用量が発生し、古いポリシーと新しいポリシーの両方が存在します。そのため、短期間、パケット転送エンジンには古いポリシーと新しいポリシーの両方が存在し、2倍のメモリ要件を占有します。

そのため、メモリ要件はポリシーの特定の設定に依存し、メモリは動的に割り当てられるため、任意の時点でいずれかのコンポーネント(パケット転送エンジンまたはルーティングエンジン)によって使用されているメモリ量を明確に推測する明確な方法はありません。

ポリシー実装に関する次のベスト プラクティスにより、システム メモリをより有効に活用し、ポリシー構成を最適化できます。

• 送信元アドレスと宛先アドレスに単一のプレフィックスを使用します。たとえば、/32 アドレスを使用して各アドレスを個別に追加する代わりに、必要な IP アドレスのほとんどをカバーする大きなサブネットを使用します。

• 可能な限り、アプリケーション「any」を使用してください。ポリシーで個々のアプリケーションを定義するたびに、追加の 52 バイトを使用できます。

• IPv6 アドレスはより多くのメモリを消費するため、使用する IPv6 アドレスを少なくします。

• デバイスからも削除されます。送信元または宛先の各ゾーンは、約 16,048 バイトのメモリを使用します。

• 次のパラメータは、指定されたバイトによるメモリの消費方法を変更できます。

  • ファイアウォール認証 - 約 16 バイト以上 (固定なし)

  • Web認証 - 約16バイト以上(未固定)

  • IPsec-12 バイト

  • アプリケーション サービス - 28 バイト

  • カウント - 64 バイト

• ポリシーのコンパイル前後にメモリ使用率を確認します。

  手記：

  デバイスごとに必要なメモリは異なります。一部のデバイスはデフォルトで 512,000 セッションをサポートし、ブートアップ メモリは通常 72 〜 73 % です。他のデバイスは最大100万セッションを持つことができ、ブートアップメモリは最大83〜84%です。最悪のシナリオでは、SPU で約 80,000 個のポリシーをサポートするには、SPU は最大 82% のフロー カーネル メモリ消費量で起動し、少なくとも 170 メガバイトのメモリを使用可能にする必要があります。

この例では、すべてのトラフィックを許可または拒否するセキュリティ ポリシーを設定する方法を示しています。

この例では、選択したトラフィックを許可または拒否するセキュリティ ポリシーを設定する方法を示しています。

この例では、ワイルドカードアドレストラフィックを許可または拒否するセキュリティポリシーを設定する方法を示しています。

この例では、デバイス上で生成されたトラフィックログを外部システムログサーバーに送信するセキュリティポリシーを設定する方法を示しています。

アドレス エントリーをポリシーに手動で追加すると、時間がかかる場合があります。特定の目的(ブロックリストなど)を持つ IP アドレスや、共通の属性(脅威をもたらす可能性のある特定の場所や動作など)を持つ IP アドレスのリストを提供する外部ソースがあります。外部ソースを使用して、IP アドレスで脅威ソースを識別し、それらのアドレスを動的アドレス エントリにグループ化し、セキュリティ ポリシーでそのエントリを参照できます。これにより、これらのアドレスとの間のトラフィックを制御できます。このような IP アドレスの各グループは、動的アドレス エントリと呼ばれます。

次のタイプの IP アドレスがサポートされています。

• 単一 IP。例:192.0.2.0

• IP 範囲。例:192.0.2.0- 192.0.2.10

• CIDRです。例:192.0.2.0/24

各エントリは 1 行を占めます。Junos OS リリース 19.3R1 以降、IP アドレス範囲を昇順で並べ替える必要はなく、IP エントリーの値を同じフィード ファイル内で重複させることができます。19.3R1より前のJunos OSリリースでは、IPアドレス範囲を昇順で並べ替える必要があり、IPエントリーの値を同じフィードファイル内で重複させることはできません。

手記：

動的アドレス エントリは、単一の IP プレフィックスではなく、IP アドレスのグループです。動的アドレス エントリは、アドレス帳およびアドレス エントリ アドレスのセキュリティ アドレスの概念とは異なります。

セキュリティ ポリシーに動的アドレス エントリを展開するメリットは、以下のとおりです。

• ネットワーク管理者は、IP アドレスのグループとの間のトラフィックをより詳細に制御できます。

• 外部サーバーは、更新されたIPアドレスフィードをSRXシリーズファイアウォールに提供します。

• 管理者の労力が大幅に削減されます。例えば、レガシーセキュリティポリシーの設定では、ポリシーが参照する1000のアドレスエントリーを追加するには、約2000行の設定が必要になります。動的アドレス エントリーを定義し、セキュリティ ポリシーで参照することで、追加の設定作業を大幅に行わずに、最大数百万のエントリーを SRXシリーズ ファイアウォールに流入させることができます。

• 新しいアドレスを追加するためのコミットプロセスは必要ありません。従来の方法で数千のアドレスを設定に追加すると、コミットに長い時間がかかります。また、動的アドレス エントリーの IP アドレスは外部フィードから取得されるため、エントリーのアドレスが変更されてもコミット プロセスは必要ありません。

図 3 は、セキュリティ ポリシーの動的アドレス エントリがどのように機能するかの機能概要を示しています。

セキュリティ ポリシーは、送信元アドレスまたは宛先アドレス フィールドの動的アドレス エントリを参照します(セキュリティ ポリシーが従来のアドレス エントリを参照するのとほぼ同じ方法)。

図 4 は、Destination-address フィールドの動的アドレス エントリを使用するポリシーを示しています。

図 4 では、ポリシー 1 は宛先アドレス 10.10.1.1 を使用していますが、これは従来のセキュリティ アドレス エントリです。ポリシー 2 は、宛先アドレスのベンダー ブロックリストを使用します。これは、ネットワーク管理者によって指定された動的アドレス エントリです。その内容は、外部フィード ファイルから取得した IP アドレスのリストです。5 つの基準(untrust という名前の送信元ゾーン、engineer という名前の送信元ゾーン、任意の送信元アドレス、ベンダー ブロックリストの動的アドレス エントリに属するIP アドレス、およびメール アプリケーション)すべてに一致するパケットは、パケットを拒否してログに記録するポリシー アクションに従って処理されます。

手記：

動的アドレス エントリ名は、従来のセキュリティ アドレス エントリと同じ名前空間を共有するため、複数のエントリに同じ名前を使用しないでください。Junos OSのコミットプロセスでは、競合を避けるために名前が重複していないかチェックします。

動的アドレス グループは、次のデータ フィードをサポートします。

• カスタムリスト(許可リストとブロックリスト)

• ジオIP

• フィード サーバー
• バンドルフィード

Feature Explorerを使用して、特定の機能に対するプラットフォームとリリースのサポートを確認します。

次の表を使用して、プラットフォームのプラットフォーム固有の動作を確認します。

• プラットフォーム固有のセキュリティポリシー設定ルールの動作
• プラットフォーム固有のポリシー構成の同期動作
• プラットフォーム固有のIDPサポート動作
• プラットフォーム固有のファイアウォール ポリシー ウィザードのサポート動作

Feature Explorerを使用して、特定の機能に対するプラットフォームとリリースのサポートを確認します。追加のプラットフォームがサポートされる場合があります。

ファイルフィードサーバーをサポートするSRXシリーズデバイスとvSRX仮想ファイアウォール3.0は、以下をサポートします。	SRX300、SRX320、SRX340、SRX345、SRX550、およびSRX550M	SRX4100、SRX4200、SRX4600、SRX5400、SRX5600、SRX5800デバイス、vSRX仮想ファイアウォール 3.0	SRX1500
フィードサーバーの最大数	10	100	40
最大フィード数	500	5000	200
動的アドレス エントリーの最大数	500	5000	200

ポリシーオブジェクトをサポートするSRXシリーズデバイスは、以下をサポートします。	SRX300およびSRX320	SRX340	SRX345およびSRX380	SRX550M	SRX1500、SRX1600、SRX4100	SRX4200とSRX4300	SRX4600	SRX4700、SRX5400、SRX5600、SRX5800
アドレス オブジェクト	2048	2048	2048	2048	4096	4096	4096	16384
アプリケーションオブジェクト	128	128	128	128	3072	3072	3072	3072
セキュリティ ポリシー	1024	2048	4096	10240	16000	60000	80000	100000
ポリシーコンテキスト(ゾーンペア)	256	512	1024	2048	4096	4096	8192	8192
コンテキストごとのポリシー	1024	2048	4096	10240	16000	60000	80000	100000
カウントが有効なポリシー	256	256	256	10240	1024	1024	1024	1024