ナレッジドキュメント

※この記事は以下の記事の日本語訳です。 GLOBALPROTECT: ONE-TIME PASSWORD-BASED TWO FACTOR AUTHENTICATION https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Cm8ICAS     原文はSivasekharan   Rajasekaranによるものです。 @ srajasekar   背景   企業では社内リソースへのアクセスの許可のために、ワンタイム パスワード（OTP）のような、より強力な認証手段が求められています。OTPベースの認証を要求することで、企業は攻撃者が不正にユーザーの資格情報を入手したり、承認されないアクセスをすることを防ぐことができます。しかしOTPを要求するどの実装も、エンドユーザーがOTPを使いづらく感じ、敬遠する恐れがあります。   目的   GlobalProtectはOTPベース認証をサポートし、ユーザー体験を維持する手段を提供します。この文書の目的は、企業の管理者に異なるGlobalProtectのOTP認証のワーク フローと、彼らのセキュリティとコンプライアンスの要求に合致しつつ、ユーザー体験を簡潔に維持するGlobalProtectの認証シナリオを決定する一助となることです。     GlobalProtectのOTP認証   GlobalProtectはRADIUSまたはSAML経由のOTPベースの認証をサポートし、OTPベンダーに全く依存しません。 RADIUSかSAMLをOTPベンダーが対応している限り、どのOTPベンダーも使用できます。OTPサービスをどのように設定したか次第で、ユーザーは2つのワーク フローのいずれかに従って認証されます。 ユーザーはユーザー名とパスワードを最初に入力し、その後にOTPによりChallengeが行われます。OTPは承認のプッシュ、SMS、トークン コードのいずれかを使用します。 ユーザーはユーザー名を入力し、Challengeを待つことなくワンタイム パスワード（あるいは同時にパスワード）を即認証します。 GlobalProtectはこれらのワークフローをサポートします。  Duoによる2つのワークフローを行うRADIUS設定のサンプルはこちらです。   Always-OnモードでのOTPベース認証が必要な場合 - こちらを参照   On-DemandモードでのOTPベース認証が必要な場合   GlobalProtectをOn-Demandモードで展開している場合、ユーザーは手動で必要に応じてGlobalProgtectに接続します。このモードは一般的な安全なリモート アクセスのユース ケースで、リモートのユーザーは社内データ センターのリソースにアクセスするためにVPNトンネルをセットアップし、内部のデータ センターへのアクセスが必要なくなったときにはVPNを切断します。   ユース ケース1： RADIUSを使用したOn-DemandモードでOTPを使用する   On-Demandによる接続では、GlobalProtectエージェントは、ユーザーがGlobalProtectへの接続を開始する毎に、常に最初にポータル、続いてゲートウェイを認証します。OTP認証がポータルとゲートウェイ両方に必要ということは、ユーザーが二回OTP認証を促されることを意味します（一回はポータル、続く一回はゲートウェイ）。しかし（PAN-OS 7.1およびGlobalProtect 3.1以降から）、ユーザーの認証の回数を最小化する認証オーバーライド機能を提供しています。認証オーバーライドの詳細は、Enhanced Two-Factor Authenticationをご覧ください。   推奨の設定： ポータルとゲートウェイ両方にOTP認証を必要とする。 ポータルにて、 ユーザー認証情報の保存を “Save Username Only” 認証オーバーライドの有効化と、"クッキーを生成して認証上書き"、"クッキーを受け入れて認証上書き"の両方の有効化。 Cookie有効期間を'N'時間に設定。'N'時間はユーザーが認証情報を再度入力を促されるまでの時間です。提供したいユーザー体験に基づいて決めてください。 ゲートウェイにて、 ユーザー認証情報の保存を “Save Username Only” 認証オーバーライドの有効化と、"クッキーを生成して認証上書き"、"クッキーを受け入れて認証上書き"の両方の有効化。 クッキーの暗号化/復号には、ポータルとゲートウェイで同じ証明書を使用するようにしてください。 注： 認証オーバーライドに使用する証明書を更新する必要ができたときに柔軟に対応するため、認証クッキーの暗号化と復号化に使用する証明書は専用のものとしてください。 Configuration on the Portal   Configuration on the Gateway   この設定にて、エンドユーザーがGlobalProtectに手動で接続するとき、エンドユーザーの体験は次のようになります。   ワーク フロー – 1 ワーク フロー – 2       ユース ケース2： SAMLを使用したOn-DemandモードでOTPを使用する   GlobalProtectは、PAN-OS 8.0とGlobalProtect 4.0からSAML認証をサポートします。SAMLを使用するとGlobalProtectエージェントはSAMP IdPからの認証ページを、Web/組み込みブラウザーで表示し、ユーザーを認証します。ブラウザが異なる（組み込みブラウザー）ため、 GlobalProtectの認証により得られたSAMLクッキーは、他のSAML有効化アプリケーションによるSSOには使用できません。逆もまた同様です。 GlobalProtect の認証により得られたSAMLクッキーは、再起動やログアウト後には残りません。 SAMLによるOTPを使用した場合、透過的な認証を行うために推奨される設定は次のようになります。 ポータルとゲートウェイの両方にSAML認証を使用します。 IdP設定により、SAMLクッキーの有効な期間を決定します。SAMLクッキーが継続し有効である限り、ユーザーからみてGlobalProtectへの透過的な認証になります。 Oktaを使用したGlobalProtectのSAML認証の設定方法はこちらをご覧ください。   GlobalProtect認証オーバーライドを用いて、再起動やログアウト後も透過的な認証を提供する   ポータルにて、 ユーザー認証情報の保存を “Save Username Only” 認証オーバーライドの有効化と、"クッキーを生成して認証上書き"、"クッキーを受け入れて認証上書き"の両方の有効化。 Cookie有効期間を'N'時間に設定。'N'時間はユーザーが認証情報を再度入力を促されるまでの時間です。提供したいユーザー体験に基づいて決めてください。 ゲートウェイにて、 ユーザー認証情報の保存を “Save Username Only” 認証オーバーライドの有効化と、"クッキーを生成して認証上書き"、"クッキーを受け入れて認証上書き"の両方の有効化。 クッキーの暗号化/復号には、ポータルとゲートウェイで同じ証明書を使用するようにしてください。 注： 認証オーバーライドに使用する証明書を更新する必要ができたときに柔軟に対応するため、認証クッキーの暗号化と復号化に使用する証明書は専用のものとしてください。   GlobalProtect Always-OnモードでのOTP認証の推奨については、このシリーズのこちらの次記事を参照してください。   設定例   2つのワーク フロー実現のためのDuoによるサンプル設定です。 DuoによるOTP認証を提供する方法の詳細については、こちらをご覧ください。   ワーク フロー1： ユーザーはユーザー名とパスワードを最初に入力し、その後にOTPによりChallengeが行われます。OTPは承認のプッシュ、SMS、トークンコードのいずれかを使用します。   [ad_client] host=<AD-Server> service_account_username=<administrator> service_account_password=<administrator’s password> search_dn=DC=acme,DC=com   [duo_only_client] [radius_server_challenge] ikey=<duo-integration-key> skey=<duo-security-key> api_host=<duo-host-name> radius_ip_1=<firewall-mgmt-ip> radius_secret_1=<radius-secret> client=ad_client failmode=safe port=1812

※この記事は以下の記事の日本語訳です。 Using the "admin" user account on VM-series running on Azure public cloud https://live.paloaltonetworks.com/t5/AWS-Azure-Articles/Using-the-quot-admin-quot-user-account-on-VM-series-running-on/ta-p/209368   問題   Azure cloud上で動作しているVM-seriesの「admin」ユーザーアカウントにログオンできない。   解決方法   Azure marketplaceからVM シリーズのファイアウォールを起動する場合、「admin」ユーザー アカウントにはデフォルト パスワードが設定されていません。「admin」ユーザー アカウントを使用したい場合は、まずVM-seriesを初回起動した時に設定したsuperuser アカウントにログオンし、そのあと「admin」ユーザー アカウントのパスワードを変更する必要があります。  

※この記事は以下の記事の日本語訳です。 Controlling Skype using App-ID https://live.paloaltonetworks.com/t5/Learning-Articles/Controlling-Skype-using-App-ID/ta-p/149689   Skypeとは?     Skype （スカイプ）はよく知られているインターネット電話サービスで、 Niklas Zennstrm と Janus Friis によって開発されました。ピア・ツー・ピアのファイル共有ソフト Kazaa と新しいピア・ツー・ピアのテレビ アプリケーション Joost の創業者でもあります。 Skype は、従来の POTS から VoIP サービスまで、既存の電話サービスと競い合います。強みとしては、ファイアウォールや NAT 変換を介して接続性を提供でき、多くのアクティブ ユーザーをサポートし、強力な暗号化技術によりプライバシーを保護しています。さらに、インスタント メッセージ、チャット、ファイル転送、ビデオ会議、グローバル ディレクトリーなどをサポートしています。   スカイプの基礎となる技術は、分散型 ピア・ツー・ピア  アーキテクチャを利用して、マルチメディア パケットを中央サーバ型ではなくユーザ間でやりとりします。 ピア・ツー・ピア  ネットワークは接続性とスケーラビリティを向上させると同時に、ファイアウォール トラバーサルや、ダイナミック ルーティングによって、会社に設置されたファイアウォールを回避します。独自のプロトコルに基づくクローズド ソース アプリケーションであるにもかかわらず、Skype の独自でかつ回避的な動作は、特に、可視性や制御なしにファイルや情報を転送する能力を備えているため、エンタープライズ ネットワークにとってセキュリティ上の課題となっています。詳しくは以下の URL をご参照ください。 - https://www.skype.com/en/about/   Skypeをネットワーク上で許可するには、以下のApp-IDをパロアルトネットワークス・ファイアウォールで許可する必要があります。   office365-consumer-access rtcp rtp skype skype-probe ssl websocket stun web-browsing windows-azure-base apple-push-notifications   Policies > Security にて以下のスクリーンショットの例にあるように、Skypeを許可するためのセキュリティ ポリシーを追加します。     Skype For Business:   最小設定では、以下のApp-IDを、Skype For Businessが正しく動作するために許可する必要があります。   Ms-lync-base (matches the core functionality of the application) ms-lync-online rtcp stun (for media negotiation) rtp (for media streaming) ms-office365-base (core functionality of O365 applications) ssl web-browsing ms-lync-audio/video   クライアント端末では、固定の証明書を使用しており、 Skype For Business でも、「 *.online.lync.com 」や「 *.infra.lync.com 」を例外リストに追記し（ Device > Certificate Management の SSL 復号化例外より）、復号化の除外すべきです。     著者: vsathiamoo 

※この記事は以下の記事の日本語訳です。 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

※この記事は以下の記事の日本語訳です。 What is the Default Login Credential? https://live.paloaltonetworks.com/t5/Management-Articles/What-is-the-Default-Login-Credential/ta-p/56871   初期設定（ファクトリーデフォルト直後）のPalo Alto Networks装置のログインユーザーIDとパスワードは（WebGUI、CLI共通）:   Username:  admin Password:   admin   著者: jnguyen

※この記事は以下の記事の日本語訳です。 How Can IP Overlaps be Prevented with GlobalProtect https://live.paloaltonetworks.com/t5/Configuration-Articles/How-Can-IP-Overlaps-be-Prevented-with-GlobalProtect/ta-p/54406     問題 リモートのユーザーが社内ネットワークにGlobalProtectで接続する際、コンピューターにはゲートウェイに設定されたプールからIPアドレスが割り当てられます。このIPアドレスが該当するワークステーションが既にいるサブネットと重複している場合、問題が発生しえます。   例：リモートの従業員がホテルの部屋から、10.0.0.0/8のレンジでローカルに割り当てられたIPアドレスを用いて接続しています。GlobalProtectクライアントが利用できるIPプールは10.1.1.0/24です。これはIPプールがローカルのサブネットに包含されるため、問題が発生するでしょう。 この場合、 "Assign Private IP address failed"のエラーがファイアウォールのシステムログに生成されます。   解決方法 推奨される解決方法は異なるサブネットの新しいIPプールを作成し、新しいプールをリストの下に配置することです。IP プールは上から使用されますが、もしクライアントのサブネットが最初のIP プールと衝突する場合は、ファイアウォールは自動的に2つ目のプールからIPアドレスをアサインします。   著者: tpiens

※この記事は以下の記事の日本語訳です。 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  

※この記事は以下の記事の日本語訳です。 Useful CLI Commands to Troubleshoot LDAP Connection https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-Agentless-User-ID/ta-p/...   概要 このドキュメントでは、グループ情報を参照するために LDAP サーバーへの接続が成功したことを確認することができる CLI コマンドについて説明します。   詳細 Device > サーバー プロファイル > LDAP にて LDAP サーバー プロファイルを設定する際、LDAP サーバーへの接続が成功するとデバイスは自動的にベース DN を取得します：   グループ マッピングに LDAP サーバー プロファイルを使用している場合は、show user group-mapping state all コマンドを使用して LDAP 接続に関する情報を表示できます。 例： > show user group-mapping state all Group Mapping (vsys1, type: active-directory) : grp_mapping   Bind DN    : pantac2003\adminatrator   Base       : DC=pantac2003,DC=com   Group Filter: (None)   User Filter: (None)   Servers    : configured 1 servers           10.46.48.101 (389)                   Last Action Time: 2290 secs ago(took 71 secs)                   Next Action Time: In 1310 secs   Number of Groups: 121   cn=administrators,cn=builtin,dc=pantac2003,dc=com   cn=ras and ias servers,cn=users,dc=pantac2003,dc=com   cn=s,cn=users,dc=pantac2003,dc=com   LDAP サーバー プロファイルで設定されたバインド DN が正しくない場合は、コマンド実行結果として "invalid credentials" が表示されます。 次の出力例は、バインド DN に "cn=Administrator12" （正："cn=Administrator"）が設定された場合となります： > show user group-mapping state all Group Mapping (vsys1, type: active-directory) : grp_mapping   Bind DN    : CN=Administrator12,CN=Users,DC=pantac2003,DC=com   Base       : DC=pantac2003,DC=com   Group Filter: (None)   User Filter: (None)   Servers    : configured 1 servers           10.46.48.101 (389)                   Last Action Time: 0 secs ago(took 0 secs)                   Next Action Time: In 60 secs                    Last LDAP error: Invalid credentials   Number of Groups: 0   次のコマンドを使用して useridd ログからエラー メッセージを取り出すことができます： > less mp-log useridd.log Dec 30 15:59:07 connecting to ldap://[10.46.48.101]:389 ... Dec 30 15:59:07 Error: pan_ldap_bind_simple(pan_ldap.c:466): ldap_sasl_bind result return(49) : Invalid credentials Dec 30 15:59:07 Error: pan_ldap_ctrl_connect(pan_ldap_ctrl.c:832): pan_ldap_bind()  failed Dec 30 15:59:07 Error: pan_gm_data_connect_ctrl(pan_group_mapping.c:994): pan_ldap_ctrl_connect(grp_mapping, 10.46.48.101:389) failed Dec 30 15:59:07 Error: pan_gm_data_connect_ctrl(pan_group_mapping.c:1061): ldap cfg grp_mapping failed connecting to server 10.46.48.101 index 0 Dec 30 15:59:07 Error: pan_gm_data_ldap_proc(pan_group_mapping.c:1942): pan_gm_data_connect_ctrl() failed Dec 30 15:59:14 Warning: pan_ldap_ctrl_construct_groups(pan_ldap_ctrl.c:546): search aborted Dec 30 15:59:16 Error: pan_ldap_ctrl_query_group_membership(pan_ldap_ctrl.c:2384): pan_ldap_ctrl_construct_groups() failed Dec 30 15:59:16 Error: pan_gm_data_update(pan_group_mapping.c:1431): pan_ldap_ctrl_query_group_membership()  failed Dec 30 15:59:16 Error: pan_gm_data_ldap_proc(pan_group_mapping.c:1976): pan_gm_data_update() failed Dec 30 16:00:07 connecting to ldap://[10.46.48.101]:389 ... Dec 30 16:00:07 Error: pan_ldap_bind_simple(pan_ldap.c:466): ldap_sasl_bind result return(49) : Invalid credentials Dec 30 16:00:07 Error: pan_ldap_ctrl_connect(pan_ldap_ctrl.c:832): pan_ldap_bind()  failed Dec 30 16:00:07 Error: pan_gm_data_connect_ctrl(pan_group_mapping.c:994): pan_ldap_ctrl_connect(grp_mapping, 10.46.48.101:389) failed   LDAP サーバーへの接続を再確立するコマンド： > debug user-id reset group-mapping <grp_mapping_name>   useridd ログの LDAP に関する debug レベルを変更するコマンド： > debug user-id set ldap all   useridd の debug をオンに変更するコマンド： > debug user-id on debug   useridd の debug をオフに変更するコマンド： > debug user-id off   MGT インターフェイスを使用して LDAP サーバーと通信している場合に、LDAP 通信をキャプチャするコマンド： > tcpdump filter "port 389"   MGT インターフェイスを使用して LDAP サーバーと通信している場合に、LDAPS (SSL) 通信をキャプチャするコマンド： > tcpdump filter "port 636"   MGT インターフェイスで取得した pcap の内容を確認するコマンド： > view-pcap mgmt-pcap mgmt.pcap   上記で取得した pcap を scp や tftp で外部のホストにエクスポートするコマンド： > scp export mgmt-pcap from mgmt.pcap to username@host:path > tftp export mgmt-pcap from mgmt.pcap to <tftp host>   著者： sdarapuneni

  ※この記事は以下の記事の日本語訳です。 User Identification through TSA not working for HTTP https://live.paloaltonetworks.com/t5/Management-Articles/User-Identification-through-TSA-not-working-for-HTTP/ta-p/62949   問題 ターミナルサーバーエージェント(TSA) の ip-user-port マッピングが、http トラフィックにおいて正しく実施されません。（事象が報告された環境では）80以上のCitrixサーバーが構成されており、すべてがパロアルトネットワークスのターミナルサービスエージェントを実行しています。 ユーザーが PC で https サイトを閲覧すると、トラフィックは Citrix サーバーに送信され、ip-port-user-mapping は正しく（TSAで設定された範囲内で）https トラフィックが許可されます。 ユーザーが同じマシンと同じブラウザー（Internet Explorer）から http サイトを閲覧すると、トラフィックは Citrix サーバーに送信されますが、誤った送信元ポートが割り当てられてしまいます（TSAで割り当てられた範囲外のポート）。送信元ポートが正しくないためなので、誤った ip-port-user-mapping が原因でファイアウォールによってトラフィックが拒否されます。   原因 Citrix ターミナルサーバーに TrendMicro 製品がインストールされている場合、TrendMicro プロキシ機能によって問題が発生している可能性が考えられます。   解決方法 この問題を解決するには、TrendMicro プロキシ機能、またはすべての TrendMicro サービスを無効にします。 （※日本語訳者注：この問題は、同様のプロキシ機能を持つ 他製品/ソフトウェア の場合にも発生する可能性が考えられます。）   owner:  tpiens

※この記事は以下の記事の日本語訳です。 Zone Protection Recommendations https://live.paloaltonetworks.com/t5/Learning-Articles/Zone-Protection-Recommendations/ta-p/55850     以下の記事は、Palo Alto NetworksのエンジニアであるGraham Garrisonによって執筆されました。   PAN-OSを実行しているPalo Alto Networksデバイスは、ユーザーやネットワーク、クリティカルなシステムを守るために、App-IDやUser-IDのような数々の次世代ファイアウォールの機能を提供しています。これらの強力な技術に加え、PAN-OSはネットワーク及びトランスポートレイヤーでの悪意ある活動に対して、ゾーン プロテクション プロファイルを使用した防御も提供します。セキュリティ ゾーンに対してこれらのプロファイルを適用は、フラッド攻撃や偵察行為、その他のパケット ベースの攻撃への防御の一助となります。   ゾーン プロテクションを設定する際、それがシステムによりどのように適用されるのかを理解することや、パケット処理のどのステージで適用されるのかを理解することが重要です。ゾーン プロテクションは常に入力インターフェイスに適用されるため、インターネットからのフラッド攻撃や偵察行為から防御したい場合、信頼されないインターネットのインターフェイスを含むゾーンに対してプロファイルを設定して適用します。ネットワークをより強化したいと思われるセキュリティの管理者は、防御する手段がすべての環境に適用されていることを確実にするために、さらに内外両方のすべてのインターフェイスに対してゾーン プロテクションを適用することができます。このタイプのゼロ トラスト アプローチは、企業におけるモビリティが増大し続ける中で、ますます推奨されるようになってきました。   また各ネットワーク環境は各々異なり、それゆえ防御措置を適用するにあたってフラッドの閾値を調整する必要があることへの理解も重要です。設定されたフラッドの閾値を超えた場合は脅威ログが生成され、Syslogを使用している場合は外部に転送することができます。ご利用の環境においてどのような設定が適切かを決めるために、ベースラインを確立するためのピーク時間中の平均的なネットワークの稼働状態を決めることから始めてください。そして、ネットワークの稼働状態に通常の範囲の変動の余地を残しつつ、セキュリティの目標を満たすポイントに達するまで、閾値を徐々に下げて調整してます。正当なトラフィックを通すために防御を有効化したり最大の閾値が低くなりすぎるのを避けたいでしょうが、望まないトラフィック量のスパイクを緩和に効果的になるように高すぎるのも避けたいはずです。   その一方で、いくつかのパケット ベースの攻撃保護は、組織全体に多少は等しく適用されます。例えば、「不明」や「異常な形式」のIPオプションは一般的に不要であり、ドロップできます。「重複するTCPセグメントの不一致」や「TCP タイムスタンプの削除」をドロップするためにオプションの選択は、ファイアウォールを通過する回避技術を防ぎ、一般的にすべてのお客様に推奨されます。さらに、「スプーフされたIPアドレス」に対する防御を有効にすることで、セキュリティ ゾーンにおけるアドレス詐称を防ぐことができます。このことが、パケット入力においてファイアウォールのルーティング テーブルに合致する送信元アドレスを持つトラフィックだけ許可されることを確実にします。   上記の推奨事項の従うことで、所属する組織をより安全にすることとなります。その他の有益な秘訣やコツについては、Live Communityを継続して閲覧の上、確認するようにしてください。   追加資料： Threat Prevention Deployment Tech Note Understanding DoS Protection What Are The Differences Between Dos Protection and Zone Protection?     著者：Graham Garrison

※この記事は以下の記事の日本語訳です。 Slow or Failed Commits https://live.paloaltonetworks.com/t5/Management-Articles/Slow-or-Failed-Commits/ta-p/61172     問題 時折、コミットが遅くなったり、完全に失敗することがあります。以下の" devsrv.log"の例では、"pan_util.c"のコールが"devsrv"への接続に失敗し、"phase1"処理に合流していないことを意味します。 2181 root 20 0 975m 11m 1468 S 2 1.2 196:53.46 cryptod 9620 root 20 0 798m 127m 39m S 2 12.9 97:40.63 devsrvr 1 root 20 0 1832 560 532 S 0 0.1 0:12.83 init mp\devsrv.log 10-17 17:20:15 Error: pan_util_connect_server(pan_util.c:1776): Failed to connect to server: Connection refused mp\devsrv.log 10-17 17:20:15 Error: pan_util_connect_server(pan_util.c:1776): Failed to connect to server: Connection refused mp\devsrv.log 10-17 17:20:15 Error: pan_util_connect_server(pan_util.c:1776): Failed to connect to server: Connection refused mp\devsrv.log 10-17 17:20:21 Error: pan_util_connect_server(pan_util.c:1776): Failed to connect to server: Connection refused mp\devsrv.log 10-17 17:20:21 Error: pan_util_connect_server(pan_util.c:1776): Failed to connect to server: Connection refused mp\devsrv.log 10-17 17:20:21 Error: pan_util_connect_server(pan_util.c:1776): Failed to connect to server: Connection refused mp\devsrv.log 10-17 17:20:23 SIGTERM triggered mp\devsrv.log 10-17 17:20:23 DEVSRV: connection to MS terminated mp\devsrv.log 10-17 17:21:00 BrightCloud URL engine startup... mp\devsrv.log 10-17 17:21:01 pan_shmgr_merge_with_peer(runtime.user-idmgr) begin mp\devsrv.log 10-17 17:21:35 BrightCloud URL filtering engine started mp\devsrv.log 10-17 17:22:05 Config commit phase1 started   解決方法 以下のコマンドを使用して、"devsrvr"プロセスによって使用されているメモリの使用量の多さを確認します： > show system resources | match devsr 2672       20   0  172m  67m  13m S    0  1.7   7:00.84 devsrvr   必要に応じて、以下のコマンドを使用してdevice serverを再起動します： > debug software restart device-server プロセスが再起動した後、"phase1"が伝えられると、コミットを完了することができます。   注："devsrvr"プロセスは、管理プレーン上で実行されており、データ プレーンに設定を流すことについては注意が必要です。該当のプロセスは、URLフィルタリングの要求や応答のような、管理プレーンとデータ プレーン間のいくつかの通信も担当しています。     著者：rkalugdan

※この記事は以下の記事の日本語訳です。 How to Restart the "mgmtsrvr" Process https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Restart-the-quot-mgmtsrvr-quot-Process/ta-p/63119     問題 WebGUIの応答が遅い、あるいは反応がない。 管理者アカウントが、すでにログアウトしている状態なのに、ログインしていると表示されている。 ライセンスの認証コードは入力されているが、ライセンスを有効化したり更新できたりしない。 WebGUIにてログが表示されない。 " show system resources"コマンドの出力結果は、" mgmtsrvr"プロセスが、異常にメモリを消費していることを示している。     Resolution これらの問題を解決するには、Management serverのプロセス"mgmtsrvr"の再起動を推奨します。 以下の手順に従い、Managment serverのプロセスを再起動してください。   CLIでコマンドを入力します: PAN-OS 5.0, 6.0, 6.1, 7.0 > debug software restart management -server   PAN-OS 7.1 > debug software restart  process  management -server 注： これにより"mgmtsrvr"プロセスが再起動します。ログインしている管理者がいる場合、WebGUIとCLIから切断されます。 数分後にWebGUI、あるいはCLIに、再度ログインします。 Management serverのプロセス以下をチェックするために、以下のCLIコマンドを実行します。 > s how system resources | match mgmtsrvr このコマンドの出力結果は、"mgmtsrvr"プロセスは、再起動前に比べてほとんどメモリを消費していないことを示すでしょう。WebGUIも正しく機能しているはずです。 > show system resources | match mgmt       2140       20   0  708m 484m 9828 S    2 12.9   8:13.06 mgmtsrvr   著者：jdavis  

※この記事は以下の記事の日本語訳です。 Unable to Connect to or Ping a Firewall Interface https://live.paloaltonetworks.com/t5/Management-Articles/Unable-to-Connect-to-or-Ping-a-Firewall-Interface/ta-p/62505     問題 あるサービスを利用するために、ファイアウォールのインターフェイスのIPアドレスに接続しようとした際に、あるいはそのインターフェイスにPingしようとした際に、その通信が失敗してしまう。HTTPSやSSHでデバイスを管理しようとしたり、GlobalProtect ポータルやNetConnect webポータルに接続しようとしたり、あるいは単にインターフェイスにPingしようとしているだけでも起きる可能性があります。   解決方法 インターフェイスが必要なサービスを有効にしたり、接続元からのIPアドレスを許可する適切な管理プロファイルを持っていることを確認します。 管理プロファイルが疑われる場合、以下の"counter"コマンドを実行し、"counter"の増加を確認します： > show counter global name flow_host_service_deny トラフィック ログを確認することにより、インターフェイスに向かうトラフィックをブロックしているセキュリティ ポリシーがないことを確認します。宛先アドレスにファイアウォールのインターフェイスのIPアドレスとなるようにフィルタ対象となるように設定をします。一般的に、セキュリティ ポリシーは接続をブロックしませんが、ブロックしてしまう可能性はあります。 パケットが到達するインターフェイスが、開始パケットがファイアウォールに入っていくインターフェイスと異なり、それら2つのインターフェイスが異なるゾーンにある場合、それはインター ゾーン（ゾーン間）のセッションだと考えられるため、そのセッションを許可するセキュリティ ポリシーが必要です。 パケットが到達するインターフェイスが、開始パケットがファイアウォールに入っていくインターフェイスと同じ場合、それはイントラ ゾーンのセッションだと考えられ、イントラ ゾーン（ゾーン内）のセッションはデフォルトで許可されているので、セキュリティ ポリシーは必要ありません。しかし、明示的に定義された"deny any to any zone"のセキュリティ ポリシーがあると、デフォルトの許可を上書きしてしまいます。そのため、ファイアウォールのインターフェイスに対して初期化セッションを許可する、より明確なポリシーを保持する必要があります。 注：インターフェイスのセッションのログが何も観測されていない場合、デフォルトのアクションがインター ゾーンやイントラ ゾーンのセッションで取られている時、拒否、許可のどちらについても、トラフィック ログは生成されない動作によることが考えられます。 問題がまだ解決できない場合は別の可能性として、送信元NATで開始パケットの送信元アドレスを、パケットが到達するインターフェイスのアドレスへ変換していることが考えられます。これはファイアウォールに、パケット処理の早い段階でのパケットのドロップを引き起こします。なぜならアドレス変換後にそのパケットは、送信元と宛先が同じとなるLAND攻撃のように見えてしまうからです。 これは外部インターフェイスと検証機が内部ネットワークにあり、GlobalProtectポータルへの接続を検証している時によく見られる振る舞いです。開始パケットは外部ゾーンにアクセスするための送信元NATによって外部インターフェイスに変換されてしまいます。 ログ プロセスの前にこの仕組みが動き出すため、この場合はトラフィックのログは何も見られません。 以下のコマンドを入力して、これが問題なのかどうかを確認するためにカウンタの増加分を確認します： > show counter global name flow_policy_nat_land この問題を解決するために、原因となるNATポリシーのクローンを作成し、[送信元アドレスの変換]を"none"に変更し、[宛先アドレス]を該当のインターフェイスのIPアドレスに変更します。そして問題のNATポリシーの直上に新しいポリシーを置きます。この措置により、宛先が該当インターフェイスの場合のみ、新しいNATポリシーが適用されます。 NATポリシーによって引き起こされる別の問題は、宛先NATが、サーバーのアドレスに向かう該当のインターフェイスのアドレスを宛先アドレスを持つパケットを、変換する場合です。一般的にこの宛先NATは、外部インターフェイスのパブリックなIPアドレスを含みます。この問題を引き起こす可能性のあるNATの設定は2つ考えられます。 宛先NATをすべてのサービスのために設定している場合、該当するインターフェイスの宛先アドレスを持ちNATポリシーに該当するパケットはすべて変換されます。たとえその意図がリモート ホストではなく、該当インターフェイスにパケットを到達させるためであったとしてもです。以下の方法で、この問題を解決できる可能性があります： サーバーが特定のサービス、あるいはファイアウォールのインターフェイスに届く必要のあるポートとは異なるポートを使用する場合、必要なサービスだけを変換してサーバーへ転送するために、NATポリシーの適用範囲を狭くします。 その宛先NAT用に特定のサービスが指定して、それらのサービスの宛先ポートに合致するパケットだけが宛先変換されますが、443番ポートの変換を例として挙げると、宛先NATポリシーに合致するパケットであるからといって、ファイアウォールのインターフェイスの443番ポートへ接続されることはありません。以下の方法で、この問題を解決できる可能性があります： 利用可能なアドレスがある場合、別のアドレスをファイアウォールのインターフェイスに追加します。同じサブネット内にアドレスを追加する場合、そのサブネット マスクは"/32"である必要があります。 ファイアウォールのインターフェイスのアドレスは変更するか、サーバーのアドレスを変更するべきです。 上記の選択肢のどちらも相応しいアクションでない場合、問題は、サービスが提供されるために十分なパブリックなアドレスを持っていないことである可能性があります。より手の掛かる解決策ではありますが、パブリックなアドレスを追加で入手する必要があるかもしれないということです。 上記の解決方法でも問題を解決できない場合、通信を開始するコンピュータとファイアウォールのインターフェイス間において、ネットワーク上のルートを確認する価値は大いにあります。他のコンピュータがファイアウォールに接続できるかどうかを確認します。必要に応じて、開始パケットがファイアウォールに届いているかどうかを確認するために、ファイアウォール上でパケット キャプチャをします。   Trustゾーンのホストが、外部インターフェイスのIPアドレスへの接続を防ぐ送信元NATの例： インターネットからの外部インターフェイスのIPアドレスへのすべての接続を防ぐ宛先NATの例：   注：この解決方法は、ファイアウォールの管理インターフェイスには適用されません。     著者：astanton

※この記事は以下の記事の日本語訳です。 Using Packet Filtering through the WebGUI https://live.paloaltonetworks.com/t5/Management-Articles/Using-Packet-Filtering-through-the-WebGUI/ta-p/56363     訳注：本文書で紹介する機能はPAN-OS：5.0以降で対応しています。   概要 この資料は、WebGUIを利用したPCAPについて詳述しています。ここでは、GUIを利用したフィルターの設定方法を扱っており、パケットのキャプチャ方法や、どのパケットがどのステージへ向かうのかを決める方法について説明しています。   いつパケットをキャプチャを必要があるのか? ネットワーク トラフィックを分析する際にパケットキャプチャを行います。PAN-OSは、3種類のパケット キャプチャに対応しています： フィルター PCAP／デバッグ フィルター 送信元／宛先IPアドレス、および送信元／宛先ポートに基づいてパケットをキャプチャするため。 アプリケーション PCAP 特定のApp-IDのパケットをキャプチャするため (特にApp-IDが該当のアプリケーションを検出せず、アプリケーション欄に"incomplete"と表示されている状況）。 "Incomplete"とは、TCP 3ウェイ ハンド シェイクが完了していないということを意味しています。Palo Alto Networksファイアウォールは、クライアントからのSYNパケットの確認はしたが、サーバーからSYN-ACKを得ることはなかった、ということです。それには、2つの理由が考えられます： サーバーは、SYN-ACKの返答を一度もしなかった。これは、サーバーに問題があるということを意味しています。 サーバーは、SYN-ACKを返答したが、SYN-ACKが異なるルートを通ったため、Palo Alto Networksデバイスを通過しなかった (非対象ルーティングとも呼ばれます)。 この問題を解決するためには、フィルターとキャプチャを設定して、Palo Alto NetworksデバイスがSYN-ACKを確認しているかを判断する必要があります。 Unknown PCAP "unknown-tcp"や"unknown-udp"、"unknown-p2p"のパケットをキャプチャするため。 Palo Alto Networksデバイスが、App-IDを使用してアプリケーションを特定できない場合、パケットは、"unknown-tcp"、"unknown-udp"または"unknown-p2p"に分類されます。 キャプチャしたファイルはハード ディスク上に保存されます。ファイアウォールは、PCAPをログ毎に20MBずつ保存し、1時間ごとにディスクの空き容量を確認しています。ディスクの使用量が90％を超えた場合、パケット キャプチャは、90％以下になるまで、古いものから順番に削除されていきます。 注：ファイルのサイズを制限するために、オフ ピーク時にトラフィックをキャプチャすることの考慮が必要となる場合があります。   キャプチャする前にフィルターを設定することが重要である理由 フィルターに合致するパケットだけがキャプチャされるように、フィルターを定義します。パフォーマンスの低下を最小限に抑えたり、他の不要なデータがキャプチャされないことを保証するために、キャプチャを有効にする前に、フィルターを定義することが重要です。同様に、PCAPを取得後は、フィルターを解除する前にキャプチャを無効にすることが重要です。 そのようにしないと送信元IPアドレスだけをフィルターする代わりに、すべてのトラフィックがフィルターの対象となり、 Palo Alto Networksファイアウォールのパフォーマンスが低下することになります。     フィルターとキャプチャを設定するためのステップ バイ ステップ ガイド   WebGUIを利用したPCAP フィルタリング [ Monitor ] > [ パケット キャプチャ ] を選択します： フィルターを設定する前に、以前の設定が不要である場合、「すべての設定をクリア」を選択して、すべてのPCAP設定を削除します。 最初にフィルターを設定する方がより安全です。それにより、フィルターに合致するパケットだけをキャプチャすることができます。フィルターを設定するために、「フィルタの管理」を選択し、「追加」をクリックして新しいフィルターを設定します。 以下の情報を指定します： ID：フィルターを識別するためのIDを入力します。 入力インターフェイス：ファイアウォールのインターフェイスを入力します。 送信元：送信元IPアドレスを入力します。 宛先：宛先IPアドレスを入力します。 送信元ポート：送信元ポートを入力します。 宛先ポート：宛先ポートを入力します。 非 IP：非 IPトラフィックを扱うためのオプションを1つ選択します。 None：IPフィルターを使用しない。 Exclude Include Only：IPだけを含めるフィルター。 IPv6：IPv6パケットを含めるには、チェックボックスにチェックを入れます。 フィルタリングと事前解析一致を有効にします： 注：事前解析一致は、高度なトラブルシューティングのためのものです。あるパケットが入力インターフェイスに入ってきた際に、何らかの失敗によりそのパケットはフィルタリングのステージまで到達しないことがあります。しかし、この設定を有効にすることで、ファイアウォールはフィルタリングのステージに到達しないパケットもキャプチャします。   キャプチャ キャプチャを有効にする前に、以下のステージを設定します： 「追加」をクリックして、キャプチャされるパケットのステージを設定します。パケットは、以下の4つのステージでキャプチャされます： Drop：エラーが原因で、Palo Alto Networksデバイスによってドロップされたパケットが、Dropステージに入ります。 Firewall：Palo Alto Networksデバイスが、パケットを処理している時のパケットのステージです (キャプチャされたパケットは、ポリシーやIPS機能などを通過していきます)。 Receive：Palo Alto Networksデバイスによって受信されたパケットは、このステージでキャプチャされます。 Transmit：送信元から送出されるパケットは、(Firewallステージ後に) このステージでキャプチャされます。 パケット キャプチャを有効にします。ダイアログが表示されますので、OKをクリックします。 注：特定のトラフィックのパケットだけがキャプチャされるように、キャプチャを有効にする前に、フィルターが有効になっていることを確認します。そうでない場合、作成されたすべての新しいセッションがキャプチャされてしまい、データ プレーンのパフォーマンスを著しく低下させることになります。 パケットをキャプチャするために、送信元からのトラフィックを生成します。 画面を更新して、PCAPファイルがキャプチャされたかどうかを確認します。 パケット キャプチャ画面の右側にPCAPファイルが表示された後、キャプチャとフィルターを無効にします。 注：フィルターを無効にする前に、キャプチャを無効にすることが重要です。さもないと、すべてのトラフィックがフィルターの対象となり、ファイアウォールのパフォーマンスを低下させてしまうことになります。   すべての設定は以下の「すべての設定をクリア」を使用することで削除することができます：   シナリオ例 "10.1.1.1"を使用している端末からのトラフィックをキャプチャします。 送信元が"10.1.1.1"であるフィルターを設定します。 4つのキャプチャ ステージを設定し、各ステージに対して個々にファイル名を付けます (Receive、Firewall、Transmit、Drop)。 フィルタリングと事前解析一致を有効にします。 キャプチャを有効にします。 パケット キャプチャを有効にすると、ファイアウォールのパフォーマンスに影響を与えるという旨のリマインダーとして、警告が表示されます。 必要なトラフィックを生成します。 更新アイコンをクリックします。 PCAPファイルが表示されます。最初にキャプチャを無効にし、次にフィルタリングを無効にします。 4つのキャプチャしたファイル (各ステージにつき1つ) をダウンロードし、Wiresharkを使用して開きます。 注：ステージに関連付けられたファイルは、トラフィックがキャプチャされた場合のみに作成されます。例えば、パケットが1つもドロップしない場合は、そのステージに関連付けられたファイルは何も作成されません。     著者：mvora

※この記事は以下の記事の日本語訳です。 GUI Error 'opaque: Failed to check content upgrade info due to generic communication error' https://live.paloaltonetworks.com/t5/Management-Articles/GUI-Error-opaque-Failed-to-check-content-upgrade-info-due-to/ta-p/60791     症状 日常的に、ファイアウォールは以下のエラーを報告します： opaque: Failed to check Content content upgrade info due to generic communication error   アップデート サーバーへの接続は確認されましたが、問題は何も見つかりませんでした。   問題 このエラーは、2つ、あるいはそれ以上のコンテンツのアップデートが、同時刻に実行されるように予定が組まれている場合に発生します (例：アンチウィルスやURLデータベース)。   解決方法 [ Device] > [ ダイナミック更新 ] 画面から、コンテンツのデータベース毎に予定を変更し、更新時間が同じか、あるいは近い時間にならないようにします。     著者：rvanderveken

※この記事は以下の記事の日本語訳です。 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

※この記事は以下の記事の日本語訳です。 How to Configure a DHCP Relay on Palo Alto Networks Firewall  https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-a-DHCP-Relay-on-Palo-Alto-Networks-Firewall/ta-p/59544     概要 この資料では、Palo Alto Networksファイアウォールにおける、DHCPリレーを設定する手順を記載しています。下記図のシナリオを例に、設定を手順を説明します。 手順 DHCPリレーをするインターフェイスを設定します (例：Trust E1/5) ： Web UI画面から[ Network ] > [ DHCP ] > [ DHCP リレー ]を開きます。 追加をクリックし、DHCPサーバーのIPアドレスを設定します。 注：DHCPサーバーのIPアドレスは、4つまで設定することができます。 ゾーン間のDHCPトラフィックを許可するために、セキュリティ ルールを設定します： Trust to Trust - クライアント用の、DHCPリレー インターフェイスへの／からの通信 (ブロードキャスト／ユニキャスト) Trust to DMZ - DHCPリレー インターフェイス用の、DHCPサーバーへの／からの通信 (ユニキャスト) 下記のダイアグラムは、典型的なDHCPセッションに基づいています。ダイアグラムは、DHCPリレー インターフェイスとDHCPサーバー間の通信はすべてユニキャストであることを表しています。 下記のスクリーンショットは、DHCPサーバー側における、DHCP動作例のパケットキャプチャです： 下記図は、設定されているセキュリティ ポリシーの例です： コミットをクリックして、設定を反映させます。   動作確認 クライアント上での動作確認を行います。例えば、Windowsクライアントにて以下を実行します： ipconfig /release ipconfig /renew ipconfig /all 注：DHCPサーバーは、この設定が動作するように、DHCPトラフィックをPalo Alto Networksファイアウォールへルーティングする必要があります。 DHCPサーバーがPalo Alto Networksファイアウォールの代わりに他のデフォルト ゲートウェイを持っている（あるいは、DHCPサーバーが直接接続されておらず、どこかへ返信トラフィックをルーティングする）場合、問題が起きる可能性があります。その場合、DHCPトラフィックは非対照であると考えられます。DHCPサーバーのトラフィックが非対照である場合、セッションはファイアウォール上で正しく構築されず、完全なDHCP通信は完了することはありません。   著者：jlunario

※この記事は以下の記事の日本語訳です。 How to Designate Source Interface for the Ping Host Command https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Designate-Source-Interface-for-the-Ping-Host-Command/ta-p/55051   概要 送信元を明示せずに " ping host " コマンドを使用したとき、ファイアウォール自身 (データ プレーン) に設定されていないアドレスに送信する場合は、Palo Alto Networks デバイスはデフォルトで管理 (MGMT) インターフェイスを使用します。データプレーンアドレスへ送信する場合、送信元アドレスが明示的に指定されていないと、ping トラッフィクがファイアウォールの内部を通過します。この理由はデータプレーンに設定されたアドレスが、マネジメントプレーン カーネルに割り当てられているからです。したがって、" ping host <ip_dataplane> " コマンドが実行されたときは、基本的にマネジメントプレーン (MP) のカーネル上で ping します。 注: " debug dataplane internal vif address " コマンドは MP カーネルに割り当てられた全ての設定 IP アドレスを示します。   詳細 ping host コマンドの使用法: > ping host <not_ip_dataplane> - デフォルトで MGMT インターフェイスから送出されます > ping host <ip_dataplane>     - local ping のような動作 (MGMT インターフェイスから送出されません)   データプレーンのIPアドレスに対して MGMT インターフェイスから ping を送出したい場合は、"source" オプションを指定する必要があります: > ping source <mgmt_address> host <ip_data_plane>   例としてレイヤー3インターフェイスからpingを発信する場合のコマンドは以下となります: > ping source <x.x.x.x> host <y.y.y.y>     x.x.x.x はPalo Alto Networks デバイスのレイヤー3インターフェイス アドレスであり、 y.y.y.y は送信先 host です。   著者:  gbogojevic

※この記事は以下の記事の日本語訳です。 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

※この記事は以下の記事の日本語訳です。 How to Generate and Upload a Tech Support File Using the WebGUI and CLI https://live.paloaltonetworks.com/t5/Featured-Articles/How-to-Generate-and-Upload-a-Tech-Support-File-Using-the-WebGUI/ta-p/60757   概要 本ドキュメントでは、WebGUIもしくはCLIを使用した、tech support fileを作成方法/アップロード方法を説明しています。   手順 Tech Support Fileの作成  WebGUIを使用した場合: Device > Supportの順にクリックします。Panoramaの場合, Panorama > Supportの順にクリックします。 Tech Support Fileの下にあるGenerate Tech Support Fileをクリックします。 Note: Device Administratorの権限をもつユーザーでログインしていた場合、本機能は使用できません。Web UIからTech Support Fileを作成するには、Super Userの権限が必要です。 Tech Support Fileが作成されるまで待ちます。 注意: Tech Support Fileが最後に作成された時間が Web UIから確認することができます。 Download Tech Support Fileが表示されたら、Click Download Tech Support Fileをクリックし保存します。 Device > Support , showing you where to generate the Tech Support file from the WebGUI. CLIを使用した場合: SSHもしくはTelnetを使用して、Palo Alto Networks deviceに接続します。 注意: ファイルが保存できるTFTP/SCPサーバが必要となります。 Tech Support Fileを作成するために以下のコマンドを実行します。 > request tech-support dump 準備しているサーバに応じ、Tech Support Fileを保存するため、 以下のいずれかのコマンドを実行します。 > tftp export tech-support to <tftp host> > scp export tech-support to <username@host:path>   Tech Support File をアップロード 以下のいずれかの方法で、Palo Alto Networks support caseの調査用のTech Support fileをアップロードします。Tech Support fileをアップロードするためには、事前にケースオープンが必要です。   方法 1: Palo Alto Networks Support Portalを利用する場合  https://support.paloaltonetworks.comから、Palo Alto Networks Support Portalにログインします。 Case Managementをクリックします。 Palo Alto Networks Support Portal showing where the Case Management option is. case numberもしくはcase subjectをクリックします。注意: edit ボタンはクリックしないでください. Case Filesを表示させるため、画面を一番下までスクロールさせます。 Upload File(s)をクリックし、Tech Support Fileをアップロードします。 Upload file option inside of Support site.   方法 2: TAC Upload Service を利用する場合 tacupload.paloaltonetworks.com にアクセスします。 ケース番号とケースオープン時に利用した email addressを入力します。 ログインします。 .Tech Support File をChoose Fille から選択し、Upload ボタンでアップロードします。 注意: 一度に一つのファイルのみ選択/アップロードできます。 正常にファイルがアップロードされると, 自動送信されたメールにより通知がされます   方法 3: CLIでTAC Upload Server に直接アップロードする場合 SCP export tech-support to xxxxxxxx @ tacupload.paloaltonetworks.com:/   xxxxxxxxはケース番号になります。ケース番号には、最初に00が続きます。 例: 00654321@tacupload.paloaltonetworks.com:/   実行するには、ケースオープン時に利用したemail addressをパスワードとして入力する必要があります。     よく聞かれる質問:  'Tech support file' にはどういったデータが含まれるのでしょうか？装置に関わる設定ファイルはすべて含まれるのですか？PaloAltoサポートに提供することは安全なのでしょうか。   答え: Tech Support fileには、装置に関わる構成ファイル、システムに関わる情報、ログ等が含まれます。(Trafficログは含まれません。) PaloAltoサポートでは、提供された情報を安全に管理します。Tech Support fileは、サポートエンジニアがお客様の設定を理解する上で必要な情報で、調査を円滑に進めることを可能にするものです。すべての情報は安全に管理されます。

※この記事は以下の記事の日本語訳です。 How to View Currently Installed SFP Modules https://live.paloaltonetworks.com/t5/Management-Articles/How-to-View-Currently-Installed-SFP-Modules/ta-p/60908   概要 SFPとは小型で、活線挿抜（ホットスワップ）可能なテレコム用途、データ通信用途双方で使用可能な光トランシーバーです。PA-2000シリーズ、PA-3000シリーズ、PA-4000シリーズ、PA-5000シリーズはSFPモジュールに対応しています。この文書は現在インストールしているSFPモジュールの確認方法について記載します。   詳細 PAN-OS 4.1.x やPAN-OS 5.0ではCLIから以下のコマンドを実行します。 >show system state filter sys.sX.pY.phy 例えばinterface1/21に実装している場合、 X=slot=1、Y=port=21と指定します。 通常のSFPモジュールの出力結果例 sys.s1.p21.phy: { 'link-partner': { }, 'media': SFP-Plus-Fiber, 'sfp': { 'connec tor': LC, 'encoding': Reserved, 'identifier': SFP, 'transceiver': , 'vendor-name ': FINISAR CORP.   , 'vendor-part-number': FTLX8571D3BCL   , 'vendor-part-rev': A   , }, 'type': Ethernet, }   故障したSFPモジュールの出力結果例 以下の例に似た出力の場合、該当のSFPモジュールは故障している可能性があります。 sys.s1.p21.phy: { 'link-partner': { }, 'media': SFP-Fiber, 'sfp': { 'connec tor': vendor specific, 'encoding': Reserved, 'identifier': SFP, 'transceiver': , 'vendor-name ': yyyyyyyyyyyyyyyy, 'vendor-part-number': yyyyyyyyyyyyyyyy , 'vendor-part-rev': yyyy, }, 'type': Ethernet, }   注：故障が疑われる出力結果例の場合、一度該当のSFPモジュールを抜き取り、異なるSFPポートに挿してみると良いでしょう。同じ show system state filter コマンドを再度実行してください。出力が同じなら該当のモジュールは故障していると考えられます。   著者：gcapuno

※この記事は以下の記事の日本語訳です。 How to Configure a Palo Alto Networks Device for Tap Mode Operation https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-a-Palo-Alto-Networks-Device-for-Tap-Mode/ta-p/59438     [Network] タブ > [ゾーン] に移動します。タイプがタップの新しいゾーンを作成し、名前をつけます（例：tapzone、intranetzone、など）。     [Network] タブ > [インターフェイス] に移動します。該当のインターフェイスのタイプをタップに編集します。それから前述の手順1で設定したゾーンを割り当てます（下記の図ではethernet1/1を使用しています）。       [Policies] > [セキュリティ] に移動します。ルールを作成し、手順1で作成したゾーンを送信元ゾーンと宛先ゾーンとしたルールを作成します。  例： 名前 = TAP_Allow 送信元ゾーン = Tap_Zone 宛先ゾーン = Tap_Zone ルール: any any any any any アクション = 許可 任意で脅威プロファイル（アンチウイルス、スパイウェアなど）を作成し、作成したルールに割り当てます。   著者: jnguyen

※この記事は以下の記事の日本語訳です。 How to upgrade a High Availability (HA) pair https://live.paloaltonetworks.com/t5/Management-Articles/How-to-upgrade-a-High-Availability-HA-pair/ta-p/57081   概要   HAペアのPAN-OSをアップグレードするにあたって、この記事に書かれている手順を実行することを推奨します: アップグレード前にHA機能が正常に動作している事を確認できます。 ２番目の機体をアップグレードする前に一つ目の機体が正常にアップグレードされた事を確認できます。 手順のどの時点で、なんらかの事象が発生した場合、ダウンタイム無しでバージョンを元に戻す事ができます。 (OSPFやBGPなどのルーティングプロトコルを使用していない場合)。 HAペアのアップグレード完了した時点で必要最小限のfailover(二回)で元のアップグレード前のactive/passive状態に戻す事ができます。   アップグレードの準備:   Configurationのバックアップと Tech Supportファイルを HA Pair両方からダウンロードします。 個々のファイルに適切なファイル名をつけます。 Device > Setup > Operations > Save Named Configuration Snapshotをクリックしconfiguration snapshotの名前を設定し、保存します。 Device > Setup > Operations > Export Named configuration Snapshotをクリックし前のステップで設定したconfiguration snapshotをダウンロードします。 (HAペアがPanoramaで管理されている場合) Device > Setup > Operations > Export Device State をクリックし、Device stateをダウンロードします。 Device > Support > Generate Tech Support Fileをクリックし、生成された後ダウンロードします。 (アップグレード中なんらかの事象が発生した場合に必要になります) （オプショナルですが推奨）： アップグレード中、不必要なfailoverを避けるためHigh Availability 設定でPreemptionを無効にします。Preemption無効の設定はHA Pair 両方にcommitしてください. アップグレードの完了後、また両方に有効にします。 preemptionを無効にするには, Device > High Availability > Election Settings で Preemptiveのチェックを外し、 commitします。     メジャーバージョン間のアップグレードの場合(6.0 -> 6.1 または 6.1-> 7.0), HA Pair間でセッションがsyncしてなくともfailoverする様にTCP-Reject-Non-SYNを無効にすることを推奨します。 # set deviceconfig setting session tcp-reject-non-syn no # commit （オプショナルですが推奨）予想外の事象でSSHやWebUIでログインできなくなることを想定し、FirewallへOut-of-Band アクセス (コンソールアクセス) が出来るのを確認します。   ステップ:   先にactive機(firewall A)を CLIでsuspendします。以下のコマンドを実行します: > request high-availability state suspend または WebUIで Device > High Availability > Operations > Suspend local deviceをクリックします。  注意: このステップでpassive機(firewall B)へのHA failoverが発生します.  これをする事によってアップグレードを実行する前にHA機能が正常に動作していることを確認できます。 前Active機(firewall A)がsuspended状態で現在のActive機(firewall B)の動作が安定していることを確認します。 suspended機(firewall A)上で新しいPAN-OSをインストールし、再起動してインストールを完了します。  How to Upgrade PAN-OS and Panorama アップグレードされた機体(firewall A)が再起動した後、 CLI プロンプトでは passive (メジャーバージョン間のアップグレードの場合はnon-operational)と表示され、 PAN-OS versionも新しくインストールされたバージョンが反映されます。 Passive機(firewall A)のCLI で以下のコマンドを使い , auto commit が成功したことを確認します(FIN OK)。  > show jobs all   注意:  Passive機(firewall A)がnon-functional状態の場合, 以下のコマンドを実行して実行(functional)状態に戻します：  > request high-availability state functional Active機(firewall B)をsuspendします。Suspendedを実行した後, 既にアップグレードされている機体(firewall A)がまたActiveに戻ります。 注意: OSPFやBGPの様なルーティングプロトコルを使用しているHAペアのActive機をsuspendするに当たり、ネットワーク構成によって短時間の通信遮断を起こす事があります。 これは ルーターとsuspendされた ファイアウォール 間の隣接関係が切断され、 新しくActiveになった機体と確立するためです。 ダウンタイムを短縮するためには, Firewallと隣接関係のルーター間でGraceful restartを有効にしてください。Graceful Restart機能はPAN-OS　6.0以降でサポートされてます。 Suspend 状態の機体 (Firewall B) 上で新しい PAN-OSをインストールし、 リブートします。 リブートが終わった後, Passive機として起動します。Passive機(firewall B)のCLI で以下のコマンドを使い、 auto commit が成功したことを確認します(FIN OK)。 > show jobs all 注意:  Active-ActiveのHAペアの場合, Active-Passiveと同じ様にステップを実行してください。アップグレード全体は30分程かかると思われます。   ダウングレードの方法 新しいバージョンでなんらかの事象が発生してダウングレードが必要になった場合： 前のPAN-OSのバージョンに戻すには, 以下のCLIコマンドを実行します： > debug swm revert   このコマンドによってアップグレード前に使用していたパーティション（前のPAN-OSバージョン）からブートされます。 何もアンインストールされず、設定変更もありません。

※この記事は以下の記事の日本語訳です。 How and When to Clear Disk Space on the Palo Alto Networks Device https://live.paloaltonetworks.com/t5/Management-Articles/How-and-When-to-Clear-Disk-Space-on-the-Palo-Alto-Networks/ta-p/55736    詳細 Palo Alto Networks のデバイスは、保存済みのログがログ クォータの上限に達した場合、一番古いログから順に削除します。デバイスは "show system logdb-quota" コマンド結果にある各カテゴリ毎にログをパージします。 各プラットフォームでのログ パージ動作については、When are Logs Purged on the Palo Alto Networks Devices?を参照してください。 デバイスがディスクのルート パーティションを使い切っている場合、手動でのファイル削除が必要となります。ルート パーティションがフル状態の場合、デバイスは各コンテンツのインストール(アンチウィルス、アプリケーション及び脅威、URL)などの管理タスクの実行や、Tech Support ファイルの生成が出来なくなります。ルート パーティションの状態を確認するには、"show system disk-space" コマンドを実行します。Core ファイルは容量が大きい場合が多いため、必要のないファイルは "delete core management-plane file <ファイル名>" コマンドを使ってファイルを削除してください。 ディスク領域を参照及び削除するには、以下コマンドを実行します。   > show system disk-space Filesystem Size Used Avail Use% Mounted on /dev/sda3 3.8G 3.8G 0 100% / /dev/sda5 7.6G 3.4G 3.8G 48% /opt/pancfg /dev/sda6 3.8G 2.7G 940M 75% /opt/panrepo tmpfs 493M 36M 457M 8% /dev/shm /dev/sda8 51G 6.6G 42G 14% /opt/panlogs 手順 容量の大きい Core ファイルがないかどうか、"show system file" の結果を確認します。 >show system files /opt/dpfs/var/cores/: total 4.0K drwxrwxrwx 2 root root 4.0K Jun 10 20:05 crashinfo   /opt/dpfs/var/cores/crashinfo: total 0   /var/cores/: total 115M drwxrwxrwx 2 root root 4.0K Jun 10 20:15 crashinfo -rw-rw-rw- 1 root root 867M Jun 12 13:38 devsrvr_4.0.3-c37_1.gz -rw-rw-rw- 1 root root  51M Jun 12 13:39 core.20053   /var/cores/crashinfo: total 16K -rw-rw-rw- 1 root root 15K Jun 10 20:15 devsrvr_4.0.3-c37_0.inf o "delete core management-plane file devsrvr_4.0.3-c37_1.gz" コマンドを使って、必要ないファイルを削除します。(このコマンドは、管理プレーンの device server の Core ファイルを削除する例です) レポートの削除も同様にコマンドライン上で実行することが出来ます。例えば、864 で始まるファイルをすべて削除するには、"delete report summary scope shared report-name predefined file-name 864*" コマンドを実行します。   著者: bpappas

※この記事は以下の記事の日本語訳です。 GlobalProtect Client not Connecting https://live.paloaltonetworks.com/t5/Management-Articles/GlobalProtect-Client-not-Connecting/ta-p/53185   GlobalProtect 1.2 以上   問題 GlobalProtect クライアントで接続ができません。   以下のログが PanGPA.log 内で出力されます: P 195-T519 Oct 09 18:02:17:24315 Info ( 83): Failed to connect to server at port:4767 P 195-T519 Oct 09 18:02:17:24325 Info ( 460): Cannot connect to service, error: 61 P 195-T519 Oct 09 18:02:17:24330 Debug( 742): Unable to connect to service   原因 これは、PanGPA サービスの接続が同じ端末上の PanGPS サービスへ実施される際に発生する問題です。   解決策 PanGPA サービスは localhost の 4767ポートで通信を待ち受けている必要があります。確認するには以下のコマンドを実施します。   MACの場合 : netstat -an | grep 4767 tcp4 0 0 127.0.0.1.4767 *.* LISTEN   Windowsの場合 : netstat -an | find "4767" TCP    127.0.0.1:4767         0.0.0.0:0              LISTENING   4767ポートでの待ち受けが確認できない場合、サービスは正しく起動していません。PanGPS.log の内容を確認したり、OS上で競合状態等が発生してないかを確認します。   もし4767ポートでの待ち受けが確認できた場合、TELNETコマンドで接続性を確認します。(telnet 127.0.0.1:4767)  TELNET接続に失敗する場合、端末上のファイアーウォール機能が通信を破棄していないか確認します。ファイアーウォール機能を一時的に無効にしてテストを実施することも検討します。