ナレッジドキュメント

※この記事は以下の記事の日本語訳です。 How to Allow a Single YouTube Video and Block All Other Videos https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClGzCAK     1 つの YouTube 動画へのアクセスのみ許可し、それ以外の動画は全てブロックする方法 この記事は、1つのYouTube動画(https://www.youtube.com/watch?v=hHiRb8t2hLM)へのアクセスのみ許可し、それ以外の動画のアクセスは拒否したい場合の例です。 これを達成するには、以下の手順に従ってください。   手順 URL フィルタリングプロファイルにて、streaming-mediaをブロックに設定してください。WebGUI > Objects > セキュリティ プロファイル > URL フィルタリング > 利用したい URL フィルタリングプロファイルをクリックします。 これはURL フィルタリングプロファイルでstreaming-mediaをブロックに設定した際の画面です。   Objects > カスタム オブジェクト > URL カテゴリ から、カスタム URL カテゴリを作成します。 カスタム URL カテゴリには以下のエントリを追加する必要があります。   *.youtube.com *.googlevideo.com www.youtube-nocookie.com www.youtube.com/yts/jsbin/ www.youtube.com/yts/cssbin/   これですべてのYouTubeページやコンテンツが復号化され、完全なHTTP GETが取得できるようになります。   「SSL フォワードプロキシ」タイプの復号ポリシーを追加し、その「サービス/URL カテゴリ」に、上記で追加したカスタムURLカテゴリを設定します。 SSL 復号に関しては、以下の記事を参照してください。 How to Implement and Test SSL Decryption URL フィルタリングプロファイルに移動し、以下のURLを許可リストに追加します。   www.youtube.com/watch?v=hHiRb8t2hLM *.googlevideo.com   1つ目のエントリはコンテナページ自体のURL、2つ目の *.googlevideo.comは、*.googlevideo.com の Google CDN で表示されるコンテナページから取得されるメディアを許可します。   また、URLフィルタリングプロファイル上で、作成したカスタムURLカテゴリが"allow"になっていることを確認してください。 これはURLフィルタリングプロファイルで許可リストを設定した際の画面です。   Commitを実行し、動作をテストします。   Milvaldiの貢献に感謝します。   注：この手順はこの記事が発行された時点では有効でしたが、YouTubeはサーバーの設定を絶えず変更しているため、今後動作しなくなる可能性もあります。   著者: jdelio  

※この記事は以下の記事の日本語訳です。 How to Check if an Application Needs Explicitly Allowed Dependency Apps https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Check-if-an-Application-Needs-Explicitly-Allowed/ta-p/61893     PAN-OS 5.0, 6.0, 6.1   概要 PAN-OS 5.0 以前は、依存関係を持つアプリケーションを許可するために、セキュリティポリシー上ですべての依存関係をもつアプリケーションを同様に許可する必要がありました。   PAN-OS 5.0 より、いくつかのプロトコルのアプリケーションは明示的に依存関係を可能にするために必要とせずに許可することができます。Palo Alto Networks ファイアウォールは、ライブセッションで事前定義された特徴を持つのアプリケーションを識別することができれば、いくつかのアプリケーションに対してこれを実施できます。Palo Alto Networks デバイスが事前に定義された特徴によってアプリケーションを決定することができないようデベロッパーによって作成されている場合、そのアプリケーションはセキュリティルールの一つによって遮断することができます。これらのアプリケーションには依存関係を持つアプリケーションの明示的な許可が必要とされます。   ここではこのプロセスを説明するために、以下の用語を適用します: イネーブラーアプリ (Enabler app) ：セッションが最初に一致するApp-ID (例. web-browsing) 従属アプリ (Dependent app) ：セッションがあとで一致するApp-ID (例. facebook-base)   注: アプリケーションを許可する場合は、常に依存関係を確認してください。また、正しいポリシーを作成することができるよう、依存アプリケーションで暗黙的に使用されるアプリケーションもチェックしてください。   詳細 正しくライブセッションで事前に決定ポイントで特定することができる上記のアプリケーションでは、ファイアウォールは、暗黙的にイネーブラアプリを許可します。このためにファイアウォールはアプリケーションのコンテンツアップデートのメタデータの一部である “uses-apps” と “implicit-uses-apps” を使用します。 “implicit-uses-apps” のアプリリストを持っているアプリケーションの場合、それらのアプリケーションは暗黙的に許可されるため、別途許可するためのセキュリティルールは必要ありません。   アプリケーション定義の一部として “uses-apps” のアプリリストを持ち、“implicit-uses-apps” アプリのリストを持っていないアプリケーションの場合、依存するアプリケーションを許可するために、明示的にそれら（イネーブラーアプリケーション）を許可する必要があります。これは、別のセキュリティルールとして追加することも、同じルールに設定して依存するアプリケーションを許可することもできます。   アプリケーション定義で、明示的にイネーブラアプリケーションを許可する必要があるかどうかをチェックすることができます。コンフィギュレーションモードから次のコマンドを実行します。 # show predefined application <name-of-app>   手順 この例として、ここでは "facebook-base" と "office-on-demand" を使用します。   Facebook-base アプリケーション定義: # show predefined application facebook-base facebook-base {   ottawa-name facebook;   category collaboration;   subcategory social-networking;   technology browser-based;   description "......THIS PART IS OMITTED..... ";   alg no;   appident yes;   vulnerability-ident yes;   evasive-behavior no; consume-big-bandwidth no;   used-by-malware yes; able-to-transfer-file yes; has-known-vulnerability yes; tunnel-other-application yes;   prone-to-misuse no;   pervasive-use yes;   per-direction-regex no;   deny-action drop-reset;   run-decoder no;   cachable no;   references {     Wikipedia {       link http://en.wikipedia.org/wiki/Facebook;     }   }   default {     port tcp/80,443;   }   use-applications [ ssl web-browsing];   tunnel-applications [ facebook-apps facebook-chat facebook-file-sharing facebook-mail facebook-posting facebook-social-plugin instagram] ; implicit-use-applications [ ssl web-browsing];   applicable-decoders http;   risk 4; application-container facebook; } [edit]   facebook-base を許可するには、facebook-base アプリケーションを持つセキュリティポリシーのみが必要です。アプリケーション定義内の以下の部分に基づいて暗黙的に許可されているため、SSLやWebブラウジングを可能にする必要はありません: "use-applications [ ssl web-browsing]; implicit-use-applications [ ssl web-browsing];"   "facebook-base" のために、"facebook-base" だけを許可する "allow-facebook" のセキュリティルールがあります。web-browsing や ssl を許可する明示的なルールはありません。逆にテストの目的で、web-browsing や ssl を拒否ルールが使用されます:   ログで facebook が許可されているのが表示されます:   Office-on-demand アプリケーション定義: # show predefined application office-on-demand office-on-demand {   category business-systems;   subcategory office-programs;   technology browser-based;   description "......THIS PART IS OMITTED..... ";   alg no;   appident yes;   virus-ident yes;   spyware-ident yes;   file-type-ident yes;   vulnerability-ident yes;   evasive-behavior no; consume-big-bandwidth yes;   used-by-malware no; able-to-transfer-file yes; has-known-vulnerability yes;   tunnel-other-application no;   prone-to-misuse no;   pervasive-use yes;   per-direction-regex no;   deny-action drop-reset;   run-decoder no;   cachable no;   file-forward yes;   references {     "Office on Demand" {       link http://office.microsoft.com/en-us/support/use-office-on-any-pc-with-office-on-demand-HA102840202.aspx;     }   }   default {     port tcp/80;   }   use-applications [ ms-office365-base sharepoint-online ssl web-browsing];   applicable-decoders http;   risk 3; application-container ms-office365; } [edit]    office-on-demand 場合、 use-applications [ ms-office365-base sharepoint-online ssl web-browsing] が見られ、 implicit-use-applications のリストがありません。 これは、office-on-demand のすべての機能が正しく動作するように、リスト内のすべてのアプリケーションを明示的に許可する必要があることを意味します。 web-browsing や office-on-demand として許可されたトラフィックを見ることができます。アプリケーションはweb-browsing としてスタートし、Palo Alto Networks DFAにより正しく確認され、これにより "office-on-demand" に変更されます。   もし web がセキュリティポリシーで拒否されている場合、office-on-demand のアプリケーションを許可するルールにヒットしないため、接続が確立されていないように見えます。   owner: ialeksov

※この記事は以下の記事の日本語訳です。 How to Set Up DoS Protection https://live.paloaltonetworks.com/t5/Tutorials/How-to-Set-Up-DoS-Protection/ta-p/71164   ルールベースのDoS protectionを使用する場合、管理者はポリシーを設定して、DoS攻撃者から防御設定できます。ルールベースの設定はPolicies > DoS Protectionからできます。これらのポリシーは、ゾーン、インターフェイス、IPアドレス、ユーザ情報などが一致するものを条件として設定できます。     DoS protectionを使用するには、DoSのルールをセキュリティ・ポリシーのように、設定された条件で流れているトラフックが一致するよう作成します。これらの設定はObjectsタブ> Security Profiles > DoS Protectionにて設定できます。   まず初めに、プロファイルのタイプを明示的にします。aggregateかclassifiedを選びます。   Aggregate: プロファイル上のDoSの閾値をこのプロファイルに設定した条件ルールに一致する全てのパケットに対して適応します。例えば、秒間10000パケットのSyn flood閾値のaggregateルールは、その特定のDoSルールにヒットする全てのパケットをカウントします。 Classified: プロファイル上のDoSの閾値は分類基準別（送信元IP、宛先IPもしくは送信元、宛先IPの組み合わせ別）にカウントします。   DoS protectionプロファイルは、いくつかの種類のDoS攻撃を緩和させるために利用することができます。   Flood protectionはゾーン protectionプロファイルの一つに似ています。Syn floodでは、SYN CookieとRandom Early Drop(RED)がオプションで選べます。他のタイプのfloodではREDが使われます。ゾーン protectionプロファイルでは同じ設定オプションになっていることにお気づきになるでしょう。加えて、Block Durationがあり、攻撃しているIPを何秒間Denyするか設定できます。   Flood protectionに加えて、リソースprotectionも選択できます。このタイプのprotectionは、ホストの使用率を強制します。 特定の送信元IPアドレス、宛先IPアドレス、またはIP送信元と宛先ペアに対して許可されるセッションの最大数を制限します。   次に、Policies > DoS Protectionに移動し、セキュリティ・ルールと同様の手順で、DoSポリシーを作成します。   お気づきのように、ほとんどのパラメータはセキュリティ・ルールと同様です。 ルール名を設定した後、送信元、宛先、およびサービスを設定したら、Aggregateドロップダウンを使用してルールにプロファイルを添付するか、New DoS Protectionをクリックして新しいポリシーを作成できます。   deny/allow/protectの3種類の異なるアクションがあります。   Deny – トラフィックを全て落とします Allow - トラフィックを全て通します Protect - このルールに適用されるDoSプロファイルの一部として構成された閾値で設定された保護を実施します。   Schedule プルダウンを使用して、特定の日時にDoSルールを適用するスケジュールを割り当てることができます。 Log Forwarding プルダウンを使用して、脅威ログエントリをsyslogサーバやPanoramaなどの外部サービスに転送するようにログ転送を設定できます。 このチュートリアルのために、分類されたDoS保護プロファイルタイプを作成しました。 チェックボックスをオンにすると、Profile プルダウンメニューをから分類されたプロファイルタイプを選択できます。 下のAddressプルダウンメニューにて、先ほど述べた分類基準（source-ip-only / destination-ip-only / src-dest-ip-both）を選択できます。   例として、aggregate DoS protectionプロファイルとclassified DoS protectionプロファイルの両方を同じDoSルールに設定できます。   OKを選択し、Commitで設定を保存します。   CLIの場合、設定したDoS ルールを以下のコマンドで確認できます:   > show dos-protection rule <name> settings   このサンプル例では、以下のDoSルールが参照できます。 name = DosRule aggregate profile = DosProtection classified profile = Dos_classified classification criteria = source-only action = Protect   出力結果では、プロファイルで設定した全ての閾値も確認できます。   他にもVideo上で話されているトピックや、サンプルに関連した便利なリンク集が以下となります :   Understanding DoS Protection How to Configure a policy with DoS protection to protect hosted services  Differences between DoS protection and zone protection Video Tutorial – Zone protection profiles Understanding DoS logs and counters   著者: Kim

※この記事は以下の記事の日本語訳です。 How to Create a Security Policy to Block Selective Flash https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Create-a-Security-Policy-to-Block-Selective-Flash/ta-p/61505   概要 この記事は標準のAdobe Flash サイトをブロックしつつ、特定のFlash サイトは許可するセキュリティ ポリシーの設定方法について説明したものとなります。 注: この設定が完全に動作するにはドメインがダイナミック IP アドレスを使用していない必要があります。   手順 example.com と example.org 用のアドレス オブジェクトを作成します。 Object > アドレス に移動し、新たなアドレスオブジェクトを追加します。どちらのアドレス オブジェクトもタイプでFQDNを選択し、ドメイン名を入力します: 注:  example.com が3つのダイナミック IP アドレスにマッチする場合、取得したIPアドレスに基づいた制御になり、FQDN リフレッシュの度(デフォルト30分間隔)にアクセス可能なIP アドレスが変わることになります。 アドレス グループ オブジェクトを作成します。 Object > アドレス グループに移動し、example.com と example.org 用の新たなアドレス グループ オブジェクトを作成します: Policies > セキュリティに移動し、宛先アドレスとして新たに作成したアドレス グループを含むセキュリティ ポリシーを作成します。アプリケーションに"flash"を設定し、アクションは"Allow"を設定します。作成したらこのポリシーを最上部に移動します。 上記のセキュリティ ポリシーの下に、"flash"を拒否する別のセキュリティ ポリシーを作成します。重要なポイントは、上記で設定した以外全てのFlashへのアクセスをブロックするためにこのポリシーを2番目に設定することです。   著者: pchanda  

※この記事は以下の記事の日本語訳です。 What Happens When Licenses Expire on the Palo Alto Networks Firewall? https://live.paloaltonetworks.com/t5/Management-Articles/What-Happens-When-Licenses-Expire-on-the-Palo-Alto-Networks/ta-p/53918   質問: Palo Alto Networks ファイウォールでライセンスの有効期限が切れた場合に何が起こりますか？   回答: ファイアウォールでライセンスの有効期限が切れた場合、下記の事象が発生します。 Support   - オンラインでのソフトウェア アップデートが不可となります。 Threat Prevention   - ThreatおよびAntivirus アップデートが実行されなくなり、スキャンには現状のデータベースが利用されます。 GlobalProtect サブスクリプション   - iOSおよびAndroid デバイスからのVPN接続が不可になります。 WildFire   - FreeバージョンのWildFire機能で動作します。つまり： WildFireではPortable ExecutableもしくはPEファイルのアップロードのみサポートします。 PEファイルタイプとは、拡張子が .exe、 .dll、.scrのファイルや、PEのヘッダー マジック ナンバーと一致したその他の拡張子のファイルを含むコンテナを意味します。 WildFire シグネチャに関しては、WildFire ライセンス有効時のようにWildFire signature feed (5分間隔)でのアップデートは行われませんが、有効なThreat Preventionのライセンスによりアップデートは行われます。 URL Filtering BrightCloud - BrightCloud データベースのアップデートは行われなくなります 。 URL Filtering ライセンスが切れた際の全体の通信に対するURL Filteringのアクションを指定できます。 WebGUI のObjects > セキュリティ プロファイル > URL フィルタリングへ進み、任意のプロファイル名をクリックし下記のウィンドウを表示します。URL Filtering ライセンスが切れた際のアクションとして、通信を許可("allow") もしくはブロック（"block") の2つのオプションから選択できます。 Action On License Expiration で設定されたアクションは、当該URL Filtering プロファイルが適用されたルールにマッチする全てのウェブ通信に適用されます。アクションが"block"に指定されている場合、このルールにマッチする全てのウェブ通信は許可されません。アクションが "allow"に指定されている場合、通信は許可されます。 URL Filtering profile showing Action On License Expiration (BrightCloud) PAN-DB - PAN-DB クラウドではURLのルックアップとアップデートがブロックされます。 URL のカテゴライズには現状のデータベースが引き続き利用されます。現状のURL Filtering セキュリティ プロファイルで各カテゴリ毎に指定されているアクションがウェブ通信に適用されます。 URL エントリがキャッシュに存在する場合は、ルックアップの結果としてキャッシュ内のどのカテゴリでも返ります。 キャッシュ内のエントリが期限切れの場合もしくは存在しない場合は、ファイアウォールは最新の情報をクラウドへ問い合わせることができません。 カテゴライズされないURLへの通信は許可されます。 カスタム カテゴリ設定で指定されているURLは引き続きカスタム カテゴリに一致する動作になります。 PAN-DBの場合、URL Filtering セキュリティプロファイルに"Action On License Expiration   option "設定はありません。 新しいライセンスを取得した場合 ファイアウォールでDevice > ライセンス より新しいライセンスを取得した場合は、適用後すぐにライセンスに準じた通常の動作に戻ります。 注:  ファイアウォール上で 再度動作させるためのcommitや再起動は不要です。   著者: jjosephs

※この記事は以下の記事の日本語訳です。 How to View/Clear Sessions https://live.paloaltonetworks.com/t5/Management-Articles/How-to-View-Clear-Sessions/ta-p/52577   ファイアウォール上のアクティブセッションを表示： > show session all ------------------------------------------------------------------------------------------ ID/vsys application state type flag src[sport]/zone/proto (translated IP[port]) dst[dport]/zone (translated IP[port] ------------------------------------------------------------------------------------------ 129617/1 skype ACTIVE PRED 0.0.0.0[0]/corp-trust/6 (0.0.0.0[0]) 97.87.56.37[28775]/corp-untrust (97.87.56.37[28775]) 114143/1 yahoo-voice ACTIVE FLOW 10.16.3.232[49259]/corp-trust/6 (10.16.3.232[49259]) 68.142.233.183[443]/corp-untrust (68.142.233.183[443])   セッション ID を指定して特定のセッションを削除： > clear session ID 129617 session 129617 cleared   全てのセッションを削除： > clear session all    セッションを削除する際に利用可能なフィルターの一覧を表示： > clear session all filter [tab] + application Application name + destination destination IP address + destination-port Destination port + destination-user Destination user + from From zone + nat If session is NAT + nat-rule Rule name + protocol IP protocol value + proxy session is decrypted + rule Rule name + source source IP address + source-port Source port + source-user Source user + state flow state + to To zone + type flow type <Enter> Finish input   特定のアプリケーションのセッションを削除： > clear session all filter application skype Sessions cleared   特定の送信元もしくは宛先 IP アドレスのセッションを削除： > clear session all filter source 192.168.51.71 Sessions cleared > clear session all filter destination 8.8.8.8 Sessions cleared     注:  セッションを削除するすべてのコマンドは、単体のファイアウォールもしくは High Availability (HA) 構成のペアのファイアウォール上で同様に動作します。     参照:   How to Clear Sessions from the Session Monitor   著者: panagent

※この記事は以下の記事の日本語訳です。 How to View Application-Default Ports for an Application https://live.paloaltonetworks.com/t5/Management-Articles/How-to-View-Application-Default-Ports-for-an-Application/ta-p/61616   概要 "Application-default" ポートは、様々なアプリケーションで使用されるデフォルトの宛先ポートであり、セキュリティ ポリシーの設定でよく使用されます。   詳細 次のコマンドを使用して、各アプリケーションの"application-default" ポートを確認することができます: # show predefined application <application>   以下の例では、"gmail-base"によって使用されるデフォルトの宛先ポートがデフォルト セクションに表示されています: > configure Entering configuration mode [edit] # show predefined application gmail-base gmail-base {   ottawa-name gmail;   category collaboration;   subcategory email;   technology browser-based;   description "Gmail is a free, advertising-supported email service provided by Google. Users may access Gmail as secure webmail, as well as via POP3 or IMAP4 protocols.";   alg no;   appident yes;   virus-ident yes;   spyware-ident yes;   file-type-ident yes;   vulnerability-ident yes;   evasive-behavior no;   consume-big-bandwidth no;   used-by-malware yes;   able-to-transfer-file yes;   has-known-vulnerability yes;   tunnel-other-application yes;   prone-to-misuse no;   pervasive-use yes;   per-direction-regex no;   timeout 1800;   deny-action drop-reset;   data-ident yes;   run-decoder no;   cachable no;   file-forward yes;   references {     Wikipedia {       link http://en.wikipedia.org/wiki/Gmail;     }   }   default {     port tcp/80,443,993,995,465,587;   }   use-applications [ imap pop3 smtp ssl web-browsing];   tunnel-applications [ gmail-chat gmail-drive gmail-enterprise google-buzz google-talk-base];   implicit-use-applications web-browsing;   applicable-decoders http;   risk 4;   application-container gmail; } Web UIで同じ情報を確認することができます。(Objects > アプリケーション) 以下のスクリーンショットは、gmail-baseのポートを表示したもので、標準ポート (Standard Ports) で確認できます:   著者: sdurga

※この記事は以下の記事の日本語訳です。 How to Use Anti-Spyware, Vulnerability and Antivirus Exceptions to Block or Allow Threats https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Use-Anti-Spyware-Vulnerability-and-Antivirus-Exceptions/ta-p/66099   この記事は、アンチスパイウェア、脆弱性防御、アンチウイルスの例外設定において、Palo Alto Networks ファイアウォールで、特定脅威のアクションを変更する方法について記述しています。    アンチスパイウェア、脆弱性防御の例外設定 この例では、アンチスパイウェアの既存プロファイル名 "Threat_exception_test_profile" の例外設定に脅威ID番号30003を追加します。 Objects > セキュリティ プロファイル > 'アンチスパイウェア' もしくは '脆弱性防御' に移動します。 既存のプロファイルを選択 "例外 (Exceptions)"タブを選択 まず、画面左下にある"Show all signatures"チェックボックスを選択し、 検索フィールドで、検索したい文字列（例：'microsoft' ）もしくは脅威ID番号（例：30003）を入力し、改行ボタン、もしくは緑の矢印をクリックし、検索を実行します。 注意: もしシグネチャ検索がdynamic update直後で、検索結果が得られない場合は、GUIのキャッシュをクリアするために、WebUIをログアウトして、ログインしなおしてください。 "Microsoft Windows DCOM RPC Interface Buffer Overrun Vulnerability"（脅威ID番号30003）が表示されます。 注意: 脅威ID番号は、threatログから容易に見つけられます。 この例外を有効にするため'Enable'ボックスをクリックします。 既定の'アクション'を変更するため、通過させたい場合はAllow、落としたい場合は、Dropを選択します。 Threat Action detail - change default action. IPアドレスの例外欄は、脅威例外をIPアドレスでフィルターしたい場合に使います。もしIPアドレスが追加されれば、送信/宛先IPアドレスが例外設定と一致した場合のみ、シグネチャのルールアクションが適応されます。シグネチャ当たり100個までIPアドレスを追加できます。このオプション設定によって、特定のアドレス毎に、新しいセキュリティ・ルールを作る必要はありません。全てのトラフィックでなく特定のアドレスを除外したい場合、画面下の"IP Address Exemptions"をクリックして、追加したいIPアドレスを100個まで追加してください。 IP Address Exemption detail. IPアドレス例外設定詳細 アンチスパイウェアもしくは脆弱性防御プロファイルが適切なセキュリティ ポリシーに設定されていることを確認してください。 例外設定を有効にするためにCommitを実行します。   アンチウイルス例外設定 この例では、アンチウイルスの既存のプロファイル名 "AV_exception_test_profile" の例外設定に脅威ID番号253879を追加します。 （注意: アンチウイルスの例外設定は、全体に対して有効か無効かの設定であり、特定のIPアドレスに対しての例外設定はできません）   Objects > セキュリティ プロファイル > アンチウイルスに移動します。 既存のプロファイルを選択し、ウイルス例外 (Virus Exception) タブをクリック。 ID（この例では253879）をページ下の脅威 ID フィールドに入力し、追加をクリックします。 注意: 脅威 IDはthreat ログから見つけられます。 この例では、"Win32/Virus.Generic.koszy"の例外が作られました。 AntiVirus - Virus Excemption window detail. AntiVirus – Virus例外ウィンドウの詳細 アンチウイルス プロファイルが適切なセキュリティ ポリシーに設定されていることを確認してください。 アンチウイルス例外設定には特定IP アドレスを除外するオプションはありません。 変更を反映するためにCommitを実施します。   著者: kadak

※この記事は以下の記事の日本語訳です。 How to View the Installed and Latest Versions of PAN-DB https://live.paloaltonetworks.com/t5/Management-Articles/How-to-View-the-Installed-and-Latest-Versions-of-PAN-DB/ta-p/61912     概要 BrightCloudの利用時はweb UIの   Device > ダイナミック更新 > URLフィルタリング  にてバージョンを確認することができます。しかしPAN-DBの更新では異なります。この文書はPalo Alto NetworksファイアウォールにインストールされているPAN-DBバージョンと、ダウンロードできる最新の利用可能なバージョンの確認方法を記載します。     詳細 show system info コマンドは、ファイアウォールにインストールされているPAN-DBのバージョンを表示するのみです。   > show system info    ..... url-filtering-version: 2013.06.10.107    .....   ファイアウォールにインストールされたバージョンだけでなくクラウドで利用可能なバージョンは   show url-cloud status   コマンドを使うことで確認できます。   例： > show url-cloud status PAN-DB URL Filtering License : valid Current cloud server : s0200 Cloud connection : connected URL database version -   device   : 2013.06.10.107 URL database version -   cloud   : 2013.06.10.107 ( last update time 2013/06/11 15:54:22 ) URL database status : good URL protocol version - device : pan/0.0.2   PAN-DBは日次の更新はなく、代わりに必要に応じてURLのエントリーが取得されます。Palo Alto Networksファイアウォールは更新を自動でチェックし、８時間おきに最新のURLフィルタリングデータベースがダウンロードされたかを示すシステムログが生成されます（訳注：2018/02/28現在、PAN-OS 7.1.15環境で15分おきにチェック、ログ生成が行われています）。   参照 How to Install and Activate PAN-DB for URL Filtering   著者： kprakash

※この記事は以下の記事の日本語訳です。 VOIP Traffic Disconnects Every 30 Seconds https://live.paloaltonetworks.com/t5/Configuration-Articles/VOIP-Traffic-Disconnects-Every-30-Seconds/ta-p/54844   問題 VoIPでの通話をカスタマーが行う際、  Palo Alto Networks機器がINVITE（訳注：SIPでのセッション確立要求）を受信すると、適切なメッセージとサウンド（訳注：RINGINGを指すと思われます）にて対向側は応答します。電話はメッセージを受信しますが、カスタマーは相手と30秒のみ通話可能で、その後に切断されてしまいます。     原因 SIP ALG （アプリケーション レベル ゲートウェイ）は通常ルーターまたはファイアウォールに実装されるセキュリティコンポーネントです。この機能はNAPT（ネットワーク アドレス ポート変換）時に、ファイアウォールのプライベートからパブリック、またその逆の両方の方向でVoIPトラフィックを許可します。SIP ALGはSIPトラフィックを透過させるために、SIPパケットの精査と書き換えを行います。   この問題はINVITE ハンドシェイクにおける致命的な応答の欠落によって引き起こされていることが考えられます。もし200 OKに対応するACKが受信されていないと、通話はおよそ30秒後に切断されます。     解決策 RTPとSIPトラフィックのためのカスタム アプリケーション オーバーライドを設定します（参照：Application Override Policyの作成方法）。   例: 以下の2つのスクリーンショットがSIPオーバーライド ポリシーの設定のサンプルとなります。     以下のスクリーンショットが アプリケーション オーバーライド設定が完了した状態を示します。   注：設定した カスタムアプリケーションはセキュリティー ポリシーでも許可される必要があります。   著：pvemuri  

※この記事は以下の記事の日本語訳です。 How to Improve Performance for Protocols like SMB and FTP Without Application Override https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Improve-Performance-for-Protocols-like-SMB-and-FTP/ta-p/60544     概要 SMBやFTP ファイル転送は多量の双方向トラフィックを生成します。SMBはほとんどすべてのデータ パケットの生成毎に、応答パケットを生成し、それゆえにやりとりが多くなります。Palo Alto Networksファイアウォールは、デフォルトでクライアント→サーバー方向(C2S)とサーバー→クライアント方向(S2C)の双方向を検査をします。これによりファイアウォールを通過するSMBやFTPファイル転送は遅くなりがちです。   トラフィックのパフォーマンスを向上する方法の一つとして、レイヤー7の検査とアプリケーション識別を行わないようにする、アプリケーション オーバーライドを使用する方法があります。   もしレイヤー7の検査が必要、かつパフォーマンス向上が必要な場合は、関連のトラフィックが該当するセキュリティ ポリシーにて'サーバー レスポンス検査の無効化(DSRI)'オプションをチェックする方法があります。これは該当のサーバーが信用できる場合にのみチェックされるべきです。 'サーバー レスポンス検査の無効化(DSRI)'がチェックされると、ファイアウォールはC2Sのトラフィックのみ検査し、転送レートが向上します。   詳細 'サーバー レスポンス検査の無効化(DSRI) ' を有効にするには、WebUIにてPolicies > セキュリティ > アクションに移動する必要があります。   ポリシーが作成されると、 'サーバー レスポンス検査の無効化(DSRI) ' オプションがチェックされたことを示すアイコンがセキュリティ ルール上に表示されます。   著者: kadak

※この記事は以下の記事の日本語訳です。 How to Block the Psiphon Application https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Block-the-Psiphon-Application/ta-p/52256   問題 Psiphonのトラフィックを止めるには、複数のアプリケーションをブロックする必要があります。   解決策 Psiphonは検閲回避のためのトンネリングアプリケーションですが、コミュニケーションに追加の保護を加えません。Psiphonのサイトでは  「Psiphonは通常フィルターされているコンテンツへアクセスするチャネルを提供します。Psiphonはセキュアなコミュニケーション環境の代替手段とはなりません。Psiphonはセキュアなe-mail、暗号化ハード ドライブ、あるいはend-to-endの匿名性を提供することはありません。」（訳注）と記載されています。   訳注：上記のPsiphonサイトの引用原文"Psiphon is designed to provide a channel to access content that is normally filtered. It is not a replacement for a secure communication environment. Psiphon will not secure e-mail, encrypt hard drive, or provide the user with end-to-end anonymity."は本ドキュメントの原文作成時点での記載です。現在のPsiphonのサイトの記載は、一部変更されています。   Psiphonは以下の3つのプロトコルを使用します： 新しい版のドキュメンテーションに基づいたHTTPプロキシー。SSLのサポートが追加されています。 SSH VPN: Ike/Ipsec/l2tp Psiphonをブロックするには、内部セグメントのVPNトラフィックに加えて、SSLとSSHの復号化もブロックしなければなりません。内部のユーザーのVPN関連アプリケーションのみをブロックすることが大変重要です。広範に渡るルールの追加は、リモートサイトとの接続性の問題の原因となる可能性があります。   著者：ppolizzi  

※この記事は以下の記事の日本語訳です。 Differences between DoS Protection and Zone Protection https://live.paloaltonetworks.com/t5/Learning-Articles/Differences-between-DoS-Protection-and-Zone-Protection/ta-p/57761   DoS プロテクション ポリシーは ある程度はゾーン プロテクションと同等の目的を達するために使用されますが、いくつか主要な違いがあります。 大きな違いはClassifiedとAggregateがDoS プロテクション ポリシーにあることです。ゾーンプロテクションではAggregateが利用可能です。 Classifiedのプロファイルは一つの送信元 IPに対する閾値の作成を可能とします。 例：ポリシーにマッチするすべてのトラフィックに対して、IPごとの最大セッション レートを設定し、一つのIPアドレスが閾値に達したらブロックする。 Agregate プロファイルはポリシーにマッチするすべてのトラフィックに対しての最大セッション レートの作成を可能とします。閾値はすべてのIPを合わせた新規セッション レートに対して適用されます。閾値に達するとすべてのマッチするトラフィックに適用されます。 ゾーン プロテクション ポリシーはフラッド防御とポートスキャニング/スイープとパケットベース攻撃に対して防御することが可能となります。例としてIPスプーフィング、フラグメント、オーバーラッピング セグメント、 tcp-non-syn拒否が挙げられます。 ゾーン プロテクション プロファイルは、セッション生成前に適用されてポリシー エンジンの処理に入らないため、パフォーマンスへのインパクトが小さくなります。   著者： jteetsel

※この記事は以下の記事の日本語訳です。 How to Import and Export Address and Address Objects https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Import-and-Export-Address-and-Address-Objects/ta-p/56124   詳細 この文書は、あるファイアウォールから別のファイアウォールへのアドレスとアドレスオブジェクトを再度手動で定義し直すことなく、インポート/エクスポートする方法を記載します。複数のパロアルトネットワークス ファイアウォールが異なるサイトにあり、既存のアドレスおよびアドレスグループ設定を活用したい状況を想定しています。   手順 既存のファイアウォールにアドレスとアドレス オブジェクトがあることを確認します。 CLIから設定の出力フォーマットを'set'として、アドレスとアドレスグループ 情報を抽出します。 > set cli config-output-format set > configure Entering configuration mode [edit] # show address set address google fqdn google.com set address google description "FQDN address object for google.com" set address mgmt-L3 ip-netmask 10.66.18.0/23 set address mgmt-L3 description "IP Netmask address object for mgmt-L3" set address trust-L3 ip-netmask 10.66.20.0/23 set address untrust-L3 ip-netmask 10.66.24.0/23 set address dmz-L3 ip-netmask 10.66.22.0/23 [edit] # show address-group set address-group Inside static [ dmz-L3 mgmt-L3 trust-L3 ] set address-group Outside static [ google untrust-L3 ] [edit] 上記の出力から全ての'set' コマンドをメモ帳などでファイルに保存し、他のファイアウォール向けに編集します。アドレス グループについては、'[]'部分も含めて全てsetコマンドをコピー/ペーストするようにしてください。 他のファイアウォールのCLIにログインし、CLI 設定出力フォーマットを 'set' として、コマンドの出力結果をコンフィグレーションモードでペーストします。 > set cli config-output-format set > configure # <paste all the set commands here> # commit   著者：  kadak

※この記事は以下の記事の日本語訳です。 How to Create Subordinate CA Certificates with Microsoft Certificate Server https://live.paloaltonetworks.com/t5/Learning-Articles/How-to-Create-Subordinate-CA-Certificates-with-Microsoft/ta-p/58046   概要 この文書はMicrosoft Certificate Serverを使用した下位CA証明書の作成方法について記載します。 " http:// <IPアドレスまたはサーバー名>/certsrv"をブラウザで開き、サーバーの画面にアクセスします。 "Welcome"画面にて、"Request a Certificate"を選択します。 次の画面で"advanced certificate request"を選択します。 "Create and Submit a request to the CA"を選択します。 次の画面のフォームで、"Certificate Template"のプルダウン メニューから"Subordinate Certification Authority"を選択します。証明書のための必要事項を入力します（名前、連絡先など）。申請を行うとローカル システムに証明書をダウンロードするためのリンクが表示されます。 ダウンロード後、ローカルの証明書ストアから証明書をエクスポートします。"Internet Options"画面にて"Content"タブを選択し、"Certificates"ボタンをクリックします。新しい証明書をPersonal証明書ストアからエスクポートすることができます。 "Certificate Export Wizard"を表示するには、"Export"ボタンをクリックします。 "Certificate Export Wizard"画面にて、"Yes, export the private key"を選択し、続いてフォーマットを選択します。パスワードとファイル名、保存場所を指定します。   Microsoft Certificate Serverは、おそらく証明書をPFXフォーマット(PKCS #12)で提供しています。 証明書をPEMフォーマットでエクスポートするには、以下の手順で行います。 openSSLを使い、 openssl pkcs12 –in pfxfilename.pfx –out tempfile.pem と入力します。 "tempfile.pem"をテキスト エディターで開きます。 -----BEGIN RSA PRIVATE KEY----- で始まっているセクションを見つけます。 -----END RSA PRIVATE KEY----- までの全テキストを選択し、新しいファイルに貼り付けて、拡張子".key"をつけて保存します。 ".pem"ファイルからそれ以外のテキストをコピーし、別のファイルに貼り付け、拡張子".crt"をつけて保存します。 上記の手順により、keyファイルと証明書をインポートすることができます。   CLIコマンド お客様のルートCAがWebインターフェイスを備えていない場合もあり、その場合はCLIを通して 同じ操作を 行うことができます。 Microsoft CAにおけるコマンド：   certreq -submit -attrib "CertificateTemplate:SubCA" <certificate-signing-request>.csr   このコマンドを入力することでGUIプロンプトが表示され、そのプロンプトで申請するCAを選択します。通常、同じサーバ上にはルートCAは1つだけなので、表示されているCAを選択します。 その後、該当する申請がCAサーバーの保留中の申請の中に表示されます。     著者：panagent

※この記事は以下の記事の日本語訳です。 Resolving the URL Category in Decryption When Multiple URLs Use the Same IP https://live.paloaltonetworks.com/t5/Management-Articles/Resolving-the-URL-Category-in-Decryption-When-Multiple-URLs-Use/ta-p/62573   PAN-OS 6.0 問題 Google のように同一 IP アドレスに紐付く複数の Web サービス (Google ドライブ、翻訳、ウェブ検索、Google+、マップ、Google Play、Gmail、カレンダーなど) がある場合に問題が発生します。   DNS が www.google.com と www.drive.google.com の両方を同じ IP アドレス（例：173.194.78.189）に解決する場合、ホストは google.com と drive.google.com の両方で同じ IP アドレスを使用します。そのため、最初のセッションで処理されるトラフィックが www.google.com の場合、ローカル キャッシュは IP アドレス 173.194.78.189 を "search-engines" にマッピングします。その後、次のホストが同じ宛先 IP アドレスを使用して www.drive.google.com にアクセスした場合、URL カテゴリは "online-personal-storage" ではなく "search-engines" にマッピングされます。 "online-personal-storage" のカテゴリを復号化するように設定された復号化ポリシーは、"search-engines" にマッピングされたトラフィックにマッチしないので、drive.google.com へアクセスした際のトラフィックは復号化されません。   詳細 SSL 復号化に関する問題のトラブルシューティングの際には、まず初めに復号化メカニズムが URL  カテゴリとどのように機能するかを理解することが肝心です。セキュアな SSL トンネルを確立するために、クライアントとサーバーは SSL ハンドシェイクを実施し、クライアントは通常、サーバ証明書に基づいてサーバーを認証します。HTTPS 接続は常にクライアントによって開始され、最初にサーバー URL を名前解決した後、名前解決した IP アドレス宛に Client Hello メッセージを送信します。クライアントはサーバー側からサーバー証明書を含む応答を待ちます。   適切な URL カテゴリに解決した上で、SSL トラフィックを復号化するかどうかを決定するために、Palo Alto Networks ファイアウォールはサーバーから受信した証明書のコモン ネーム (CN) フィールドを使用します。そのため、URL のカテゴリ識別はサーバー証明書の CN フィールドに基づいて行われます。解決された URL カテゴリはクライアント側から送信されたパケットの宛先 IP アドレスにマッピングされます。URL カテゴリを識別する処理を高速化するために、ファイアウォールはローカル キャッシュ メモリに各 URL と宛先 IP アドレスのマッピング情報を格納します。したがって、次に同じ宛先 IP アドレスへの SSL トラフィックが発生した際は、既にローカル キャッシュ ファイルに格納されている URL カテゴリで解決されます。復号化のための URL カテゴリのメカニズムは次のようになります: ファイアウォールによって Client Hello メッセージがインターセプトされます ファイアウォールはパケットの宛先 IP を決定します ファイアウォールは宛先 IP とローカル キャッシュ メモリに保存されている IP, URL カテゴリのマッピングリストを比較します リストに同じ IP が存在した場合、URL カテゴリはローカル キャッシュ メモリのリストで識別されます ローカル キャッシュのリストに同じ IP が存在しなかった場合、ファイアウォールはサーバー証明書の CN フィールドを確認するために、サーバーからの応答を待ちます URL カテゴリ識別が CN フィールドに基づいて行われ、サーバーの IP と URL カテゴリがマッピングされるとともに、次回以降に利用するためにローカル キャッシュ メモリのリストに追加されます   解決方法 PAN-OS 6.0 以降では SSL 復号化の適正化を目的として URL のカテゴリ識別の新しい方法を導入しました。この新しい方法はサーバー証明書の CN フィールドに基づくのではなく、SSL Client Hello メッセージの SNI (Server Name Indication) 値に基づきます。この方法を使用すると各状況下で Palo Alto Networks のファイアウォールがアップ ストリーム トラフィックの URL カテゴリを適切に識別し、その情報を基に正しい復号化ポリシーを適用することができます。     注意: Windows XP の最終バージョンである IE 8.0 のような古いバージョンのブラウザでは SNI フィールドはサポートされていません。そのため、SNI を用いたこの解決方法は Windows XP や古いバージョンのブラウザを使用しているクライアントでは機能せず、引き続き CN フィールドを用いて識別されます。   著者: djoksimovic  

※この記事は以下の記事の日本語訳です。 URL Filtering Order https://live.paloaltonetworks.com/t5/Management-Articles/URL-Filtering-Order/ta-p/59334   問題 URL Filtering プロファイルの中で URL が複数の箇所(複数のカスタム URL フィルタリング カテゴリや、許可/ブロック リスト)にマッチした場合、どうなりますか？   解答 その場合、下記の中で一番厳しいアクションが設定されたカテゴリが選択されます(block が最も厳しく、allow が最も軽い)。 block override continue alert allow   例えば、*.yahoo.com が同じ URL Filtering プロファイル内の MyAlertList と MyBlockList というカスタム カテゴリに同時に存在する場合、www.yahoo.com という URL に対するアクションは block となり、そのカテゴリは MyBlockList となります。これは、許可リストとブロック リストに同時にマッチする URL があった場合、許可リストより先にブロック リストがチェックされるのと同様です。 URL Filtering のプライオリティは以下の通りです。 ブロック リスト 許可リスト カスタム カテゴリ キャッシュ 事前定義済みのカテゴリ   著者:  ukhapre

この記事は以下の記事の日本語訳です。 Incorrect QoS Configuration Caused Network Traffic Outage https://live.paloaltonetworks.com/t5/Configuration-Articles/Incorrect-QoS-Configuration-Caused-Network-Traffic-Outage/ta-p/62576 問題 特定のクラスに対してQoSプロファイルにて帯域を制限しようとすると、QoS機能により通信障害が発生する。   詳細 以下の例は、QoSを使用するインターフェイスに関連付けられた誤った設定の例です。 この例のシナリオでは、10Gbインターフェイスが使用されており、上記のスクリーンショットは最大保証帯域 出力側を100Mbpsと設定していることを示します。プロファイル部の最大保証帯域 出力側には、この10Gbインターフェイスを通過するトラフィックのための、すべてのクラスに対しての最大の出力帯域を設定します。   多くの場合に、上記の設定がユーザーより重度の輻輳や通信断の振る舞いとして報告される問題の原因となっています。   解決策 QoSプロファイルを設定するときは、該当のインターフェイスに流れ込む総合的な帯域を考慮し、最大保証帯域 出力側を慎重に設定する必要があります。前述の意図した設定は、class7 のトラフィックを最大保証帯域 出力側を100、そして最低保障帯域 出力側を10とすることでしたが、他のすべてのトラフィックも該当インターフェイスの残りの帯域を使用します。   以下のスクリーンショットは、プロファイルの最大保証帯域 出力側を10000Mbpsとし、class7 トラフィックの最大保証帯域 出力側を100、最低保障帯域 出力側を10とした 正しい設定です。   該当のQoS インターフェイス設定も正しい値で最大保証帯域 出力側が設定されている必要があります。   注: 必要なクラスのみをQoS プロファイルで設定するだけで構いません。他のトラフィックはデフォルトのclass4となります。   著者: fkhan

この記事は以下の記事の日本語訳です。 Using IP Address Lists on Palo Alto Networks Policies https://live.paloaltonetworks.com/t5/Configuration-Articles/Using-IP-Address-Lists-on-Palo-Alto-Networks-Policies/ta-p/57411     詳細 ファイアウォールのポリシーにて使用するIPアドレス リストおよびそのインポート手段には、複数の方法があります。   選択肢 定義済みの地域（Region）またはカスタムの地域の使用 定義済みの地域あるいはカスタムで作成した地域の使用法については How to Configure a Security Policy to Use a Region（訳注1）をご覧ください。 カスタムの地域は単体のIP(x.x.x.x)、範囲指定（x.x.x.x-y.y.y.y）ないしはIP/ネットマスク（x.x.x.x/n）となります。もしカスタムの地域を使用しており、そして隣接していないアドレス体系をWeb GUIかCLIで手動で追加した場合、CLI端末上でのコマンドのリストをコピーしたり、バッチ処理したりすることができます。   > configure # set region <RegionName> # set region <RegionName> address <IPAddress_01> where <RegionName> is a string (31 characters max) <IPAddress> is a list of values, an IP range, or ip/netmask   エントリーの削除 # delete region <MyRegion> address <IPAddress_nn>   使用しているすべての地域の削除 # delete region <MyRegion> 注: 変更後はコミットを実行してください。   FQDNアドレスオブジェクトの使用 DNS Aレコードは権威のない複数の回答に関連付けられます。Palo Alto Networks ファイアウォールは権威のない回答のうち最初の10個の回答のみを読み込んでキャッシュします。この動作の詳細はFQDN オブジェクトの設定およびテスト方法を参照してください。このソリューションは10個以上のIPアドレスがリストにある場合にはスケールせず、DNS問い合わせは設定されたDNSサーバーに到達するインターフェイスのIPアドレスを送信元として使用します。サービスルートを設定しない限りは、デフォルトの管理インターフェイスのアドレスがDNS問い合わせに使用されます。DNS サービスルートの設定とその注意点についてはDNS Service Route is Applied to All Traffic Going to DNS Server IP Addressを参照してください。     ダイナミック ブロック リスト(EBL)の使用（訳注2） この方法はウェブサーバー上へのテキストファイルのホスティングが必要となります。"繰り返し”オプションにて毎時、毎日、毎週、月次といった形での更新が可能です。ダイナミック ブロック リスト オブジェクトの作成後は、該当のアドレス オブジェクトをポリシーの送信元や宛先のフィールドに使用できます。インポートしたリストはIPアドレス（IPｖ4とv6の合計）、IPの範囲、またはサブネット指定です。エントリーの上限については 外部ブロック リスト (EBL) のフォーマットと制限の操作をご覧ください （訳注3）。また設定の詳細はDynamic Block List (DBL) や External Block List (EBL)の構成方法について をご覧ください。     ダイナミック アドレス グループの使用 ダイナミック アドレス グループを使うとPalo Alto Networks APIを活用できます。IPアドレスのリストはXMLフォーマットに準拠する必要があります。この方法は大変スケーラブルかつフレキシブルで、自動でダイナミック アドレス グループをサードパーティーのスクリプトで変更する場合に推奨されます。ダイナミック アドレス グループを使用する大きな利点は、既存のダイナミック アドレス グループに対してIPアドレスの追加や削除をコミットなしで迅速に行えることです。詳細は Working with Dynamic Address Groups on the Palo Alto Networks firewall をご覧ください。   スタティック アドレス グループの使用 アドレス オブジェクトはWeb GUI上で作成でき、アドレス グループに関連付けられます。この処理はCLIでバッチ化することも可能です。詳細は How to Add and Verify Address Objects to Address Group and Security Policy through the CLIをご覧ください。 > configure # set address <AddressObject_01> ip-netmask 1.1.1.1/32 # set address <AddressObject_02> fqdn my.example.com . . . # set address <AddressObject_nn> ip-range 2.2.2.2-3.3.3.3 # set address-group <AddressGroup> static [ <AddressObject_01> <AddressObject_02> ...<AddressObject_nn> ]   変更を有効にするためにコミットを実行してください。   注: <AddressObject> 部分は以下のフォーマットとなります。      <ip-range>      <ip/netmask>      <fqdn>   アドレス オブジェクトを削除するには以下のコマンドを使用してください。 # delete address <AddressObject_01> ip-netmask 1.1.1.1/32 # delete address <AddressObject_02> fqdn my.example.com . . . # delete address <AddressObject_nn> ip-range 2.2.2.2-3.3.3.3   注：アドレス オブジェクトは個別のエントリーであり、スタティック アドレス グループを削除しても、そのグループが参照するアドレス オブジェクトは削除されません。 以下のコマンドのいずれかでアドレス オブジェクトの関連付けを解除します。 # delete address-group <AddressGroup> static <AddressObject_nn> # delete address-group <AddressGroup> static ><AddressObject_01> <AddressObject_02> ... <AddressObject_nn> ]   すべてのグループを削除するには以下のコマンドを使用します。 # delete address-group <AddressGroup> static   変更を有効にするためにコミットを実行してください。   訳注1：原文では Palo Alto Networks Pre-defined Regions を参照していますが、現在このドキュメントは参照ができないため、本文中では別のドキュメントを参照しています。 訳注2：PAN-OS 7.1から"外部ダイナミック リスト"に名称を変更しています。 訳注3：参照ドキュメントを加えた上で、原文より記載を変更しています。   著者：mivaldi

※この記事は以下の記事の日本語訳です。 How to Add and Verify Address Objects to Address Group and Security Policy through the CLI https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Add-and-Verify-Address-Objects-to-Address-Group-and/ta-p/61627     複数のアドレス オブジェクトを作成し、それをグループやポリシーに追加する方法を説明します。   手順 アドレス オブジェクト "test" を作成し、それをアドレス グループ "test-group" に割り当てます。 設定モードに入ります。 > configure IPアドレスを持つアドレス オブジェクトを作成します。 # set address test ip-netmask 10.30.14.96/32 そのアドレス オブジェクトをアドレス グループに割り当てます。 # set address-group test-group test その変更をコミットします。 # commit   アドレス グループ "test-group" をセキュリティ ポリシーに追加します。 設定モードに入ります。 > configure そのアドレス グループをセキュリティ ポリシーに割り当てます。 # set rulebase security rules trust-DMZ action allow source test-group その変更をコミットします。 # commit   以下のコマンドで、先ほど定義した "test-group" の内容を表示できます。 > configure # show rulebase security rules DMZ-Trust DMZ-Trust {   source test-group ;   destination any;   service any;   application any;   action allow;   source-user any;   option {     disable-server-response-inspection no;   }   negate-source no;   negate-destination no;   log-start no;   log-end yes;   from DMZ;   to L3-Trust;   disabled no;   category any;   hip-profiles any; }   CLI上でアドレス オブジェクトやグループ オブジェクトを確認するには、以下のコマンドを実行します。 # show address-group address-group {   test-group {     static [ test1 test1-1 test2 test2-1 test3];   } }   個別のアドレスを確認するには、以下のコマンドを実行します。 # show address   注：CLIに関する情報をさらに知りたい場合は、Live Community 内でCLI リファレンス ガイドをご参照ください。     著者：djoksimovic

※この記事は以下の記事の日本語訳です。 How to Verify DNS Sinkhole Function is Working https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Verify-DNS-Sinkhole-Function-is-Working/ta-p/65864     詳細 この資料では、DNSシンクホール機能がPAを経由して正しく動作しているかどうか確認する方法について説明します。 以下の2つのシナリオに対応しています： クライアントが外部DNSサーバーを使用している クライアントが内部DNSサーバーを使用している   DNSシンクホールのコンフィグレーション DNSシンクホールの設定方法についてはこちらを参照して下さい。 How to Configure DNS Sinkhole   また、DNSシンクホールの設定方法について、ビデオでのチュートリアルが以下に公開されています。 Video Tutorial: How to Configure DNS Sinkhole   クライアントが外部DNSサーバーを使用している 注：DNSシンクホールのIPアドレスは、ファイアウォールとクライアントの経路上にある必要があります。それにより、ログを見ることができます。例えば、Palo Alto Networksファイアウォールは感染したクライアントとデータ センターの間に位置していますが、インターネットへ向かうトラフィックはファイアウォールを通過しない環境だとします。そのシナリオでは、DNSシンクホールがインターネットのIPアドレスで設定されている場合、ファイアウォールは、感染したクライアントがC&C(コマンド＆コントロール)サーバーに接続しようとしているのを見ることは出来ません。   DNSシンクホールの機能がPalo Alto Networksファイアウォールで設定されており、クライアント システムが外部DNSサーバーを使用している時、クライアントからのDNSクエリは、Palo Alto Networksファイアウォールを通って、外部DNSサーバーに向かいます (クライアントとDNSサーバーは異なるサブネットに属しています)。期待したとおりに、ユーザーは送信元としてのクライアントのIPアドレスを含む脅威ログを見ることができます。   ユーザーは感染したウェブサイトにアクセスしようとしています。クライアント システムは、感染したウェブサイトのIPアドレスを取得するために、DNSクエリを外部DNSサーバーへ送ります。ファイアウォールは、クライアント システムから直接DNSクエリを受け取ります。 ファイアウォールはDNSクエリを乗っ取り、DNSシンクホール IPアドレスがクライアントに渡されることで、送信元としてのIPアドレスを含む脅威ログを見ることができます。   クライアントのTCP/IPプロパティの設定 以下の設定例をご覧ください。   脅威ログ 外部DNSサーバーを使用している際、脅威ログでは、感染したウェブサイトにアクセスしようとしているクライアントのIPアドレス "10.50.240.131" を送信元として表示しています。   外部DNSサーバーを使用している時のクライアントの出力   上記のスクリーンショットは、ホスト マシン "10.50.240.131" が "sp-storage.spccint.com(疑わしいURL)" に対してDNSリクエストをしていることを示しており、それが "1.1.1.1" であることを表示しています。このように、DNSシンクホールは期待した通りに動作していることを示しています。   クライアントが内部DNSサーバーを使用している クライアント システムが内部DNSサーバーを使用している場合(クライアントとDNSサーバーは同じサブネットに所属しています)、クライアントからのDNSクエリは内部DNSサーバーに向かいます。内部DNSサーバーがこのクエリを外部DNSサーバーに転送することで、送信元としての内部DNSサーバーのIPアドレスを含む脅威ログを見ることができます。   現在、Palo Alto Networksファイアウォールでは、脅威ログを利用したとしても、どのエンドのクライアントが感染したウェブサイトにアクセスしようとしているのかを特定することはできません。なぜなら、すべての脅威ログは送信元として、内部DNSサーバーのIPアドレスが表示されるためです。しかしながら、ファイアウォールはトラフィック ログを利用することでエンドのクライアントのIPアドレスを特定することができます。   以下の例は、ユーザーが感染したウェブサイトにアクセスしようとしているところです。クライアント システムは、感染したウェブサイトのIPアドレスを取得するために、DNSクエリを内部DNSサーバーに送ります。そして、内部DNSサーバーは、そのDNSクエリを外部DNSサーバーに転送します。ファイアウォールは、外部DNSサーバーからDNSクエリを受け取ります。   ファイアウォールはDNSクエリを乗っ取り、内部DNSサーバーにDNSシンクホールのIPアドレスを渡します。内部DNSサーバーがクライアント システムに返答を転送することで、送信元としての内部DNSサーバーのIPアドレスを含む脅威ログを見ることができます。しかし以下のスクリーンショットのように、クライアントがDNSシンクホールのIPアドレスを使ってウェブサイトにアクセスしようとするため、Palo Alto Networksファイアウォールは、トラフィック ログにおいてクライアントのIPアドレスを見ることができます。   クライアントのTCP/IPプロパティの設定   脅威ログ 脅威ログでは、ファイアウォールは、送信元として "10.50.240.101" という内部DNSサーバーのIPアドレスだけを表示しています。なぜなら、クライアント システムが内部DNSサーバーのIPアドレスを使用しているからです。そのため、ファイアウォールはどのエンドのクライアントがウェブサイトにアクセスしようとしているのかを特定することができません。   トラフィック ログ しかし、クライアントがDNSサーバーからIPアドレスを取得するとすぐに、DNSシンクホールのIPアドレスに対してトラフィックを生成します。そのため、ファイアウォールは、以下に表示されているように、トラフィック ログの中でエンドのクライアントのIPアドレス "10.50.240.131" を表示することになります。   内部DNSサーバーを使用している時のクライアントの出力 上記のスクリーンショットは、ホスト マシン "10.50.240.131" が "sp-storage.spccint.com(疑わしいURL)" に対してDNSリクエストを実行していることを示しており、それが "1.1.1.1" であることを表示しています。このことから、DNSシンクホールが期待通りに動いていることが確認できます。   参照 How to Configure DNS Sinkhole Video Tutorial: How to Configure DNS Sinkhole     著者：sbabu

※この記事は以下の記事の日本語訳です。 Data Filtering Best Practices https://live.paloaltonetworks.com/t5/Configuration-Articles/Data-Filtering-Best-Practices/ta-p/58093     初期設定では、データ フィルタリングにはシグネチャが2つあります： クレジットカード：デバイスは16桁（訳注1）の番号を探し、ハッシュ アルゴリズムの検証を進めます。クレジットカードの番号として検出する前に、ハッシュ アルゴリズムに合致しなければなりません。この手法により、偽陽性（False Positive）を減らしています。 社会保障番号（訳注2）：形式に関わらず、あらゆる9桁の番号が社会保障番号として検出されます。こちらは偽陽性となる傾向があります。 どのようなドキュメントのタイプに対して、クレジットカードと社会保障番号を検知するかを定義することが重要です。この記事に添付している2つのPDFを使用して、ポリシーでの定義を検証することができます。1つはダミーの社会保障番号で、もう1つはダミーのクレジットカード番号です。   2種類のキーワードを見つけ、アラートを生成するプロファイルを設定します。さらなる条件として、10個の9桁の番号または10個のクレジットカードの番号、あるいは9桁の番号とクレジットカード番号が合計で10個の組み合わせを持つファイルを確認することとします。 カスタムのデータ パターンを設定します。 作成したデータ パターンをプロファイルを設定します。 作成したデータパターンをセキュリティ プロファイルに設定します。   カスタムのデータ パターンは以下の方法で設定します： カスタムのデータ パターンの重みを、10で設定します。 社会保障 (CC#) とクレジットカード (SSN#) には、1を設定します (以下のスクリーンショットをご覧ください)。 データ フィルタリング プロファイルを、アラートしきい値を10に設定します (以下のスクリーンショットをご覧ください)。 Data Filtering Profile このプロファイルをセキュリティ ルールに追加します。このルールは該当のデータ パターンを見つけると、上記で設定した条件でアラートを挙げます。この設定をすることで、いくつかの誤検出を防ぐことができます。   データ フィルタリング ログのモニタ ログの各エントリーに表示される緑色の矢印をクリックすることで、データ フィルタリングをトリガーしたパケットのキャプチャを見ることができます。 パケットキャプチャには保護すべき内容を含むため、データ保護を有効にしパケットキャプチャの閲覧にパスワードを保護をかけることができます。パスワードは[Device] > [セットアップ] > [コンテンツ ID] > [コンテンツ ID 機能] > [データ保護の管理]で設定します 。   注：このKB記事には2つのテストファイルを添付しており、ポリシーが動作しているかを確認に使用できます。 訳注1：一部のクレジットカード発行元によっては、13桁など16桁以外のクレジットカード番号への対応もあります。  訳注2：アメリカ合衆国において社会保障法に基づき市民・永住者・外国人就労者に対して発行される9桁の番号。   著者：wtam

※この記事は以下の記事の日本語訳です。 After Allowing ICMP, Ping is Still Denied https://live.paloaltonetworks.com/t5/Configuration-Articles/After-Allowing-ICMP-Ping-is-Still-Denied/ta-p/61589     症状 ICMPを許可するルールを作成した後でも、ホストへPingしようとすると拒否されてしまう。   問題 ICMP タイプ 8 メッセージ (ping) は独自のものであり、ICMPを利用する、よく使用される「アプリケーション」です。そのため、1つの別のアプリケーションとして定義されています。   解決方法 セキュリティ ルールを使用してPingを許可するためには、アプリケーションとして"ping"を選択します。ICMPを許可するだけでは、Pingを許可したことにはなりません。pingプリケーションはICMPへの依存性はなく、単独で正しく動作します。   注：TracerouteはPingを使用しているので、アプリケーションとしてPingを許可することは、Tracerouteも同様に許可することになります。       著者：gwesson

※この記事は以下の記事の日本語訳です。 Agentless User-ID Connection to Active Directory Servers Intermittently Connect and Disconnect https://live.paloaltonetworks.com/t5/Management-Articles/Agentless-User-ID-Connection-to-Active-Directory-Servers/ta-p/52041     問題 エージェントレスUser-IDで設定したActive Directoryのサーバーがファイアウォールとの接続を頻繁に切断します。これらのサーバーに対してユーザーマッピングのサーバー  モニタリングの接続状態は"connected"と"not connected"を繰り返します。User-IDのログは各々設定されたADサーバーに対して以下のエラーメッセージを記録します。 Error: pan_user_id_win_sess_query(pan_user_id_win.c:1241): session query for ＜ サーバー名＞   failed: [wmi/wmic.c:216:main()] ERROR: Retrieve result data.   以下のスクリーンショットが示すように、 "not connected"状態が[Device] > [ユーザー ID] > [ユーザー マッピング] > [サーバー モニタリング]で確認できます。   原因 エージェントレス User-IDはサーバー モニタリング リストのサーバーから、ユーザーのセッション情報をモニターします。ファイアウォールからADサーバーへのセッション 問い合わせはパーミッションの問題により失敗します。セッション情報へのアクセスに使用されるドメインアカウントが、ユーザーのセッション情報をサーバーから読み取る権限がないためです。Server Operators グループとDomain Adminsグループはセッションクエリを読む権限を持ちます。   以下の例が示すように [Device] > [ユーザー ID] > [ユーザー マッピング] > [Palo Alto Networks ユーザー ID エージェント設定]の[WMI 認証]にてユーザー名とパスワードの設定を行います。これはエージェントレス User IDがADサーバー（この例では172.30.30.15）接続するのに使用されます。   下記の例のとおり、ADサーバー（172.30.30.15）はユーザー cr7の権限を確認しています。   解決策 オプション1: Server OperatorsまたはDomain Adminsの権限をWMI認証に使うアカウントに付与します。この例では、cr7に Server Operatorsを付与しています。 Server Operators権限をcr7に付与した後、以下の例ではエージェントレス User-IDはADサーバーへの接続に成功しています。 オプション2： 必要でなければ、サーバーセッションを読み取るためのオプション）を無効にします（[セッションの有効化]のチェックを外す）。   訳注：オプション1で付与する権限は、最小限のものとなるよう検討してください。より安全なUser-ID 展開のため、下記の文書も合わせてご参照ください。   Best practices for securing User-ID deployments（原文） 安全な User-ID 展開のためのベスト プラクティス（上記文書の日本語訳）     著者: knarra

※この記事は以下の記事の日本語訳です。 How to Serve a URL Response Page Over an HTTPS Session Without SSL Decryption https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Serve-a-URL-Response-Page-Over-an-HTTPS-Session-Without/ta-p/55998   詳細 このドキュメントは SSL 複合化を実施せずに HTTPS セッション上で URL 応答ページを表示する方法 について記述しています。   必要条件 セキュリティ ポリシー内の URL フィルタリング プロファイル にて、対象のHTTPS サイトへのアクセスに対して "Block" アクションが設定されていること 応答ページを有効にする必要があります。V-wire インターフェイスで応答ページを表示するためには SSL 復号化が必要になるため、V-wireでは実行することができません Network > ネットワーク プロファイル > インターフェイス管理 応答ページを有効にしたインターフェイス管理プロファイルを作成します Network > インターフェイス > Ethernet?/? > 詳細 > 管理プロファイル a で作成した管理プロファイルを選択します 証明書は Palo Alto Networks デバイス上でフォワード プロキシ用の信頼された証明書として使用されます。それは次のいずれかとなります: "認証局" にチェックされた自己署名/自己生成した証明書 注: 自己署名/自己生成した証明書を使用している場合、ブラウザ上に表示される証明書エラーを回避するためにはクライアント PC の証明書ストアにこの証明書をインポートする必要があります。 組織内の内部CAによって生成された Palo Alto Networks デバイス用の中間CA証明書 "認証局" にチェックされた自己署名/自己生成したフォワードプロキシ用の信頼されない証明書。この証明書は受け取った全てのクライアントで信頼されません 注: BrightCloudのダイナミック URL フィルタリングを使用する場合、全てのURL フィルタリング プロファイル上でダイナミック URL フィルタリングを有効にした上、デバイス全体でも有効にしてください。デバイスのCLIで configure モードから次のコマンドを入力します: # set deviceconfig setting url dynamic-url yes 上記のコマンドはファイアウォール上で BrightCloud の URL フィルタリング ライセンスが有効な場合にのみ動作します。PAN-DB URL フィルタリングでは動作しません。   上記の要件が満たされた時点で、次のコンフィグレーション コマンドを実行するとPalo Alto Networks デバイスが HTTPS セッション上で URL フィルタリング レスポンス ページを表示できるようにします。このコマンドは BrightCloud か PAN-DB に関わらず動作します: # set deviceconfig setting ssl-decrypt url-proxy yes   クライアント PC では HTTPS セッション上で URL フィルタリング ポリシーによって指定された URL フィルタリング レスポンス ページが表示されます。   アクション タイプ "continue（続行）" と "override（オーバーライド）" に関する注意 今日のウェブサイトのサーバー コンテンツは複数の送信元から提供されているため、URL フィルタリング レスポンス ページのアクション タイプを "continue" または "override" で提供する場合、ページ上の一部のコンテンツが正しく表示されない可能性があります。アクションを "block（ブロック）" や "continue"、"override" に設定しているカテゴリのサイトからコンテンツが提供される場合に発生し、ファイアウォールはそれぞれの埋め込まれたリンクに対して "continue" や "override" のレスポンスページを表示しません。   注: 有効期限を更新するために証明書を置き換えた場合は、データプレーンの再起動かデバイスの再起動を実施します。 これによりデータプレーン上の有効期限切れ証明書のキャッシュが削除されます。  

※この記事は以下の記事の日本語訳です。 Vulnerability Profile Actions https://live.paloaltonetworks.com/t5/Management-Articles/Vulnerability-Profile-Actions/ta-p/61708     この資料では、脆弱性防御プロファイルで利用できる様々なアクションについて説明します。アクションはセキュリティ プロファイルの各ルールや、特定の脅威IDの例外に対して指定することができます。   アクションの種類（訳注） アクション 対象 アクションの詳細 Default （デフォルト） 重大度に基づいた定義済みのアクション ルール 脅威ごとに選択された定義済みのアクションが適用されます。 Allow （許可） セッションは許可するが、脅威ログに記録しない           ルール 　     脅威ログに記録しないように、イベント用の例外を作成することができます。 Alert セッションを許可し、脅威ログに記録する ルール 重大度に関係なく、すべての脅威に対してログが有効になります。 Block （ブロック） セッションのすべてのパケットを破棄する ルール パケットが破棄されます。TCPは再度パケットを転送しようとしますが、再度破棄される点にご注意ください。実質的に、セッションそのものが遮断されます。 reset-server RSTパケットをサーバーに送信する 例外 パケットは破棄され、TCPリセットがTCP コネクションのサーバー側に送信されます。 reset-both RSTパケットをクライアントとサーバーに送信する 例外 パケットは破棄され、TCPリセットがクライアントとサーバーの両方に送信されます。 reset-client RSTパケットをクライアントに送信する 例外 パケットは破棄され、TCPリセットがTCPコネクションのクライアント側に送られます。 drop-all-packets セッションのすべてのパケットを破棄する 例外 セッションに対してのすべてのパケットが破棄されます。 drop 特定のパケットを破棄する 例外 特定のパケットが破棄されます。TCPは再度パケットを転送しようとしますが、再度破棄される点にご注意ください。 実質的に、セッションそのものが遮断されます。 block-ip 送信元IPアドレスからのすべてのパケットを破棄する 例外 ある送信元IPアドレスから送られてきた、特定の期間のすべてのセッションが遮断されます。   *「セッション」という言葉は、プロトコルがUDPの時のファイアウォール テーブルへの参照という意味で使用されています。   * 脅威ログに記録されるアクションは、プロトコルよっては脅威シグネチャ毎の既定のアクションの定義とは異なる場合があります。例えば"drop"がセキュリティ プロファイルに設定されている場合、TCPセッションでは" drop-all-packets" 、UDPセッションでは"drop"がアクション欄に記録されます。   訳注：括弧内はWeb UIで言語の表記を日本語にした際の表記です。   著者：jjosephs

※この記事は以下の記事の日本語訳です。 Working with External Block List (EBL) Formats and Limitations https://live.paloaltonetworks.com/t5/Learning-Articles/Working-with-External-Block-List-EBL-Formats-and-Limitations/ta-p/58795   訳注：本文書で紹介するダイナミック ブロック リストはPAN-OS 5.0以降が対象です。   概要 PAN-OS 5.0 で導入された ダイナミック ブロック リスト（Objects > ダイナミック ブロック リスト） を使用すると、外部で作成された IP アドレスのリストをインポートしセキュリティ ポリシーの中でアドレス オブジェクトとして使用することが可能になります。このドキュメントでは、IP アドレス リスト用のテキスト ファイルを作成する際に考慮すべきフォーマートの規則を説明します。   詳細 EBL（外部ブロック リスト）の各行には IP アドレス、IP 範囲、もしくはサブネット（IPv6 サポート）が入力できます: 192.168.20.10/32 は 1 つの IP アドレスを意味します 192.168.20.0/24 はサブネットを意味します 192.168.20.40-192.168.20.50 IP 範囲を意味します 2001:db8:123:1::1 は 1 つの IP アドレスを意味します 2001:db8:123:1::/64 はサブネットを意味します 注: EBL の各行は改行文字 (LF) で終端します。Windows 形式 (CR-LF) はサポートされません。 EBL を使用した URL または FQDN の動的なブロックは現在されポートされていません。 ファイアウォール上のリストの最後の IP アドレスの最後のオクテットを参照するためには、テキスト ファイルの最後の IP アドレスの後に "リターン" が入力されている必要があります。 サービス ルートの設定では、EBL は 'Palo Alto Updates' の選択に分類されます。   役立つコマンド: CLI 上で EBL を表示します: > request system external-list show name <オブジェクト名>   CLI から EBL リフレッシュをリクエストします: > request system external-list refresh name <オブジェクト名>   EBL リフレッシュのステータスを表示します: > show jobs id <ジョブ ID>   追加情報: 次のエラー （各コマンドからのエラー）が CLI 上で確認される場合があります: > request system external-list show name <オブジェクト名> Server error : external list file not found.   または > show jobs id <値>  （<値> は EBL リフレッシュ ジョブ）は次のエラーを返す場合があります: Warnings: EBL(vsys1/test) Unable to fetch external list. Using old copy for refresh.   上記エラーは IP アドレス リストをホストする Web サーバーに問題がある可能性があることを示唆しています。しかし、多くの場合、リストは正常に取得されたが （GUI でテストすると "Source URL is accessible" となる）、Palo Alto Networks デバイスがそのリストを読むことができなかったことが考えられます。ソース アドレスが HTTP/HTTPS URL 上の .txt ファイルを指していることを確認してください。 例えば: https://www.example.com/blocklist.txt   HTTPS ロケーションを使用する場合は、PAN-OS 5.0.10 以上であることを確認してください。それより前のバージョンを稼動している場合、正常に動作していてもGUI の Test URL オプションがエラーを返す場合があります。 注: ファイアウォール上のリストを参照するためには DBL（ダイナミック ブロック リスト）がポリシーで使用されている必要があります。   同エラーは、セキュリティ ルールがダイナミック ブロック リストを使用して設定されていない場合や、対象 vsys が マルチ vsys システムに設定されていない場合にも現れる場合があります。 ダイナミック ブロック リストをセキュリティ ルールに適用するためには、次の例を参照してください: EBL オブジェクトを宛先として使用するルールに対しては、アクションは 'Allow' ではなく 'Block' を設定します。 対象 vsys を設定するためには: > set system setting target-vsys <vsys1>   EBL（非共有 EBL）を Panorama 上で作成する場合は、プレ ルールに適用しマルチ vsys（仮想システム） の管理デバイスにプッシュします。   注 1: 'Palo Alto Updates' サービス ルートは EBL にも影響を及ぼします。   注 2: PAN-OS 6.1 より前では、コメントのある行はセキュリティ ポリシーに適用されると削除されます。6.1 以降では、コメントのある行は適切に適用されます。   例: #test dbl 1.2.3.4 10.10.10.10 10.11.12.13 testingcommentsread here 10.12.12.14 #testingcommentsread here   > show running security-policy TestDBL { from trust-L3; source any; source-region none; to untrust-L3; destination [ 1.2.3.4 10.10.10.10 ]; destination-region none; user any; category any; application/service any/any/any/any; action allow; terminal yes; }   注: EBL をリフレッシュした際に他のエラーが表示される場合、management server debug を有効にし ms.log を追跡することができます。EBL リストのフォーマットに問題がある場合は、ms.log に明確に記されます。ms.log ファイルの記録例を次に示します:   Feb 15 12:43:21 EBL entry(0xf30a77f0, 0xe0b6ac60, 0xe210b998 vsys1/test, 1, 0) Refresh job cancelled Feb 15 12:43:21 EBL entry(0xf30a77f0, 0xe0b6ac60, 0xe210b998 vsys1/test, 1, 0) EBL Refresh job success Feb 15 12:43:21 EBL ALLOC free timer (0xdbfbecb0, 1356) Feb 15 12:43:21 EBL entry(0xf30a77f0, 0xe0b6ac60, 0xe210b998 vsys1/test, 1, 0) Releasing ebl Feb 15 12:43:21 EBL ALLOC free size(0xe0b6ac60 1196)   外部ブロック リストと各リスト内のアドレス エントリーの最大数:   各プラットフォームは最大 10 個の外部ブロック リストを持つことができます。 各リストにはファイアウォールのモデルがサポートする最大アドレス数 から300少ないアドレス を含めることができます。 各 EBL は 1 アドレス オブジェクトとして数えられ、max-address のプラットフォームの最大数には影響を与えません。すなわち、デバイスの最大アドレス数が 5000 の場合、それぞれ 4700 アドレスのサイズの EBL を 10 個持つことができ、その他に 4990 個のアドレス オブジェクトを持つことができます。   ご使用のシステムの最大アドレス数を確認するためには、CLI より次のコマンドを入力してください:   PA-200 上ではコマンドと出力はこのように見えるはずです: > show system state | match cfg.general.max-address cfg.general.max-address: 2500   こちらはハードウェアと最大アドレス エントリーを示すグラフです: ハードウェア 最大アドレス エントリー PA-200 PA-500 2500 PA-3020 5000 PA-3050 PA-3060 PA-5020 10000 PA-5050 40000 PA-5060 PA-7050 80000     PA-200 で PAN-OS 7.0.x を稼動している場合は、以下の最大数をもつことができます: 最大 10 個の外部ブロック リスト 全ての外部リスト合わせて最大 50000 個の IP (50000 個の IP をもつ 1 つのリスト、または、5000 個の IP をもつ 10 個のリストは両方ともサポートされます) 1 つのデバイスで 10 個以上の EBL を使用した場合、コミット中に次のエラーが表示されます:       Exceeding max number of supported external block lists (10)   注: 共有 EBL オブジェクトを Panorama から マルチ vsys が有効化されたデバイスにプッシュする場合は、各 EBL が vsys ごとに 1 カウントされる問題に遭遇する可能性があります。この問題はアーキテクチャの変更により PAN-OS 7.1 で解決しています。   エントリ数がキャパシティの総数を超えた場合は、次のエラーがシステム ログに表示されます:       EBL(<EBL 名>) Exceeding max number of ips at line XXXX     著者: jdelio 

※この記事は以下の記事の日本語訳です。 How to Deal with Conficker using DNS Sinkhole https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Deal-with-Conficker-using-DNS-Sinkhole/ta-p/52920     訳注：本文書で紹介するDNSのシンクホール機能はPAN-OS 6.0から対応しています。   概要 Confickerは2008年11月に初めて見つかり、Windowsを実行しているコンピューターに最も広く感染したワームの１つです。 Palo Alto Networksは、Confickerワームを見つけ、遮断することができるシグネチャ群を作成しました。それらの中でもConfickerの亜種によって使用されるDNSドメインを見つけることのできるアンチ ウィルス／アンチ スパイウェアのシグネチャがあります。 このドメインは、Confickerの亜種が見つかるとすぐに更新されます。WildFireライセンスが使用されている場合、新しく見つかったドメインは、WildFireシグネチャをとおして、1時間ごとにPalo Alto Networksファイアウォールに展開されます。ライセンスを使用していない場合、シグネチャは24時間ごとに展開され、すべてのPalo Alto Networksデバイスに対して、ダイナミック アップデートによってダウンロードされます。次回の更新時に、新しいAVシグネチャに対してもアップデートが実施されます。この保護は、ネットワーク内のユーザーが「悪意ある」ドメインを要求している時に機能します。ログの分析を行うことで、感染したドメインに対する要求が、ローカルのDNSサーバーから来ていることを確認することができます。これは、DNSの階層構造により発生します。   詳細 すべてのPalo Alto Networksプラットフォームは、有害なドメインに対するクエリに対して、シンクホール機能を実装しています。この機能を使用して、Palo Alto Networksファイアウォールは、ネットワーク内の感染したホストを見つけることができ、セキュリティの管理者に通知を行うことができます。これにより、そのネットワークから感染した端末を隔離することができます。   一連の動作： 感染したコンピューターは、ローカルのDNSサーバーから、感染したドメインの名前解決を依頼します。 ローカルのDNSサーバーは、公開されているDNSサーバーにクエリを送ります。 Palo Alto Networksデバイスは、最新のシグネチャを使用して、そのクエリー内容から有害なドメインを見つけます。 管理者が設定したIPアドレス (シンクホール アドレス) を付与してDNS要求に対する回答を上書きし、クライアントに対して改変された回答を送ります。 クライアントは、シンクホールのIPアドレスに接続しようとします。 Palo Alto Networksは、そのトラフィックを遮断し、その試みをログに記録します。 ファイアウォールの管理者は、そのイベントの通知を受け取ります。 有害なクライアントは、ネットワークから隔離、除去されます。   手順 DNSシンクホール機能を設定するために、こちらをご覧ください： How to Configure DNS Sinkholing on PAN-OS 6.0 L3インターフェイスが、シンクホール インターフェイスとして設定されているPalo Alto Networksデバイスを使用して(ループバック インターフェイスを使用することもできます) 、以下の手順を行います： 仮想 ルーターとセキュリティ ゾーンに、以下の例のようにインターフェイスを追加します。このゾーンは、ユーザーが接続を開始するものとは異なります。有害なコンピューターはトラフィックを送り出すかは定かではありませんが、ベストプラクティスとしてはこのインターフェイスに対して新しいシンクホール ゾーンを作成します。 新しい"sinkhole"ゾーンの作成にし、作成したループバック インターフェイスを"loopback.222"を追加します。 現在使用されておらず、管理者に対して分かりやすいIPアドレスをインターフェイスに割り当てます。 社内でIPv6が使用されている場合、インターフェイスにIPv6アドレスも割り当てます。 [ Objects ] > [ セキュリティ プロファイル ] > [ アンチ スパイウェア ] を開き、インターネット ユーザーに割り当てられるプロファイルを選択（あるいは作成）します。 DNS シグネチャ タブ内で、DNSクエリ時のアクションとして"シンクホール"を選択します。"ブロック"を選択した場合、有害なドメインに対してのクエリを遮断し、ログにはローカルのDNSのみが"attacker"として表示されます。先ほど作成したシンクホールIPアドレス (222.222.222.222) を選択します。 IPv6のDNSクエリ用には、IPv6のIPアドレスを選択します。 「パケット キャプチャ」欄で、シグネチャをトリガーにしたパケットだけではなく、より多くのパケットをキャプチャするために、"extended-capture"を選択します。この値は、[ Device ] > [ セットアップ ] > [ コンテンツ ID ] > [ コンテンツ ID 設定 ] で定義されています。 アンチ スパイウェア プロファイルをセキュリティ ルールに適用し、「セッション終了時にログ」を有効にします。 コミットをクリックして、設定を反映させます。   検証 設定の反映が完了した後、トラフィックがキャプチャされることを確認し、有害なコンピューターを特定します。 ファイアウォールの背後にある検証機を使用します。 Confickerドメインの１つに対して、DNSトラフィックを開始します（この検証では"fetyeq.net"を使用します）。 注：他のConfickerドメインを確認するためには、Palo Alto Networksデバイス上にインストールされているダイナミック アップデートのアンチウィルス リリース ノートを開きます。Palo Alto Networksは、これらのドメインを定期的に更新しており、アンチウィルス シグネチャのリリース ノート内で確認することができます。 [ Device ] > [ ダイナミック更新 ] > [ アンチ ウィルス ] > [ リリース ノート ] を開き、"conficker"を検索すると、約1,000件のドメインを見ることができます。 脅威ログにて、アクションが"sinkhole"となっているログを確認します。 必要に応じて、パケット キャプチャを確認します。 クエリ ビルダーにて、フィルタとして"( action eq sinkhole)" を使用してカスタム レポートを作成します。毎日実行するために、スケジュール設定にチェックを入れます。 翌日、データが収集、表示されていることを確認するために、レポートを確認します。 上記の手順に従うことで、特定のネットワーク内の有害なコンピューターを追跡したり、隔離することができます。     著者：ialeksov

※この記事は以下の記事の日本語訳です。 How to Configure GlobalProtect Portal Page to be Accessed on any Port https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-GlobalProtect-Portal-Page-to-be-Accessed-on-any/ta-p/53460   訳注：GlobalProtectの設定画面はPAN-OS Versionにより大幅に異なります。ご使用になるPAN-OSバージョンのWebインターフェイス リファレンス ガイドを合わせてご参照ください。   GlobalProtectが使用するポートを変更することはできませんが、ループバック IPアドレスとセキュリティ ルールによって他のポートを使うことができます。   設定方法： ループバック Interfaceを作成します。 Untrustのインターフェイスが、ループバックにpingできることを確認しておきます。 ポータルのアドレスとゲートウェイのアドレスに、ループバックアドレスを設定します。 GlobalProtectポータルにて、[クライアントの設定]タブよりクライアントの設定を作成し、[外部 ゲートウェイ]を設定します (例：10.30.6.56:7000) 。 ポート番号7000を使用する10.30.6.56 （Untrustのインターフェイス）が、ポート番号443を使用する10.10.10.1 (ループバック) に変換される宛先NATルールを作成します。 Untrustのインターフェイスを宛先アドレスとし、ポート番号7000と443をサービスとしてセキュリティ ポリシーを作成します。 この設定を行うことで、https://10.30.6.56:7000 でGlobalProtectポータルにアクセスできるようになります。https://10.30.6.56:7000  は https://10.10.10.1  が変換されたものです。 GlobalProtectクライアント ソフトウェアをダウンロードして、インストールします。 [ユーザー名]と[パスワード]で資格情報を使用します。[ポータル]欄では、以下の図のように10.30.6.56:7000 をIPアドレスとして使用します。                             著者：mvenkatesan

※この記事は以下の記事の日本語訳です。 How to Configure a Policy with DoS Protection to Protect Hosted Services https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Configure-a-Policy-with-DoS-Protection-to-Protect-Hosted/ta-p/56507   概要 この環境では、Paloalto Networks ファイアーウォールはサービスをホストするように設定されています。この例では、ファイアーウォールは Trust ネットワークにある Web サーバーに対して Destination NAT が設定されているとします。この場合、DoS 攻撃に対しての防御ポリシーが必要になります。   手順 カスタム DoS プロテクション プロファイルを作成します。 Objects > DoS プロテクションに移動します。 「追加」をクリックします。 DoS プロテクション プロファイルを設定します。(以下の例を参照してください)   手順1.で作成した DoS プロテクション プロファイルを使った DoS プロテクション ポリシーを作成します。 Policies > DoS プロテクションに移動します。 「追加」をクリックして、新しい DoS ルール ダイアログを表示させます。 上記で作成した DoS プロテクション プロファイルを適用します。 アクションを「Protect」に設定します。デフォルトのアクションは「Deny」となっているため、このフローにマッチしたトラフィックは全て拒否されます。       注：この例では、閾値に検証環境の設定を反映させています。運用環境に適用する場合は、そのネットワークにおいて想定されるトラフィックに応じて値を設定してください。   著者: sberti