ナレッジドキュメント

※この記事は以下の記事の日本語訳です。 Limitations and Recommendations While Implementing SSL Decryption https://live.paloaltonetworks.com/t5/Learning-Articles/Limitations-and-Recommendations-While-Implementing-SSL/ta-p/60036     詳細 SSL 復号化は以下のシナリオの下では有効に機能しません:   制限事項 フォワードプロキシ復号化は、相互認証では動作しません サーバー が、ハンドシェイク中にユーザー証明書の提示がされることを想定している場合。Palo Alto Networks ファイアウォールはユーザーの秘密鍵と証明書へのアクセス権がありません。 サポートされていないプロトコルや暗号が使用されているときに、コンテンツを復号化することはできません TLS 1.2 は、PAN-OS 6.0 以前では復号化することはできません PAN-OS6.0 以前では、TLS1.2 セッションは TLS 1.1 にダウングレードされます 以下の暗号スイートは、復号化ではサポートされていません : AES128-GCM-SHA256 AES256-GCM-SHA256 Perfect Forward Secrecy または Diffie Hellman key exchange を使用している暗号化スイート   推奨事項 エンタープライズ CA がある場合は、信頼されているため、それを使用します 小さなグループのユーザーまたは単一サブネットに対して SSL 復号化を有効にします "ソーシャル ネットワーキング"など、選択されたコンテンツを復号するために、常に URL カテゴリを使用します 一部の国では、法律によって特定の接続は復号化できないため、敏感なカテゴリを除外するために URL カテゴリを使用します   以下の文書では、 SSL 復号化から除外されているアプリケーションのリストが含まれています: List of Applications Excluded from SSL Decryption    (英文)   参考 SSL Decryption Not Working Due to Unsupported Cipher Suites  (英文) How to Implement and Test SSL Decryption   (英文)   著者: dantony  
記事全体を表示
dyamada ‎07-13-2016 05:15 AM
5,767件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How Session Rematch Works https://live.paloaltonetworks.com/t5/Learning-Articles/How-Session-Rematch-Works/ta-p/60326   概要 このドキュメントでは、セッションの再マッチング (Session Rematch) が Palo Alto Networks ファイアウォール上でどのように動作するかを説明します。   詳細 セキュリティポリシーに変更が行われコミットされます。セッションの再マッチングが有効になっている場合、ファイアウォールは、すべての既存のセッションを精査してすべての一致するトラフィックに新しいセキュリティポリシーを適用します。   WebGUI から Device > Setup > Session へ行くと、"Rematch Sessions "が以下のページで見つかります。   注: セッションの再マッチングは、 PAN-OS 5.0 以上ではデフォルトで有効になっています。   例 次の例では、セッションの再マッチングが有効になっている場合の動作を示しています。   以下に表示されているのがオリジナルのセキュリティポリシーです:   オリジナルセッションは以下で表示されます:     以下の表示がセキュリティポリシーです:     ポリシーがコミットされた後のセッション: コミットされた直後、セッションは新しいポリシーに再照合し、Active状態からからDiscard状態に変更されたことに注意してください。   owner: mbutt
記事全体を表示
dyamada ‎07-13-2016 01:50 AM
4,164件の閲覧回数
0 Replies
Difference Between SSL Forward-Proxy and Inbound Inspection Decryption Mode https://live.paloaltonetworks.com/t5/Learning-Articles/Difference-Between-SSL-Forward-Proxy-and-Inbound-Inspection/ta-p/55553   概要 SS通信を復号化する対象にするために、SSL復号化ポリシーを設定する際、2つの違うモードを選択できます。 SSL フォワード プロキシ SSL インバウンド インスペクション この文章では2つのモードの違いについて説明します。   詳細   フォワード プロキシ フォワード プロキシ・モードでは、PAN-OSはポリシーにヒットしたSSL通信をインターセプトし、Proxy(中間者)として動作し、アクセスするURLの新しい証明書を発行します。この新しい証明書は、クライアントがウェブサイトにSSLでハンドシェイクする際に使われます。この証明書は、自己証明局もしくは他の証明局によって認証されたものです。 注意: もし第三者機関によって発行された証明書を使いたい場合は、CA証明局と、パブリック、ブライベート(鍵ペア)をインポートする必要があります。   クライアントはHTTPSで、www.google.comに接続しにいきます。通信が復号化ポリシーにマッチします。 この通信はSSLプロキシ・エンジンに受渡しされ、www.google.comへの証明書はインターナルPKIによって生成されます (CA証明書によって署名される)。 PAN-OSはSSL通信を代理応答し、Webサーバに対してSSL通信をセットアップします。 WebサーバーはPAN-OS デバイスとハンドシェイクを始めます。 PAN-OSデバイスはServer Helloメッセージ内の生成された証明書とクライアント情報でSSLハンドシェイクを完了します。   インバウンド インスペクション インバウンド インスペクション・モードではPAN-OSはポリシーにヒットしたSSL通信をProxyとして動作しません。PAN-OSはSSL通信を復号化して、密かにSSLハンドシェイクを盗聴して、以下の設定例にあるように、設定された関連した証明書(鍵ペア)を使用します。 注意: この復号化モードは、対象のWebサーバー証明書がコントロール配下で、パロアルトネットワークス デバイスに鍵ペアを取り込むことができることが前提です。それゆえ、この復号化モードは、内側Webサーバー向けの内向き通信に対してSSL復号化としてしばしば使われます。   クライアントはHTTPSで、www.google.comに接続しにいきます。通信が復号化ポリシーにマッチします。 SSLプロキシ・エンジンがSSLセッションに関連された鍵ペアを盗聴し始めます。 SSLリクエストは、ProxyされずにWebサーバーに送付されます。 PAN-OSは両証明書(サーバーが送付したものとステップ2の証明書)が同じかどうかハンドシェイク中のServer-Helloメッセージにて検査します。 一致した場合、復号化は残りのセッションに対して成功します。さもなければ、復号化は失敗します(該当のグローバル カウンターが計上されていきます。)   著者 : nbilly
記事全体を表示
kkondo ‎07-12-2016 12:48 AM
13,451件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Palo Alto Networks TCP Settings and Counters https://live.paloaltonetworks.com/t5/Learning-Articles/Palo-Alto-Networks-TCP-Settings-and-Counters/ta-p/54049   次世代Palo Alto Networks ファイアウォールは様々なタイプの不法侵入に対して、防御するセキュリティー機能を提供します。不法侵入を検知すると、初期設定の動作ではトラフィックログや脅威ログに記録せず、パケットを破棄します。   グローバル カウンター値を参照する グローバル カウンター値はセキュリティ機能によってトラフィックがドロップされたことを示します。以下のコマンドによって確認します。   現在の設定の確認 現在の装置の設定値を確認するために、以下のコマンドを実行します。   カウンター値の説明と、関連するコマンド設定 flow_tcp_non_syn_drop - Packets dropped: non-SYN TCP without session match   次世代Palo Alto Networks ファイアウォールは3ウェイ ハンドシェイクによってTCPセッションを構築します。デバイスの初期設定では、3ウェイ ハンドシェイクのないTCPパケットをドロップします。正規なnon-SYN TCP通信は、非対称ルーティングによって発生し、そのため通信の一部のパケットしか通信機器を通過しません。正規なnon-SYN TCP通信は他にも、機器を新規に追加した場合に、既存の通信によって発生することがありえます。   このような場合に、この機能を無効にする必要性があるかもしれません。 CLI 設定 : set session tcp-reject-non-syn <yes|no>   この設定を設定ファイルに追加して、コミットを実行することによって、再起動後、初期設定動作を変更することができます。   > configure # set deviceconfig setting session tcp-reject-non-syn <yes|no> # commit   この機能は、 ゾーン  プロテクションを使っている場合、WebUI経由で、設定、解除をすることもできます。 ゾーン  プロテクション設定プロファイルで、管理者はグローバルでYes/Noを選択できます。 ゾーン  プロテクション設定プロファイルはnon-SYN TCP通信を拒否するように、システム全体に適応されるグローバル設定をそのまま使うことも可能です。 ゾーン  プロテクション設定プロファイル選択設定されたYes/No選択はグローバル設定に上書きさます。   注 : ゾーン  プロテクション設定プロファイルは内側通信セッションに対して適応されます。仮に、ゾーンAに設定されている場合、ゾーンAに入ってくる通信に対して、ゾーンプロテクション設定プロファイルは適応されますが、ゾーンAから出ていく通信に対しては適応されません。   tcp_drop_out_of_wnd - out-of-window packets dropped Palo Alto Networks ファイアウォールは元のACKから始まるスライディング シーケンス ウィンドウを作成します(ウィンドウ サイズは、セッション内の通信タイプに依存します)。パケットのシーケンス番号は、スライディング ウィンドウ内に納まることが期待されます。このウィンドウは、トラフィックの種類や、ACKメッセージが受信された際に調整します。初期設定の動作では、シーケンス番号がウィンドウ外だった場合、ドロップします。   この設定を設定ファイルに追加して、コミットを実行することによって、再起動後、初期設定動作を変更することができます。   > configure # set deviceconfig setting tcp asymmetric-path < bypass|drop > # commit   tcp_exceed_flow_oo_seg_limit out-of-window packets dropped due to the limitation on tcp out-of-order queue size Palo Alto Networks ファイアウォールはセッションにつき32個まで、順不同のパケットを保持しようとします。このカウンターは32個の保持できるパケット制限を越えた場合にカウントされます。正しい順番が確認される前に32個の制限に達した場合、機器の初期設定では、Layer4-7のスキャンをバイパスします。   もしバイパス設定をNoに変更すると、システムは32個の制限を越えた場合、パケットをドロップします。   この設定を設定ファイルに追加して、コミットを実行することによって、再起動後、初期設定動作を変更することができます。 > config # set deviceconfig setting tcp bypass-exceed-oo-queue <yes|no> # commit   tcp_out_of_sync - can't continue tcp reassembly because it is out of sync このカウンターは、ACKのシーケンス番号がスライディング シーケンス番号よりも外側にある場合に増加します。スライディング シーケンス番号は元のACKと、セッションのトラフィック タイプによって計算されます。初期設定では、これらのout-of-syncパケットはドロップします。この機能を無効にすると、パイパスされます。out-of-syncとセッションが判定されると、セッションがスキャンされるのを効果的にバイパスされます。この設定を設定ファイルに追加して、コミットを実行することによって、再起動後、初期設定動作を変更することができます。   > config # set deviceconfig setting tcp asymmetric-path < bypass|drop > # commit       著者 :  rnitz
記事全体を表示
kkondo ‎07-12-2016 12:24 AM
5,820件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Common Issues with GlobalProtect https://live.paloaltonetworks.com/t5/Learning-Articles/Common-Issues-with-GlobalProtect/ta-p/59534   よくある問題1 GlobalProtectポータルへのログインができるものの、それ以上すすまない。   トラブルシューティング 場合によっては先のインスタンスを完全に削除したことを確認の上、Global Protectクライアント/エージェントを再度ダウンロードする必要があるかもしれません。 接続がどこで失敗しているかを確認するため、調査用のログを収集します。これらのログから認証が意図通り機能しているのか、あるいは認証設定を調整する必要があるのかを確認することができます。どのステージでエラーが発生しているのかの確認のため、GlobalProtectクライアント/エージェントからのログ収集を推奨します。ログは "トラブルシューティング> ログ > ログ  = PanGPサービス、デバッグ レベル: = デバッグ"と設定して収集することができます。 ファイアウォール上では、GlobalProtectのユーザーが接続を試行した際は、以下のログを確認して調査する必要があります。 tail follow yes web-server-log sslvpn-access.log tail follow yes mp-log authd.log   現在のユーザーをチェックするには、以下のコマンドを実行してください。 > show global-protect-gateway current-user     よくある問題 2 GlobalProtectポータルは認証に成功するが、Global Protectゲートウェイでは失敗する。   トラブルシューティング ポータルの認証の際、ユーザーの資格情報はポータルからゲートウェイに渡されます。ポータルとゲートウェイが同じ認証方法が設定されている場合、この問題は発生しません。 ゲートウェイが異なるタイプの認証方法を設定していると、ゲートウェイの認証でポータルの認証と同じユーザー名を使用していることが重要になります。もしポータルからゲートウェイに渡された資格情報をゲートウェイが認識できない場合、ユーザーは再度パスワードの入力を促されます。重要!別のユーザー名を使うことはできないため、同じユーザー名をそれぞれの認証方法で使うようにしてください。 LDAP(またはRADIUS)に加えて二要素認証(例としてRSA SecurID)を行うには、LDAP/RADIUS認証はポータルのステージで設定されなければなりません。ユーザーは最初にドメイン名とパスワードでのログインをし、それから再度(ゲートウェイによって)チャレンジ レスポンスのため RSA SecurIDトークンに表示された ワンタイム パスワードを入力します。ここでもまたユーザー名はGlobalProtectポータルとゲートウェイは同じものが使われる前提です。   著者: sjamaluddin
記事全体を表示
TShimizu ‎07-06-2016 12:48 AM
6,072件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Troubleshoot Using Counters via the CLI https://live.paloaltonetworks.com/t5/Learning-Articles/How-to-Troubleshoot-Using-Counters-via-the-CLI/ta-p/57496   カウンターはパロアルトネットワークス ファイアウォールにおいて、プロセス群、パケット フロー、そしてセッション管理における大変有用な指標です。トラブルシューティングの際は様々な状況で大変強力なツールとなります。   パケット ドロップのトラブルシューティング 以下はパケット ドロップが疑われる状況で有効なコマンドです。パケット ドロップの理由は問題原因の絞込の一助となります。   > show counter global filter severity drop Global counters: Elapsed time since last sampling: 34.999 seconds   name                                   value     rate severity  category  aspect    description -------------------------------------------------------------------------------- flow_rcv_err                              98        0 drop      flow      parse     Packets dropped: flow stage receive error flow_rcv_dot1q_tag_err                     1        0 drop      flow      parse     Packets dropped: 802.1q tag not configured flow_no_interface                        263        0 drop      flow      parse     Packets dropped: invalid interface flow_ipv6_disabled                     30622        0 drop      flow      parse     Packets dropped: IPv6 disabled on interface flow_policy_nat_land                    6732        0 drop      flow      session   Session setup: source NAT IP allocation result in LAND attack flow_fwd_l3_mcast_drop                  2756        0 drop      flow      forward   Packets dropped: no route for IP multicast flow_fwd_l3_ttl_zero                       4        0 drop      flow      forward   Packets dropped: IP TTL reaches zero flow_fwd_l3_noroute                        5        0 drop      flow      forward   Packets dropped: no route flow_fwd_l3_noarp                          1        0 drop      flow      forward   Packets dropped: no ARP flow_action_reset                          1        0 drop      flow      pktproc   TCP clients reset via responding RST flow_arp_rcv_err                         162        0 drop      flow      arp       ARP receive error flow_host_decap_err                      412        0 drop      flow      mgmt      Packets dropped: encapsulation error to control plane flow_host_service_deny                153865        0 drop      flow      mgmt      Device management session denied flow_host_service_unknown               2762        0 drop      flow      mgmt      Session discarded: unknown application to control plane flow_tunnel_encap_err                     33        0 drop      flow      tunnel    Packet dropped: tunnel encapsulation error appid_lookup_invalid_flow                  1        0 drop      appid     pktproc   Packets dropped: invalid session state proxy_offload_check_err                 1030        0 drop      proxy     pktproc   The number offload proxy setup check failed because of not SYN or no certificate url_request_pkt_drop                     204        0 drop      url       pktproc   The number of packets get dropped because of waiting for url category request -------------------------------------------------------------------------------- Total counters shown: 18 --------------------------------------------------------------------------------   上記のコマンドは差分(Delta)オプションとともに使用できます。前回のコマンド実行時からの差分のみ確認することができます。 > show counter global filter delta yes severity drop   Global counters: Elapsed time since last sampling: 55.446 seconds name                                   value     rate severity  category  aspect    description -------------------------------------------------------------------------------- flow_ipv6_disabled                         3        0 drop      flow      parse     Packets dropped: IPv6 disabled on interface flow_fwd_l3_mcast_drop                     2        0 drop      flow      forward   Packets dropped: no route for IP multicast flow_host_service_deny                    26        0 drop      flow      mgmt      Device management session denied flow_host_service_unknown                  2        0 drop      flow      mgmt      Session discarded: unknown application to control plane -------------------------------------------------------------------------------- Total counters shown: 4 --------------------------------------------------------------------------------   severity dropの他にも、状況に応じた様々なseverity(重大度)が定義されています。例として error、informational、そしてwarningがあります。     マネジメント サーバー統計情報に関するトラブルシューティング カウンターはマネジメント サーバー統計情報も確認することができます(内部のログの追記に伴い、各マネジメント サーバー関連プロセスに関連付けられたカウンターが変化します)。   RMAによる交換対応の必要性が疑われるような状況で、下記のコマンドは有効です。   > show counter management-server Log action not taken            :          0 Logs dropped because not logging:          0 User information from AD read   :          2 Certificates information read   :          0 License information fetched from update server:          0 Sighash refcount                :          1 Tunnelhash refcount             :          1 URLcat refcount                 :          1 ip2loc refcount                 :          1   管理用インターフェイスの統計 管理用インターフェイスもまた統計情報を持ち、接続性の問題の確認に有効な情報です。   > show counter interface management Interface: Management Interface ------------------------------------------------------------------------------- Logical interface counters: ------------------------------------------------------------------------------- bytes received                    505700037 bytes transmitted                 295080711 packets received                  772181 packets transmitted               874087 receive errors                    0 transmit errors                   0 receive packets dropped           0 transmit packets dropped          0 multicast packets received        0 -------------------------------------------------------------------------------   データプレーン インターフェイス統計情報 show counter interfaceコマンドは各ポートの統計情報を表示します。    > show counter interface tunnel.51 Interface: tunnel.51 -------------------------------------------------------------------------------- Logical interface counters read from CPU: -------------------------------------------------------------------------------- bytes received                           0 bytes transmitted                        0 packets received                         0 packets transmitted                      0 receive errors                           0 packets dropped                          0 packets dropped by flow state check      0 forwarding errors                        0 no route                                 0 arp not found                            0 neighbor not found                       0 neighbor info pending                    0 mac not found                            0 packets routed to different zone         0 land attacks                             0 ping-of-death attacks                    0 teardrop attacks                         0 ip spoof attacks                         0 mac spoof attacks                        0 ICMP fragment                            0 layer2 encapsulated packets              0 layer2 decapsulated packets              0 --------------------------------------------------------------------------------   レイヤー2接続性のトラブルシューティング レイヤー2のトラブルシューティングはARPエントリーの異常として現れます。以下のコマンドにてグローバル カウンターのarp 関連項目を確認することができます。 > show counter global filter aspect arp   Global counters: Elapsed time since last sampling: 8.330 seconds   name                                   value     rate severity  category  aspect    description -------------------------------------------------------------------------------- flow_arp_pkt_rcv                       42685        0 info      flow      arp       ARP packets received flow_arp_pkt_xmt                        1875        0 info      flow      arp       ARP packets transmitted flow_arp_pkt_replied                    6995        0 info      flow      arp       ARP requests replied flow_arp_pkt_learned                      17        0 info      flow      arp       ARP entry learned flow_arp_rcv_gratuitous                  494        0 info      flow      arp       Gratuitous ARP packets received flow_arp_rcv_err                         162        0 drop      flow      arp       ARP receive error flow_arp_resolve_xmt                    1843        0 info      flow      arp       ARP resolution packets transmitted -------------------------------------------------------------------------------- Total counters shown: 7     他の有用な統計情報 トラブルシューティングにおいて様々なカウンターを使用できます。以下はその例です。   anatrajan@PAN_WICH_52> show counter global name   aho_alloc_lookup_failed              warn      failed to alloc regex lookup   aho_fpga                             info      The total requests to FPGA for AHO   aho_fpga_invalid_wqe                 error     when getting result from fpga, wqe index was not valid   aho_fpga_ret_error                   error     Dropped results from FPGA caused by unexecpted type   aho_fpga_ret_invalid_fid             error     Dropped results from FPGA caused by invalid flow id   aho_fpga_ret_length_error            error     Dropped results from FPGA caused by short length   aho_fpga_ret_multi_bufs              info      Aho fpga result with multiple buffers   aho_fpga_ret_offset_error            error     Dropped results from FPGA caused by invalid offset   aho_fpga_ret_wrong_size              error     Dropped results from FPGA caused by wrong packet size   aho_fpga_state_verify_failed         info      when getting result from fpga, session's state was changed   aho_fpga_unmatched_type              error     when getting result from fpga, type in session was not matched   aho_fpga_unmatched_wqe               warn      when getting result from fpga, wqe was not matched in session   aho_match_overflow                   info      number of aho matches overflow   aho_sw                               info      The total usage of software for AHO   aho_sw_fpga_fail                     warn      Usage of software AHO caused by failure for sending fpga request   aho_sw_fpga_full                     info      Usage of software AHO caused by fpga requests threshold   aho_sw_fpga_unavailable              warn      Usage of software AHO caused by fpga unavailable   aho_too_many_matches                 info      too many signature matches within one packet   aho_too_many_mid_res                 info      too many signature middle results within one packet   appid_dfa_invalid_result             error     The invalid dfa result for appid   appid_exceed_pkt_limit               warn      App. identification failed caused by limitation of total queued packe   appid_exceed_queue_limit             warn      App. identification failed caused by limitation of session queued pac   appid_exceed_queue_limit_post        warn      App. identification failed caused by limitation of session queued pac   appid_fini_with_wqe_2_fpga           info      session ends with wqe in fpga   appid_flow_state_fail                info      The session's state was changed   appid_ident_by_cache                 info      Application identified by cache   appid_ident_by_dport                 info      Application identified by L4 dport   appid_ident_by_dport_first           info      Application identified by L4 dport first   appid_ident_by_heuristics            info      Application identified by heuristics   appid_ident_by_icmp                  info      Application identified by icmp type   appid_ident_by_ip                    info      Application identified by ip protocol   appid_ident_by_sport                 info      Application identified by L4 sport   appid_ident_by_sport_first           info      Application identified by L4 sport first   appid_ident_by_supernode             info      Application identified by supernode   appid_lookup_invalid_flow            drop      Packets dropped: invalid session state   appid_match_overflow                 info      The dfa matches overflow   appid_no_policy                      error     App. identification failed because of no policy   appid_override                       info      Application identified by override rule   appid_proc                           info      The number of packets processed by Application identification   appid_reset_sess_tcp_reass           error     reset sess failed at tcp reassembly   appid_result_id_changed              info      The session's appid status was changed   appid_result_no_policy               info      The session's policy was changed during appid proc   appid_skip_terminal                  info      The dfa result is terminal   appid_ssl_no_cert_no_reset           info      ssl sessions with unknown server certificate but no previous reset   appid_stop_by_ager                   info      Application identification terminated by session ager   appid_stop_by_ager_nopkts            info      Ager can't stop appid because no packets were queued   appid_unknown_by_stop                info      The number of unknown applications because of being stopped   著者: anatrajan
記事全体を表示
TShimizu ‎07-05-2016 08:06 PM
5,600件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 What Conditions Trigger Microsoft Windows SMB Fragmentation RPC Request Attempt Alert? https://live.paloaltonetworks.com/t5/Threat-Articles/What-Conditions-Trigger-Microsoft-Windows-SMB-Fragmentation-RPC/ta-p/54033       Microsoft Windows SMB (Server Message Block) フラグメント RPC (Remote Procedure Call) を発生させる条件は以下の通りです: MSRPC データ長が2バイト未満 MSRPC データ長が MSRPC ヘッダ長より小さい MSRPC フラグメント長が現在のパケット長よりも大きい これは回避手法の検知を示すものであり、攻撃が実際に行われていることを意味するわけではありません。また、回避手法は脆弱性とは異なるため、これに該当するCVE番号は存在しません。より詳細についてはこちら(英文)を参照してください。   著者: jnguyen
記事全体を表示
ymiyashita ‎06-07-2016 06:32 PM
2,552件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Session Tracker Feature https://live.paloaltonetworks.com/t5/Learning-Articles/Session-Tracker-Feature/ta-p/61790   PAN-OS 6.0, 6.1   詳細 PAN-OS 6.0 において、"show session id" コマンドでのセッション終了理由の追跡機能が追加されました。セッションの終了理由が、"show session id <ID番号>" 結果の下部にある "tracker stage firewall" 部分に出力されます。 セッションはパケットの処理の様々なフェーズでクローズされる可能性があります。例えば、以下のようなケースがあります。 セッションが拒否された、あるいはタイムアウトした 脅威が検知されたことによりパケットが破棄された エンド端末によりリセットされた セッション追跡の目的は、特定のセッション上で取られたアクションに対して、より明確な理由を確認することにあります。表示された情報によって、セッション切断について過去に遡って分析することが出来ます。また多くの場合事象を再現させることは難しいですが、この機能によって事象再現に要する時間を削減することが出来ます。 以下のような複数のステータスが用意されています。   Aged out - セッションがタイムアウトにより終了しました。 TCP FIN - 接続の一方または両方のホストが TCP FIN パケットを送信してセッションをクローズしました。 TCP RST - client - クライアントがサーバーへ TCP リセットを送信しました。 TCP RST - server - サーバーがクライアントへ TCP リセットを送信しました。 appid policy lookup deny - セッションが、拒否またはドロップ アクションが指定されたセキュリティ ポリシーと一致しました。 mitigation tdb - 脅威を検知したためセッションは終了しました。 resource limit - セッションがリソース制限の問題によりドロップされました。たとえば、セッションの順序外パケット数が、フローまたはグローバル順序外パケット キューごとに許容された数を超えた場合などが考えられます。他の多数の理由によっても出力される場合があります。 host service - トラフィックがファイアウォールへ送信されましたが、サービスが許可されていないあるいは有効になっていません。 以下は "show session id" コマンドのセッション終了理由の例です。   > show session id 4632   Session            4632   c2s flow: source:      192.168.210.103 [trust] dst:         198.172.88.58 proto:       6 sport:       4475            dport:      80 state:       INIT            type: FLOW src user:    unknown dst user:    unknown pbf rule:    wt-VPNTest 1   s2c flow: source:      198.172.88.58 [VPN] dst:         192.168.210.103 proto:       6 sport:       80              dport:      4475 state:       INIT            type:       FLOW src user:    unknown dst user:    unknown   start time                    : Mon Sep  9 16:39:06 2013 timeout                       : 30 sec total byte count(c2s)         : 1063 total byte count(s2c)         : 1461 layer7 packet count(c2s)      : 12 layer7 packet count(s2c)      : 10   […..]   session via syn-cookies       : False session terminated on host    : False session traverses tunnel      : True captive portal session        : False ingress interface             : ethernet1/6 egress interface              : tunnel.179 session QoS rule              : N/A (class 4) tracker stage firewall        : TCP FIN   以下のコマンドは、"tracker stage" が有効なセッション一覧を出力させるコマンドです。   > show log traffic direction equal backward show-tracker equal yes Time                App             From            Src Port          Source Rule                Action          To              Dst Port          Destination Src User            Dst User        Session Info ================================================== ============================= 2013/09/09 16:44:01 flash           trust           4433              192.168.210.103 TCP-logging         allow           VPN             80                74.125.239.124                                                      TCP FIN 2013/09/09 16:44:00 incomplete      untrust         52405             10.30.6.210 allow-any           allow           untrust         135               10.30.14.212                                                      Aged out 2013/09/09 16:40:25 ms-update       trust           4402              192.168.210.103 TCP-logging         allow           VPN             80                96.17.148.40                                                      TCP RST – client   著者: djoksimovic  
記事全体を表示
hfukasawa ‎04-20-2016 03:09 AM
19,121件の閲覧回数
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,362件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 CLI Commands to Status, Clear, Restore, and Monitor an IPSEC VPN Tunnel https://live.paloaltonetworks.com/t5/Learning-Articles/CLI-Commands-to-Status-Clear-Restore-and-Monitor-an-IPSEC-VPN/ta-p/55917   概要 このドキュメントのCLI コマンドを使用することにより IPSEC tunnel のステータスの確認、 Tunnel のモニタリング、 Tunnel の切断と再接続ができます。   詳細 VPN Tunnelのモニタリングと接続状況の確認: show vpn flow Note: monitor status がdownの場合は 宛先IP Address への接続ができていないことを示します。   例: > show vpn flow   total tunnels configured:        1 filter - type IPSec, state any   total IPSec tunnel configured:   1 total IPSec tunnel shown:        1   id  name     state    monitor  local-ip        peer-ip        tunnel-i/f -------------------------------------------------- ------------------------ 4   tunnel   active    up      172.17.128.135  172.17.128.1     VPN Tunnel 内でデータ通信が行われてる事の確認 : show vpn flow tunnel-id x   << VPN Tunnel の ID 番号(上の例だと4)   例: データ通信が行われていればpackets と bytes のカウンターは上がります。 > show vpn flow tunnel-id 2         encap packets:    500         decap packets:    500         encap bytes:      54312         decap bytes:      54312         key acquire requests: 35     接続しているIKE phase 1 SAの詳細の表示: show vpn ike-sa gateway <gateway name>   例: > show vpn ike-sa gateway GW-to-Lab1   phase-1 SAs GwID  Peer-Address    Gateway Name    Role Mode Algorithm ----  -------------  ---------------  ---------------------------                1    57.1.1.1        gw-to-Lab1      Init Main PSK/DH2/A128/SHA1   Show IKEv1 IKE SA: Total 1 gateways found.     接続しているIKE phase 2 SAの詳細の表示: show vpn ipsec-sa tunnel <tunnel name>   Example: > show vpn ipsec-sa tunnel IPVPN-tunnel1.1-to-LAB1   GwID  TnID  Peer-Address  Tunnel(Gateway)          Algorithm      ----  ----- ------------  -----------------------  ------------ 1     2     57.1.1.1      IPVPN-tunnel1.1-to-LAB1  ESP/A128/SHA1   Show IPSec SA: Total 1 tunnels found.     これらのコマンドはVPN Tunnel を切断する時に使用します : > clear vpn ike-sa gateway GW-to-Lab1 Delete IKEv1 IKE SA: Total 1 gateways found.   > clear vpn ipsec-sa tunnel IPVPN-tunnel1.1-to-LAB1 Delete IKEv1 IPSec SA: Total 1 tunnels found.   これらのコマンドはVPN Tunnel を再接続する時に使用します : > test vpn ike-sa gateway GW-to-Lab1 Initiate IKE SA: Total 1 gateways found. 1 ike sa found.   > test vpn ipsec-sa tunnel IPVPN-tunnel1.1-to-LAB1 Initiate IPSec SA: Total 1 tunnels found. 1 ipsec sa found.   注意: GW-to-Lab1 と IPVPN-tunnel1.1-to-LAB1 はgateway と tunnel 名前の例です。   Phase 1 Phase 2  
記事全体を表示
oconnellm ‎04-19-2016 10:30 PM
7,135件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Run a Packet Capture https://live.paloaltonetworks.com/t5/Learning-Articles/How-to-Run-a-Packet-Capture/ta-p/62390   概要 このドキュメントではパケット キャプチャを設定したり、キャプチャの開始・停止、および収集したキャプチャ ファイルを操作する基本手順とコマンドについて説明しています。ここでは最も一般的に用いられるオプションを使用して、プロセスの概要を提供することを目的とします。パケット キャプチャと全てのオプションについてのより良い理解を得るためには、以下のドキュメントを参照してください: Packet Based Troubleshooting - Configuring Packet Captures and Debug Logs   詳細 CLI での実施 パケット フィルタの作成 debug dataplane packet-diag set filter match source <IP_1> destination <IP_2> debug dataplane packet-diag set filter on debug dataplane packet-diag show setting 注: 最大4つの一致条件をパケット キャプチャのために設定することができます。送信元、先IP アドレスが設定されていない場合は "any" (0.0.0.0) となります。   パケット キャプチャ ステージと対応するファイルを定義します。 debug dataplane packet-diag set capture stage transmit file <filename_transmit> debug dataplane packet-diag set capture stage receive file <filename_receive> debug dataplane packet-diag set capture stage firewall file <filename_firewall> debug dataplane packet-diag set capture stage drop file <filename_drop>   パケット キャプチャの開始 debug dataplane packet-diag set capture on   注:キャプチャの開始前に、キャプチャ フィルタが設定されているかとフィルタリングが有効になっているかを確認します。 例: admin@PAN-FW> debug dataplane packet-diag show setting -------------------------------------------------------------------------------- Packet diagnosis setting: -------------------------------------------------------------------------------- Packet filter   Enabled:                   yes   Match pre-parsed packet:   no   Index 1: 192.168.0.1[0]->10.20.30.1[0], proto 0            ingress-interface any, egress-interface any, exclude non-IP -------------------------------------------------------------------------------- 重要! フィルタリングしないままキャプチャを開始するとファイアウォールに負荷がかかりすぎることになります。   パケット キャプチャの停止 debug dataplane packet-diag set capture off   キャプチャ ファイルの参照 view-pcap filter-pcap <filename>   キャプチャ実行中にリアルタイムにキャプチャ ファイルを表示するには、以下のコマンドを使用します: view-pcap follow yes filter-pcap <filename>   キャプチャ ファイルのエクスポート scp export filter-pcap from <file> to <SCP_serv> <SCP_Serv> = user@server:path tftp export filter-pcap from <file> to <tftp_Server_addr>   キャプチャ フィルタとファイルのクリア debug dataplane packet-diag set filter off debug dataplane packet-diag clear filter all debug dataplane packet-diag clear capture all   WebUI での実施 Monitor > パケット キャプチャ に移動します。 パケット フィルタの作成と有効化: パケットをキャプチャするためにステージとファイル名を指定して作成します: キャプチャを有効にするために OK をクリックします: キャプチャ  ページを更新した後、対応するリンクをクリックすることで、 HTTP 経由でキャプチャ ファイルをダウンロードします:  
記事全体を表示
tsakurai ‎04-17-2016 05:28 AM
11,991件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 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
記事全体を表示
hfukasawa ‎04-15-2016 03:28 AM
7,308件の閲覧回数
0 Replies
Ask Questions Get Answers Join the Live Community