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

dyamada · ‎04-20-2016

※この記事は以下の記事の日本語訳です。
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 すべての 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 機器による不必要なセキュリティポリシー照合を低減します。

Strata

Prisma

Cortex

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

目次

概要

２種類のセキュリティ ポリシー

セッション

構成

アプリケーション デフォルト (application-default) サービス

ルールのシャドウイング (Shadowing)

ユーザー ベースのセキュリティ ポリシー

NAT された IP アドレスとセキュリティ ポリシー

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

アプリケーションの依存関係およびアプリケーション シフト