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

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

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

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

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

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

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

• 会計および監査要素—カウント、ロギング、または構造化システム ロギング。

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

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

SRX300、SRX320、SRX340、SRX345、SRX380およびSRX550Mデバイスには、工場出荷時のデフォルトのセキュリティポリシーが用意されています。

• trustゾーンからuntrustゾーンへのすべてのトラフィックを許可します。

• 信頼ゾーン間、つまりtrustゾーンからイントラゾーンのtrustゾーンへのすべてのトラフィックを許可します。

• untrust ゾーンから trust ゾーンへのすべてのトラフィックを拒否します。

セキュリティ ポリシーは、コンテキスト(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アドレスのサポートが追加されました。

ポリシーは、ファイアウォール フィルターとスクリーンが処理され、SPU(サービス処理ユニット)によってルート ルックアップが完了した後に、フロー処理中に検索されます(SRX5400、SRX5600、および SRX5800 デバイスの場合)。ポリシールックアップは、宛先ゾーン、宛先アドレス、およびegressインターフェイスを決定します。

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

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

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

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

• 一致条件における送信元アドレスは、.from-zone

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

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

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

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

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

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

• 以下の条件では、 from-zone または to-zone 以外 のいずれも指定globalできません。

  as a グローバル ゾーンで to-zone 構成されたポリシーには、静的 NAT または受信 NAT のいずれかがポリシーで構成されていることを示す宛先アドレスが 1 つ必要です。

• SRXシリーズファイアウォールでは、NATでのポリシー許可オプションが簡素化されています。各ポリシーは、オプションで、NAT変換を許可するか、NAT変換を許可しないか、または許可しないかを示します。

• アドレス名を次の予約済みプレフィックスで始めることはできません。これらは、アドレス NAT 構成にのみ使用されます。

  • static_nat_

  • incoming_nat_

  • junos_

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

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

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

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

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

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

メモ：

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

メモ：

セキュリティポリシーは、関連するサービスとのセルフトラフィックに対してのみ設定できます。例えば、ホストアウトバウンドトラフィックに fwauth サービスを設定することは関係ありませんし、gprs-gtp サービスはセルフトラフィックのセキュリティポリシーには関係ありません。

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

メモ：

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

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

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

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

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

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

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

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

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

表 1 に、SRX300、SRX320、SRX340、SRX345、SRX380、SRX550、SRX650、SRX550M、SRX1400、SRX1500、SRX3400、SRX3600、SRX4100、SRX4200、SRX4600、SRX5400、SRX5600、SRX5800デバイスのポリシー制限を示します。プラットフォームのサポートは、インストールされた Junos OS のリリースによって異なります。

メモ：

Junos OSリリース12.3X48-D15およびJunos OSリリース17.3R1以降、SRX5400、SRX5600、およびSRX5800デバイスのポリシーあたりのアドレスオブジェクトの最大数は1024から4096に増加し、コンテキストごとのポリシーの最大数は10240から80,000に増加します。

Junos OS Release 17.3R1から、SRX5400、SRX5600、およびSRX5800デバイスのセキュリティポリシーの数とコンテキストごとのポリシーの最大数が、80,000から100,000に増加しました。

Junos OSリリース15.1X49-D120以降、SRX5400、SRX5600、およびSRX5800のポリシーあたりのアドレスオブジェクト数が4096から16,000に増加しました。

表1:SRXシリーズデバイスのポリシーの制限

SRXシリーズ デバイス	アドレス オブジェクト	アプリケーションオブジェクト	セキュリティ ポリシー	ポリシーコンテキスト(ゾーンペア)	コンテキストごとのポリシー数	カウントが有効なポリシー
SRX300、SRX320	2048	128	1024	256	1024	256
SRX340	2048	128	2048	512	2048	256
SRX345:	2048	128	4096	1024	4096	256
SRX380	2048	128	4096	1024	4096	256
SRX550M	2048	128	10240	2048	10240	1024
SRX1500	4096	3072	16000	4096	16000	1024
SRX4100	4096	3072	60000	4096	60000	1024
SRX4200	4096	3072	60000	4096	60000	1024
SRX4600	4096	3072	80000	8192	80000	1024
SRX5400 SRX5600 SRX5800	16384	3072	100000	8192	100000	1024

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

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

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

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

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

したがって、ポリシーの設定によっては、ルーティング エンジンへのポリシー コントリビューターとパケット転送エンジンへのポリシー コントリビューターが異なり、メモリが動的に割り当てられます。

メモリは、"遅延削除" 状態によっても消費されます。遅延削除状態では、SRXシリーズファイアウォールがポリシーの変更を適用すると、一時的なピーク使用が発生し、古いポリシーと新しいポリシーの両方が存在することになります。そのため、しばらくの間、パケット転送エンジンには古いポリシーと新しいポリシーの両方が存在し、メモリ要件の2倍を占有します。

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

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

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

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

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

• ポリシー構成で使用するゾーン ペアの数を減らします。各移行元ゾーンまたは移行先ゾーンは、約 16,048 バイトのメモリを使用します。

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

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

  • ウェブ認証 - 約16バイト以上(固定なし)

  • IPsec–12 バイト

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

  • カウント - 64 バイト

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

  メモ：

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

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

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

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

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

ポリシーにアドレス エントリを手動で追加すると、時間がかかる場合があります。特定の目的 (ブロックリストなど) を持つ 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 Release 19.3R1以降、IPアドレス範囲は昇順でソートする必要がなく、IPエントリーの値は同じフィードファイル内で重複していてもかまいません。19.3R1より前のJunos OSリリースでは、IPアドレス範囲は昇順でソートする必要があり、IPエントリーの値が同じフィードファイル内で重複することはできません。

メモ：

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

セキュリティ ポリシーに動的アドレス エントリを展開する利点を次に示します。

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

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

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

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

図 3 は、セキュリティ ポリシーの動的アドレス入力の機能の概要を示しています。

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

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

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

メモ：

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

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

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

• Geoip

• フィード サーバー
• バンドルフィード
• SRXシリーズファイアウォールのフィードサーバーのサポート

概要 この例では、EVPN(イーサネットVPN)仮想拡張LAN(VXLAN)トンネルインスペクションのセキュリティポリシーを設定します。

概要 この設定を使用して、Geneve パケット フロー トンネル検査用の vSRX 仮想ファイアウォール 3.0 のセキュリティ ポリシーを有効にします。

vSRX仮想ファイアウォール3.0インスタンスでのGeneveサポートにより、vSRX3.0を使用して以下のことが可能になります。

• キャンパス、データセンター、パブリッククラウド環境のエンドポイントとそのバンシェを接続します。

• 埋め込みのセキュリティでこれらの環境を保護します。