ナレッジドキュメント

※この記事は以下の記事の日本語訳です。 How to Configure Dynamic Routing over IPSec against Cisco routers https://live.paloaltonetworks.com/t5/Documentation-Articles/How-to-Configure-Dynamic-Routing-over-IPSec-against-Cisco/ta-p/60523     添付の技術文書は、Palo Alto NetworksファイアウォールとCiscoルーター間での、IPSecトンネルを使用したダイナミック ルーティング プロトコルを設定、実行するために必要な手順を説明しています。 この中では、Palo Alto Networksと互換性のあるCisco IPSec VTIインターフェイスの設定方法を説明しています。また、CiscoとPalo Alto Networksの両方のデバイスのための設定を含んでいます。 記載例はOSPFに基づきますが、RIPやBGPに対しても拡張できます。     著者:jdiaz
記事全体を表示
hshirai ‎04-16-2017 10:56 PM
8,513件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 PAN-OS 6.0 CEF Configuration Guide https://live.paloaltonetworks.com/t5/Configuration-Articles/PAN-OS-6-0-CEF-Configuration-Guide/ta-p/59938     こちらの文書は、 CEFフォーマットでSyslogイベントを収集するために、 PAN-OS 6.0を搭載したPalo Alto Networks 次世代ファイアウォールを 設定する情報を記載しています。PAN-OSバージョン6.0.0、あるいはそれ以降のバージョンをサポートしています。 最終更新日 2014年5月22日。   訳注:上記の通り原文はPAN-OS 6.0用の文書ですが、その後により新しいPAN-OSバージョン向けの文書も発行しております。以下よりご使用のPAN-OSバージョンに一致するCommon Event Format (CEF) Configuration Guidesをご参照ください。   Common Event Format (CEF) Configuration Guides       以下は、CEFスタイルのログ フォーマットのHTML版となっており、コピー&ペーストしていただけます:   トラフィック CEF:0|Palo Alto Networks|PAN-OS|6.0.0|$subtype|$type|1|rt=$cef-formatted-receive_time deviceExternalId=$serial src=$src dst=$dst sourceTranslatedAddress=$natsrc destinationTranslatedAddress=$natdst cs1Label=Rule cs1=$rule suser=$srcuser duser=$dstuser app=$app cs3Label=Virtual System cs3=$vsys cs4Label=Source Zone cs4=$from cs5Label=Destination Zone cs5=$to deviceInboundInterface=$inbound_if deviceOutboundInterface=$outbound_if cs6Label=LogProfile cs6=$logset cn1Label=SessionID cn1=$sessionid cnt=$repeatcnt spt=$sport dpt=$dport sourceTranslatedPort=$natsport destinationTranslatedPort=$natdport flexString1Label=Flags flexString1=$flags proto=$proto act=$action flexNumber1Label=Total bytes flexNumber1=$bytes in=$bytes_sent out=$bytes_received cn2Label=Packets cn2=$packets PanOSPacketsReceived=$pkts_received PanOSPacketsSent=$pkts_sent start=$cef-formatted-time_generated cn3Label=Elapsed time in seconds cn3=$elapsed cs2Label=URL Category cs2=$category externalId=$seqno   脅威 CEF:0|Palo Alto Networks|PAN-OS|6.0.0|$subtype|$type|$number-of-severity|rt=$cef-formatted-receive_time deviceExternalId=$serial src=$src dst=$dst sourceTranslatedAddress=$natsrc destinationTranslatedAddress=$natdst cs1Label=Rule cs1=$rule suser=$srcuser duser=$dstuser app=$app cs3Label=Virtual System cs3=$vsys cs4Label=Source Zone cs4=$from cs5Label=Destination Zone cs5=$to deviceInboundInterface=$inbound_if deviceOutboundInterface=$outbound_if cs6Label=LogProfile cs6=$logset cn1Label=SessionID cn1=$sessionid cnt=$repeatcnt spt=$sport dpt=$dport sourceTranslatedPort=$natsport destinationTranslatedPort=$natdport flexString1Label=Flags flexString1=$flags proto=$proto act=$action request=$misc cs2Label=URL Category cs2=$category flexString2Label=Direction flexString2=$direction externalId=$seqno requestContext=$contenttype cat=$threatid filePath=$cloud fileId=$pcap_id fileHash=$filedigest   設定 CEF:0|Palo Alto Networks|PAN-OS|6.0.0|$result|$type|1|rt=$cef-formatted-receive_time deviceExternalId=$serial dvchost=$host cs3Label=Virtual System cs3=$vsys act=$cmd duser=$admin destinationServiceName=$client msg=$path externalId=$seqno   注:設定に追加することができるオプション フィールドは以下のとおりです: cs1Label=Before Change Detail cs1=$before-change-detail cs2Label=After Change Detail cs2=$after-change-detail   例えば、すべての文字列を設定に追加するには、以下のように設定します: CEF:0|Palo Alto Networks|PAN-OS|6.0.0|$result|$type|1|rt=$cef-formatted-receive_time deviceExternalId=$serial dvchost=$host cs3Label=Virtual System cs3=$vsys act=$cmd duser=$admin destinationServiceName=$client msg=$path externalId=$seqno cs1Label=Before Change Detail cs1=$before-change-detail cs2Label=After Change Detail cs2=$after-change-detail   システム マッチ CEF:0|Palo Alto Networks|PAN-OS|6.0.0|$subtype|$type|$number-of-severity|rt=$cef-formatted-receive_time deviceExternalId=$serial cs3Label=Virtual System cs3=$vsys fname=$object flexString2Label=Module flexString2=$module msg=$opaque externalId=$seqno cat=$eventid   HIP マッチ CEF:0|Palo Alto Networks|PAN-OS|6.0.0|$matchtype|$type|1|rt=$cef-formatted-receive_time deviceExternalId=$serial suser=$srcuser cs3Label=Virtual System cs3=$vsys shost=$machinename src=$src cnt=$repeatcnt externalId=$seqno cat=$matchname cs2Label=Operating System cs2=$os     著者:TechPubs
記事全体を表示
hshirai ‎04-06-2017 10:21 PM
7,630件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Create Subordinate CA Certificates with Microsoft Certificate Server https://live.paloaltonetworks.com/t5/Learning-Articles/How-to-Create-Subordinate-CA-Certificates-with-Microsoft/ta-p/58046   概要 この文書はMicrosoft Certificate Serverを使用した下位CA証明書の作成方法について記載します。 " http:// <IPアドレスまたはサーバー名>/certsrv"をブラウザで開き、サーバーの画面にアクセスします。 "Welcome"画面にて、"Request a Certificate"を選択します。 次の画面で"advanced certificate request"を選択します。 "Create and Submit a request to the CA"を選択します。 次の画面のフォームで、"Certificate Template"のプルダウン メニューから"Subordinate Certification Authority"を選択します。証明書のための必要事項を入力します(名前、連絡先など)。申請を行うとローカル システムに証明書をダウンロードするためのリンクが表示されます。 ダウンロード後、ローカルの証明書ストアから証明書をエクスポートします。"Internet Options"画面にて"Content"タブを選択し、"Certificates"ボタンをクリックします。新しい証明書をPersonal証明書ストアからエスクポートすることができます。 "Certificate Export Wizard"を表示するには、"Export"ボタンをクリックします。 "Certificate Export Wizard"画面にて、"Yes, export the private key"を選択し、続いてフォーマットを選択します。パスワードとファイル名、保存場所を指定します。   Microsoft Certificate Serverは、おそらく証明書をPFXフォーマット(PKCS #12)で提供しています。 証明書をPEMフォーマットでエクスポートするには、以下の手順で行います。 openSSLを使い、 openssl pkcs12 –in pfxfilename.pfx –out tempfile.pem と入力します。 "tempfile.pem"をテキスト エディターで開きます。 -----BEGIN RSA PRIVATE KEY----- で始まっているセクションを見つけます。 -----END RSA PRIVATE KEY----- までの全テキストを選択し、新しいファイルに貼り付けて、拡張子".key"をつけて保存します。 ".pem"ファイルからそれ以外のテキストをコピーし、別のファイルに貼り付け、拡張子".crt"をつけて保存します。 上記の手順により、keyファイルと証明書をインポートすることができます。   CLIコマンド お客様のルートCAがWebインターフェイスを備えていない場合もあり、その場合はCLIを通して 同じ操作を 行うことができます。 Microsoft CAにおけるコマンド:   certreq -submit -attrib "CertificateTemplate:SubCA" <certificate-signing-request>.csr   このコマンドを入力することでGUIプロンプトが表示され、そのプロンプトで申請するCAを選択します。通常、同じサーバ上にはルートCAは1つだけなので、表示されているCAを選択します。 その後、該当する申請がCAサーバーの保留中の申請の中に表示されます。     著者:panagent
記事全体を表示
hshirai ‎04-03-2017 08:33 PM
7,187件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Terminal Server Agent Registry Tuning for Better Port Allocation and Handling, Time Wait State https://live.paloaltonetworks.com/t5/Configuration-Articles/Terminal-Server-Agent-Registry-Tuning-for-Better-Port-Allocation/ta-p/51985     問題 特定のサイトへWebブラウザでアクセスする際、ターミナルサーバーによりユーザはすべてを閲覧することが出来ません。   原因 原因は、一部のWebサイトにおいてポートを解放するより前に短時間にポートを多く使用することがあるためです。Webサイトからの継続的なポート割り当てにより、Windowsオペレーティングシステムがポートを開放する前に、Terminal Server Agent(TSA)からの早すぎるポートの割り当てが発生します。したがって、接続エラーが発生します。 注:この問題は、多数のポートの使用と解放を高速に行うアプリケーションでも発生する可能性があります。   Windows は Timed Wait State をポートに割り当てます。これはWindows上で設定可能な値です。30-300 秒の10進数の値で、デフォルトは240秒です。 (Default)                REG_SZ          (value not set) TcpTimedWaitDelay        REG_DWORD       0x0000001e (30)   対応するレジストリ設定: システムキー: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters] 値名: TcpTimedWaitDelay データ型: REG_DWORD (DWORD 値)     解決方法 この問題に対処するため、TSA (Terminal Server Agent) バージョン5.0.1 では新しい設定が導入されました。この追加された Time Wait State (TWS) 設定により、TSエージェントは Windows システムの TcpTimedWaitDelay を追跡することができるため、Timed Wait State にあるポートはTSエージェントにより選択されなくなります。この設定を有効にすると、システムがポートブロックの通常の低いしきい値に達すると、新しいポートブロックが割り当てられます。デフォルトでは、この新しい動作は無効になっており、レジストリの編集でのみ設定の変更が可能です。   加えて、複数のポートが Timed Wait State に置かれることから、ユーザーの多くのアクティビティによりさらに多くのポートが Timed Wait State となり、その結果その時点では実際には必要のない追加のブロックが割り当てられる可能性があります。他のユーザーは、その他のユーザが蓄積している、すでに必要のない、しかしアクティビティ不足により開放されないポートブロックにより、ポート不足に陥るかもしれません。これに対処するため、TSAに不要となったポートブロックを解放するためにドライバをポーリングするタイマー設定を導入しました。このタイマーは、TWS機能が有効な場合にのみ実行されます。デフォルトのタイマー値は240秒で、レジストリで変更することができます。   Time Wait State (TWS) 機能の動作と設定 この機能を有効にするUIはありません。この機能を無効にする際にも、Windowsレジストリを編集する必要があります。 警告:レジストリの変更を行うときは注意が必要です。レジストリの値の変更時にエラーチェックはありません。     TWSの有効化/無効化 レジストリキー: HKEY_LOCAL_MACHINE\SOFTWARE\Palo Alto Networks\TS Agent\Conf\EnableTws デフォルト値: 0    [0-無効, 1-有効] 変更が反映されるようにTerminal Server Agentサービスを再起動します。   未使用ポートブロックの定期的な消去: レジストリキー: HKEY_LOCAL_MACHINE\SOFTWARE\Palo Alto Networks\TS Agent\Conf\FreePortBlockDelay デフォルト値: 240  (秒), 0の場合タイマーは無効 この値の変更は自動的に適用されるため、サービスを再起動する必要はありません ドライバによる多くのクリーンアップ動作を引き起こすため、FreePortBlockDelay を極端に短くし、積極的に動作させるべきではありません。この値はシステムのデフォルトの Timed Wait Delay(TcpTimedWaitDelay)の 240秒 に一致させることをお勧めします。   解決方法 多くのTime Wait 接続のためにポートが枯渇した場合は、次のレジストリを変更してください。   Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpTimedWaitDelay Value: 30 Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\StrictTimeWaitSeqCheck Value: 1 Key: HKEY_LOCAL_MACHINE\SOFTWARE\Palo Alto Networks\TS Agent\Conf\EnableTws Value: 1 Key: HKEY_LOCAL_MACHINE\SOFTWARE\Palo Alto Networks\TS Agent\Conf\FreePortBlockDelay Value: 30 2番目のregedit値がない場合には、手動で追加する必要があります。これらの値は Windows カーネルに、TcpTimedWaitDelay 設定の代わりに、カーネルに30秒以内にこれらのポートを解放するよう通知します。これらの設定がない場合、Windowsカーネルは、ビジー状態等が発生した際にポートを解放するのを遅延させる可能性があります。   最初の2つの値は、WindowsカーネルにTime_Waitedポートを30秒以内に解放するように指示します(デフォルトのカーネル値:240秒)。 TSエージェント側でこのような値を短くする場合は、一貫性を保つために Windows カーネルの値も短くする必要があります。   注:ターミナルサーバーエージェントサービスは、TSエージェントのレジストリ値を変更した後にサービスを再起動する必要があります(3番目と4番目の値)。 カーネルの Tcpip スタックの パラメータ(最初と2番目の値)が変更された場合、Windows OSを再起動する必要があります。     owner: sberti
記事全体を表示
dyamada ‎03-26-2017 06:23 PM
6,174件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 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
記事全体を表示
hshirai ‎03-21-2017 11:02 PM
9,192件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Policy-based forwarding doesn't work for traffic sourced from the Palo Alto Networks firewall https://live.paloaltonetworks.com/t5/Management-Articles/Policy-based-forwarding-doesn-t-work-for-traffic-sourced-from/ta-p/58821     問題 あるゾーンからISP経由でインターネットへ向かうすべてのトラフィックを転送するためにポリシー ベース フォワーディング (PBF) ルールを設定している場合、そのルールは、Palo Alto Networksファイアウォールの背後にある端末にだけ適用されるが、ファイアウォール自身を送信元とするトラフィックには適用されない。   原因 PBFルールに加えてルートがルーティング テーブルにある場合、最初にPBFルールだけが上から順番に評価されます。しかし、これはファイアウォールの背後にある端末にだけ適用されます。PBFがTrustゾーンからUntrustゾーンへ向かうすべてのトラフィックを転送するよう設定されていると、Palo Alto Networksファイアウォールの背後にある端末を送信元とするトラフィックにのみ、ルールが適用されます。しかしファイアウォールを送信元とするトラフィックは、PBFテーブルの評価をバイパスし、代わりに出力インターフェイスからトラフィックを転送するルートに合致するかのルーティング テーブルの評価が開始されます。   WebGUIから、[ Network ] > [ インターフェイス ] > [ Ethernet ] を開きます。続くシナリオでは、インターフェイスは以下の通り設定されています:   [ Network ] > [ 仮想ルーター ] > [ スタティック ルート ] 内に、デフォルト ルートが以下の通り設定されています:   端末から来ているトラフィックである場合、セッション情報は以下の通り表示されます:   WebGUIから、[ Policies ] > [ ポリシー ベース フォワーディング ] を開き、以下のデフォルト ルートと同じPBFルールを作成します:   端末から来ているトラフィックの場合、セッション情報は以下の通り表示されます(デフォルト ルートがあるにもかかわらず、PBFルールだけがまず評価されています):   ファイアウォールの背後にある端末からや、ファイアウォールの信頼済みインターフェイスから、パブリックなIPアドレス 4.2.2.2 へ継続的なPingをすると、どちらもPingは成功しました。これはPBFルールを使用する端末からのトラフィックであるため、そしてルーティング テーブルを使用しているファイアウォールからのトラフィックであるためです:   デフォルト ルートだけが削除し、端末からのトラフィックはPBFルールを使用して通過することに成功していますが、デフォルト ルートが削除されたため以下の通りファイアウォールからのトラフィックは失敗しました:   PBFは、ファイアウォールの背後にいる端末からのトラフィックに対してのみ動作し、ファイアウォールからのトラフィックに対しては動作しません。   以下が既知の制限事項となります: PBFは、Palo Alto NetworksファイアウォールへのIPsecトンネルのトラフィックには機能しません。 PBFは、フェーズ1トンネルに対して機能しないので、IKEを開始するためにルーティング テーブルのデフォルト ルートを使用する必要があります。 PBFは、GlobalProtect接続に対して機能しません。 PBFルールのためにアプリケーションを使用している場合、TCPトラフィックに合致するアプリケーションのシグネチャは、3ウェイ ハンドシェイクの後に識別されます。そのため、PBFルールは、最初の3ウェイ ハンドシェイクには合致しないかもしれず、ルート探索にだけ基づいてファイアウォールを通過します。   著者:dantony
記事全体を表示
hshirai ‎03-21-2017 08:41 PM
12,536件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Configure LDAP Server Profile https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-LDAP-Server-Profile/ta-p/58689   手順 Device をクリック Server Profiles 配下にある LDAP をクリック Add をクリックして LDAP Server Profile ダイアログを表示 Server名、IP Address、ポート番号を入力 (389 はLDAP) LDAP サーバー type をドロップダウン メニューから選択。ドメインのベース識別名 (Base Distinguished Name) を入力。バインドDN と そのサーバー アカウントのバインド パスワードを入力。SSL のチェックボックスをはずす。 (ドメイン コントローラーが ポート 636 で LDAP SSL を待ち受けている場合、SSLが利用可能) 変更をCommit   著者: bnelson
記事全体を表示
dyamada ‎03-19-2017 11:42 PM
5,483件の閲覧回数
0 Replies
対象 旧WildFire Japan クラウド wildfire.paloaltonetworks.jp をご利用されていた全てのお客様   概要 旧WildFire Japanクラウドドメイン(wildfire.paloaltonetworks.jp)に接続されてるファイアウォールに 対し、実施しておりました、現WildFire Japanクラウドドメイン(jp.wildfire.paloaltonetworks.com)へ のリダイレクト処理についてですが、2017年4月15日16:00(日本時間)まで延長させていただくことに致しました。   これにより、下記の”WildFire Japan アップデート”にてご案内致しておりましたリダイレクト期間は、下記のとおり延長させていただくことになりました。     移行期間開始日:2016年12月15日((日本時間)   移行期間終了日:2017年 4月15日(日本時間)   ”WildFire Japan アップデート”の内容をご確認いただく場合、こちらのURLの情報をご参照ください。 https://live.paloaltonetworks.com/t5/%E3%83%8A%E3%83%AC%E3%83%83%E3%82%B8%E3%83%89%E3%82%AD%E3%83%A5%E3%83%A1%E3%83%B3%E3%83%88/WildFire-Japan-%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88/tac-p/132607#M251 お客様の機器で旧WildFire Japanクラウド(wildfire.paloaltonetworks.jp)が指定されていた場合、2017年4月15日16:00(日本時間)まではWildFireにて提供される、シグニチャのアップデートと脅威防御の機能をご利用いただけます。 2017年4月15日16:00(日本時間)以降上記のリダイレクト処理を停止致しますので、旧WildFire Japanクラウドドメイン(wildfire.paloaltonetworks.jp)に接続されてるファイアウォールはWildFire Japanクラウドへの接続処理やサンプルの転送が適切に実施されません。そのため、2017年4月15日16:00(日本時間)までに、下記の移行手順を実施くださいますようお願いいたします。移行手順を実施いただいていないファイアウォールは、FirewallによるWildFireクラウドへの未知の検体の転送処理/ならびに防御が正常に実施されません。   実施していない場合、Firewallでtest wildfire registrationを実施した場合、失敗し、wildfire registration:の結果がfailedとなります。以下がtest wildfire registrationコマンドが失敗した際のサンプル出力となります。 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> admin@PA-200> test wildfire registration This test may take a few minutes to finish. Do you want to continue? (y or n) Test wildfire Public Cloud Testing cloud server jp.wildfire.paloaltonetworks.com ... wildfire registration: failed >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   移行手順 ファイアウォール上にて、WildFire Japan クラウドドメインの設定を jp.wildfire.paloaltonetworks.com に変更します。 WildFire Test PEファイルを使用し、新しいWildFire Japanクラウド設定が機能していることを確認します。 参考資料 1. PAN-OS 設定変更 PAN-OSにおけるWildFire クラウドのドメイン変更方法は以下に記載されています。 https://www.paloaltonetworks.com/documentation/70/pan-os/pan-os/getting-started/enable-wildfire WildFire 管理者ガイド: https://www.paloaltonetworks.jp/content/dam/paloaltonetworks-com/ja_JP/Assets/PDFs/technical-documen... WildFire FAQ 日本語版: https://live.paloaltonetworks.com/t5/Threat-Articles/WildFire-Japan-FAQ-日本語版/ta-p/54621 2. APIの変更 APIを使用する際もドメインをwildfire.paloaltonetworks.jp からjp.wildfire.paloaltonetworks.comへの変更が必要です。 例えば、WildFire Japanクラウドから検体のVerdictを取得するcurlコマンドは以下のようになります。 curl -F 'こちらにご利用のAPIキ-を指定してください' -F 'hash=こちら に対象のサンプルのsha256を指定してください' 'https://jp.wildfire.paloaltonetworks.com/publicapi/get/verdict' 以下はWildFire API に関するドキュメントとなります。 https://www.paloaltonetworks.com/documentation/71/wildfire/wf_api/about-the-wildfire-api
記事全体を表示
kkawachi ‎03-16-2017 10:21 PM
5,761件の閲覧回数
0 Replies
対象 旧WildFire Japan クラウド wildfire.paloaltonetworks.jp をご利用されていた全てのお客様   概要 2017年3月15日16:00 (日本時間) に、WildFireクラウドのバージョンアップの移行期間(90日)の完了をもちまして、wf10.wildfire.paloaltonetworks.jpを停止させていただきます。 これにより、wf10.wildfire.paloaltonetworks.jpを使用したWildFireポータルから、2016年12月15日9:00(日本時間) 以前に作成された以下のデータの取得が実施できないようになります。 ・過去のレポートの取得 ・Malware検体の取得 ・PCAPファイルの取得 WildFire Japan アップデート: https://live.paloaltonetworks.com/t5/ナレッジドキュメント/WildFire-Japan-アップデート/tac-p/132607#M251 2016年12月15日9:00(日本時間)以後に作成されたレポート/マルウェア検体/PCAPファイルについては、現状のWildFireクラウドのFQDN (jp.wildfire.paloaltonetworks.com) のWildFireポータルからの取得が行えます。 ※上記はWildFireポータルのほか、WildFire API、PAN-OS、Trapsからも可能です。 ※現状のWildFireクラウド (jp.wildfire.paloaltonetworks.com) のデータ保存期間については,以下のKBに添付 されておりますドキュメントをご参照ください。 https://live.paloaltonetworks.com/t5/Threat-Articles/WildFire-Japan-FAQ-日本語版/ta-p/54621 旧ドメイン(wildfire.paloaltonetworks.jp)に接続されているFirewallについては、 お客様の作業にて、新ドメイン (jp.wildfire.paloaltonetworks.com) をWildFireの設定情報として 変更する必要があります。実施いただかない場合、FirewallによるWildFireクラウドへの未知の検体の転送処理/ならびに防御が正常に実施されません。 上記の構成変更を実施していない場合、Firewallでtest wildfire registrationを実施した場合、失敗し、 wildfire registration:の結果がfailedとなります。 以下がtest wildfire registrationコマンドが失敗した際のサンプル出力となります。   >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> admin@PA-200> test wildfire registration This test may take a few minutes to finish. Do you want to continue? (y or n) Test wildfire Public Cloud Testing cloud server jp.wildfire.paloaltonetworks.com ... wildfire registration: failed >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 参考資料: PAN-OSにおけるWildFire クラウドのドメイン変更方法は以下のURLもしくは、WildFire 管理者ガイドをご参照ください。 https://www.paloaltonetworks.com/documentation/70/pan-os/pan-os/getting-started/enable-wildfire   WildFire 管理者ガイド: https://www.paloaltonetworks.jp/content/dam/paloaltonetworks-com/ja_JP/Assets/PDFs/technical-documentation/wildfire-70/WildFire_Administrator_Guide-7.0-Japanese.pdf
記事全体を表示
kkawachi ‎03-09-2017 10:29 PM
5,279件の閲覧回数
0 Replies
JPのIPアドレスの問題に特化したトラッカーです。   日付 報告バージョン IPレンジ 変更内容 修正バージョン (内部 ID) 2016-01-03 548 158.198.0.0/16 CN -> JP 551 89899  2016-06-02 586 158.198.140.0 - 158.199.140.255 CN -> JP 587 97237 2016-08-11 603 210.226.32.0- 210.226.35.255 AU -> JP 607 102212 2016-08-23 607 (603) 210.140.196.0/22 CN -> JP 609 103035 2016-08-18 606 (603) 158.199.128.0/19 158.199.192.0/19 160.16.192.0/20 210.140.64.0/21 210.140.96.0/21 210.140.55.00 - 210.140.79.255 210.140.85.00 - 210.140.109.255 CN -> JP 609 102755 2016-08-30 607 (603) 153.126.145.0 - 153.126.159.255 CN -> JP 615 103506 2016-08-30 607 (603) 158.199.192.0 - 158.199.200.255 CN -> JP 615 103506 2016-08-30 607 (603) 160.16.195.0 - 160.16.199.255 CN -> JP 615 103506 2016-08-30 607 (603) 160.16.243.0/24 CN -> JP 615 103506 2016-08-30 607 (603) 210.129.19.0 - 210.129.26.255 CN -> JP 615 103506 2016-08-30 607 (603) 210.152.241.0 - 210.152.250.255 CN -> JP 615 103506 2016-09-01 610 (603) 210.129.18.0/24 CN -> JP 615 103807 2016-08-30 608 (603) 210.140.193.128/27 210.140.191.0 - 210.140.199.255 CN -> JP 615 103495 2016-09-06 610 (603) 210.151.32.0/20 CN -> JP 615 103913 2016-08-30 608 (603) 160.16.224.0/19 160.16.224.0 - 160.16.255.255 CN -> JP 626 103496 CON-25963 2016-09-23 615 153.126.128.0 - 153.126.144.255 210.129.27.0 - 210.129.31.255 CN -> JP 622 105312 CON-26226 2016-09-23 615 158.199.217.85 158.199.212.115 158.199.201.0 - 158.199.210.255 158.199.211.0 - 158.199.224.255 CN -> JP 622 105303 CON-26224 2016-08-18 606 (603) 158.199.158.129 158.199.137.0 - 158.199.191.255 CN -> JP 622 102755 103506 105101 CON-26184 2016-09-23 615 158.199.157.0 - 158.199.159.255 CN -> JP 622 CON-26184 2016-10-17 623 (603) 210.170.99.178 210.170.99.179 210.148.58.0 - 210.175.255.255 SG -> JP 626 CON-26461 2016-10-26 625(625) 160.16.200.0 - 160.16.255.0 CH -> JP 626 -  
記事全体を表示
ymiyashita ‎03-08-2017 08:21 PM
9,631件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Resolving the URL Category in Decryption When Multiple URLs Use the Same IP https://live.paloaltonetworks.com/t5/Management-Articles/Resolving-the-URL-Category-in-Decryption-When-Multiple-URLs-Use/ta-p/62573   PAN-OS 6.0 問題 Google のように同一 IP アドレスに紐付く複数の Web サービス (Google ドライブ、翻訳、ウェブ検索、Google+、マップ、Google Play、Gmail、カレンダーなど) がある場合に問題が発生します。   DNS が www.google.com と www.drive.google.com の両方を同じ IP アドレス(例:173.194.78.189)に解決する場合、ホストは google.com と drive.google.com の両方で同じ IP アドレスを使用します。そのため、最初のセッションで処理されるトラフィックが www.google.com の場合、ローカル キャッシュは IP アドレス 173.194.78.189 を "search-engines" にマッピングします。その後、次のホストが同じ宛先 IP アドレスを使用して www.drive.google.com にアクセスした場合、URL カテゴリは "online-personal-storage" ではなく "search-engines" にマッピングされます。 "online-personal-storage" のカテゴリを復号化するように設定された復号化ポリシーは、"search-engines" にマッピングされたトラフィックにマッチしないので、drive.google.com へアクセスした際のトラフィックは復号化されません。   詳細 SSL 復号化に関する問題のトラブルシューティングの際には、まず初めに復号化メカニズムが URL  カテゴリとどのように機能するかを理解することが肝心です。セキュアな SSL トンネルを確立するために、クライアントとサーバーは SSL ハンドシェイクを実施し、クライアントは通常、サーバ証明書に基づいてサーバーを認証します。HTTPS 接続は常にクライアントによって開始され、最初にサーバー URL を名前解決した後、名前解決した IP アドレス宛に Client Hello メッセージを送信します。クライアントはサーバー側からサーバー証明書を含む応答を待ちます。   適切な URL カテゴリに解決した上で、SSL トラフィックを復号化するかどうかを決定するために、Palo Alto Networks ファイアウォールはサーバーから受信した証明書のコモン ネーム (CN) フィールドを使用します。そのため、URL のカテゴリ識別はサーバー証明書の CN フィールドに基づいて行われます。解決された URL カテゴリはクライアント側から送信されたパケットの宛先 IP アドレスにマッピングされます。URL カテゴリを識別する処理を高速化するために、ファイアウォールはローカル キャッシュ メモリに各 URL と宛先 IP アドレスのマッピング情報を格納します。したがって、次に同じ宛先 IP アドレスへの SSL トラフィックが発生した際は、既にローカル キャッシュ ファイルに格納されている URL カテゴリで解決されます。復号化のための URL カテゴリのメカニズムは次のようになります: ファイアウォールによって Client Hello メッセージがインターセプトされます ファイアウォールはパケットの宛先 IP を決定します ファイアウォールは宛先 IP とローカル キャッシュ メモリに保存されている IP, URL カテゴリのマッピングリストを比較します リストに同じ IP が存在した場合、URL カテゴリはローカル キャッシュ メモリのリストで識別されます ローカル キャッシュのリストに同じ IP が存在しなかった場合、ファイアウォールはサーバー証明書の CN フィールドを確認するために、サーバーからの応答を待ちます URL カテゴリ識別が CN フィールドに基づいて行われ、サーバーの IP と URL カテゴリがマッピングされるとともに、次回以降に利用するためにローカル キャッシュ メモリのリストに追加されます   解決方法 PAN-OS 6.0 以降では SSL 復号化の適正化を目的として URL のカテゴリ識別の新しい方法を導入しました。この新しい方法はサーバー証明書の CN フィールドに基づくのではなく、SSL Client Hello メッセージの SNI (Server Name Indication) 値に基づきます。この方法を使用すると各状況下で Palo Alto Networks のファイアウォールがアップ ストリーム トラフィックの URL カテゴリを適切に識別し、その情報を基に正しい復号化ポリシーを適用することができます。     注意: Windows XP の最終バージョンである IE 8.0 のような古いバージョンのブラウザでは SNI フィールドはサポートされていません。そのため、SNI を用いたこの解決方法は Windows XP や古いバージョンのブラウザを使用しているクライアントでは機能せず、引き続き CN フィールドを用いて識別されます。   著者: djoksimovic  
記事全体を表示
tsakurai ‎03-08-2017 08:02 PM
5,323件の閲覧回数
0 Replies
概要: ETL (イベントトレースログ) は Traps の動作を詳細に記録するためのものです。 標準のサービスログには問題が記録されない場合には本データを採取することで有用な情報が取得される見込みがあります。例えば、他社製品との互換性の問題(EPM 保護対象のプロセスの動作に問題が発生する)や Traps の導入後に特定の操作でプロセスがクラッシュするようになった等の問題を調査するために有効な情報です。 本稿では ETL の取得手順を説明いたします。   ※ ETL はバイナリ形式で記録されます。採取した ETL についてはユーザー様側でデコード、閲覧することはできません。調査をご要望の際には弊社のサポートまでお問合せください。   対象とする Traps のバージョン: Traps Version 3.4.x   手順:   A.) ETL の採取開始 --------------------------------------------- 1. ETL 取得対象のコンピューターにログインします。   2. コマンドプロンプトを開きます。   3. Traps インストールフォルダーへ移動します。 (デフォルトパス: C:\Program Files\Palo Alto Networks\Traps)   4. 下記のコマンドを実行します。 cytool log start * Verbose <Log_size> (log_size*1024KB)   >例 cytool log start * Verbose 500   * 上記例は 500MB の場合です。記録されるデータの容量は環境および利用状況によって大幅に変化します。 例えば、問題を再現させた後にログの記録を停止した結果、設定したデータ容量と同様のログファイルが記録されている場合は既に現象発生前後のデータが上書きされている可能性があります。この場合にはログサイズを増やした上で再度データを取得してください。 * 実施前に、ディスクに十分な空き領域があることをご確認ください。 * Log_size で指定した容量を超えた場合にはデータはローテーションされ上書きされます。   5. Traps アンインストールパスワード を入力します。データ採取が開始されます。   B.) 現象の確認と ETL の採取停止 --------------------------------------------- 1. 現象を再現させます。 現象再現にコンピューターの再起動が必要な場合には、再起動後に問題が発生したことを確認した上で ETL 採取を停止します。   2. 下記のコマンドを実行し、ETL のログ出力を停止します。 cytool log stop   3. ログは "%PROGRAMDATA%\Cyvera\Logs\" パス内に以下のような名称で記録されます。   >名称 native.<Version>.<Build>.etl   ※ 再現手順にOSの再起動が含まれている場合、以下のような追加のログが記録されます。 native_autolog.3.4.3.19949.etl.001 C.) サポートファイルの取得 --------------------------------------------- GetLogsUtil、Send Support File(サポートファイルの送信) または One Time Action(OTA)を使用してログを収集します。以下は Traps エージェント上で GetLogsUtil を利用してデータを採取する手順です。   1. コマンドプロンプトを起動します。   2. Traps インストールフォルダーへ移動します。 (デフォルトパス: C:\Program Files\Palo Alto Networks\Traps)   3. 下記のコマンドを実行します。 GetLogsUtilAgent C:\temp   4. C:\temp フォルダに、ログファイルの圧縮データが作成されます。 ETL のログは他のデータと併せてサポートファイル内に含まれます。     以上となります。   
記事全体を表示
hsasaki ‎03-06-2017 11:38 PM
4,270件の閲覧回数
0 Replies
概要: ESM コンソールの Hash Control のページでは、あらかじめ用意された Hash 情報をファイルベースで取り込む("Import Hashes") ことが可能です。本記事ではその手順を説明いたします。   対象とする Traps のバージョン: Traps Version 3.4.x   事前準備: 事前に登録対象の実行ファイル名および SHA 256 形式のハッシュの対応情報をサードパーティー製のツール等により取得してください。本例ではそれらの情報を元に Excel を利用してESM に登録可能なフォーマットでファイルを作成します。   手順:   1. ) 初めに Excel でブランクのシートを1つ用意します。       2.)  1行目に次の 2つの列を追加します。 列:A に "Path" を追加  ( "二重引用符" なし ) 列:B に "SHA256" を追加 ( "二重引用符" なし)     3.) この2つのカラムに登録対象の実行ファイル名およびハッシュ情報を入力します。 ------------------------------------ Path = 実行ファイル(プロセス)名 SHA256 = ハッシュ情報 ------------------------------------   データをコピーペーストするか、あらかじめ用意されたデータを "外部データの取り込み" によって取り込みます。    4.) 入力済みのセルを選択した上で 右クリック -> "セルの書式設定" を行います。   5.)  セルの書式設定のダイアログで、[ユーザー定義] の [種類] に  !"@!"  を入力します。     6.) セルの書式設定を行うと以下のように""で囲まれた状態になります。ファイルを保存します。 保存形式は CSV 形式とします。       7.) ESM コンソールを開き、 Hash Control のページから "Import Hashes" を選択します。   8.)  Import hashes only (Recommended) を選択した上で "Browse" をクリックして、登録対象のファイルを選択して、 "Upload" ボタンをクリックします。     9.) ハッシュが正常にインポートされた旨のダイアログが表示されます。[OK]をクリックします。 ※ファイルフォーマットや記述内容に問題がある場合はエラーが表示されます。     以上となります。
記事全体を表示
hsasaki ‎02-27-2017 08:57 PM
3,685件の閲覧回数
0 Replies
  概要: 本記事では ESM サーバーの Tech Support ファイルを分析することで Traps エージェントのハートビートの間隔およびポリシールールを特定する方法を記載します。 ハートビートの間隔が短い (10分 あるいは 3分等) ことで、ESM サーバーのリソース消費(CPU 及び メモリ)に著しい影響を与えるケースがあります。テスト目的等で作成した設定が残存していることで予期しない影響を招く場合があります。短いハートビート間隔は、Traps エージェントの台数が比較的少ない場合はパフォーマンスに大きな影響は発生しません。しかしながら、Traps エージェントの展開台数の規模によっては ESM サーバーに予期しない負荷に至るケースがあります。   ※ Traps エージェントのハートビートは Traps エージェント自身が稼働中であることをESM サーバーに報告することのみならず、ESM サーバー側に存在する最新のポリシーの要求、ライセンスの有効性確認等、様々な処理が行われます。そのため、この間隔が短いことで ESM サーバー側の処理負荷を招く可能性があります。 通常の利用環境下ではハートビートの間隔はデフォルトのポリシーである 60分 を使用することを推奨いたします。   対象とする Traps のバージョン: Version 3.4.x   手順:   A.) ESM サーバーのログ分析 ================================ 初めに ESM サーバーで採取した Tech Support ファイルのサービスログよりハートビートの動作を確認します。 ESM サーバーで取得した Tech Support ファイルを展開すると、さらに "Core_<コンピューター名>.zip" および "Console_<コンピューター名>.zip" の2つのファイルが展開されます。 それぞれの zip ファイルを展開してください。 ESM サーバーのサービスログ (ファイル名: Server_<コンピューター名>.log) は Core 側の Logs フォルダに存在します。 これらの ログより、ある Traps エージェントのマシン名を選択し、そのハートビートの間隔を調べます。 これは ハートビートセッションが 2回発生している間の時間差を測ることで判明します。   ログ内の次の文字列を探します。これはESMサーバーがTrapsエージェントのコンピューターからハートビートを受け取り、処理を終了したことを示します。これが1回のハートビートセッションとなります。   -------------- Started handling HeartbeatEx call from machine Finished handling HeartbeatEx call from machine --------------    次の例では、2つのエージェント("CLIENT1" および "CLIENT2") のハートビートの間隔が3分であることが判ります。 通常利用環境において 3分は短すぎる値です。   >ログの例 ※ Started および Finished の間には実際に行われた処理を示すログが記録されます。(本例では割愛) -------------- 2017-01-26 14:06:56.8055 DEBUG CyveraServer 104 Cyvera.Server.Facades.ClientServices Heartbeat Started handling HeartbeatEx call from machine CLIENT1 2017-01-26 14:06:56.9303 DEBUG CyveraServer 104 Cyvera.Server.Facades.ClientServices Heartbeat Finished handling HeartbeatEx call from machine CLIENT1 2017-01-26 14:09:56.7795 DEBUG CyveraServer 146 Cyvera.Server.Facades.ClientServices Heartbeat Started handling HeartbeatEx call from machine CLIENT1 2017-01-26 14:09:56.8107 DEBUG CyveraServer 146 Cyvera.Server.Facades.ClientServices Heartbeat Finished handling HeartbeatEx call from machine CLIENT1 2017-01-26 14:09:59.4473 DEBUG CyveraServer 209 Cyvera.Server.Facades.ClientServices Heartbeat Started handling HeartbeatEx call from machine CLIENT2 2017-01-26 14:09:59.4785 DEBUG CyveraServer 209 Cyvera.Server.Facades.ClientServices Heartbeat Finished handling HeartbeatEx call from machine CLIENT2 2017-01-26 14:12:59.4575 DEBUG CyveraServer 122 Cyvera.Server.Facades.ClientServices Heartbeat Started handling HeartbeatEx call from machine CLIENT2 2017-01-26 14:12:59.6603 DEBUG CyveraServer 122 Cyvera.Server.Facades.ClientServices Heartbeat Finished handling HeartbeatEx call from machine CLIENT2 --------------   B.) ユーザー定義のポリシールールの確認 ================================ ESM サーバーの Tech Support ファイルにはデータベース上に存在する各種情報を出力した結果も含まれます。 これらのファイルは Console 側フォルダの "DBQueries" フォルダの内に存在します。     "DBQueries" フォルダを開きます。       "Active_user_rules.csv" には、Traps 環境において Active となっているユーザ定義の全ルールが含まれています。 テキストエディタ等でファイルを開き、"HeartBeat" の文字列を検索します。   例えば以下のルール(ID 3645)には、ユーザーが定義したハートビート設定のルールが存在していることが判ります。 ------------------- 3645 Agent Setting - 2017/02/22 14:38 Agent settings: Heartbeat interval have been set on all computers where CLIENT1 and CLIENT2 included True Active EndPointSettings 0 -------------------   本ルールが意図して作成されたものか、あるいは値は意図したものかを確認した上で必要に応じてルールを編集、削除あるいは無効化してハートビートの値を修正します。   以上となります。  
記事全体を表示
hsasaki ‎02-22-2017 10:50 PM
2,925件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Firewall unable to respond 'reset' to malicious content and HTTP response https://live.paloaltonetworks.com/t5/Management-Articles/Firewall-unable-to-respond-reset-to-malicious-content-and-HTTP/ta-p/98405   症状 Antivirus Profile Actionにreset-bothを適切に構成していても、脅威の存在するコンテンツとHTTPレスポンス コードがひとつのパケットで送信された場合では、FirewallがRSTで応答しないケースがあります。   この動作については制限事項となり、本ナレッジベースではその詳細を説明しております。本制限事項は、eicar test file (eicar_com.zip)を、Eicarのサイト(http://www.eicar.org/)からダウンロードする試験をした場合、発生することがあります。 その際、以下の点が確認できます。   ブラウザからeicar test file (eicar_com.zip)を、Eicarのサイト(http://www.eicar.org/)よりダウンロードした場合、Firewall は "Virus/Spyware Download Blocked" ページをブラウザに応答します。 "Virus/Spyware Download Blocked" ページが応答に使用されているにも関わらず、構成されたアクション(今回の場合は、reset-both) がThreat logのイベントにおいて、トリガされたアクションとして記録されます。 対して、お客様がeicar test file (eicar_com.zip) を、お客様社内のWebサーバ上に置き、Firewallを経由して eicar test file (eicar_com.zip)をダウンロードする試験をした場合、以下の点が確認できます。   "reset-both" が期待通り応答に利用され、FirewallからブラウザにRST が送信される。 構成されたアクション(今回の場合 reset-both)が期待通り、Threat logのイベントにおいてトリガされたアクションとして記録されます。   ケース 1 ケース1では、本制約がどのように症状に関わってくるのかを説明しております。 例として、ブラウザからeicar test file (eicar_com.zip)を、Eicarのサイト(http://www.eicar.org/)よりダウンロードした場合にやり取りされるHTTP通信を使用します。この通信では、EicarのサイトのIPアドレスを188.40.238.250、ブラウザのIPアドレスを1.1.1.4とします。   以下のスクリーンショットは、 eicar test file (eicar_com.zip)をEicarのサイト(http://www.eicar.org/)よりダウンロードした場合にやり取りされるHTTP通信のパケットキャプチャとなります。 ブラウザとEicarのサイト間で実施されているHTTP通信において、以下の内容が順番に発生していることが上記のスクリーンショットから判ります。   ブラウザが、No 809 のパケットで "GET /download/eicar_com.zip HTTP/1.1"を送信しています。 Eicarのサイトが、No 812のパケットで EicarのTestvirusのパターンとHTTPレスポンスコード200を一つのパケットとして送信しています。 Firewallが、No 813のパケットで "HTTP/1.1 503 Service Unavailable" を"Download of the virus/spyware has been blocked in accordance with company policy. Please contact your system administrator if you believe this is in error"とともにブラウザに対し送信しています。(RSTが送信されていない。) 以下のスクリーンショットは、ケース1の通信により発生したイベントがThreat Logに記録された内容となります。 Firewallが"HTTP/1.1 503 Service Unavailable"をブラウザに送信しているにも関わらず、reset-both がThreat logのイベントにおいて、トリガされたアクションとして記録されています。 ケース 2 ケース2では、FirewallがEicarのTestVirusに対し、 構成されたアクションのとおりRST を送信している動作を説明しております。例として、ブラウザからeicar test file (eicar_com.zip)を、お客様の社内サイトよりダウンロードした場合にやり取りされるHTTP通信を使用します。この通信では、お客様の社内サイトのIPアドレスを10.128.128.218、ブラウザのIPアドレスを1.1.1.4とします。   以下のスクリーンショットは、 eicar test file (eicar_com.zip)をお客様の社内サイトよりダウンロードした場合にやり取りされるHTTP通信のパケットキャプチャとなります。  お客様の社内サイトよりダウンロードした場合に、お客様の社内サイトがEicarのTestvirusのパターンとHTTPレスポンスコード200を2つのパケットに分割して、No 2004 とNo 2005のパケットで送信している点に留意してください。上のスクリーンショットで赤く囲われた箇所が、パケットの分割が実施されている様子を示す内容です。   ブラウザとお客様の社内サイト間で実施されているHTTP/TCP通信において、以下の内容が順番に発生していることが上記のスクリーンショットから判ります。   ブラウザが、No 2002のパケットで、"GET /download/eicar_com.zip HTTP/1.1"を送信しています。 お客様の社内サイトが、No 2004とNo 2005のパケットにおいて、EicarのTestvirusのパターンとHTTPレスポンスコード200を2つのパケットに分割して送信しています。 次に、No 2010のパケットで、FirewallがRSTをブラウザに送信しています。("HTTP/1.1 503 Service Unavailable"ではなく) さらに以下のスクリーンキャプチャでは、 No 2002とNo 2010 のパケットが同じTCPストリームで扱われていることが判ります。 以下のスクリーンショットでは、No 2004とNo 2005のパケットにおいて、2つに分割されたEicarのTestvirusのパターンとHTTPレスポンスコード200をお客様の社内サイトから受信した後に、FirewallがRSTをブラウザに送信している様子が判ります。   以下のスクリーンショットは、ケース2の通信により発生したイベントがThreat Logに記録された内容となります。 FirewallがRSTを送信し、reset-bothが期待通り、Threat logのイベントにおいて、トリガされたアクションとして記録されています。   著者: kkawachi
記事全体を表示
kkawachi ‎02-21-2017 02:41 AM
5,036件の閲覧回数
0 Replies
概要: 本記事では Traps エージェントのコンソール (Traps Console) の表示言語の設定が保持される場所について説明します。   対象とするTrapsのバージョン: Version 3.4.x   説明: Traps Console の表示言語は [設定] メニュー内の "インターフェイスの表示言語を選択:" で変更することが可能です。    Traps Console が使用している表示言語の設定はレジストリ上に保持されます。 ---------------------------------------------------- レジストリパス: [HKEY_CURRENT_USER\Software\Palo Alto Networks\Traps] 値:Localization ----------------------------------------------------    設定される値は以下のいずれかとなります。 ---------------------------------------------------- 1.en-US (英語) 2.de-DE (ドイツ語) 3.es-ES (スペイン語) 4.fr-FR (フランス語) 5.ja-JP (日本語) 6.zh-CN (簡体字中国語) 7.zh-TW (繁体字中国語) ----------------------------------------------------   なお、本設定をESMサーバー側から変更することはできません。   以上となります。  
記事全体を表示
hsasaki ‎02-14-2017 05:56 PM
3,159件の閲覧回数
0 Replies
概要: 本記事では、PowerShell コマンドを使用して、Traps エージェント側のコンピューターから ESM サーバーの Forensic フォルダに任意のファイルをアップロードすることによって、基本的なBITS 接続をテストする方法を記載します。 これにより、Traps エージェントを介在させることなく ESM サーバーへの BITS 接続を簡単にテストできます。   ※ BITS は、アイドル状態のネットワーク帯域幅のみを使用して、インターネット経由でファイルを転送するように設計された Windows OS 上のファイル転送サービスです。Traps ではフォレンジックデータおよびサポートファイルのESMサーバーの送信のために本サービスを利用します。   対象とするTrapsのバージョン: Version 3.4.x   事前準備: 1. Forensic フォルダの URL は ESM コンソールの次の箇所で設定します。 [Settings] タブ -> [ESM] -> [Settings] -> [Forensic Folder URL]   2. BITS (Background Intelligent Transfer Service) がテストを行うエージェント側のコンピューターで開始していることを確認します。     3. Forensicフォルダの物理パスは、ESMサーバーの IIS マネージャーで構成されています。 ESM サーバーのコマンドラインから管理者として "inetmgr"を開き、[サイト] -> [Default Web Site] -> [BitsUploads] をクリックします。続いて [操作] ペイン 内の [基本設定] をクリックします。 表示された "アプリケーションの編集" ダイアログ内の "物理パス" が実際の物理パスとなります。   4. 続いて、[アプリケーションプール] をクリックし、"ESMAppPool" が開始していることを確認します。 手順: 1.テストを行うエージェント側のコンピューターにログインし、PowerShell を管理者として実行します。   2.テキストファイルを作成します(例えば C:\ 配下に"test.txt" を作成します。)   3.コマンドの一般的なパターンは次のとおりです。 PS C:\Windows\system32> Import-Module BitsTransfer PS C:\Windows\system32> PS C:\Windows\system32> Start-BITStransfer -source '[test file full path]' -destination '[BITS URL/test file name]' -transfertype upload   4.コマンドを実行すると進行状況が表示され即座にアップロードが開始されます。   5.エラーが表示されない場合は、ファイルは ESM に正常に転送されています。 >実行例   7.ファイルがESMに正常にアップロードされている場合は、テストファイルが Forensic フォルダに存在していることが確認できます。     以上となります。
記事全体を表示
hsasaki ‎02-13-2017 10:00 PM
2,659件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 URL Filtering Order https://live.paloaltonetworks.com/t5/Management-Articles/URL-Filtering-Order/ta-p/59334   問題 URL Filtering プロファイルの中で URL が複数の箇所(複数のカスタム URL フィルタリング カテゴリや、許可/ブロック リスト)にマッチした場合、どうなりますか?   解答 その場合、下記の中で一番厳しいアクションが設定されたカテゴリが選択されます(block が最も厳しく、allow が最も軽い)。 block override continue alert allow   例えば、*.yahoo.com が同じ URL Filtering プロファイル内の MyAlertList と MyBlockList というカスタム カテゴリに同時に存在する場合、www.yahoo.com という URL に対するアクションは block となり、そのカテゴリは MyBlockList となります。これは、許可リストとブロック リストに同時にマッチする URL があった場合、許可リストより先にブロック リストがチェックされるのと同様です。 URL Filtering のプライオリティは以下の通りです。 ブロック リスト 許可リスト カスタム カテゴリ キャッシュ 事前定義済みのカテゴリ   著者:  ukhapre
記事全体を表示
hfukasawa ‎02-13-2017 12:55 AM
8,153件の閲覧回数
0 Replies
概要: 本記事では "Disable All Protection" (すべての保護を無効化) の設定を行った後に確認するべきポイント等を説明いたします。Trapsでは、"Disable All Protection" を設定することで、EPM によるTraps インジェクション 及びWildFire での検証等を含め、Traps の保護機能を全て無効化することが可能です。 Trapsの導入後に保護対象のコンピューターに何らかの問題が発生した場合や、Traps のポリシーの変更によって新たに問題が発生した場合には、本設定により問題の切り分けを行うことが可能です。   対象とするTraps のバージョン: Version 3.4.x   手順:  A.) Traps による保護を無効化する方法 ============================================== 1. ESM 管理コンソールより、"Disable All Protection" をクリックします。 [Policices] -> [Exploit Protection Module] あるいは [Malware] -> [WildFire]/[Restrictions]/[Restriction Modules] 内で表示されます。       2. 表示されたダイアログで "Yes" をクリックします。    ※ 設定は次回の Traps エージェントの ハートビート通信の際、更新されたセキュリティポリシーが反映されます。 設定は即座には反映されません。即座に反映する必要がある場合は Traps エージェント側で "今すぐチェックイン"をクリックして設定を反映してください。   3. 設定完了後は ESM コンソール内に Traps の保護が無効となっていることを示すメッセージが表示されます。     4. Traps エージェント側のコンソールは全ての保護が無効化された状態を示す表示に変化します。   TIPS: Traps エージェント側のサービスログには Disable All Protection の設定を受信したことを示す以下のログが記録がされます。 ----------------------------------------------------------------------------------------- 2017-02-12 16:21:34.5120 INFO CyveraService 15 Cyvera.Client.Service.Policy.PolicyManagerBase Policy Disabling protection on server request. -----------------------------------------------------------------------------------------   (補足) Disable All Protection の設定を行った場合でも、Traps エージェント側の Traps Service (CyveraService.exe) は起動した状態となります。 そのため、ハートビート及びポリシーの受信は引き続き実施されます。   B.) Traps による保護を有効化する方法 ============================================== Enable All Protection (すべての保護を有効化) をクリックします。 設定を有効化すると全てのポリシーが再度有効化されます。    ※ A.) 同様、設定は次回の Traps エージェントの ハートビート通信の際、更新されたセキュリティポリシーが反映されます。設定は即座には反映されません。即座に反映する必要がある場合は Traps エージェント側で "今すぐチェックイン"をクリックして設定を反映してください。        以上となります。  
記事全体を表示
hsasaki ‎02-12-2017 09:11 PM
2,866件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 ARP Entries Stay Cached for 30 Minutes https://live.paloaltonetworks.com/t5/Management-Articles/ARP-Entries-Stay-Cached-for-30-Minutes/ta-p/55717   概要 Palo Alto Networks ファイアウォールの ARP キャッシュタイムアウトは全てのインターフェイスの ARP エントリに対して30分 (1800秒)です。これは固定値であり設定変更により調整することはできません。   タイムアウト値を表示するには CLI にて "show arp all" コマンドを使用します。以下はPA-5060でのコマンド出力結果を抜粋したものです: > show arp all maximum of entries supported :      32000 default timeout:                    1800 seconds total ARP entries in table :        97 total ARP entries shown :           97 status: s - static, c - complete, e - expiring, i - incomplete   必要に応じて次の CLI コマンドを実行することでインテーフェイス毎に ARP エントリをクリアすることが可能です: > clear arp ethernet1/1   また、次のコマンドを実行すると全インターフェイスのARP エントリをクリアすることが可能です: > clear arp all   著者: gwesson  
記事全体を表示
tsakurai ‎02-09-2017 07:27 PM
5,639件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Palo Alto Networks Firewall not Forwarding Logs to Panorama (VM and M-100) https://live.paloaltonetworks.com/t5/Configuration-Articles/Palo-Alto-Networks-Firewall-not-Forwarding-Logs-to-Panorama-VM/ta-p/59799   事象 Palo Alto Networks M-100 デバイスまたは仮想アプライアンスとして導入されている Panorama が Palo Alto Networks ファイアウォールからログを受信しなくなる。トラフィック ログや脅威ログは、ファイアウォール上で直接確認すると見ることができるが、Panorama 上では見ることができない。   詳細 Palo Alto Networks ファイアウォールは Panorama に転送されたログをシーケンス番号を使用して記録します。ログが受信されると、Panorama はシーケンス番号を認識します。ファイアウォールが異なる Panorama (例えば、Panorama の HA ピア) に接続されると、これらのシーケンス番号は非同期となって、ファイアウォールがログを転送しなくなることがあります。ログのアップロード処理も、Panorama に送信された大量のログによってスタック (停滞) することがあります。   解決策   Panorama 5.0, 5.1, 6.0, 6.1, 7.0, 7.1 現在のログ状況を確認します > show logging-status device <シリアル番号> 最後に ACK されたログ ID からのログ転送をローカルディスクへのバッファリング有りで開始します > request log-fwd-ctrl device <シリアル番号> action start-from-lastack ログが転送されているかどうか確認します > show logging-status device <シリアル番号> ログが転送されていない場合、次のことを行います: ログ転送が停止していることを確認します > request log-fwd-ctrl device <シリアル番号> action stop バッファリング無しでログ転送を開始します (この状態で約 1 分間放置します) > request log-fwd-ctrl device <シリアル番号> action live ログ転送をバッファリング有りで開始します > request log-fwd-ctrl device <シリアル番号> action start   重要! シリアル番号内のアルファベット文字はすべて大文字である必要があります。例えば: > request log-fwd-ctrl device 0000C123456 action live scheduled a job with jobid 12   小文字が使用された場合は、次のエラーメッセージが返されます: > request log-fwd-ctrl device 0011c123456 action live Server error : failed to schedule a job to do log fwd ctrl from panorama to device 0000c123456   デバイスのポリシーにてログのアクションが Panorama への転送に設定されていることを確認します。 ロギングがスタックする場合は、log-receiver サービスを次のコマンドを使用して再起動します: > debug software restart log-receiver もしくは、次のコマンドを使用して Management Server を再起動します (log-receiver サービスも再起動されます): > debug software restart management-server   著者: swhyte
記事全体を表示
kishikawa ‎02-09-2017 07:27 PM
4,497件の閲覧回数
0 Replies
この記事は以下の記事の日本語訳です。 Incorrect QoS Configuration Caused Network Traffic Outage https://live.paloaltonetworks.com/t5/Configuration-Articles/Incorrect-QoS-Configuration-Caused-Network-Traffic-Outage/ta-p/62576 問題 特定のクラスに対してQoSプロファイルにて帯域を制限しようとすると、QoS機能により通信障害が発生する。   詳細 以下の例は、QoSを使用するインターフェイスに関連付けられた誤った設定の例です。 この例のシナリオでは、10Gbインターフェイスが使用されており、上記のスクリーンショットは最大保証帯域 出力側を100Mbpsと設定していることを示します。プロファイル部の最大保証帯域 出力側には、この10Gbインターフェイスを通過するトラフィックのための、すべてのクラスに対しての最大の出力帯域を設定します。   多くの場合に、上記の設定がユーザーより重度の輻輳や通信断の振る舞いとして報告される問題の原因となっています。   解決策 QoSプロファイルを設定するときは、該当のインターフェイスに流れ込む総合的な帯域を考慮し、最大保証帯域 出力側を慎重に設定する必要があります。前述の意図した設定は、class7 のトラフィックを最大保証帯域 出力側を100、そして最低保障帯域 出力側を10とすることでしたが、他のすべてのトラフィックも該当インターフェイスの残りの帯域を使用します。   以下のスクリーンショットは、プロファイルの最大保証帯域 出力側を10000Mbpsとし、class7 トラフィックの最大保証帯域 出力側を100、最低保障帯域 出力側を10とした 正しい設定です。   該当のQoS インターフェイス設定も正しい値で最大保証帯域 出力側が設定されている必要があります。   注: 必要なクラスのみをQoS プロファイルで設定するだけで構いません。他のトラフィックはデフォルトのclass4となります。   著者: fkhan
記事全体を表示
TShimizu ‎02-09-2017 07:16 PM
6,864件の閲覧回数
0 Replies
この記事は以下の記事の日本語訳です。 Using IP Address Lists on Palo Alto Networks Policies https://live.paloaltonetworks.com/t5/Configuration-Articles/Using-IP-Address-Lists-on-Palo-Alto-Networks-Policies/ta-p/57411     詳細 ファイアウォールのポリシーにて使用するIPアドレス リストおよびそのインポート手段には、複数の方法があります。   選択肢 定義済みの地域(Region)またはカスタムの地域の使用 定義済みの地域あるいはカスタムで作成した地域の使用法については How to Configure a Security Policy to Use a Region(訳注1)をご覧ください。 カスタムの地域は単体のIP(x.x.x.x)、範囲指定(x.x.x.x-y.y.y.y)ないしはIP/ネットマスク(x.x.x.x/n)となります。もしカスタムの地域を使用しており、そして隣接していないアドレス体系をWeb GUIかCLIで手動で追加した場合、CLI端末上でのコマンドのリストをコピーしたり、バッチ処理したりすることができます。   > configure # set region <RegionName> # set region <RegionName> address <IPAddress_01> where <RegionName> is a string (31 characters max) <IPAddress> is a list of values, an IP range, or ip/netmask   エントリーの削除 # delete region <MyRegion> address <IPAddress_nn>   使用しているすべての地域の削除 # delete region <MyRegion> 注: 変更後はコミットを実行してください。   FQDNアドレスオブジェクトの使用 DNS Aレコードは権威のない複数の回答に関連付けられます。Palo Alto Networks ファイアウォールは権威のない回答のうち最初の10個の回答のみを読み込んでキャッシュします。この動作の詳細はFQDN オブジェクトの設定およびテスト方法を参照してください。このソリューションは10個以上のIPアドレスがリストにある場合にはスケールせず、DNS問い合わせは設定されたDNSサーバーに到達するインターフェイスのIPアドレスを送信元として使用します。サービスルートを設定しない限りは、デフォルトの管理インターフェイスのアドレスがDNS問い合わせに使用されます。DNS サービスルートの設定とその注意点についてはDNS Service Route is Applied to All Traffic Going to DNS Server IP Addressを参照してください。     ダイナミック ブロック リスト(EBL)の使用(訳注2) この方法はウェブサーバー上へのテキストファイルのホスティングが必要となります。"繰り返し”オプションにて毎時、毎日、毎週、月次といった形での更新が可能です。ダイナミック ブロック リスト オブジェクトの作成後は、該当のアドレス オブジェクトをポリシーの送信元や宛先のフィールドに使用できます。インポートしたリストはIPアドレス(IPv4とv6の合計)、IPの範囲、またはサブネット指定です。エントリーの上限については 外部ブロック リスト (EBL) のフォーマットと制限の操作をご覧ください (訳注3)。また設定の詳細はDynamic Block List (DBL) や External Block List (EBL)の構成方法について をご覧ください。     ダイナミック アドレス グループの使用 ダイナミック アドレス グループを使うとPalo Alto Networks APIを活用できます。IPアドレスのリストはXMLフォーマットに準拠する必要があります。この方法は大変スケーラブルかつフレキシブルで、自動でダイナミック アドレス グループをサードパーティーのスクリプトで変更する場合に推奨されます。ダイナミック アドレス グループを使用する大きな利点は、既存のダイナミック アドレス グループに対してIPアドレスの追加や削除をコミットなしで迅速に行えることです。詳細は Working with Dynamic Address Groups on the Palo Alto Networks firewall をご覧ください。   スタティック アドレス グループの使用 アドレス オブジェクトはWeb GUI上で作成でき、アドレス グループに関連付けられます。この処理はCLIでバッチ化することも可能です。詳細は How to Add and Verify Address Objects to Address Group and Security Policy through the CLIをご覧ください。 > configure # set address <AddressObject_01> ip-netmask 1.1.1.1/32 # set address <AddressObject_02> fqdn my.example.com . . . # set address <AddressObject_nn> ip-range 2.2.2.2-3.3.3.3 # set address-group <AddressGroup> static [ <AddressObject_01> <AddressObject_02> ...<AddressObject_nn> ]   変更を有効にするためにコミットを実行してください。   注: <AddressObject> 部分は以下のフォーマットとなります。      <ip-range>      <ip/netmask>      <fqdn>   アドレス オブジェクトを削除するには以下のコマンドを使用してください。 # delete address <AddressObject_01> ip-netmask 1.1.1.1/32 # delete address <AddressObject_02> fqdn my.example.com . . . # delete address <AddressObject_nn> ip-range 2.2.2.2-3.3.3.3   注:アドレス オブジェクトは個別のエントリーであり、スタティック アドレス グループを削除しても、そのグループが参照するアドレス オブジェクトは削除されません。 以下のコマンドのいずれかでアドレス オブジェクトの関連付けを解除します。 # delete address-group <AddressGroup> static <AddressObject_nn> # delete address-group <AddressGroup> static ><AddressObject_01> <AddressObject_02> ... <AddressObject_nn> ]   すべてのグループを削除するには以下のコマンドを使用します。 # delete address-group <AddressGroup> static   変更を有効にするためにコミットを実行してください。   訳注1:原文では Palo Alto Networks Pre-defined Regions を参照していますが、現在このドキュメントは参照ができないため、本文中では別のドキュメントを参照しています。 訳注2:PAN-OS 7.1から"外部ダイナミック リスト"に名称を変更しています。 訳注3:参照ドキュメントを加えた上で、原文より記載を変更しています。   著者:mivaldi
記事全体を表示
TShimizu ‎02-09-2017 07:11 PM
11,306件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Split Tunneling for VPNC Client on Linux Distributions https://live.paloaltonetworks.com/t5/Configuration-Articles/Split-Tunneling-for-VPNC-Client-on-Linux-Distributions/ta-p/57244     概要 VPNCはオープンソースのサードパーティ IPsec VPNクライアントで拡張認証 (X-Auth) をサポートしており、組織内部ののネットワークへのアクセス用としてGlobalProtectゲートウェイへのVPNトンネルを確立します。PAN-OS 5.0.xから、以下のVPNクライアントがGlobalProtectのVPNアクセスのサポート対象となっています(訳注)。 Ubuntu Linux 10.04 LTS VPNC CentOS 6 VPNC この文書は、VPNCクライアントがGlobalProtectゲートウェイに接続される際、どのようにスプリット トンネリングが動作するのかを説明します。   詳細 VPNCクライアントから接続することができるネットワークを定義するために、あるいはVPN接続上で送られるトラフィックのため、(スプリット トンネリングとしても知られている) アクセス ルートを、GlobalProtectゲートウェイのクライアントの設定(訳注1:PAN-OS 7.1以降では[エージェント] > [クライアントの設定])に追加する必要があります。参照: GlobalProtect Configuration Tech Note アクセス ルートがGlobalProtectゲートウェイに設定されている時、すべてのアクセス ルートの内の1つの集約ルートが、VPNCクライアントに送られます。DNSサーバーのアドレスが含まれている場合、ルートを集約する際にはそれも考慮に入れなければなりません。   例: アクセス ルートが 10.66.22.0/23 と 192.168.87.0/24 のネットワークを含む場合、サードパーティのVPNCクライアントに送られる集約ルートは、デフォルト ルート 0.0.0.0/0 で、以下のように表示されます。 > show global-protect-gateway gateway name test_vpnc   GlobalProtect Gateway: test_vpnc (0 users) Tunnel Type          : remote user tunnel Tunnel Name          : test_vpnc-N         Tunnel ID                 : 7         Tunnel Interface          : tunnel.1         Encap Interface           : ethernet1/3         Inheritance From          :         Local Address             : 10.66.24.87         SSL Server Port           : 443         IPSec Encap               : yes         Tunnel Negotiation        : ssl,ike         HTTP Redirect             : no         UDP Port                  : 4501         Max Users                 : 0         IP Pool Ranges            : 172.16.7.1 - 172.16.7.7;         IP Pool index             : 0         Next IP                   : 0.0.0.0         DNS Servers               : 4.2.2.2                                   : 0.0.0.0         WINS Servers              : 0.0.0.0                                   : 0.0.0.0         Access Routes             : 10.66.22.0/23; 192.168.87.0/24;         Access Route For Third Party Client: 0.0.0.0/0         VSYS                      : vsys1 (id 1)         SSL Server Cert           : SERVER_CERT         Auth Profile              : vpnc_auth         Client Cert Profile       :         Lifetime                  : 2592000 seconds         Idle Timeout              : 10800 seconds   アクセス ルートが 10.66.22.0/23 と 10.66.12.0/23 のネットワークを含む場合、サードパーティのVPNCクライアントに送られる集約ルートは 10.66.0.0/19 で、以下のように表示されます。 > show global-protect-gateway gateway name test_vpnc   GlobalProtect Gateway: test_vpnc (0 users) Tunnel Type          : remote user tunnel Tunnel Name          : test_vpnc-N         Tunnel ID                 : 7         Tunnel Interface          : tunnel.1         Encap Interface           : ethernet1/3         Inheritance From          :         Local Address             : 10.66.24.87         SSL Server Port           : 443         IPSec Encap               : yes         Tunnel Negotiation        : ssl,ike         HTTP Redirect             : no         UDP Port                  : 4501         Max Users                 : 0         IP Pool Ranges            : 172.16.7.1 - 172.16.7.7;         IP Pool index             : 0         Next IP                   : 0.0.0.0         DNS Servers               : 10.66.22.77                                   : 0.0.0.0         WINS Servers              : 0.0.0.0                                   : 0.0.0.0         Access Routes             : 10.66.22.0/23; 10.66.12.0/23;         Access Route For Third Party Client: 10.66.0.0/19         VSYS                      : vsys1 (id 1)         SSL Server Cert           : SERVER_CERT         Auth Profile              : vpnc_auth         Client Cert Profile       :         Lifetime                  : 2592000 seconds         Idle Timeout              : 10800 seconds   注:VPNCクライアントに送られる集約ルートが、デフォルト ルート (0.0.0.0/0) である場合、VPNCクライアントは以下に表示されているように、スプリット トンネリングの設定をする必要があります。   VPNCクライアントを開き、[ IPv4設定] > [ ルート ] ボタンをクリックします。   必要なアクセス ルートを追加し、「そのネットワーク上のリソースのためにのみこの接続を使用」のチェックボックスにチェックが入っていることを確認します。 GlobalProtectによって送られた集約ルートは 0.0.0.0/0 ですが、接続は以下に表示されているように、10.66.22.0/23 ネットワークに対してのみ許可されます。 Linux ホストのターミナルからの出力結果: t un0   Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00        inet addr:172.16.7.1 P-t-P:172.16.7.1 ask:255.255.255.255        UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1412 Metric:1        RX packets:0 errors:0 dropped:0 overruns:0 frame:0        TX packets:0 errors:0 dropped:0 overruns:0 carrier:0        collisions:0 txqueue1en:500        RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) VPNCクライアントに送られた集約ルートは 0.0.0.0/0 でしたが、192.168.87.0/24 のためのアクセス ルートは追加されませんでした。 tobby@VirtualBox:~$ ping 192.168.87.1 PING 192.168.87.1 (192.168.87.1) 56(84) bytes of data.   --- 192.168.87.1 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2014ms   VPNCクライアントで、10.66.22.0/23 のために追加されたアクセス ルート tobby@VirtualBox:~$ ping 10.66.22.87 PING 16.66.22.87 (16.66.22.87) 56(84) bytes of data. 64 bytes from 10.66.22.87: icmp_req=1 ttl=61 time=6.87 ms 64 bytes from 10.66.22.87: icmp_req=2 ttl=61 time=2.02 ms   --- 16.66.22.87 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 2.021/4.450/6.879/2.429 ms   訳注:原文執筆時点の情報です。最新版の GlobalProtect(TM) Administrator's Guideご参照の上、都度現在のサポートバージョンをご確認ください。   著者:gchandrasekaran
記事全体を表示
hshirai ‎02-05-2017 11:59 PM
2,628件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Set Up Shared Gateway and Inter VSYS https://live.paloaltonetworks.com/t5/tkb/articleeditorpage/tkb-id/ConfigurationArticles/message-uid/57370   概要 Palo Alto Networksは多くの組織にて必要とされる柔軟性のため、複数の仮想システムと、仮想システム間の通信機能をサポートしています。この文書では、業務用と家庭用に別の仮想ファイアウォールを必要とするのものの、仮想システムが同じISPを外部接続に共有する典型的な在宅勤務者の状況の2つの例を紹介します。両方のシナリオとも、双方の仮想システムが外部のISP接続を共有する状況をカバーし、相互の仮想システム(WORK_192とHOME_10)間の通信を許可します。   この文書ではこれらの機能を設定するための手順を示します。       論理構成 手順 パート1:仮想システムと共有ゲートウェイのセットアップ 最初に[Device] > [セットアップ] > [管理] > [一般設定] に移動し、マルチ仮想システム機能が有効になるようにチェックします。 2つの内部のインターフェイス ethernet1/2 (WORK_192) とethernet1/3 (zone: HOME_10)は別の仮想システムに設定されるべきです。 外部インターフェイス(ethernet1/1; zone: SHARED_UNTRUST)は手順4で共有ゲートウェイに設定するため、仮想システムに組み込まないでください。 注:この文書でインターフェイスをどう設定するか理解するために、概要に記載の論理構成をレビューしてください。 仮想システムの定義のため、Deviceタブで仮想システムを選択してください。[認識可能な仮想システム]列で互いの仮想システムが認識できるようにしてください。例えばvsys1 workはvsys2 homeが見えるように設定する必要があり、逆もまた可能なよう設定しなければなりません。 共有ゲートウェイを追加するため、[Device] > [共有ゲートウエイ]で名前とIDを割り当てます。インターフェイスを割り当てるため、[Network] > [インターフェイス]を選択し、仮想システムメニューから共有ゲートウェイを選択してください。この例ではethernet 1/1はISPからIPアドレスを提供された外部インターフェイスであり、従ってこれが設定される必要があります。 Networkタブからインターフェイスを選択してして、インターフェイスが適切に設定されていることを確認してください。 [Network] > [インターフェイス] 各インターフェイスが同じ仮想ルーター(この例ではAll-Routesという名称)に加わります。すべてのゾーンを同じ仮想ルーターに加えますが、その仮想ルーターは共有ゲートウェイや他の仮想システム間の通信を許可しません。これは後でStep8とパート2で紹介しますが、セキュリティポリシーで制御します。 [Network] > [仮想ルーター] 単一のISP上のネクストホップへのデフォルトルートを設定することが本文書の目的です。もし他にもルートが必要であれば、この仮想ルーターに追加してください。上記のスクリーンショットの3列目で"none"となっているとおり、仮想ルーターはどの仮想システムのメンバーにもなっていないことに注意してください。 Networkタブの下にあるゾーンを選んで、HomeからUntrust、WorkからUntrustの外部ゾーンを作成します。これらの2つの外部ゾーンは、内部ゾーン(例 HOME_10 and WORK_192)からSHEARED_Untrustへのトラフィックを許可あるいは禁止するポリシーを設定するためのものです。それらは効果的に内部から外部へのトラフィックの移動を、経由のゾーンで見ることができます。この例では共有ゲートウェイ ゾーンです。タイプを外部として設定し、そのゾーンに向けて通信経路が設定されているよう定義することが重要です。 ポリシーを設定する際は、内部のネットワークから共有ゲートウェイに向かうトラフィックをファイアウォールのuntrust側で許可するルールを作成します。これでHome-to-UntrustとWork-to-Untrustがともに有効に働きます。加えて、SHARED_UNTRUSTを持つShared_External_GW仮想システムに設定するNATが必要になります。 そのポリシーを設定するには[Policy] > [セキュリティ]に移動します。ポリシーを設定したい仮想システムを選ぶようにしてください。 前述したとおり、NATはShared_External_GW仮想システムに設定します。PoliciesタブのNATに移動して、WORK_192  とHOME_10のゾーンに属するホストから隠蔽する、共有ゲートウェイ外部インターフェイス(例:外部ISPアドレスがethernet1/1に割り当てられている)を使用する隠蔽用NAT設定します。このデザインではすべてのNATの設定は、仮想システムとして Shared_External_GW を選択して行われていること確認してください。この例ではどの仮想システムも外部ゲートウェイを共有するコンセプトのため、送信元ゾーンは'any'と設定します。以下は内部ホストの送信元アドレスを外部IPアドレスに変換するシンプルな隠蔽NATの例です。 テストのため、 WORK_192とHOME_10からインターネットへ向かうトラフィックを生成し、トラフィックログで観察してください([Monitor] > [ログ] > [トラフィック])。   パート2:仮想システム間通信 仮想システム間通信のコンセプトは共有ゲートウェイのセットアップと似ています。それらの仮想システムは互いに通信できる必要があり、個々の外部ゾーンの設定とそのトラフィックを許可するポリシーが必要です。 仮想システム間通信のためには  HOME_10ゾーンはWORK_192に、またその逆も到達できる必要があります。そのため2つの外部ゾーンと、ゾーン間のトラフィックを制御するポリシーの設定が必要です。ゾーンを設定するにはNetworkタブに移動し、ゾーンを選択します。 すべての共有ゲートウェイと仮想システム間通信のためのすべてのゾーンの一覧です。 ポリシーを設定する際は、ゾーン間の通信を許可するルールを作成します。 これでHome-to-Work とWork-to-Home 外部ゾーンが、ともに有効に働きます。これらのゾーンのホスト間のトラフィックは外部ゾーンを経由のために使い、従ってポリシーを設定する必要があります。 ポリシーを設定するには[Policies] > [セキュリティ]に移動します。 ポリシーを設定したい仮想システムを選ぶようにしてください。 テストのため、 WORK_192とHOME_10のホストから相手のゾーンへ向かうトラフィックを生成し、トラフィックログで観察してください([Monitor] > [ログ] > [トラフィック])。   著者:jhess  
記事全体を表示
TShimizu ‎01-25-2017 11:57 PM
4,716件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Add and Verify Address Objects to Address Group and Security Policy through the CLI https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Add-and-Verify-Address-Objects-to-Address-Group-and/ta-p/61627     複数のアドレス オブジェクトを作成し、それをグループやポリシーに追加する方法を説明します。   手順 アドレス オブジェクト "test" を作成し、それをアドレス グループ "test-group" に割り当てます。 設定モードに入ります。 > configure IPアドレスを持つアドレス オブジェクトを作成します。 # set address test ip-netmask 10.30.14.96/32 そのアドレス オブジェクトをアドレス グループに割り当てます。 # set address-group test-group test その変更をコミットします。 # commit   アドレス グループ "test-group" をセキュリティ ポリシーに追加します。 設定モードに入ります。 > configure そのアドレス グループをセキュリティ ポリシーに割り当てます。 # set rulebase security rules trust-DMZ action allow source test-group その変更をコミットします。 # commit   以下のコマンドで、先ほど定義した "test-group" の内容を表示できます。 > configure # show rulebase security rules DMZ-Trust DMZ-Trust {   source test-group ;   destination any;   service any;   application any;   action allow;   source-user any;   option {     disable-server-response-inspection no;   }   negate-source no;   negate-destination no;   log-start no;   log-end yes;   from DMZ;   to L3-Trust;   disabled no;   category any;   hip-profiles any; }   CLI上でアドレス オブジェクトやグループ オブジェクトを確認するには、以下のコマンドを実行します。 # show address-group address-group {   test-group {     static [ test1 test1-1 test2 test2-1 test3];   } }   個別のアドレスを確認するには、以下のコマンドを実行します。 # show address   注:CLIに関する情報をさらに知りたい場合は、Live Community 内でCLI リファレンス ガイドをご参照ください。     著者:djoksimovic
記事全体を表示
hshirai ‎01-15-2017 08:51 PM
8,149件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Verify DNS Sinkhole Function is Working https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Verify-DNS-Sinkhole-Function-is-Working/ta-p/65864     詳細 この資料では、DNSシンクホール機能がPAを経由して正しく動作しているかどうか確認する方法について説明します。 以下の2つのシナリオに対応しています: クライアントが外部DNSサーバーを使用している クライアントが内部DNSサーバーを使用している   DNSシンクホールのコンフィグレーション DNSシンクホールの設定方法についてはこちらを参照して下さい。 How to Configure DNS Sinkhole   また、DNSシンクホールの設定方法について、ビデオでのチュートリアルが以下に公開されています。 Video Tutorial: How to Configure DNS Sinkhole   クライアントが外部DNSサーバーを使用している 注:DNSシンクホールのIPアドレスは、ファイアウォールとクライアントの経路上にある必要があります。それにより、ログを見ることができます。例えば、Palo Alto Networksファイアウォールは感染したクライアントとデータ センターの間に位置していますが、インターネットへ向かうトラフィックはファイアウォールを通過しない環境だとします。そのシナリオでは、DNSシンクホールがインターネットのIPアドレスで設定されている場合、ファイアウォールは、感染したクライアントがC&C(コマンド&コントロール)サーバーに接続しようとしているのを見ることは出来ません。   DNSシンクホールの機能がPalo Alto Networksファイアウォールで設定されており、クライアント システムが外部DNSサーバーを使用している時、クライアントからのDNSクエリは、Palo Alto Networksファイアウォールを通って、外部DNSサーバーに向かいます (クライアントとDNSサーバーは異なるサブネットに属しています)。期待したとおりに、ユーザーは送信元としてのクライアントのIPアドレスを含む脅威ログを見ることができます。   ユーザーは感染したウェブサイトにアクセスしようとしています。クライアント システムは、感染したウェブサイトのIPアドレスを取得するために、DNSクエリを外部DNSサーバーへ送ります。ファイアウォールは、クライアント システムから直接DNSクエリを受け取ります。 ファイアウォールはDNSクエリを乗っ取り、DNSシンクホール IPアドレスがクライアントに渡されることで、送信元としてのIPアドレスを含む脅威ログを見ることができます。   クライアントのTCP/IPプロパティの設定 以下の設定例をご覧ください。   脅威ログ 外部DNSサーバーを使用している際、脅威ログでは、感染したウェブサイトにアクセスしようとしているクライアントのIPアドレス "10.50.240.131" を送信元として表示しています。   外部DNSサーバーを使用している時のクライアントの出力   上記のスクリーンショットは、ホスト マシン "10.50.240.131" が "sp-storage.spccint.com(疑わしいURL)" に対してDNSリクエストをしていることを示しており、それが "1.1.1.1" であることを表示しています。このように、DNSシンクホールは期待した通りに動作していることを示しています。   クライアントが内部DNSサーバーを使用している クライアント システムが内部DNSサーバーを使用している場合(クライアントとDNSサーバーは同じサブネットに所属しています)、クライアントからのDNSクエリは内部DNSサーバーに向かいます。内部DNSサーバーがこのクエリを外部DNSサーバーに転送することで、送信元としての内部DNSサーバーのIPアドレスを含む脅威ログを見ることができます。   現在、Palo Alto Networksファイアウォールでは、脅威ログを利用したとしても、どのエンドのクライアントが感染したウェブサイトにアクセスしようとしているのかを特定することはできません。なぜなら、すべての脅威ログは送信元として、内部DNSサーバーのIPアドレスが表示されるためです。しかしながら、ファイアウォールはトラフィック ログを利用することでエンドのクライアントのIPアドレスを特定することができます。   以下の例は、ユーザーが感染したウェブサイトにアクセスしようとしているところです。クライアント システムは、感染したウェブサイトのIPアドレスを取得するために、DNSクエリを内部DNSサーバーに送ります。そして、内部DNSサーバーは、そのDNSクエリを外部DNSサーバーに転送します。ファイアウォールは、外部DNSサーバーからDNSクエリを受け取ります。   ファイアウォールはDNSクエリを乗っ取り、内部DNSサーバーにDNSシンクホールのIPアドレスを渡します。内部DNSサーバーがクライアント システムに返答を転送することで、送信元としての内部DNSサーバーのIPアドレスを含む脅威ログを見ることができます。しかし以下のスクリーンショットのように、クライアントがDNSシンクホールのIPアドレスを使ってウェブサイトにアクセスしようとするため、Palo Alto Networksファイアウォールは、トラフィック ログにおいてクライアントのIPアドレスを見ることができます。   クライアントのTCP/IPプロパティの設定   脅威ログ 脅威ログでは、ファイアウォールは、送信元として "10.50.240.101" という内部DNSサーバーのIPアドレスだけを表示しています。なぜなら、クライアント システムが内部DNSサーバーのIPアドレスを使用しているからです。そのため、ファイアウォールはどのエンドのクライアントがウェブサイトにアクセスしようとしているのかを特定することができません。   トラフィック ログ しかし、クライアントがDNSサーバーからIPアドレスを取得するとすぐに、DNSシンクホールのIPアドレスに対してトラフィックを生成します。そのため、ファイアウォールは、以下に表示されているように、トラフィック ログの中でエンドのクライアントのIPアドレス "10.50.240.131" を表示することになります。   内部DNSサーバーを使用している時のクライアントの出力 上記のスクリーンショットは、ホスト マシン "10.50.240.131" が "sp-storage.spccint.com(疑わしいURL)" に対してDNSリクエストを実行していることを示しており、それが "1.1.1.1" であることを表示しています。このことから、DNSシンクホールが期待通りに動いていることが確認できます。   参照 How to Configure DNS Sinkhole Video Tutorial: How to Configure DNS Sinkhole     著者:sbabu
記事全体を表示
hshirai ‎01-12-2017 12:01 AM
5,037件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Block Web Browsing while Allowing Microsoft Update https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Block-Web-Browsing-while-Allowing-Microsoft-Updates/ta-p/58399     以下の手順を行うことで、Microsoftのアップデートを許可しながら、Webブラウジングをブロックすることができます。   すべてのURLカテゴリをブロックするために、URLフィルタを作成します ( [ Objects ] > [ セキュリティ プロファイル ] > [ URL フィルタリング ] )。 許可リストに以下のサイトを追加します。 windowsupdate.microsoft.com *.microsoft.com download.windowsupdate.com *.windowsupdate.com 以下のアプリケーションを許可するためのセキュリティ ポリシーを作成します。 [ Policies ] > [ セキュリティ ] を開き、新しいルールを追加します。アプリケーション タブ内にて、 ms-update と web-browsing を追加します。 アクション タブ内のプロファイル設定にて、 ms-update 用に作成したURL フィルタリングを追加します。   著者:panagent
記事全体を表示
hshirai ‎01-10-2017 05:27 PM
6,893件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Can I Put a Wildcard in the Traffic Log Filter to View All Hits on a Subnet? https://live.paloaltonetworks.com/t5/Management-Articles/Can-I-Put-a-Wildcard-in-the-Traffic-Log-Filter-to-View-All-Hits/ta-p/62997     ワイルド カードをフィルタの中で使用することはできませんが、フィルタの中でサブネットをまとめたり、特定したりすることができます。   以下の使用例をご覧ください: 送信元フィルタ、/24 サブネット: ( addr.src in 192.168.10.0/24 ) 宛先フィルタ、/24 サブネット: (addr.dst in 192.168.10.0/24)   著者:mrajdev
記事全体を表示
hshirai ‎01-10-2017 04:44 PM
4,857件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 What are Universal, Intrazone and Interzone Rules? https://live.paloaltonetworks.com/t5/Management-Articles/What-are-Universal-Intrazone-and-Interzone-Rules/ta-p/57491     詳細 セキュリティ ポリシーを設定する時、ルールベースを見ても、どのルールにも合致していないトラフィックがどうなるのか明確にはわかりません。さらに、明示的にルールを作成する以外にそのトラフィックに対する扱い方を変える方法はありません。多くの場合、ユーザーは単にこれらのトラフィックに対してロギングすることだけを必要とすることが多いでしょう。あるいはイントラ ゾーンのトラフィックの処理を簡単に変更することを要求するユーザもいるかもしれません。現時点では、これらの要求に対しては各ゾーンに対して明示的なルールを設定する必要があります。   PAN-OS 6.1より前のリリースでは、セキュリティ ポリシーの中にはルール タイプという分類はありませんでした。ルール タイプは、PAN-OSのバージョン6.1から組み込まれた新しい機能です。この機能により、"interzone"や"intrazone"、"universal"というパラメータに基づいてルールを作成するオプションが提供されるようになりました。この機能を利用すると、どのルールがネットワーク内のゾーンに基づいて作られているか管理者が制御することができ、監査をしている最中にも役立ちます。   PAN-OS 6.1以降のバージョンでは、デフォルトのセキュリティ ルールは、以下に示されているように通常のセキュリティ ルールの最後に付与されています。 "intrazone-default"ルール名の隣にある緑色の歯車アイコンは、そのルールは事前定義済みのものか、あるいはPanoramaからきているものであることを示しています。歯車アイコンにカーソルを合わせると、ツール チップが表示されます。 "interzone-default"ルール名の隣にある二重の歯車イメージは、ルールが現在のVSYSにあり、事前定義済みあるいはPanoramaからプッシュされた別のルールの値をオーバーライドしていることを示しています。 "intrazone-default"ルールのアクションは許可です。 "interzone-default"ルールのアクションは拒否です。   下記の表は、ルール タイプとその説明を詳細に記載しています。 ルール タイプ 説明 Universal デフォルトではこのルール タイプの場合、2つのゾーン間のすべてのトラフィックは、同じゾーンまたは異なるゾーンに関係なく、指定された送信元ゾーンおよび宛先ゾーンにマッチする全てのトラフィックに適用されます。 例えば、送信元ゾーンをAとB、宛先ゾーンをAとBと設定したUniversalルールを作成した場合、そのルールはゾーンA間(ゾーンAからゾーンA)のすべてのトラフィック、ゾーンB間(ゾーンBからゾーンB)のすべてのトラフィック、そしてゾーンAからゾーンBへのすべてのトラフィック、ゾーンBからゾーンAへのすべてのトラフィックに適用されます。 Intrazone 同じゾーン間のトラフィックを許可するセキュリティ ポリシーです。このルール タイプでは指定された送信元ゾーン内のマッチする全てのトラフィックに適用されます。 (intrazoneルールでは、宛先ゾーンを特定することはできません)。 例えば、送信元ゾーンをAとBに設定する場合、そのルールは、ゾーンA間(ゾーンAからゾーンA)のすべてのトラフィックとゾーンB間(ゾーンBからゾーンB)のすべてのトラフィックに対して適用されますが、ゾーンAとゾーンB間のトラフィックには適用されません。 Interzone 2つの異なるゾーン間のトラフィックを許可するセキュリティ ポリシーです。しかしこのタイプが指定された場合、同じゾーン間のトラフィックは許可されません。このルール タイプでは、指定された異なるゾーン間の全てのマッチするトラフィックに適用されます。 例えば、送信元ゾーンをAとBとCに、宛先ゾーンをAとBに設定する場合、そのルールは、ゾーンAからゾーンBへ、ゾーンBからゾーンAへ、ゾーンCからゾーンAへ、ゾーンCからゾーンBへのトラフィックに適用されますが、同じゾーン間(AやBやC)のトラフィックには適用されません。   ユーザーが定義したセキュリティ ルールは、以下のように"universal"や"intrazone"、"interzone”として設定することができます。   あるルールが"intrazone"として設定されている時、宛先ゾーンは変更することができません (グレーアウトしています)。その値は、送信元ゾーンから来ています。   事前定義済みであったり、Panoramaからの"intrazone-default"と"interzone-default"ルール名、あるいは機能は、変更することができません。 画面の縁が緑色で囲われ、タイトルに「読み取り専用」と書かれていることが、変更できないことを示しています。 事前定義済みのものや、Panoramaからの"intrazone-default"と"interzone-default"ルールを変更するためには、ユーザーは、これらのルールをオーバーライドしなければなりません。 "intrazone-default"と"interzone-default"ルールは、ルール名の隣に二重になっていない緑色の歯車アイコンがある場合にはオーバーライドできます。 「オーバーライド」をクリックすると、2つのタブだけを持つ、セキュリティ ルールの編集画面が表示されます。 全般タブでは、タグだけを変更することができます。   アクション タブにて、プロファイル設定とログ設定だけを変更することができます。   事前定義済みのものや、Panoramaがプッシュした値を元に戻すには、「戻す」アクションにより行うことができます。Panoramaでは、デフォルトのルールはセキュリティのノードの中にあり、プレ ルールとポスト ルールの下にあります。 ルール名の隣にある緑色の歯車アイコンは、そのルールは"ancestor"デバイス グループや"shared"、"Predefined"から来ていることを示しています。 ルール名の隣にある二重の歯車アイコンは、そのルールは"ancestor"デバイス グループのルールや"shared"ルール、"Predefined"ルールをオーバーライドしていることを示しています。 ユーザーは、以下のように、"intrazone-default"、あるいは"interzone-default" ルールをオーバーライドすることができます。   Panorama VMとM-100 Panoramaは新しい機能をサポートしています。新しいデフォルト ルールは、ポスト ルールの下に表示されています。   Panoramaについての詳細: デフォルトのルールは、デバイスのデータプレーンにプッシュされると、他のどのルールよりも後に実行されることになります。 Palo Alto Networksデバイス上で、ローカルに"interzone-default"や"intrazone-default"に行われた変更は、Panoramaからプッシュされたどの変更よりも優先されます。   Panorama 6.1 と 5.x/6.0 PAN-OSデバイスとの相互作用: バージョン6.1のPanorama からバージョン6.1より前のPANOSデバイスへセキュリティ ルールをプッシュする場合、期待される動作は以下のとおりです。 事前定義済みのデフォルト ルールは、プッシュされるルールベースから削除される。 "intrazone"や"interzone"タイプのルールはプッシュされるルールベースから削除される。 "universal"タイプのルールは、バージョン6.1以前のルールに変換される。 Panoramaは、すべてのルールがバージョン6.1以前のデバイスにプッシュされるわけではないという警告を出す。 admin@Panorama> show jobs id 25970   Enqueued            ID Type      Status    Result     Completed -------------------------------------------------------------------------- 2014/07/22 22:03:38 25970        CommitAll FIN        OK 100 %    Warnings: 001606007416 is below 6.1, removing intrazone and interzone rules - 010401000006                   commit succeeded     OK 22:03:39 22:03:57 - 001606007416                   commit succeeded     OK 22:03:39 22:05:15   アップグレード/ダウングレード: アップグレード:"intrazone-default"や"interzone-default"という名前のルールが既にある場合、"custom-intrazone-default"や"custom-interzone-default"に名前を変更する必要があります。 注:PAN-OS 6.1にアップグレードする時、セキュリティ ルールベースの中にあるすべての既存のルールは、"universal"ルールに変換されます。 ダウングレード:全ての"universal"ルールから「ルール タイプ」を削除します。全ての"intrazone"や"interzone"ルールを削除します。   参照 PAN-OS 6.1 Administrator's Guide     著者:jdelio
記事全体を表示
hshirai ‎01-09-2017 07:12 PM
6,580件の閲覧回数
0 Replies
Ask Questions Get Answers Join the Live Community