セキュリティポリシーの基本

463068

Created On 09/25/18 19:21 PM - Last Modified 10/15/19 23:29 PM

Resolution

セキュリティポリシーの基本

概要

このドキュメントは、パロ・アルトのネットワークファイアウォールのセキュリティポリシーの基本を説明します。

パロ・アルトのネットワークファイアウォールのデータプレーン・を通過するすべてのトラフィックは、セキュリティポリシーと照合されます。これは、既定では、このトラフィックは、ファイアウォールのデータプレーン・を通過しないため、ファイアウォールの管理インターフェイスから発信されたトラフィックを含まれていません。ゾーン、アプリケーション、IP アドレス、ポート、ユーザー、およびヒッププロファイルなどのさまざまな基準を使用して、ファイアウォールのセキュリティポリシーを定義できます。ファイアウォールの管理者は、広い基準としてゾーンから始まるし、ポート、アプリケーション、およびヒッププロファイルなどのより詳細なオプションを使用してポリシーを微調整するか、トラフィックを拒否するセキュリティポリシーを定義できます。

2種類のセキュリティ policies

ファイアウォールには、セキュリティポリシーの 2 種類があります。

明示的なセキュリティポリシーでは、ユーザーによって定義され、表示を CLI および Web UI のインターフェイスで。
暗黙的なセキュリティポリシーは、CLI インタフェースまたは Web UI のインターフェイス経由でユーザーに表示されていないルールです。次のセクションでは、パロ・アルトのネットワークファイアウォールの暗黙的なセキュリティポリシーについて説明します。

暗黙的なセキュリティポリシー

既定では、ファイアウォールは暗黙的にイントラゾーン (発信元と宛先は同じゾーン内) のトラフィックを許可し、間ゾーン (ゾーン) 間のトラフィックを暗黙的に拒否します。トラフィックを許可または暗黙的なポリシーによって拒否ログオンしていないファイアウォール既定では、このトラフィックのログが見つからないので。ファイアウォールによってログに記録される、トラフィックはファイアウォール上明示的に構成済みのセキュリティポリシーに一致しています。しかし、トラブルシューティングの目的、既定の動作を変更できます。参照:トラフィックログの既定のセキュリティポリシーからのトラフィックを確認する方法。

セッション

パロアルトネットワークファイアウォールは、ファイアウォールを通過するすべてのトラフィックがセッションに対して一致し、各セッションがセキュリティポリシーと照合されることを意味するステートフルファイアウォールです。

セッションは、2 つのフローで構成されます。サーバー (c2s フロー) にクライアントとクライアント (s2c フロー) します。トラフィックが開始するエンドポイントは、常にクライアントとトラフィックの送信先がエンドポイントサーバーであります。セキュリティポリシーを定義する、c2s のみの流れ方向と見なされる必要があります。C2s の方向では、移動先のゾーンの元のゾーンからトラフィックを拒否するポリシーを定義します。帰りの流れ、s2c は、新しいルールを必要としません。一覧の最初の最も近い規則に一致するトラフィックがセッションに適用されますので、ファイアウォールでセキュリティポリシーの評価は、リストの底に上から順番に発生します。

ここでは、CLI からのセッションでフローを識別する方法の例です。

> 表示セッション id 107224

セッション 107224

c2s の流れ:

ソース: 172.23.123.5 [テスト]

dst: 172.23.123.1

プロト: 50

スポーツ: 37018 dport: 37413

状態: アクティブなタイプ: TUNN

src ユーザー: 未知

dst ユーザー: 不明

s2c の流れ:

ソース: 172.23.123.1 [テスト]

dst: 172.23.123.5

プロト: 50

スポーツ: 37750 dport: 50073

状態: アクティブなタイプ: TUNN

src ユーザー: 未知

dst ユーザー: 不明

トポロジ

このドキュメントの次のトポロジは、セキュリティポリシーの例を使用してに適用されます。

スクリーン + ショット + 2014-06-26 + で + 8.25.25 + AM.png

サービス「アプリケーション・デフォルト」

以下の例では、セキュリティポリシーは許可して次の条件に一致するトラフィックを拒否します。

規則 a: IP サブネット 192.168.1.0/24 宛ての信頼ゾーンに信頼ゾーンから開始されるすべてのアプリケーションは、任意の送信元と送信先ポートで許可しなければなりません。
ルール b: アプリケーション、DNS、Web のブラウジング、信頼ゾーン宛ての ip アドレス 192.168.1.3 から信頼ゾーンから開始された FTP トラフィックを許可する必要があります。
アプリケーションは、「アプリケーション既定値」ポートでのみの使用に限定する必要があります。たとえば、DNS のアプリケーションは、既定では、宛先ポート 53 を使用します。だから DNS のアプリケーションは、このポート上でのみ許されるべき。残りの送信先ポートにこのアプリケーションを使用を拒否する必要があります。
規則 c: 192.168.1.3 から他のすべてのアプリケーション信頼ゾーンにはブロックする必要があります。
ルール d: 信頼ゾーンから任意のゾーンにすべてのトラフィックをブロックする必要があります。

セキュリティポリシーのサービス] 列は、ソースと宛先ポートのトラフィックを許可する必要がありますを定義します。4 つのオプションは次のとおりです。

アプリケーション-デフォルト: デフォルトの宛先ポートのトラフィックを許可します。
さまざまなアプリケーションで使用されるデフォルトの宛先ポートの検索の詳細については、次のドキュメントを参照してください。アプリケーション
の既定のポートを表示する方法を参照してください。
any: 送信元と宛先のポートでトラフィックを許可します。
定義済みサービス: ファイアウォールで既に定義されているサービス。
カスタムサービス: 管理者は、アプリケーションポートの要件に従ってサービスを定義できます。

この例では、上記の条件を一致するように作成されたルールを示します。

上記の構成の変更のコミット、シャドウ、次の警告が表示されます。

画面 2014-06-26 9.36.41 AM.png

次に、シャドウ警告とそれらを回避するためのヒントの影響を説明します。

ルールのシャドウイング

上記の例では、IP アドレスが 192.168.1.3 など信頼ゾーンに属しており、サブネット 192.168.1.0/24 に落ちる。ファイアウォールは、セキュリティポリシーの参照を上から下には、以来、192.168.1.3 の ip アドレスからのすべてのトラフィックはルールに一致してセッションに適用されます。ルールはルール B および規則 C をシャドウするために、これらの規則はこのトラフィックに加わらないが、トラフィックはまた規則 B および規則 C の条件を満たす、

シャドウイングの影響を避けるためには、規則 B と規則 C 必要があります前ルールは、以下のよう。今トラフィックは正しいルールに一致して、コミット中に「シャドウ警告」を防ぐことができます。

2014-07-18 画面 1.56.08 で PM.png

ユーザーに基づくセキュリティポリシー

上記の例では、ポリシーは、IP アドレスに基づいて書き込まれます。同じ方法でも LDAP ユーザー、LDAP グループ、およびファイアウォールでローカルに定義されているユーザーをセキュリティポリシーで使用ができます。ユーザー ID を構成して、セキュリティポリシーにユーザーを追加する方法の詳細については、次のドキュメントを参照してください。

はじめに: ユーザー ID

セキュリティポリシーにグループを追加する方法

Nat 変換された IP アドレスを持つセキュリティポリシー

このセクションでは、セキュリティポリシーと IP アドレスの変換を行っていますが、記述する方法ともセキュリティポリシーの URL カテゴリを使用して、さまざまなウェブサイトを制御する方法をについて説明します。

次の例では、セキュリティポリシーは、次の条件に一致する定義されます。

パブリック IP 192.0.2.1 信頼ゾーンでは、DMZ ゾーン内の Web サーバーのプライベート ip アドレス 10.1.1.2 に変換されます。

ポート 8080 のみ、443、25 では、10.1.1.2 DMZ ゾーン内の Web サーバーに信頼ゾーンから着信トラフィックを許可する必要があります。
信頼ゾーンのすべてのユーザーは、信頼ゾーンで「大人とポルノグラフィー」カテゴリのウェブサイトへアクセスを拒否する必要が。
信頼ゾーンから他のすべてのトラフィックを信頼ゾーンを許可する必要があります。

以下のルールは、上記の基準を満たすために構成を表示します。

スクリーンショット 2014-08-04 6.00.18 で PM.png

信頼ゾーンから Web サーバーに送信されるすべてのトラフィックは宛先パブリック ip アドレス 192.0.2.1 信頼ゾーンに属するのだろうトラフィックが信頼ゾーンから発信された、信頼ゾーン内の IP 宛ては、同じゾーントラフィックを許可暗黙のルールでこのトラフィックが許可します。セキュリティポリシーの参照後ファイアウォールは NAT ポリシー参照と Web サーバーのパブリック ip アドレスをプライベート ip アドレス 10.1.1.2、DMZ ゾーンに位置するのに翻訳を取得を決定します。この段階でファイアウォールは最終的な宛先地帯 (DMZ) が、IP 192.0.2.1 から 10.1.1.2 への実際の翻訳はまだ発生しません。post NAT トラフィックの最終的な宛先ゾーンの情報を決定した後、ファイアウォールは 2 番目のセキュリティポリシールックアップを実行して、最終的な宛先ゾーンである DMZ に宛てられたトラフィックを許可するポリシーを検索します。したがって、上記ルール X がポスト NAT トラフィックを許可するように構成されています。移動先のゾーンと宛先 IP アドレスとして 192.0.2.1 (前 NAT IP) ルール X が DMZ (ポスト NAT ゾーン) ください。上記の例では、サービス「Web server_Ports」が宛先ポート 8080、443、25 を許可するように構成されています。詳細については、「ポートの範囲を使用するようにポリシーを構成する方法」を参照してください。

セキュリティポリシーの URL カテゴリ

上記の例では、セキュリティポリシーで、URL カテゴリオプションを使用してアダルトカテゴリのウェブサイトをブロックするルール Y を構成します。Web 参照アプリケーションは、セキュリティポリシーの URL カテゴリオプションを使用して明示的にポリシーに記載する必要があります。それ以外の場合、関連性の低いトラフィックはこの規則に一致します。URL カテゴリに基づいて web サイトを制御する別の方法は、プロファイルをフィルタリング URL を使用することです。

アプリケーションの依存関係、アプリケーションシフト

このセクションでは、「アプリケーションの依存関係」を説明し、セッションのアプリケーション id がセッションの途中で変更されたときに何が起こるかについて説明します。

次の例では、セキュリティポリシーが許可し、次の条件に一致するトラフィックを拒否する定義されます。

アプリケーションどころ、信頼ゾーンに信頼ゾーンから Youtube が許されるべき。
Facebook はアプリケーション、信頼ゾーンにゲストゾーンから Gmail ベースが許されるべき。
アプリケーション SSL や Web ブラウジングをゲストゾーンユーザーでブロックされる必要がある場合します。

この例では、上記の条件を一致するように作成されたルールを示します。

2014-07-18 画面 2.27.17 で PM.png

変更構成をコミットしながら、次のアプリケーションの依存関係の警告を表示できます。

画面 2014-06-26 11.07.41 AM.png

アプリケーションどころと YouTube は、SSL として特定されたような web ブラウジングと Citrix。これらのセッションのためのより多くのパケットはファイアウォールを通過、アプリケーションを識別するために詳細については、ファイアウォールに。ファイアウォールは、アプリケーションとどころや Youtube のようなアプリケーションをそれぞれをシフトします。

アプリケーションシフトが起こるたびにファイアウォールは新しいセキュリティポリシーの参照を新しいアプリケーションと一致する最も近いルールを見つけることです。従って上記の例では、SSL や web ブラウジングがどころや YouTube のために依存するアプリケーションと呼びます、したがってこれらのアプリケーションも許されるべきセキュリティポリシーで。トラフィックのアプリケーションがセッションの途中で変更された場合、2 番目のセキュリティポリシールックアップは、セキュリティポリシーに対するトラフィックを rematches して、新しい最も近い一致ポリシーを見つけます。

2014-07-18 画面 3.00.38 で PM.png

上記の例では、SSL や web ブラウジングを許可するセキュリティポリシー「ルール依存アプリ」が作成されます。Youtube のトラフィックがこの規則を最初に一致し、アプリケーションシフトが発生すると、セキュリティポリシーの参照を 2 番目は照合ルール 10。

PAN-OS 5.0 以降では、依存関係を明示的に許可する必要なく、一部のプロトコルのアプリケーションを許可することができます (「アプリケーションが明示的に許可されている依存アプリを使用する必要があるかどうかを確認する方法」を参照)。上記の例では、Facebook や gmail ベース、SSL や web ブラウジングに依存し、その依存関係アプリを明示的に許可を必要としないことなどのアプリケーションです。

アプリケーションの識別と復号化

特定のアプリケーションには、Vimeo、SSL を使用し、暗号化、SSL 復号化せずファイアウォールによって識別することができますが好きです。ただし、SSL を使用するには、YouTube のようなアプリケーションは、それらの識別のファイアウォールによって復号化される必要があります。SSL 接続は暗号化されるため、ファイアウォールとそれを識別するためにはこのトラフィックの可視性がありません。ファイアウォールでは、アプリケーション id の証明書に共通の名前フィールドを使用します。これは、SSL ハンドシェイクプロセス中にクリアテキストで交換されます。

Vimeo のようなウェブサイトは、ウェブサイトの URL 名を共通名として使用し、SSL 復号化を構成する必要はありません。YouTube のようないくつかのウェブサイトは、共通名としてワイルドカード名を持つ証明書を使用します。YouTube の場合、それは *. google.com。だから不可能アプリケーション識別のためこの情報を使用して、ウェブサイトの URL に可視性を取得する SSL 復号化を構成しなければなりません。SSL 復号化を実装およびテストする方法については、次のドキュメントを参照してください。

クリーンアップルール

一部の環境では、拒否され、ファイアウォールによって許可されているすべてのトラフィックをログを必要があります。既定では、ファイアウォールによって明示的に許可されているトラフィックのみが記録されます。ファイアウォールの暗黙のルールで許可されているトラフィックをログに記録するを参照してください。

いずれか/すべて/拒否セキュリティルール変更の既定の動作

トラフィックのログのデフォルトセキュリティポリシーからのトラフィックを参照してくださいする方法

セキュリティポリシーに関するヒント

次の条件は、セキュリティポリシーに対するトラフィックに一致する同じ順序では、ファイアウォールによってチェックされます。

ソースと宛先のアドレス
送信元ポートと宛先ポート
アプリケーション
ユーザーID
URL カテゴリ
ソースと宛先ゾーン

2014-07-18 画面 3.19.35 で PM.png

上記の構成例では、「web ブラウジング」TCP ポート信頼ゾーンに信頼ゾーンから 80 のアプリケーションが、ファイアウォールを通過するときセキュリティの検索は次の方法で行います。

送信元/送信先アドレス - 以来、規則 A、B、および C は、「任意」のソースを持っているし、トラフィックの宛先アドレスに一致するすべてのこれらの規則。
送信元ポートと宛先ポート - 以来、規則 A、B、および C は「任意」のサービスを持って、トラフィックがすべてのこれらの規則を一致しました。
アプリケーション - ルール A と B は、アプリケーションの「web ブラウジング」からのトラフィックはこれらの規則と一致します。
ユーザ ID - ここでは適用されません。
URL カテゴリ - ここでは適用されません。
ソースと宛先ゾーン - トラフィックが信頼と信頼、間にあるので、このトラフィックの規則 A が選択されます。

セキュリティポリシーを構成する最適な方法は、"any"の使用を最小限に抑えるため、可能な場合は、値を特定することです。これはパロ・アルトのネットワークデバイスによって実行される不要なセキュリティポリシー参照を軽減されます。

セキュリティポリシーの基本

Resolution