※この記事は以下の記事の日本語訳です。
Security policy fundamentals
https://live.paloaltonetworks.com/t5/Learning-Articles/Security-policy-fundamentals/ta-p/53016
PAN-OS 4.1, 5.0, 6.0
目次
- 概要
- ２種類のセキュリティ ポリシー
- セッション
- トポロジー
- "application-default" サービス
- ルールのシャドウイング (Shadowing)
- ユーザー ベースのセキュリティ ポリシー
- NATされたIPアドレスとセキュリティ ポリシー
- セキュリティ ポリシー上のURLカテゴリ
- アプリケーションの依存関係およびアプリケーション シフト
- アプリケーション識別と復号化
- ルールの整理
- セキュリティ ポリシーTIPS
- 関連ドキュメント
概要
このドキュメントは、Palo Alto Networks ファイアウォールにおけるセキュリティ ポリシーの基礎を説明しています。
Palo Alto Networks ファイアウォールのデータプレーンを通過するトラフィックはすべてセキュリティ ポリシーと照合されます。マネジメント インターフェースより発信されるトラフィックは、デフォルトではデータプレーンを通過しないため、これには含まれません。ファイアウォールのセキュリティ ポリシーは、ゾーン、アプリケーション、IPアドレスポート、ユーザー、HIPプロファイル等、様々な基準によって定義できます。ファイアウォール管理者は、ゾーンのような広い基準を始め、ポート、アプリケーション、および HIP プロファイルなどのより詳細なオプションでポリシーを調整し、トラフィックを許可または拒否するようにセキュリティ ポリシーを定義することができます。
２種類のセキュリティ ポリシー
Palo Alto Networks ファイアウォールは２つの種類のセキュリティ ポリシーを持ちます：
- 明示的な (Explicit) セキュリティ ポリシーは、ユーザーによって定義され、CLI や Web-UI から見ることができます。
- 暗黙的な (Implicit) セキュリティ ポリシーは、CLI や Web-UI から見ることができません。続いてのセクションではPalo Alto Networks ファイアウォール上の暗黙のセキュリティ ポリシーについて議論します。
暗黙のセキュリティ ポリシー
デフォルトでは、ファイアウォールはイントラゾーン (intra-zone: 発信と宛先が同じゾーン) のトラフィックを許可し、インターゾーン (inter-zone: 異なるゾーン間) の通信は拒否します。暗黙のポリシーで許可または拒否されたトラフィックはデフォルトではログに記録されず、このトラフィックを確認することができません。ファイアウォールによってログに記録するためには、設定された明示的なポリシーに一致しなければなりません。しかし、トラブルシューティングを目的として、このデフォルト動作を変更することができます。DOC-6957: How to See Traffic from Default Security Policies in Traffic Logs のドキュメントを参照してください。
セッション
Palo Alto Networks ファイアウォールはステートフル ファイアウォールであり、これは、すべてのファイアウォールを通過するトラフィックはセッションと照合され、すべてのセッションはセキュリティ ポリシーと照合されることを意味します。
セッションは２つのフローから成ります。クライアントからサーバーへのフロー (c2s flow) とサーバーからクライアントへのフロー (s2c flow) です。トラフィックを開始した始点が常にクライアントであり、トラフィックの到達する終点がサーバーです。セキュリティを定義するためには、c2sフローの方向だけが考慮されます。許可や拒否のポリシーを発信ゾーンから宛先ゾーンへ定義した場合、それは c2s の方向となります。戻りのフロー、s2c については新たなルールは不要です。ファイアウォール上のセキュリティ ポリシーの評価はリストの上から下へと順次行われるため、最初の最も近いルールに一致したトラフィックがセッションに適用されます。
以下は CLI でセッション内のフローを識別する方法です。:
> show session id 107224
Session 107224
c2s flow:
source: 172.23.123.5 [Test]
dst: 172.23.123.1
proto: 50
sport: 37018 dport: 37413
state: ACTIVE type: TUNN
src user: unknown
dst user: unknown
s2c flow:
source: 172.23.123.1 [Test]
dst: 172.23.123.5
proto: 50
sport: 37750 dport: 50073
state: ACTIVE type: TUNN
src user: unknown
dst user: unknown
構成
このドキュメントでは、以下の構成がセキュリティ ポリシーの使用例として適用されます:
アプリケーション デフォルト (application-default) サービス
以下の例では、セキュリティ ポリシーは以下の基準でトラフィックを許可または拒否します。
- Rule A: Trust ゾーンに所属するサブネット 192.168.1.0/24 から Untrust ゾーンへ向けて発信されるすべてのアプリケーションはすべての送信元ポートおよび宛先ポートにおいて許可されなければならない。
- Rule B: Trust ゾーンの 192.168.1.3 から発信される DNS, Web-browsing, FTP のアプリケーション通信は許可されなければならない。
- アプリケーションは "application-default" のポートのみに制限されるべきである。たとえば、DNS アプリケーションであれば、デフォルトでは、宛先ポート 53 番を使用する。よって、DNS アプリケーションはこのポートのみに制限されるべきである。このアプリケーションを使ったほかの宛先ポートの利用は拒否されるべきである。
- Rule C: 他のすべての 192.168.1.3 から Untrust ゾーンへ抜けるアプリケーションはブロックされなければならない
- Rule D: すべての Untrust ゾーンから開始されほかのゾーンへ抜けるトラフィックはブロックされるべきである。
セキュリティ ポリシーの Service 列は、許可されるべきトラフィックの送信元と宛先ポートを定義します。4つのオプションがあり、：
- Application-default: デフォルトの宛先ポートの通信を許可。
様々なアプリケーションのデフォルト宛先ポートを確認するには以下のドキュメントを参照:
DOC-7276: How to view Application-default ports for an application. - Any: すべての送信元と宛先ポートを許可。
- Predefined services: ファイアウォール上ですでに定義されているサービス
- Custom services: 管理者がアプリケーションポート要件に沿ってサービスを定義可能
この例では、上記基準に一致するよう作成されたルールを示します。
上記の設定変更をコミットをすると、以下のシャドウ警告が表示されます。
シャドウ警告の影響と、これ回避する方法は、以下で議論します。
ルールのシャドウイング (Shadowing)
上記の例では、IPアドレス 192.168.1.3 は Trust ゾーンに属し、かつ 192.168.1.0/24 に含まれます。ファイアウォールはセキュリティー ポリシーを上から下へ参照するため、192.168.1.3 のすべてのトラフィックは Rule A に合致し、セッションに適用されます。トラフィックは Rule B と Rule C を満たしているものの、Rule A が Rule B と Rule C をシャドウイングしているため、これらのルールは適用されません。
シャドウイングの影響を回避するため、以下のように、Rule B と Rule C は Rule A より上にある必要があります。これでトラフィックは正しいルールに対応し、コミット時のシャドウ警告を防ぎます。
ユーザー ベースのセキュリティ ポリシー
上記の例では、ポリシーは IP アドレスをベースとして記述されています。同様に、LDAP ユーザー、LDAP グループ、またはファイアウォール上でローカルに定義されたユーザーをセキュリティ ポリシーに使用できます。User-ID の設定方法とセキュリティ ポリシーへのユーザーの追加については、以下のドキュメントで詳細を確認してください。:
DOC-1807: User Identification Tech Note - PAN-OS 4.0
DOC-4068: How to Add Groups to Security Policy
NAT された IP アドレスとセキュリティ ポリシー
このセクションでは、変換された IP アドレスが関連する場合のセキュリティ ポリシーの記述方法と、さまざまなWebサイトを制御するために、セキュリティ ポリシーに URL カテゴリを使用する方法について議論します。
次の例では、以下の基準に一致するようセキュリティ ポリシーが定義されます:
Untrust ゾーンのパブリック IP 192.0.2.1 は、DMZ ゾーンの Web サーバーのプライベート IP 10.1.1.2 に変換されます。
- Untrust ゾーン から DMZ ゾーンの Web サーバー 10.1.1.2 宛トラフィックは、25、443、8080 番ポートのみ許可されなければならない。
- Trust ゾーンにいるすべてのユーザーの、Untrust ゾーンにある "Adult and Pornography" カテゴリの Web サイトへのアクセスは拒否されなければならない。
- その他の Trust ゾーンから Untrust ゾーンへ抜けるトラフィックは許可されなければならない。
以下のルールは上記基準を満たす設定を示します。
Untrust ゾーンから Web サーバー宛てのすべてのトラフィックは、Untrust ゾーンに属する 192.0.2.1 の送信先のパブリックIPを持ちます。トラフィックは Untrust ゾーンから発信し、Untrust ゾーン内の IP 宛てであるため、このトラフィックは、同じゾーンのトラフィックを許可する暗黙のルールで許可されています。セキュリティ ポリシー検索した後、ファイアウォールは NAT ポリシーのルックアップを行い、この Web サーバーのパブリック IP を、DMZ ゾーンにあるプライベート IP 10.1.1.2 に変換する必要があると判断します。この段階で、ファイアウォールは最終的な宛先ゾーン (DMZ) を持っていますが、192.0.2.1 から 10.1.1.2 へのIPの実際の変換はまだ発生しません。post NAT (NAT後の) トラフィックのために最終的な宛先ゾーンの情報を決定した後、ファイアウォールは最終的な宛先ゾーン、DMZ 宛てのトラフィックを許可するポリシーを見つけるために、2回目のセキュリティ ポリシー ルックアップを行います。このように、上記 Rule X は、post NATトラフィックを許可するように設定されています。この Rule X では、 DMZ (pre NATゾーン (NAT前のゾーン)) が宛先ゾーンとして設定され、192.0.2.1（pre NAT IP) が宛先 IP アドレスとしてとして定義されていることに注意してください。上記の例では、宛先ポート25、443、8080 を許可するため "Web-server_Ports" サービスが設定されています。詳細は DOC-4527:How to Configure a Policy to Use a Range of Ports を参照してください。
セキュリティ ポリシー上の URL カテゴリ
上記の例では、Rule Yは、セキュリティ ポリシーに存在する URL カテゴリのオプションを使用して、アダルトなカテゴリのウェブサイトをブロックするように設定されています。URL カテゴリのオプションを使用する場合、セキュリティ ポリシー上で Web-browsing アプリケーションが明示的に設定されていなければなりません。そうでなければ、無関係なトラフィックがこのルールに合致してしまいます。URL カテゴリに基づいてウェブサイトをコントロールする別の方法は、URLフィルタリング プロファイルを使用することです。
アプリケーションの依存関係およびアプリケーション シフト
このセクションでは、"アプリケーションの依存関係"と セッションの途中で Application-ID が変更された場合に、そのセッションに何が起こるかを説明します。
次の例では、セキュリティ ポリシーは次の条件に一致するトラフィックを許可または拒否するように定義されています。
- Trust ゾーンから Untrust ゾーンへの Gotomeeting、YouTube アプリケーションは許可します。
- Guest ゾーンから Untrustゾーンへの Facebook、Gmail-base アプリケーションは許可します。
- Guest ゾーン にいるユーザーの SSL および Web-Browsing のアプリケーションはブロックする必要があります。
以下の例では、上記基準に合致するルールが作成されています。
設定変更を実施すると、以下のアプリケーション依存関係の警告が表示されるかもしれません。
Gotomeeting や YouTube のようなアプリケーションは、初めは SSL、web-browsing、Citrix などとして識別されます。このセッションのより多くのパケットがファイアウォールを通過すると、アプリケーションを識別するためのより多くの情報が利用可能となります。その後、Gotomeeting や YouTube などの各アプリケーションにアプリケーションをシフトします。
アプリケーションのシフトが起こるたびに、ファイアウォールは、新しいアプリケーションに一致する最も近いルールを見つけるために、新しいセキュリティ ポリシー ルックアップを行います。よって、上記の例では、SSL および Web-browsing が依存するアプリケーションとして Gotomeeting や YouTube のために呼び出されているため、これらのアプリケーションもセキュリティ ポリシー上で許可されている必要があります。セッション途中でトラフィックのアプリケーションが変更になる場合、2回目のセキュリティ ポリシー ルックアップが実施され、新たな最も合致するポリシーを見つけるために、セキュリティ ポリシーに対して再度トラフィックを照合させます。
上記の例では、"Dependency Apps rule"という新しいセキュリティ ポリシーが SSL、web-browsing を許可するために作成されています。Youtube トラフィックは、初めはこのルールに一度合致し、アプリケーション シフトが発生すると、２度目のセキュリティ ポリシー ルックアップで Rule 10 に合致します。
PAN- OS 5.0からは、いくつかのアプリケーション プロトコルでは、明示的に依存関係の許可を必要とせずに許可することができます（DOC-6900を参照 ：How to Check if an Application Needs to have Explicitly Allowed Dependency Apps）。上記で例えると、 Facebook や Gmail-base はこの対象であり、SSLやweb-browsingに依存していますが、この依存するアプリケーションを明示的に許可する必要はありません。
アプリケーション識別と復号化
Vimeo のような特定のアプリケーションは、SSL を使用して暗号化されていますが、SSL 復号化せずにファイアウォールによって識別することができます。しかし、SSL を利用している YouTube のようなアプリケーションは、それらの識別のためのファイアウォールによって復号化される必要があります。 SSL 接続が暗号化されるので、ファイアウォールはそれを識別するために、このトラフィックの中身を見ることができません。ファイアウォールでは、アプリケーションを識別するために証明書のコモン ネーム(common name)フィールドを使用します。これは、SSL ハンドシェイク処理中に平文で交換されます。
Vimeo のようなウェブサイトはコモン ネームとしてとして Web サイトの URL 名を使用するため、SSL 復号化を必要としません。YouTube のようないくつかのウェブ サイトは、コモン ネームにワイルドカード名を持つ証明書を使用します。 YouTube の場合で言うと、 *.google.com となります。よって、アプリケーション識別にこの情報を使用することができないため、ウェブサイトの URL へ情報を取得するためにSSL 復号化を設定する必要があります。次のドキュメントを参照してください： How to Implement and Test SSL Decryption
ルールの整理
一部の環境では、ファイアウォールによって拒否または許可されたすべてのトラフィックをログに記録する必要があります。デフォルトでは、明示的に許可されたトラフィックだけが記録されます。ファイアウォールの暗黙のルールで許可されたトラフィックをログに記録するには、以下のドキュメントを参照してください：
DOC-1412: Any/Any/Deny Security Rule Changes Default Behavior
DOC-6957: How to See Traffic from Default Security Policies in Traffic Logs
セキュリティ ポリシーTIPS
以下の基準が、セキュリティ ポリシーにトラフィックを合致するために、この順序でファイアウォールでチェックされます。
- 送信元と宛先アドレス
- 送信元と宛先ポート
- アプリケーション
- User-ID
- URL カテゴリ
- 送信元と宛先ゾーン
上記の設定例では、Trust ゾーンから Untrust ゾーンへの TCP ポート 80 上のアプリケーション "web-browsing" がファイアウォールを通過する際、セキュリティ ルック アップは次のように行われます。:
- 送信元と宛先アドレス - Rule A、B、および C は "any" の送信元アドレスと宛先アドレスを持つため、このトラフィックはこれらすべてのルールに一致します。
- 送信元と宛先ポート - Rule A、B、および C は "any" サービスを持つため、このトラフィックはすべてこれらすべてのルールに一致します。
- アプリケーション - Rule A と B は "web-browsing" アプリケーションを持つため、トラフィックはこれらのルールに一致します。
- User-ID - ここでは適用されません。
- URL カテゴリ - ここでは適用されません。
- 送信元と宛先ゾーン - トラフィックは Trust から Untrust なので、ルールAがこのトラフィックのために選択されます。
セキュリティ ポリシーを設定する際の最適な方法は、"any" の使用を最小限に抑え、可能な場合は特定の値を利用することです。これは、Palo Alto Networks 機器による不必要なセキュリティ ポリシー照合を低減します。
関連ドキュメント
Is there a Limit to the Number of Security Profiles and Policies per Device?
How to Identify Unused Policies on a Palo Alto Networks Device
How to Test Which Security Policy will Apply to a Traffic Flow.
Why are Rules Denying Applications Allowing Some Packets?
Why Does "Not-applicable" Appear in Traffic Logs?
How to Identify Unused Policies on a Palo Alto Networks Device
How to Restrict a Security Policy to Windows and MAC Machines Using GlobalProtect HIP Profiles
How Application-Default in the Rulebase Changes the Way Traffic is Matched
Non-Applicable,Incomplete, and Insufficient Data in the Application Code Field
How to Schedule Policy Actions
Security Policy Management with Panorama
