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

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

各ポリシーは以下で構成されています。

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

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

• ポリシールールを適用するために満たす必要がある条件を定義する一連の一致基準。一致基準は、送信元IPアドレス、宛先IPアドレス、アプリケーションに基づいています。ユーザーIDファイアウォールは、ポリシーステートメントの一部として追加のタプルである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で追加されました。アクティブ/アクティブシャーシクラスター設定でのIPv6アドレスのサポート(アクティブ/パッシブシャーシクラスター設定の既存のサポートに加えて)がJunos OSリリース10.4に追加されました。

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

ポリシーを作成する際には、以下のポリシールールが適用されます。

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

• ポリシー名、一致基準、およびアクションが必要です。

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

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

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

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

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

• 会計要素と監査要素は、カウントとログとして指定できます。

• session-closeコマンドでセッションの最後に、またはsession-initコマンドでセッションの開始時にログを有効にすることができます。

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

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

  to-zoneを大域ゾーンとして設定したポリシーには、静的NATまたは着信NATのいずれかがポリシーで設定されていることを示す単一の宛先アドレスが必要です。

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

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

  • static_nat_

  • incoming_nat_

  • junos_

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

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

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

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

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

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

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

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

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

注:

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

注:

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

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

注:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ポリシー実装のための以下のベストプラクティスにより、システムメモリをより有効に活用し、ポリシー設定を最適化することができます。

• 送信元アドレスと宛先アドレスに1つのプレフィックスを使用します。例えば、/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 MB のメモリを使用できる状態で起動する必要があります。

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

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

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

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

ポリシーにアドレスエントリーを手動で追加するのは時間がかかる場合があります。特定の目的(ブロックリストなど)や共通の属性(脅威となる可能性のある特定の場所や行動など)を持つ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は、宛先アドレスフィールドに動的アドレスエントリを使用するポリシーを示しています。

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

注:

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

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

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

• GeoIP

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

機能エクスプローラーを使用して、特定の機能のプラットフォームとリリースのサポートを確認します。

お使いのプラットフォームに固有の動作を確認するには、以下の表を使用して下さい:

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

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

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

ポリシーオブジェクトをサポートする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