ナレッジドキュメント

※この記事は以下の記事の日本語訳です。 Troubleshooting Captive Portal Redirect Page Issues https://live.paloaltonetworks.com/t5/Management-Articles/Troubleshooting-Captive-Portal-Redirect-Page-Issues/ta-p/55360     キャプティブ ポータルが構築されていても、ブラウザで開くとリダイレクト ページが返ってこないことがあります。この問題が起きるのには様々な理由が考えられます。 この問題をトラブルシュートするためには、以下の項目を確認します: キャプティブ ポータル は、まだ特定されていない送信元のIPアドレスによってのみトリガーされます。 該当の送信元IPアドレスが、ユーザー名に紐付けられているかどうかを確認します。確認するためには、次のコマンドを実行します: > show user ip-user-mapping all Device > ユーザー ID >  キャプティブ ポータルの設定  に移動し、 キャプティブ ポータル が有効になっていることを確認します。 Network > ゾーン にて該当のゾーン名をクリックし、"ユーザー ID の有効化" が該当トラフィックの送信元ゾーンで有効になっていることを確認します。 リダイレクト ホスト用に設定されているホスト名、またはIPアドレスが、 キャプティブ ポータル を使うシステムから接続できることを確認します。ホスト名を使用している場合は、DNSの名前解決ができることを確認します。Telnet を使用し、ポート番号6082番でそのホスト名/IPアドレスに接続できることを確認します。接続エラーのない何も表示されていない画面が表示されていることを確認します。 Network > インターフェイス管理 に移動し、リダイレクト ホスト用に使われているインターフェースにおいて、"応答ページ" が有効になっている管理インターフェイス プロファイルが使われていることを確認します。 インターフェース管理プロファイルは以下の箇所で設定します。 "Network > インターフェイス > Ethernet > 管理プロファイル" キャプティブ ポータル のポリシーが、正しいサービスでトリガーされる設定になっていることを確認します。下記図は、"http"と"https"の両方の接続用に キャプティブ ポータル が設定されているところです: 注:"https"用に キャプティブ ポータル をトリガーするためには、SSL復号化の設定がされている必要があります。     著者:jteetsel
記事全体を表示
hshirai ‎07-15-2016 12:13 AM
4,853件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Display the Log Filter Expressions https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Display-the-Log-Filter-Expressions/ta-p/54161   概要 ログで利用可能なフィルタ式は、 [Monitor] タブの下の適切なログのフィルタ式ボタンを選択することで表示することができます。   詳細 Attirubute 配下のさまざまな操作オプションで作成されるログ フィルタが変更されます:   次の例では、"google" という単語を含むURLログをフィルタします:   次の例では 10.10.10.0 - 10.10.10.255 の範囲の IP アドレスを検索します:   "or" コネクターを使用して、複数の送信元アドレスを検索します。例えば:   著者: panagent
記事全体を表示
dyamada ‎07-13-2016 05:29 AM
7,406件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Generate a New Self-Signed SSL Certificate https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Generate-a-New-Self-Signed-SSL-Certificate/ta-p/53215   概要 デバイスに独自の証明書をロードしたくない場合やデフォルトの自己署名証明書を使用したくない場合は、新しい自己署名証明書を Web インタフェースまたは CLI を使用して生成することができます。 この新しい自己署名証明書は、SSL 復号化または GlobalProtect ポータルまたはゲートウェイ証明書に使用することができます。     手順 1. WebGUI から [デバイス]> [証明書]に移動します。 2. 画面の一番下の Genarate をクリックします。 3. 証明書の目的の詳細を入力します。ここで入力した詳細は、ブラウザを使用して暗号化されたセッションの CA 証明書を表示する場合ユーザーが見るものとなります。 注: 365日(1年)より長い有効期限を持つ証明書を作成したい場合は、証明書を作成する前に Expiration (days) を 365 より大きい値に変更してください。   4. Generate Certificate ウインドウで Generate をクリックします:   5. 証明書が正しく作成されたことを確認するために、新たに生成された証明書をクリックしてください。 注: SSL 復号化のためにこの証明書を使用している場合は、 "Forward Trust Certificate" と "Forward Untrust Certificate" にチェックを入れます。証明書を削除する場合、両方のオプションのチェックを外さないとエラーが生成されます。   6. 変更をコミットします。コミット処理が完了すると、自己署名 CA 証明書はインストールされます。   CLI CLIでは、新しい自己署名証明書を作成するには次のコマンドを <すべて1行として> 実行します。( 5.0 から 6.1 )   > request certificate self-signed country-code US email support @ paloaltonetworks.com locality Alviso state CA organization “Palo Alto Networks” organization-unit “Session inspected by policy” nbits 1024 name “SSL Inspection” passphrase bubba for-use-by ssl-decryption   6.0 の CLI コマンドに関する追加情報は、以下記事を参照してください: Command Line Interface ( CLI ) Reference Guide Release 6.0   7.0 の場合、非常にシンプルな自己署名証明書を以下のコマンドで作成することができます:   > request certificate generate name "Firewall-a" certificate-name "ssl test"   CLI 行で次に使えるコマンドを確認するために、常時 <tab> または "?" を使用することができます。   7.0 におけるCLIおよび管理情報の追加情報ついては、こちらの記事を参照してください: Palo Alto Networks Documentation for PAN-OS 7.0   owner: jebel  
記事全体を表示
dyamada ‎07-13-2016 05:05 AM
5,877件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Create an Application Filter to Block High-Risk Applications https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Create-an-Application-Filter-to-Block-High-Risk/ta-p/62794       概要 本ドキュメントでは、 peer-to-peer テクノロジーを利用したhigh-risk (5) file-sharing applicationsをブロックするためのセキュリティポリシーの作成方法を説明しています。   手順 Policies タブからSecurityを選択し、セキュリティ ポリシーの追加を行います。 General, Source,User,Destination タブの必要情報を入力します。その後、Applicationタブを選択します。 Addを選択し、 ドロップダウン リストの一番下までスクロールさせ、Application Filterを選択します。 作成するApplication Filterに対し、名前をつけます。 peer-to-peer technologyベースのhigh-risk (5) file-sharing applicationsに対して制御を行いたいため、以下の流れで指定します。 Category カラムの下にある、 highlight general-internetをクリックします。 Subcategoryの下にあるfile-sharingを選択します。 技術的な部分では、peer-to-peer Risk が 5 OKをクリックし、保存します。Application Filterがルール上に表示されます。 Security Policyの設定の残りを入力します。 Service/Urlカテゴリは、Anyを選択し、ActionについてはDenyを選択することが推奨となります。   これまでの手順を実施することで、ファイアウォールを経由するトラフィックは、application filterによりカテゴライズされます。   注: アプリケーション フィルターは、動的なものです。ビルト イン カテゴリ が選択された場合は、グループがルール内で利用できるようになります。この結果、選択されたカテゴリに該当するものはすべてグループに含まれる結果となります。 アプリケーションはリカテゴライズされたり、 もしくは、新しいアプリケーションがそのカテゴリに追加されるため、 そういったアプリケーションは、アプリケーションフィルターから動的に追加されたり、削除されたりすることになります。この動作により問題が発生する可能性があります。なぜなら、リカテゴライズにより、過去許可していたアプリケーションが突然ブロックされたり、過去ブロックしていたアプリケーションが突然許可されることが発生するからです。アプリケーション グループを使用していたケースでも、アプリケーションは、サービス グループやアドレス グループと同様に分類されます。ブロック、許可を行う対象のアプリケーションが追加されるたび、使用しているアプリケーション グループに手動で追加していく必要が見込まれます。   参考情報 セキュリティ ポリシー内で、効果的にHigh-Risk Appを活用したい場合、アプリケーションの依存関係について深い理解を得る必要があります。こちらのドキュメントをご参照ください。 How to Check if an Application Needs to have Explicitly Allowed Dependency Apps  (英文)   著者: sodhegba    
記事全体を表示
kkawachi ‎07-12-2016 01:01 AM
3,881件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Identify Root Cause for SSL Decryption Failure Issues https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Identify-Root-Cause-for-SSL-Decryption-Failure-Issues/ta-p/59445   概要 この文章では、サポートされていない暗号スイートによって、復号化されず失敗する場合において、原因を特定する方法について述べています。   Palo Alto Networks ファイアウォールによって、サポートする暗号スイートは以下です: TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES128_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA   問題 この例では、サーバーがDiffie-Hellman (DH)とElliptec Curve Ephemeral Diffie-Hellman (ECDHE)しかサポートせず、SSLプロキシが復号化に失敗しています。 以下のステップによって問題を確認します。   Palo Alto Networks ファイアウォールにてパケットキャプチャーを取得します(How to Run a Packet Captureを参照)。クライアントから送付されたClient Helloパケットとサーバーから応答されたパケットを調査します。 下記に示すような"Handshake Failure"を探します。 クライアントでサポートされている暗号スイートを参照するか、パロアルトネットワークス装置のClient Helloパケットを確認します。 SSLスキャンツール https://www.ssllabs.com/ssltest/index.html を使って、サーバーによってサポートされる暗号スイートを調べます。下記出力例を参照: 上記の出力結果によって、サポートされていない暗号スイートによって発生していたことが確認できます。   解決方法 No Decryptポリシーを作成します 該当サイトのCustom URL Categoryを作成します Objects > URL Categoryに移動します Addボタンをクリックします Custom URL Categoryの名前を設定します Addボタンを追加し、サーバーサイトを追加して、Commitを実行します 追加したURLサイト用のNo Decryptアクションの復号化ルールを作成します Policies > Decryptionに移動します Decryption Ruleを選択します Decryption Ruleをクローニングします クローンしたDecryption Policyを復号化するDecryption Policyの上に移動します クローンしたDecryption Policy > URL Categoryを選択します Addボタンをクリックします 設定したURL siteを追加し、コミットします   著者: ssastera
記事全体を表示
kkondo ‎07-12-2016 12:10 AM
6,368件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Block A Threat For a Specific Time Interval https://live.paloaltonetworks.com/t5/Threat-Articles/How-to-Block-A-Threat-For-a-Specific-Time-Interval/ta-p/58181     概要 本文書では、脅威を検知した際に、予め設定した一定時間その脅威をブロックする方法について説明します。   詳細 この制御は、アンチスパイウェアと脆弱性防御の両方において設定が可能です。   アンチスパイウェア Objects > セキュリティ プロファイル > アンチスパイウェア へ移動し、「追加」をクリックします。 アンチスパイウェア プロファイル > 例外 > 名前 の欄で、名前を入力します。 「すべてのシグネチャの表示」にチェックを入れ、該当の脅威 IDを入力し、「アクション」をクリックします。 「block-ip」を選択すると、時間を設定する項目が表示されます。時間は1秒から3600秒の間で設定が可能です。「追跡」では「IPソース」または「IPソース及び宛先」のどちらかを選択してください。 設定変更後のアクションは以下のように表示されます。 実際に攻撃が検知されるとセキュリティ ポリシーに割り当てた本プロファイルが適用されます。ソースIPと宛先IPアドレスがトラックされ、3600秒の間ブロックされ続けます。   脆弱性防御 Objects > セキュリティ プロファイル > 脆弱性防御 へ移動し「追加」をクリックします。 名前を設定し、「例外」タブへ移動します。 「すべてのシグネチャの表示」にチェックを入れ、該当の脅威 IDを入力します。 「block-ip」を選択すると、時間を設定する項目が表示されます。時間は1秒から3600秒の間で設定が可能です。「追跡」では「IPソース」または「IPソース及び宛先」のどちらかを選択してください。 設定変更後のアクションは以下のように表示されます。 実際に攻撃が検知されるとセキュリティ ポリシーに割り当てた本プロファイルが適用されます。ソースIPと宛先IPアドレスがトラックされ、3600秒の間ブロックされ続けます。   著者: dantony
記事全体を表示
ymiyashita ‎07-10-2016 10:46 PM
3,964件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Site-to-Site IPSec VPN Between Palo Alto Networks Firewall and Cisco Router using VTI Not Passing Traffic https://live.paloaltonetworks.com/t5/Configuration-Articles/Site-to-Site-IPSec-VPN-Between-Palo-Alto-Networks-Firewall-and/ta-p/62103   問題 パロアルトネットワークス ファイアウォールとCiscoルーターで仮想トンネル インターフェイス(VTI)を使用してサイト間VPNが設定されているとします。しかしIKEフェーズ2通信がパロアルトネットワークス ファイアウォールと Ciscoルーターで通りません。 まとめると、以下の状況でVPNはダウンしています。 トンネル インターフェイスがダウンしている。 IKEフェーズ1はアップしているが、IKEフェーズ2がダウンしている。   原因 PFSの不一致によりIKEフェーズ2が不一致となり、この問題が発生している可能性があります。   解決策 パロアルトネットワークス ファイアウォールとCiscoルーターが同じPFSの設定を持つように設定します。   パロアルトネットワークス ファイアウォール上では、[Network] >[IPSec 暗号]に移動します。トンネルに設定している[IPSec暗号プロファイル]を選び、DH グループの値がCiscoルーターと一致するか確認します。   Ciscoルーターではパロアルトネットワークス ファイアウォールと一致するようPFSを設定します。   以下はパロアルトネットワークス ファイアウォールのCLIで tail follow yes ikemgr.log コマンド を実行したときの出力です。 最初の赤線で囲った部分はPFSの不一致のメッセージとなります。二番目の赤線で囲った部分はPFSの不一致を修正したあとのメッセージとなります。   パロアルトネットワークス ファイアウォール上で show vpn flow tunnel-id <ID番号>  を実行すると、暗号化、復号化のパケットのカウントが増えていることを確認できます。   Ciscoルーターでは、 show crypto ipsec sa  と入力すると、暗号化、復号化のパケットが増加していることを確認できます。   著者:jlunario  
記事全体を表示
TShimizu ‎07-10-2016 10:44 PM
4,025件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Change the Brute Force Trigger Criteria https://live.paloaltonetworks.com/t5/Threat-Articles/Change-the-Brute-Force-Trigger-Criteria/ta-p/62405     概要 本文書では、 Palo Alto Networksファイアウォールを通過する brute force攻撃を検知するためのシグネチャのデフォルト設定の見方と変更方法について説明します。   手順 Objects > セキュリティ プロファイル > 脆弱性防御 へ移動し、脆弱性 防御プロファイルを開きます。 「例外」タブを開きます。 必要に応じて「すべてのシグネチャの表示」をクリックします。 検索ボックスにて、"brute force" と入力するか、脅威ID を入力します。 カスタマイズするには、シグネチャ名の横にある鉛筆アイコンをクリックします。 必要に応じて、時間属性の編集を行います。集約基準は、Source、Destination、Source-and-Destinationのいずれかを選択してください。 変更が完了したら、「有効化」チェックボックスにチェックを入れ有効にします。 変更をコミットします。    参考 brute force 関連の脆弱性リストは以下の文書を参照してください。 Trigger Conditions for Brute Force Signatures (英文)   著者: sdarapuneni  
記事全体を表示
ymiyashita ‎07-10-2016 10:22 PM
2,947件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Where to Get a Suspicious DNS Query for Testing DNS Sinkhole https://live.paloaltonetworks.com/t5/Threat-Articles/Where-to-Get-a-Suspicious-DNS-Query-for-Testing-DNS-Sinkhole/ta-p/66048     テストをするには、まず2番目に古いアンチウイルス パッケージをダウンロード & インストールします。そして最新版のアンチウイルス パッケージのリリースノートを参照し、Suspicious DNS Queryをどれか一つ選びます。   例えば、アンチウイルス パッケージ  1594-2071  をダウンロード&インストールし、アンチウイルス パッケージ  1595-2072  のリリースノートを確認します。 1595-2072  のリリースノートの中で  'Suspicious DNS Query' を検索すると、以下のような結果が得られます。   Suspicious DNS Query (generic:akrqbqpgs 1 variants: net) クライアント端末のコマンドラインで、以下のコマンドを実行するとDNSシンクホールのアドレスが得られます。 nslookup akrqbqpgs.net     著者: pankaj.kumar
記事全体を表示
ymiyashita ‎07-10-2016 10:13 PM
2,470件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 SSL Vulnerability Non-Detection Behavior is Seen when Inbound SSL Decryption Policy is Set https://live.paloaltonetworks.com/t5/Threat-Articles/SSL-Vulnerability-Non-Detection-Behavior-is-Seen-when-Inbound/ta-p/52014     問題 インバウンドSSL復号化ポリシーが設定されている場合(シングルVSYS、マルチVSYSに関わらず)、SSLに関連した脆弱性の検知に失敗します。   原因 インバウンドSSL復号化ポリシーによって復号化が行われると、脅威エンジンは復号化された後のデータのみを検査することとなります。そのためSSLのハンドシェイクのhelloパケットに含まれているSSLのバージョン番号 (SSL3.0)のチェックがされなくなり、 SSL v3の脆弱性が検知されなくなります。   詳細 以下に挙げた脆弱性は、本シナリオに当てはまります。 SSL v3 due to the Poodle SSL vulnerability (CVE-2014-3566) https://threatvault.paloaltonetworks.com (Threat ID 36815) https://live.paloaltonetworks.com/t5/Threat-Articles/SSL-3-0-MITM-Attack-CVE-2014-3566-PAN-SA-2014-0005-aka-Poodle/ta-p/61856 Poodle Bites TLS (CVS-2014-8730) https://threatvault.paloaltonetworks.com (Threat ID 37144) https://blog.qualys.com/ssllabs/2014/12/08/poodle-bites-tls   回避策 以下の手順にて、 インバウンドSSL復号化ポリシーを無効にします。 WebGUIにて、Policies > 復号 へ移動します。 無効にする “Inbound SSL Decryption Policy” を選択します。 「無効化」のボタンを押します。 コミットします。   著者: khogi
記事全体を表示
ymiyashita ‎07-10-2016 06:57 PM
1,979件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Block Traffic Based Upon Countries https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Block-Traffic-Based-Upon-Countries/ta-p/52217   詳細 Palo Alto Networks ファイアウォールでは、宛先あるいは送信元となる国全体のトラフィックをブロックすることが可能です。この機能は、PAN-OS が内部データベースからグローバル IP アドレスと地域のマッピングを取得することによって動作しています。この情報は毎週実行される content アップデートによって更新され、ファイアウォールはそのデータベースを維持しています。   手順 Policies > セキュリティ > 追加をクリック > 送信元、宛先フィールドを選択 > 追加をクリックします。 アドレス、アドレスグループ、及び地域の3つの選択オプションがあります。 以下のように、「地域」を選択します。 すべての国と、対応する地域コードが以下のとおり確認できます。 ブロックする国を選択します。ここでは China (CN )を例にしています。 ユーザーは「追加」をクリックして、国の中から特定のパブリック IP アドレスを指定することが出来ます。その国は以下のように宛先に追加されます。 最終的にセキュリティ ポリシーは以下のように表示されます。このコンフィグレーションでは、ポリシーで設定された国に基づいて、その国が送信元、あるいは宛先となるトラフィックすべてがブロックされます。 Object > 地域をクリックし、以下のように地域のオブジェクトを作成することも可能です。 新しい地域は、トラフィックと脅威マップの作成にも利用される「Geo Location」を指定して作成することも出来ます。これはその地域の正確な座標を指定することによって可能です。 注:EU のような幾つかの地域は、すべての EU の国が含まれていないことがあります。これらの国は、地域と一緒に追加する必要があります。   参照 Region Object Not Working in Security Policy     著者: dantony
記事全体を表示
hfukasawa ‎07-09-2016 10:07 PM
4,018件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Troubleshooting User-ID: Group and User-to-IP Mapping https://live.paloaltonetworks.com/t5/Management-Articles/Troubleshooting-User-ID-Group-and-User-to-IP-Mapping/ta-p/59072   概要 グループマッピング、及びユーザとIPとのマッピングは User-ID の2つの重要な機能です。グループマッピングはグループ情報とそこに含まれるユーザ情報を関連付け、ユーザ-IP マッピングは IP アドレスとユーザを関連付けます。 添付のドキュメントは、グループマッピングやユーザ-IP マッピング周りで起きる共通の User-ID 設定に関する問題の トラブルシューティング方法を説明しています。このドキュメントは以下のような問題をカバーしています。 AD/LDAP からグループマッピングを取得できない User-ID Agent からユーザと IP のマッピングが取得できない キャプティブ ポータルからユーザと IP のマッピングが取得されない IP マッピングが生成されているが、すぐ消えてしまう User-ID Agent あるいはエージェントレスの User-ID で、いくつかのユーザのIPマッピングが間違っている トラフィックログにユーザ情報が表示されない トラフィックが異常に増加する   ドキュメントの最後で、User-ID に関する共通の CLI コマンドを説明しています。また、このドキュメントにて Palo Alto Networks の役に立つサポート ナレッジベースのリンクも提供されています。 Troubleshooting_User-ID_revA.pdf   著者:sjamaluddin, jteetsel
記事全体を表示
hfukasawa ‎07-09-2016 12:29 AM
4,431件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Blocking Suspicious DNS Queries with DNS Proxy Enabled https://live.paloaltonetworks.com/t5/Management-Articles/Blocking-Suspicious-DNS-Queries-with-DNS-Proxy-Enabled/ta-p/66037   問題   パロアルトネットワークス ファイアウォール上にて、DNSプロキシを有効にした状態でアンチスパイウェアを有効にすると、設定が適切でないと、DNS要求がネットワーク全域で止められてしまう状況に陥ることがあります。これはパロアルトネットワークスの機器によるDNSリクエストと、疑わしいDNSクエリのブロック(アンチスパイウェアにより有効化)の取り扱いの仕方により発生します。 この文書はその発生の理由と解消方法について記載します。   原因 この問題は、パロアルトネットワークス ファイアウォールが外部DNSサーバー向けのセッションのみブロックしようとすることにより発生します。疑わしいDNSクエリを止めるためにアンチスパイウェア プロファイル(デフォルトの'strict'プロファイルも該当)を設定すると、ファイアウォールは悪意あるとみられるDNSのセッションをDISCARD(破棄)状態とします。これは該当するデバイスからのすべてのDNSトラフィックを、その悪意あるとみられるDNSのセッション開始からセッション タイムアウトまたはマニュアルでセッションをクリアするまで、ブロックし続けることを意味します。ユーザーが信頼された(内部)ゾーンから信頼されない(外部)ゾーンへのDNSクエリをブロックするアンチスパイウェア プロファイル設定を適用すると、望ましいDNSクエリもブロックされます(Diagram 1.0参照)。以下の図は前述のようなセキュリティ ポリシーが設定されている場合のパケット フローを説明するものです (Diagram 1.1参照) 。これは疑わしいDNSクエリが検知されると、望ましいものがあったとしても、すべてのパロアルトネットワークス ファイアウォールからDNSサーバーへのDNSクエリが拒否される原因となります。       解決策 以下に図示する2つのポリシーを設定してください。 (Diagram 2.0参照)。  最初のポリシーはユーザのファイアウォールからインターネットへのDNSクエリを許可するものです。これはネットワーク全域ですべてのDNSクエリをブロックしてしまうDISCARD(破棄)セッションの形成を防ぎます。二番目のポリシーはクライアントからファイアウォールに向かうトラフィックに対してのアンチスパイウェアを実行するためのものです。これは限定したクライアントからの疑わしいDNSクエリをブロックし、ネットワーク全域でのDNSクエリはブロックしません。     参考 How to Configure DNS Proxy on a Palo Alto Networks Firewall   著者:jwebb
記事全体を表示
TShimizu ‎07-06-2016 02:14 AM
5,655件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Set Session, TCP, and UDP Timeout Values https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Set-Session-TCP-and-UDP-Timeout-Values/ta-p/53385     概要 この文書はTCP、UDPのセッション タイムアウト設定値について、PAN-OSのweb UIとCLIでの変更、確認方法を記載します。   詳細 セッション タイムアウト設定方法: web UIから、Device >セットアップ > セッション > セッション タイムアウト PAN-OS 5.0, 6.0 PAN-OS 6.1 CLIから、以下のコマンドにて変更可能。この変更は一時的なもので再起動によりクリアされます。     > set session timeout-udp <1-15999999>     > set session timeout-tcp <1-15999999>   再起動後も継続する恒久的な変更をCLIから行うには、コンフィグレーション モードで以下のコマンドで設定します。 デフォルトのセッション タイムアウト設定の変更 # set deviceconfig setting session timeout-default   <value>  <1-15999999> set session default timeout value in seconds   TCPのセッション タイムアウト設定の変更 # set deviceconfig setting session timeout-udp   <value>  <1-15999999> set udp timeout value in seconds   UDPのセッション タイムアウト設定の変更 # set deviceconfig setting session timeout-tcp <value>  <1-15999999> set tcp timeout value in seconds           設定の保存、反映のため、コミットを実行 # commit   コミット実行の後、変更したセッション タイムアウトの値はsession informationにて確認が可能。 > show session info | match timeout Session timeout        TCP default timeout:                           3600 secs        TCP session timeout before SYN-ACK received:      5 secs        TCP session timeout before 3-way handshaking:    10 secs        TCP session timeout after FIN/RST:               30 secs        UDP default timeout:                             30 secs        ICMP default timeout:                             6 secs        other IP default timeout:                        30 secs        Captive Portal session timeout:                  30 secs        Session timeout in discard state:          TCP: 90 secs, UDP: 60 secs, other IP protocols: 60 secs   著者:ppatel
記事全体を表示
TShimizu ‎07-05-2016 07:50 PM
10,778件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Configure and Test FQDN Objects https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-and-Test-FQDN-Objects/ta-p/61903     考察 FQDN オブジェクトはアドレス オブジェクトです。すなわち、セキュリティ ポリシーで送信元アドレスや宛先アドレスを参照するのと同様の使い方ができます。 そのため、Palo Alto Networks ファイアウォールは、30 分ごとに FQDN リフレッシュを行います。FQDN リフレッシュでは、設定されている DNS サーバー (Setup > Services) へ NS ルックアップを行います。 Palo Alto Networks ファイアウォールでは 1 つの FQDN オブジェクトに IP アドレス 10 個までマッピングできます。 この DNS サーバーが、ホストが使用しているのと同じ DNS サーバーであることを確認してください。DNS マルウェアはこのようなソリューションに悪影響を及ぼす場合があります。 この方法はIP アドレスを使用することができない場合のみ使用してください。つまり、このタイプのオブジェクトを URL フィルタリング ポリシーの一部として使用しないでください。 この方法はまた、Web Browsing と関連のない他のサービス (FTP、SSH、またはその他のサービス) を制御するのにも役立ちます。 オブジェクトが IPv6 アドレスに解決される場合は、IPv6 Firewalling (Setup > Session) を有効にします。   オブジェクトの設定 FQDN オブジェクトの設定を始めるために、Objects > Addresses へ移動します。 Add をクリックして新しいアドレス オブジェクトを作成します。 タイプを‘IP/Netmask’から‘FQDN’へ変更します。 アドレスを入力します (http:// またはその他のヘッダーは含めないでください)。 OK をクリックします。 変更をコミットします。   FQDN オブジェクトは CLI のコンフィグレーション モードで以下のコマンドを使用して設定できます。 # set address Google fqdn www.google.com   変更の確認 自動 FQDN リフレッシュ タスクはバックグラウンドで実行されます。このジョブのステータスは GUI の右下角の Tasks ボタンをクリックして確認できます。 CLI コマンド 'request system fqdn show' は、FQDN オブジェクトとその名前に紐づく IP アドレスの一覧を参照するために使用できます。 リフレッシュの強制実行は 'request system fqdn refresh' コマンドを実行することにより可能です。 推奨される追加の確認としては、デスクトップからホストへ ping し、その IP アドレスが 'request system fqdn refresh' コマンド実行後一覧に表示された IP アドレスに一致することを確認することが挙げられます。   著者: kgotlob
記事全体を表示
kishikawa ‎04-25-2016 08:32 PM
11,650件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Security policy fundamentals https://live.paloaltonetworks.com/t5/Learning-Articles/Security-policy-fundamentals/ta-p/53016   PAN-OS 4.1, 5.0, 6.0   目次 概要 2種類のセキュリティ ポリシー セッション トポロジー "application-default" サービス ルールのシャドウイング (Shadowing) ユーザー ベースのセキュリティ ポリシー NATされたIPアドレスとセキュリティ ポリシー セキュリティ ポリシー上のURLカテゴリ アプリケーションの依存関係およびアプリケーション シフト アプリケーション識別と復号化 ルールの整理 セキュリティ ポリシーTIPS 関連ドキュメント   概要 このドキュメントは、Palo Alto Networks ファイアウォールにおけるセキュリティ ポリシーの基礎を説明しています。   Palo Alto Networks ファイアウォールのデータプレーンを通過するトラフィックはすべてセキュリティ ポリシーと照合されます。マネジメント インターフェースより発信されるトラフィックは、デフォルトではデータプレーンを通過しないため、これには含まれません。ファイアウォールのセキュリティ ポリシーは、ゾーン、アプリケーション、IPアドレスポート、ユーザー、HIPプロファイル等、様々な基準によって定義できます。ファイアウォール管理者は、ゾーンのような広い基準を始め、ポート、アプリケーション、および HIP プロファイルなどのより詳細なオプションでポリシーを調整し、トラフィックを許可または拒否するようにセキュリティ ポリシーを定義することができます。   2種類のセキュリティ ポリシー Palo Alto Networks ファイアウォールは2つの種類のセキュリティ ポリシーを持ちます: 明示的な (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 ファイアウォールはステートフル ファイアウォールであり、これは、すべてのファイアウォールを通過するトラフィックはセッションと照合され、すべてのセッションはセキュリティ ポリシーと照合されることを意味します。   セッションは2つのフローから成ります。クライアントからサーバーへのフロー (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 トラフィックは、初めはこのルールに一度合致し、アプリケーション シフトが発生すると、2度目のセキュリティ ポリシー ルックアップで 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 Session Rematch Works 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 Session Log Best Practice    
記事全体を表示
dyamada ‎04-20-2016 03:04 AM
22,405件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Determine the Number of Threat Signatures on a Palo Alto Networks Firewall https://live.paloaltonetworks.com/t5/Threat-Articles/How-to-Determine-the-Number-of-Threat-Signatures-on-a-Palo-Alto/ta-p/55760     概要 "すべてのシグネチャの表示"("Show all signatures")オプションを選択しなければ、脅威シグネチャーは表示されません。この動作はスパイウェア、脆弱性プロファイルの両方において同様です。 "すべてのシグネチャの表示" オプションを選択すると、全てのスパイウェア/脆弱性シグネチャが表示され、脅威シグネチャ数が確認できます。     手順 全てのシグネチャを表示するためには、以下の手順を行います。 Objects > セキュリティ プロファイル > [アンチ スパイウェア または 脆弱性防御] へ移動 プロファイルを選択 例外タブをクリック "すべてのシグネチャの表示" オプションをチェック   以下は、アンチ スパイウェア プロファイルを使った例です。 Threat IDの10001以降がアンチ スパイウェア用に割り当てられています。   注:Threat IDの15000 から 18000 まではカスタム シグネチャに割り当てられています。   以下は、脆弱性防御プロファイルを使った例です。 Threat IDの30003以降が脆弱性シグネチャに割り当てられています。 (訳注:最新の情報を反映しているため、元記事とは数値が異なっています。) 注:Threat IDの 41000 から 45000 まではカスタム シグネチャに割り当てられています。   脅威シグネチャ数はPalo Alto Networksファイアウォールにインストールされているコンテントのバージョンによって異なります。新しいシグネチャが頻繁にデータベースに追加されていくので総数は常に固定とは限りません。     参考 マッチする脆弱性防御シグネチャの見つけ方 シグネチャのDefaultアクション変更手順     著者: tshivkumar  
記事全体を表示
ymiyashita ‎04-20-2016 01:29 AM
8,069件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Find Matching Signature for Vulnerabilities https://live.paloaltonetworks.com/t5/Threat-Articles/How-to-Find-Matching-Signature-for-Vulnerabilities/ta-p/54905     Palo Alto Networksが生成した脆弱性防御のシグネチャの中で、特定のシグネチャを見つけたい場合、まず脆弱性防御ルールを作成します。   脆弱性防御ルールは 脆弱性防御プロファイルの中で定義されます。 "ルール" タブ > "脅威名" にシグネチャ名の一部となるテキストを入力します。 検索結果をフィルターするために、その他の全てのフィールドを任意に埋めます。 以下の例は、シグネチャ名に "MySQL"を含み、アクションがAlertで、かつ重大度 (Severity) が CriticalかHighのものを検索するための設定です。 OKボタンをクリックします。 脆弱性防御プロファイルのウィンドウで、検索したいルールのチェックボックスにチェックを入れた後、"一致するシグネチャを検出" ("Find Matching Signature") をクリックします。 検索結果と共に"例外"タブが表示されます。 上記で作成した脆弱性防御ルールの条件にマッチするルール名の一覧とそれぞれのアクションが表示されています。また右下の部分(ハイライト箇所)には、ページ数とマッチしたシグネチャの総数が表示されています。  参考: Palo Alto Networksファイアウォールにおける脅威シグネチャ数の確認方法 シグネチャのDefaultアクション変更手順   著者: ssunku
記事全体を表示
ymiyashita ‎04-20-2016 01:26 AM
7,055件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Create an Application Override Policy https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Create-an-Application-Override-Policy/ta-p/60044   概要 Application Override Policy はPalo Alto Networks firewallのアプリケーション識別の仕方を変えます。 Application Override を Custom Applicationで設定することによって セッションをApp-ID engineによるLayer-7検知から除外することができ、firewall はセッションをステートフルインスペクションfirewallのように Layer-4までの処理しかしなくなります。 既存の アプリケーション、 例えばweb browsingを Application Override に使用する場合、特定の アプリケーションに 一致するすべての通信 ( この例だとweb browsing)は Layer-7検知処理されることになります。 。   Application Override は標準のポート番号を使用しない内部 Custom Application やFirewallが”unknown”と識別するcustom 定義が既に設定されている内部 アプリケーション に使用する事ができます。   注意: 既存の アプリケーション を使用すると Application Override が正常に動作しない可能性があるのでCustom Applicationの使用を推薦します。   参照:Tips & Tricks: How to Create an Application Override. 以下の例では, Telnetに対して Application Override を設定します。   ステップ Custom Applicationの作成 WebUI上でObjects > Applications に行きaddをクリックします。 Applicationに名前をつけます。 (“telnet”はもう使用されているので別の名前にします)この例では”telnet_override”と名前をつけます。 Category, Subcategory, と Technology を選択します。 Advanced タブでDefaults を'Port'に設定します。 ( アプリケーション が使用するポートが表示されます)。 この例だとSignaturesを追加する必要がないので, OKをクリックし Custom Application 作成を完了します。   Application Override Policyの作成 Policies > Application Overrideへ行き、Addをクリックします。 Generalタブで Policyの名前を入力します。 Sourceタブで Source Zoneを設定します. 送信元が固定IPの場合Source Addressを設定し、固定でない場合は”Any”と設定します。 Destinationタブで Destination Zoneを設定します. 送信先が固定IPの場合Destination Addressを設定し、固定でない場合は”Any”と設定します。 Protocol/Applicationタブでは ProtocolとPort number を設定し、前のステップで作成した custom application を選択します。   Security Policyの作成 Policies > Security に行きAddをクリックします。 Custom Applicationの通信が通過するZoneを設定したSecurity policy を作成します。 新規セッションは作成した Custom Application として識別されます。 作成したCustom Applicationのセッションを表示するにはCLI で show session all filter application コマンドを使用します。 例: > show session all filter application Telnet_Override
記事全体を表示
oconnellm ‎04-19-2016 10:48 PM
5,382件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Configure Active Directory Server Profile for Group Mapping and Authentication https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-Active-Directory-Server-Profile-for-Group/ta-p/58089   概要 Palo Alto NetworksはLDAPブラウザーを使って、正確なLDAP情報を確認することを推奨します。   正確なバインド情報の見つけ方 バインドDNを検索するには、AD サーバーのコマンド ラインにて、以下のコマンド(例:ユーザー名 test1)実行します。 dsquery user -name test1 以下の例ではバインドDN "CN=test1, OU=outest2, OU=outest, DC=pantac2, DC=org" が返答されます。   または、バインドDNを検索するためにLDAPブラウザを使用することもできます。   ベースDNはLDAPディレクトリー構造で、PANがユーザー情報を検索する起点です。 バインドDNで使用するユーザーは、認証のために情報を検索するために使用するものです。   注意 : アクティブ ディレクトリー(AD)では空白のフォルダー アイコンはコンテナ (CN) 、通常のフォルダーは組織(OU)を表します。     この例では、adminアカウントがUsersコンテナにある場合、バインドDN情報はcn=admin,cn=users,dc=pantac2,dc=orgとなります。   次の例ではtest1アカウントがOUtest2組織ユニット(OU)に存在します。そしてOUtest2はOUtestの中にいます。   LDAP設定 Device > Server Profile> LDAP   上記の例ではアクティブ ディレクトリー(AD)の接続にSSL暗号化は使用されません。TCP ポート389はLDAP接続で非暗号化接続の標準ポートです。以下は、TCP ポート636(SSL暗号化)設定例です。   LDAP情報 Domain: paloalto (NETBIOS名かWindows 2000以前のドメイン名です。詳しくは What Should be Configured as Domain in an LDAP Profile? をご参照ください) Type: active-directory Base DN: DC=paloalto, DC=com Bind DN: CN=PAadmin, OU=Users, DC=paloalto, DC=com   グループ マッピング プロファイル設定 Device > User Identification> Group Mapping Settings: 許可リストのグループ化タブをクリックします。 左パネルにあるBase情報左の”+”をクリックすると、検索をかけたいグループ情報一覧が表示されます。 グループ リストから、ファイアウォール上のポリシーで使用したい"cn="で始まるグループを選択し、画面中央の”+”で右側の含まれたグループに追加します。 注意!含まれた グループに何も選択しない場合、アクティブ ディレクトリー(AD)上のすべてのグループがけ検索対象になり、負荷をかける原因になることがあります。 コミットを実行します。 CLIでLDAP serverとの接続を確認するコマンドは以下になります。 > show user group name all   LDAP認証の設定 Device > 認証プロファイル 認証 プロファイルで、クエリ検索をかけたいグループを追加します。 このプロファイルは、Captive Portal、Global Protect、ユーザー ログイン、その他ファイアウォールで使用する認証で使用することができます。 許可リストのグループが異なる場合は、別の認証プロファイルを作成し違う目的で使用することができます。
記事全体を表示
kkondo ‎04-08-2016 11:42 PM
5,955件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Configure WildFire https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-WildFire/ta-p/56165   概要   WildFireは、ユーザに悪意のあるアクティビティの有無を自動的に解析する Palo Alto Networks のセキュアかつクラウドベースの、仮想化された環境へファイルを提出することを可能にします。脆弱な環境でそのファイル実行させ、システムファイルを修正する、セキュリティ機能を無効にする、検出を回避するために様々な方法を使用する、などの特定悪意ある行動やふるまいをPalo Alto Networksは監視します。ZIP圧縮されたファイルや HTTP(GZIP) ファイルは検査され、内部の EXE や DLL ファイルを解析対象にすることが可能です。 WildFireポータルでは解析ファイルの解析結果の閲覧が可能で、標的にされたユーザー、利用されたアプリケーション、悪意のあるふるまいが確認できます。WildFireポータルでは、解析結果が利用可能になった際にEメールを送信することもできます。   構成   設定方法: Device > Setup > WildFire タブに移動 default-cloudを選択し、maximum file size を 2MBにする WildFire に転送される情報を指定 Source IP—疑わしいファイルを送信した送信元IPアドレス Source Port—疑わしいファイルを送信した送信元ポート Destination IP—疑わしいファイルが送信された宛先IPアドレス Destination Port—疑わしいファイルが送信された宛先ポート Vsys—マルウェアの可能性が識別されたファイアウォール上のバーチャルシステム Application—ファイル転送に利用されたユーザーアプリケーション User—狙われたユーザ URL—疑わしいファイルに関連するURL Filename—送信されたファイルの名称   デフォルトでは、すべてのオプションが選択されていますが、Wildfireが動作するための必須情報ではありません。選択をはずした情報はWildFireクラウドに送信されません。   復号化ポリシーを利用している場合、WildFireでは暗号化されたファイルのアップロードの有効化が可能 Device > Setup > Content-ID > Enable に移動し“Allow Forwarding of Decrypted Content”を有効化                    デフォルトでは、暗号化されたファイルはWildFireクラウドに転送されません。PAN-OS 6.0では修正されるでしょう。(翻訳者注:要確認) Objects > Security Profiles > File Blocking に移動 ルールを追加. ルール名入力 (英字 31 文字以内) Applications— anyを選択 File Types—exe, dll のファイルタイプを選択 Direction—ファイル転送の方向を選択 (Upload, Download, または Both) Action—設定したファイルタイプを検知した際のアクションを設定 : Forward (ファイルを自動的にWildFireに送信)     作成した File Blocking プロファイルを Policies > Security 内の Wildfire を利用したいルールに適用 OKをクリック 設定をコミット     WildFire CLI コマンド 基本設定完了後、以下のコマンドで接続されたサーバの詳細が確認できます。接続性の確認 : > test wildfire registration This test may take a few minutes to finish. Do you want to continue? (y or n) Test wildfire         wildfire registration:        successful         download server list:        successful         select the best server:      va-s1.wildfire.paloaltonetworks.com   初回のレジストレーションは Active/Pasive 構成の Active ユニット上でのみ実施することができます。   Note: PINGでの接続性確認は実施しないでください。PingリクエストはWildFireサーバでは無効に設定されてます。接続性確認のベストプラクティスとして、サーバの443ポートへTelnetを実施する方法があります。   確認として、もしなんらかのファイルがサーバへ転送されている場合、以下のコマンドを利用します。 > show wildfire status Connection info:         Wildfire cloud:                default cloud         Status:                        Idle         Best server:                  va-s1.wildfire.paloaltonetworks.com         Device registered:            yes         Service route IP address:      10.30.24.52         Signature verification:        enable         Server selection:              enable         Through a proxy:              no Forwarding info:         file size limit (MB):                  2         file idle time out (second):            90         total file forwarded:                  0         forwarding rate (per minute):          0         concurrent files:                      0   "total file forwarded" カウンタでサーバへ転送されたファイルの数が確認できるでしょう。   WildFireログの確認 Monitor > Logs > Data Filtering ページへ移動 :   "data filtering logs" にてファイルのステータスを確認します。 もし "forward" 以外に "wildfire-upload-success" と "wildfire-upload-skip" のどちらも確認できない場合、そのファイルは信頼された署名がされているか、クラウド上ですでに良性と判断されています。   以下はアクションについての説明です。   Forward データプレーンが潜在的に実行可能ファイルをWildFireが有効化されたポリシー上で検知しています。このファイルはマネジメントプレーン上にバッファされています。 もし "forward" 以外に "wildfire-upload-success" と "wildfire-upload-skip" のどちらも確認できない場合、そのファイルは信頼された署名がされているか、クラウド上ですでに良性と判断されています。どちらのケースでも、このファイルに対して更なるアクションは実施されておらず、クラウド上にも送信されません (以前に良性であると判断されたファイルに関するセッション情報も送信されません)。これらのファイルに関する情報は WildFire Web ポータルにも記録されません。   どれだけのPEファイルがチェックされたか、クリーンまたはアップロードするために発見されたかについてのカウンタを確認するには、以下のコマンドを実施します: > show wildfire statistics statistics for wildfire DP receiver reset count:                  12 File caching reset cnt:                  12 FWD_ERR_CONN_FAIL                        1 data_buf_meter                            0% msg_buf_meter                            0% ctrl_msg_buf_meter                        0% fbf_buf_meter                            0%   wildfire-upload-success これは、そのファイルは信頼された署名がされておらず、ファイルはまだクラウド上で確認されていないことを意味します。この場合、そのファイル(とセッション情報)は解析ためにクラウド上にアップロードされています。.   wildfire-upload-skip これは、そのファイルがすでにクラウド上で確認されていることを意味します。 もしこのファイルが以前に悪意があると判断されている場合、その悪意があると判断された際のレポートがWildFireサーバ上に表示されす。 もしファイルが悪意のない良性のファイルであると判断されている場合、レポートはWildFireサーバ上では表示されません。   WildFire ポータル WildFire Portal にアクセスするには、https://wildfire.paloaltonetworks.com にアクセスし、Palo Alto Networks のサポートアカウントまたは WildFire アカウントででログインします。ダッシュボードが表示され、WildFire アカウントまたはサポートアカウントに紐づくすべてのファイアウォールからのサマリレポート情報がリストされます。この画面では解析されたファイルの数とどのくらいのファイルが malware、 benign、 または pending と判定されたかが表示されます。     その他の便利なコマンド show wildfire disk-usage debug wildfire dp-status   See Also Not All Files Appear on the WildFire Portal When Logs Show the Wildfire-Upload-Skip Message  
記事全体を表示
dyamada ‎04-08-2016 12:31 AM
10,331件の閲覧回数
0 Replies
質問 ※この記事は以下の記事の日本語訳です。 App-ID changes to Google apps https://live.paloaltonetworks.com/t5/Management-Articles/App-ID-changes-to-Google-apps/ta-p/66890     2015年12月1日、Palo Alto Networks ファイアーウォールはGoogleアプリケーションを有効化するための簡素化、ポリシー設定のスリム化を考慮して、google-baseという名前の新しいApp-IDを追加しました。以下のFAQにて、既存ファイアーウォールの設定に対するインパクト、変更について、基本的な質疑応答を掲示します。もし追加の質問がございましたら、Discussion forumをご利用ください。     良くある御質問   質問: なぜPalo Alto Networksはこの変更を実施したのですか?   回答: 今日、Googleアプリケーションを有効化するためにはお客様にその他の依存するアプリケーション(ssl, web-browsing)を許可設定していただく必要がございました。この変更によって、明示的に依存するアプリケーションを許可するする必要なくなりました。新しいApp-ID、google-baseを許可することにより、Googleアプリケーションの基本サービスをご利用することができます。     質問: この変更によりどのような影響がありますか?   回答: 新しい変更の優位性を得るために、Googleアプリケーションを許可するために設定している、ssl, web-browsingの代わりに、google-baseをポリシーのApplication欄で許可する必要があります。サンプルの設定は以下をご参照ください。Google Calendar, Gmail, YouTubeとGoogle Mapsが許可され、その次の新しく設定されたポリシーで、google-baseをApplication欄で許可されています。        質問: どのようにしてGoogleアプリケーション継続動作することができますか?   回答: Palo Alto Networksは、2015年11月の第1週目にgoogle-baseをアプリケーションカタログに追加しました。これにより我々のお客様に、事前変更を実施することが可能となります。   この仮のApp-IDは、既存のファイアーウォールポリシーや、App-ID既存ルールに影響を及ぼすものではございません。 サンプルの移行ポリシーは以下です。   Palo Alto Networksが、仮のgoogle-baseを正式なものに更新するのは、2015年12月の第1週目です。   Palo Alto Networksの変更タイムラインはいかのようになります。   2015年10月20日 - Palo Alto Networksが次期Googleアプリケーションのファイアーウォールによる処理の変更点についてアナウンスいたします。 2015年11月の第2週目– Palo Alto Networks は仮のgoogle-baseであるApp-IDを週次で配布しているコンテンツアップデートで提供します。これにより、ファイアーウォールの事前設定が可能となります。 2015年12月の第1週目– Palo Alto Networks は正式のgoogle-baseであるApp-IDを週次で配布しているコンテンツアップデートで提供します。このアップデートにより、google-baseがApp-IDとして稼働します。以前ご使用になられていた、依存アプリケーションのssl, web-browsingを取り除くことができます。これより、いずれのGoogleアプリケーションにおいても依存アプリケーションはgoogle-baseとなります。   質問: いつこの変更が、アプリケーションと脅威のアップデートによって提供されますか?   回答: Palo Alto Networks は正式のgoogle-baseであるApp-IDを2015年12月の第1週目で配布するコンテンツアップデートで提供します。   質問: もしファイアーウォールのポリシー上にgoogle-base を追加せず、"ssl"、 "web-browsing" のままにしてたらどうなりますか?   回答: ファイアーウォールのポリシー上にgoogle-base を追加しなかった場合、Googleアプリケーションが正常に動作しなくなりますので、2015年12月の第1週目で配布されるコンテンツ アップデートで、google-base を許可する必要があります。   質問: PAN-OSどのバージョンがこの変更の影響を受けますか?   回答: 全てのPAN-OS softwareサポートバージョンで、2015年12月の第1週目で配布されるコンテンツアップデートを実施すると影響を受けます。   質問: 'google-base'が必要なアプリケーションのリストはありますか?   回答: 'google-base' が必要なアプリケーションのリストは、こちらのリンクをご参照ください。: List of applications that require 'google-base'   質問:  'google-base' App-IDを識別するためにSSL復号化を有効化する必要がありますか?   回答: いいえ、SSL復号化'google-base' App-ID を識別するために必要ではありません。しかしながら、SSL上で動作するGoogleアプリケーション(例えば、gmail)を復号化するためには必要です。   質問: 'google-base' App-IDをポリシーで許可すると、他のGoogleアプリケーション(youtube-baseやgmail-baseなど)も許可されますか?   回答: いいえ、他のGoogleアプリケーション(youtube-baseやgmail-baseなど)は個別にポリシー上で許可する必要がございます。   Palo Alto Networks 社は、お客様のファイアーウォール上のポリシーをご確認いただき、仮の'google-base' App-ID 設定を2015年12月1日以前に設定していただくことを強く推奨いたします。   その他質問に関して もしその他に、この記事に書かれている変更点についてご質問がありましたら、Discussion forumにご質問を掲示していただくようお願いします。 回答
記事全体を表示
kkondo ‎04-06-2016 12:32 AM
2,828件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Configure DNS Sinkhole https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-DNS-Sinkhole/ta-p/58891   概要 PAN-OS 6.0より、アンチスパイウェア プロファイルにおいてDNS シンクホールのアクションが使用できるようになりました。DNSシンクホールは、ファイアウォールが悪意のあるURLに対するDNSクエリが見える環境において、保護されたネットワーク内にある感染したホストをDNSトラヒックをベースに特定するために使うことができます。   このDNSシンクホールの機能により、Palo Alto Networksデバイスは悪意のある既知ドメインやURLに対するDNSクエリを見つけると、定義しておいた任意のIPアドレス(偽のIP)をクライアントに返します。それを受け取ったクライアントがその偽のIPアドレスにアクセスしようとし、かつ、そのIPアドレスへの通信をブロックするセキュリティポリシーが存在する場合、その情報がログとして残ります。   重要!  "偽のIP" を選択する際には、そのIPアドレスが内部のネットワークに実際に存在しないことを確認してください。また、悪意のあるURLが検知され、設定した偽のIPへのアクセスが止められるようにするには、該当DNSとHTTPトラヒックがPalo Alto Networksファイアウォールを通過する必要があります。もし偽のIPが別に存在しファイアウォールを通過しないのであれば、この機能は正しく動作しません。   手順 Palo Alto Networksデバイスにおいて最新のアンチウィルス シグネチャがインストールされていることを確認します。 WebUIより、"Device" > "ダイナミック更新" へ移動し、"今すぐチェック" をクリックします。アンチウィルス シグネチャが最新であることを確認します。最新でなければ、最新版をインストールしてください。スケジュールによる自動更新の設定も可能です。 注: DNSシンクホールの機能を利用するには、脅威防御 ( Threat Prevention ) のサブスクリプションが必要となります。 アンチスパイウェア プロファイル内にあるDNSシンクホールを設定します。"Objects" > "セキュリティ プロファイル" > "アンチスパイウェア" をクリックします。 既存のプロファイルを使うか、新しくプロファイルを作成します。以下の例では、"alert-all" を使用します。 プロファイル名 "alert-all" をクリックし、"DNSシグネチャ" タブを開きます。 "DNSクエリに対するアクション" をデフォルトの "alert" から ”シンクホール” に変更します。 シンクホールIPv4フィールドをクリックし、偽のIPアドレスを入力します。上記の例では、簡単のために1.1.1.1を使っていますが、内部のネットワークで使われていないIPアドレスであれば値は何でも構いません。 次に、シンクホールIPv6フィールドをクリックし、偽のIPv6 IPアドレスを入力します。たとえIPv6がネットワーク上使われていなくても、この値は入力する必要があります。上記の例では ::1 です。最後にOKボタンをクリックします。   注: シンクホールIPv6フィールドに何も設定されていない場合は、OKボタンは無効のままになります。 作成したアンチスパイウェア プロファイルを、内部ネットワーク(または内部のDNSサーバー)からインターネットへ抜けるDNSトラヒックを許可するセキュリティ ポリシーに適用します。 "Policies" > "セキュリティ" をクリックします。 セキュリティ上 ルールの一覧から外部へ抜けるDNS通信を許可するルールを特定し、そのルール名をクリックします。"アクション" タブを開き、該当のアンチスパイウェア プロファイルが選択されていることを確認し、OKボタンを押します。 最後に、設定した偽のIP 1.1.1.1 と :1 (IPv6を使用している場合) を宛先とする全てのweb-browsingとSSL通信をブロックするセキュリティ ルールを用意します。これは感染したマシンから偽のIPへの通信をブロックするためのものです。 設定をコミットします。   See Also テスト手順とセットアップの確認方法については、以下のドキュメントを参照してください。 How to Verify DNS Sinkhole Function is Working   DNSシンクホールを説明したビデオ チュートリアルもあります。 Video Tutorial: How to Configure DNS Sinkhole Video Tutorial: How to Verify DNS Sinkhole  
記事全体を表示
ymiyashita ‎04-04-2016 09:45 PM
7,639件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 URLフィルタリングによる特定HTTPSサイトのブロック方法 https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Block-a-Specific-HTTPS-Site-with-URL-Filtering/ta-p/53840   概要 URLフィルタリングは特定のHTTPSサイトをブロックし、同時にその配下のサイトをすべて許可したい場合、いくつかの課題を提示します。 たとえば、"https://public.example.com/extension1/a" はブロックしたいものの、"https://public.example.com/extension1/b" は許可したい場合などです。   セキュリティポリシーとカスタムURLカテゴリを利用する場合、そのサイトの提供する証明書の「発行先」のコモンネーム(Common Name, CN)でしかマッチさせることができません。   Note: PAN-OS 6.0リリースより、 SSLセッションの "Client Hello message"に含まれる SNI(Server Name Indication) でマッチさせることができます。詳細は Resolving URL Category in Decryption Policy When Multiple URLs are Behind the Same IP を参照ください。   以下のスクリーンショットでは、コモンネームが "*.example.com" であることを確認できます。   セキュリティポリシーでは"*.example.com"をブロックできますが、そのサイト全体がブロックされてしまいます。これでは望ましくないので、URLフィルタープロファイル (URL Filtering Profile) を設定する必要があります。しかしながら、URLフィルタープロファイルを利用する場合の問題は、ファイアーウォール上でそのセッション内のURL全体を精査しなければならないことです。セッションはSSLで暗号化されていますので、復号ポリシーを有効にしないと通信内容を確認できません。   SSL復号化は注意して実装する必要があります。もし、まだファイアウォール上でこれが実装されていない場合、必要な通信に対してのみ復号化 (Decryption) を実施します。復号ポリシーには「URLカテゴリ」を設定することができます。復号化では、セキュリティポリシーと同じ理由で、HTTPSサイト上の特定のサブページでブロックが必要なことを知ることができません。復号ポリシーは、提供された証明書の発行先のCNをチェックします。もしこれが設定上のURLカテゴリにマッチした場合、SSLセッションの復号化を実施します。   これは "*.example.com" に対し復号化を実施し、URLフィルタで "public.example.com/extension1/a" 宛ての通信をブロックしたい場合に有用な方法です。 Note: "https://" 部分は上記URLから除外しています   手順 以下の手順を実施することで、このような動作を設定できます: Objects > Custom Objects > URL Category へ移動し、"Example Blacklist" という名前のカスタム URL カテゴリを作成します。そこに「public.example.com/extension1/a」のURLを追加します。 URLリストの頭に「https://」は含めないでください。 Objects > Custom Objects > URL Category で、"Wildcard Blacklist" のカスタム URL カテゴリを作成します。URLリストに「*.example.com」を追加します。 Objects > Security Profiles > URL Filtering に移動し、"Blacklisted HTTPS Sites" という名前の URL Filtering profileを作成します。"Example Blacklist" のカスタム URL カテゴリーのアクションを「block」にします。 (これにより URL Filtering profile の URL Block Categories に追加されます) Policies > Securityに移動し、trust から untrust 宛の通信用に "Deny HTTPS Sites" のポリシーを作成します。アクションは  allow のままで、Profile Settings > Profile Type を選択し、URL Filtering で "Blacklisted HTTPS Sites" のプロファイルを選択します。 Device > Certificate Management > Certificatesへ移動し、"Palo Alto Decryption Trusted" と "Palo Alto Decryption Untrusted" という2つの自己署名 (self-signed) CA 証明書を生成します。 証明書の CN を "Palo Alto Decryption Untrusted" ではファイアウォールの信頼された IP を、 "Palo Alto Decryption Trusted" では任意のものを指定します。 (これらの証明書をエクスポートし、Group Policy等を利用してユーザへプッシュします)。"Palo Alto Decryption Trusted" 証明書を開き、 "Forward Trust Certificate" のチェックを入れます。また、"Palo Alto Decryption Untrusted"  証明書では "Forward Untrust Certificate"にチェックします。 Policies > Decryption へ移動し、"Decrypt Blacklisted Sites" という復号ポリシーを追加します。送信元ゾーンをtrust、宛先ゾーンを untrust、 URL カテゴリに "Wildcard Blacklist"、 オプションでは Action: Decrypt、Type: SSL Forward Proxy とします。 コミット後、 https://public.example.com/extension1/a はブロックされます。    
記事全体を表示
dyamada ‎04-04-2016 01:24 AM
15,406件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Configure Agentless User-ID https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-Agentless-User-ID/ta-p/62122   手順 エージェントレス User-IDを設定するには、まずサービスアカウントを作成し、作成したアカウントのセキュリティ設定を変更します。   以下のようにActive Directory(AD)サーバとPalo Alto Networks機器を設定します。 機器で使用されるサービスアカウントをAD上で作成します。作成されたユーザが、Distributed COM Users, Server Operators および Event Log Readers groups に所属することを確認してください。 Note: サービスアカウントの機能させるうえで、ドメイン管理者(Domain Admin)の権限は必須要件ではありません。詳細は「Best Practices for Securing User-ID Deployments」を確認してください。 Windows2003の場合、サービスアカウントには"Audit and manage security log"の権限をグループポリシ経由で与える必要があります。ドメイン管理者グループに所属するアカウントを作成することで、すべての操作に必要な権限が付与されます。“Event Log Readers”グループはWindows 2003では利用できません。 WMI 認証を利用する機器やユーザは、接続されるAD上でCIMV2セキュリティ属性を変更する必要があります。 コマンドプロンプト上で'wmimgmt.msc'を実行しコンソールを開き、プロパティを選択します。 WMI コントロールのセキュリティタブを選択し、CIMV2フォルダを選択します。セキュリティをクリックし、step1で作成したサービスアカウントを追加します。この例ではpanrunner@nike.localを設定しています。追加したアカウントで「アカウントの有効化」と「リモート有効化」をチェックしてください。 PAのDevice > User Identification MenuよりUser Mapping を選択します。 PAのUser-IDエージェントの設定を完了します。 User Mapping > WMI Authenticationタブのユーザーネーム設定が domain\username フォーマットになっていることを確認します。 Server Monitorオプションを有効にし、security log/session を有効にします。 Client probingはデフォルトで有効です。必要であれば無効にします。 もしセットアップ中にドメインが設定されている場合、ユーザは接続先のサーバを選択できます。もし設定されていない場合、マニュアルでサーバを設定します。 接続されたかどうか、WebUIまたはCLIにて確認します。 > show user server-monitor statistics Name                          TYPE    Host            Vsys    Status --------------------------------------------------------------------------- 2k8                            AD      10.30.14.250    vsys1  Connected ip-user-mappingが機能していることを動作を確認します。 > show user ip-user-mapping all IP              Vsys  From    User                            IdleTimeout(s) MaxTimeout(s) --------------- ------ ------- -------------------------------- -------------- ---------- 10.16.0.28      vsys1  AD      nike\palto                      2576          2541 10.30.14.106    vsys1  AD      nike\panrunner                  2660          2624 10.30.14.110    vsys1  AD      nike\panrunner                  2675          2638 Total: 3 users ユーザ識別を実施したい通信が発信されるZoneでUser Identificationが有効であることを確認します。Network > Zone でZoneを選択します。   See Also User-ID Agent Setup Tips  
記事全体を表示
dyamada ‎04-03-2016 10:30 PM
5,197件の閲覧回数
0 Replies
Ask Questions Get Answers Join the Live Community