ナレッジドキュメント

※この記事は以下の記事の日本語訳です。 What are suspicious DNS queries? https://live.paloaltonetworks.com/t5/Threat-Vulnerability-Articles/What-are-suspicious-DNS-queries/ta-p/71454   PAN-OS装置にて、疑わしい(Suspicious)DNSクエリがトリガーした脅威ログを示しています。   Detail of Threat log with Suspicious DNS Query.   疑わしい(Suspicious)DNSクエリのシグネチャとは? 疑わしい(Suspicious)DNSクエリのシグネチャは、潜在的にC2トラフィックに関連するドメインへのDNS名前解決をチェックします。このC2トラフィックはマシンが乗っ取られた兆候の可能性もあります。   疑わしいDNSクエリ・シグネチャは、多層防御を提供するために、キルチェーンの中のあらゆるポイントに保護を適用するPalo Alto Networks のアプローチのひとつです。これにより、攻撃者は攻撃を成功させるために追加の検査ポイントを回避する必要がでてきます。昨今の脅威環境は動的であるため、アンチウイルス、脆弱性エクスプロイトの検出、URLフィルタリングは有効ですが、さらに多くのことが可能です。 それは、潜在的な悪意のある接続先への接続を、名前解決が行われる前に切断することです。   疑わしいDNSシグネチャはアラート設定や、接続をリセットまたはドロップすることによって名前解決をブロックする設定、もしくは製品に備わっているDNSシンクホール機能を利用して被疑対象に接続しないような設定ができます。 パロアルト ネットワークスのベスト プラクティスは、疑わしいDNSクエリの送信元IPを特定できるように、シンクホールに設定することです。   不審なDNSクエリー・シグネチャはどのように機能しますか? どのように提供されますか? 疑わしいDNSクエリー・シグネチャ(以降、SDNSシグネチャ)は、シグネチャが存在するドメインへの名前ルックアップを検査するPAN-OSアプライアンスを通過するDNSトラフィックを元に動作します。 パケットのキャプチャがSDNSシグニチャで有効化されている場合、その中には単順に特定のドメインへのDNSクエリーが含まれます。     SDNSシグネチャは、パロアルト ネットワーク ス  バックエンドのインテリジェンス情報収集の結果です。 WildFireサンドボックスにて検体を走らせた際の結果、外部インテリジェンス フィード、および研究者からの分析、などがその例です。   作成されたシグニチャは、次の2つの方法でPAN-OS機器に送られます。   WildFireコンテンツ、脅威ID 3,800,000  - 3,999,999 。 デバイスのWildFireコンテンツ アップデート スケジュールの更新頻度の設定、およびシグネチャがまだ有効かどうかに応じて、15分ごとに更新することも可能です。 これらのシグネチャは、次のフォーマットで脅威ログに表示されます。Malwarefamilyname:domain(例: None:google[.]com)シグネチャを生成するために使用されたサンプルにファミリーネームが関連付けられていない場合は、「None」が代わりに使用されます。   アンチウイルス コンテンツ、 脅威ID  4,000,000  - 4,199,999 。 アンチウイルス  コンテンツは、通常、およそ午前7時(EST)に、24時間に1度リリースされます。これらのシグネチャは、次の形式で脅威ログに表示されます。 Suspicious DNS Query:  Malwarefamilyname:domain(例:Suspicious DNS Query: None:google[.]com)シグネチャを生成するために 使用されたサンプルにファミリーネームが関連付けられていない場合は、 「None」が代わりに使用されます。 シグネチャは、コンテンツの「スパイウェア」部分に表示されます。 シグネチャ の脅威ID番号によって識別できるものの詳細については、 このリンク(英文)を参照ください。 (※ 訳注:前述した脅威IDの範囲についても、最新情報はこのリンク先の記事を参照してください。)      以前に検知されたSDNS クエリー シグネチャは、脅威モニターで名前が変更されていることに気が付いているかもしれません。なぜ起こったのか疑問に思うかもしれません。   現在のSDNSシグネチャの実装について、コンテンツの場合は一般的に、現在のコンテンツ内で各脅威にはIDが割り当てられています。割り当てられるコンテンツ スペースは無限でないため、とある時点において、SDNSコンテンツ スペースで最もアクティブで危険な脅威を保つことが優先事項です。脅威の状況が急速に変化するため、シグネチャは置き換えられることがあります。   脅威モニターUIの現在の実装では、現在ファイアウォールにインストールされているコンテンツ データベースから直接「名前」フィールドが照会されます。これが意味することは、一旦脅威モニターがロードされると、あるドメインで読み取られた以前のシグネチャトリガーが、現在のシグネチャに関連されたものに置き換わって表示されるようになることです。   例: WildFireコンテンツ1では、Google[.]comがSDNS脅威ID 3,800,000に割当てられています。 この脅威が検知されると、 脅威ID  3,800,000 Google[.]com が脅威ログに記録されます。 WildFireコンテンツ2がインストールされます。 WildFireコンテンツ2では、Bing[.]comがGoogle[.]comに代わってSDNS 脅威ID  3,800,000が割当てられています。 以前、脅威ログに記録されていたものは、Bing[.]comとして誤って表示されます。   今のところ、最も単純な回避策は、DNSトラフィックが通過しているセキュリティ ルールに割り当てられたアンチスパイウェア プロファイルを開いて、SDNSシグネチャでパケット キャプチャ採取を有効にすることです。 パケット キャプチャは静的なデータであり、変更されません。     DNSシグネチャが変更される理由については この記事 を参照ください。   不審なDNSクエリー・シグネチャの発生を検知したらどうすべきですか? SDNSシグネチャ トリガーは、必ずしもスパイウェア感染を指し示すものではありませんが、他のインジケーターと共に使用して、危険にさらされている可能性のあるホストを特定するのに利用できます。ホストは、悪意のある行為であると言い切れない外向けネットワーク接続パターンを表示している可能性があります。   ホストがSDNSシグネチャが存在するドメインへのトラフィックを生成すると、プロアクティブなセキュリティ アナリストは、ネットワーク上のトラフィックを特定して検査やその他のアクションを保証するのに役立ちます。 もしホスト・トリガーにてSDNSシグネチャが検知されたのと同時に、AV検出、脆弱性シグネチャー検出、またはマルウェアとして分類されたURLのWeb閲覧などが見受けられた場合は、SDNSシグネチャを使用したことにより、そのホストに対してさらなるアクションが必要であることに確信が持てます。   AutoFocusのご使用の場合は、WildFireサンプルやその他の公開サンプルを調べ、マルウェアの判定を受けかつ特定のドメインに到達したサンプルを検索することができます。これにより、アナリストは、インシデント レスポンス アクションに備えるために、シグネチャが存在する理由と、疑わしいドメインへのトラフィックを生成したサンプルの動作を理解するのに役立ちます。 AutoFocus showing a query on a suspicious DNS domain. そのシグネチャーをさらに調べるために、サードパーティーからのオープンソースの情報源は、セキュリティ コミュニティがどのような種類のインテリジェンスを、そのドメインに対して持っているかを調べるのに、とても良い方法です。   いくつかのサードパーティーを利用した調査サンプル例: VirusTotal URLスキャンを使用して、他のベンダーの検査結果を確認します。 PassiveTotalを使用して、ドメインのパッシブDNS履歴を確認します。 WHOISを活用して、ドメインの所有者、登録日時、その他のデータの詳細を確認します。   アラートが調査するに値すると決まったら、ホスト上のパケットキャプチャによって、ユーザのアクティビティや疑わしいトラフィックなどのコンテキストデータを参照することは、さらなるアクションが必要かどうかの追加設定の助けとなります。   上記のすべてを行っても、特定のSDNSシグネチャが大量のアラートを生成していて、かつ、あなたが確認する限りそのドメインに対してネガティブな活動が見受けられない場合はどうしたらいいでしょうか?   この場合、Palo Alto Networksのサポートは、シグネチャが無効にすべき候補であるかどうかを特定する手助けをいたします。多くのお客様にシグネチャが重大なノイズを生成しているように見える場合は、脅威ログの調査に時間を浪費しないようにして欲しいと思います。 ただし、そのシグネチャに対し確証がある場合は、スパイウェア プロファイルの例外機能を活用して、トラフィックを許可してアラートを停止することができます。   不審なDNSクエリー・シグネチャのサンプル例:   SHA256の”932836effd33218470e1c78dad3505d59af31ecff599e875ed79f47114552883”をサンプル例としてみてみましょう。   このサンプルはPEファイルで、一旦実行すると、いくつかの不審なC2 HTTPトラフィックを作り出します。     結果、該当ドメインへのトラフィックを止めるためのC2ドメイン・シグネチャが生成されました。  
記事全体を表示
kkondo ‎08-14-2018 07:02 AM
5,280件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Tips & Tricks: Forward traffic logs to a syslog server https://live.paloaltonetworks.com/t5/Featured-Articles/Tips-amp-Tricks-Forward-traffic-logs-to-a-syslog-server/ta-p/71966   トラフィックログをPalo Alto Networks ファイアウォールからSyslog サーバに転送する必要がありますか?レポーティング、法令上、保存領域といった理由から、それらのログをファイアウォールからSyslog サーバに転送設定する必要があります。このステップ バイ ステップにそって設定してみてください。トラフィック ログをSyslog サーバに転送するには以下の4つのステップが必要です。   Syslog サーバ プロファイルの作成。 ログ転送プロファイルの作成。 作成したログ転送プロファイルをセキュリティ ポリシーに設定。 コミットにて変更を反映。 ステップ1. Syslog サーバ プロファイルの作成 WebUIからDevice > サーバー プロファイル (Server Profiles) > Syslogに移動。 2. 名前 (Name) : Syslog サーバ プロファイルの名前を入力 (最大31文字)。名前は大文字小文字を区別し、ユニークでなければなりません。      使える文字は、アルファベット、数字、スペース、ハイフンとアンダースコアです。 3. 追加 (Add) をクリックし、Syslog サーバ名を入力 (最大31文字)。名前は大文字小文字を区別し、ユニークでなければなりません。      使える文字は、アルファベット、数字、スペース、ハイフンとアンダースコアです。     Syslog サーバー (Syslog Server): Syslog サーバのIPアドレスを入力。 転送 (Transport): Syslog メッセージを送付するプロトコルをUDP、TCPもしくはSSLから選択。 ポート (Port): Syslog サーバのポート (スタンダードポート : UDPは514; SSLは6514; TCPは任意の番号を指定)を入力。 フォーマット (Format): 使用するSyslog フォーマット: BSD (デフォルト設定) もしくはIETFを指定。 ファシリティ (Facility):  Syslogのスタンダード値の一つを選択。Syslog サーバがFacility フィールドをどのように使ってメッセージを管理するかマッピングします。Facility フィールドの詳細については、 RFC 3164  (BSD format)もしくは RFC 5424 を参照ください。   あなたのSyslog サーバ プロファイルが、以下の設定例のように作成できました。     外部レポーティング ツールと連携するために、ファイアウォールはログ フォーマットをカスタマイズできます。さらに、カスタム キーの追加もできます。カスタム フォーマットは以下から設定できます。 Device > サーバー プロファイル (Server Profiles) > Syslog > プロファイル名 > カスタム ログ フォーマット (Custom Log Format):   ArcSightのCommon Event Format (CEF)に準拠したログフォーマットについては CEF Configuration Guides  を参照ください。   ステップ2. ログ転送 (Log forwarding) プロファイルの作成 WebUIからObjects > ログ転送 (Log forwarding)に移動し、追加 (Add)をクリックします。         名前 (Name): プロファイル名(最大31文字)。この名前はセキュリティ ポリシーに設定した場合に、ログ転送プロファイルの一覧に表示されます。名前は大文字小文字を区別し、ユニークでなくてはなりません。使えるのはアルファベット、番号、スペース、ハイフンそして、アンダースコアです。 Syslog : トラフィック ログを送付する宛先を指定するために、Syslog サーバ プロファイルを選択します。 設定を確認してOKをクリックします。   ログ転送プロファイルが作成できました。以下のサンプルのようになっていると思います。     ステップ3. 作成したログ転送プロファイルをセキュリティ ポリシーに設定   WebUIからPolicies > セキュリティ (Security)に移動。     ログの転送設定をしたいルールを選びます。画面サンプル例はAny Allowを選択。         次に、アクション (Actions) タブに移動し、ドロップダウンから作成したログ転送プロファイルを選択し、設定が完了したらOKをクリック。     OKをクリックした後、設定したセキュリティ ルールのオプション (Options)欄に、Forwarding アイコンが表示されます。     ステップ4. 設定が完了したら、コミット (Commit)し設定を反映する。   著者: Kim
記事全体を表示
kkondo ‎07-30-2018 02:16 AM
7,543件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 What Will Cause a URL to be Categorized as 'private-ip-address'? https://live.paloaltonetworks.com/t5/Management-Articles/What-Will-Cause-a-URL-to-be-Categorized-as-private-ip-address/ta-p/52194   カテゴリ 'private-ip-address' は、RFC 1918で定義されている以下のIPアドレスに使用されます: 10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) 169.254.0.0 - 169.254.255.255 (169.254/16 prefix)   'private-ip-address' カテゴリは、'.local' のように公的に登録されていないトップレベルドメインにも使用されます。 これには、トップレベルドメインを含まない短い名前を使用するURLも含まれます。 以下を参照してください:   著者: jteetsel  
記事全体を表示
tsakurai ‎04-28-2018 07:33 PM
3,030件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to View the Installed and Latest Versions of PAN-DB https://live.paloaltonetworks.com/t5/Management-Articles/How-to-View-the-Installed-and-Latest-Versions-of-PAN-DB/ta-p/61912     概要 BrightCloudの利用時はweb UIの   Device > ダイナミック更新 > URLフィルタリング  にてバージョンを確認することができます。しかしPAN-DBの更新では異なります。この文書はPalo Alto NetworksファイアウォールにインストールされているPAN-DBバージョンと、ダウンロードできる最新の利用可能なバージョンの確認方法を記載します。     詳細 show system info コマンドは、ファイアウォールにインストールされているPAN-DBのバージョンを表示するのみです。   > show system info    ..... url-filtering-version: 2013.06.10.107    .....   ファイアウォールにインストールされたバージョンだけでなくクラウドで利用可能なバージョンは   show url-cloud status   コマンドを使うことで確認できます。   例: > show url-cloud status PAN-DB URL Filtering License : valid Current cloud server : s0200 Cloud connection : connected URL database version -   device   : 2013.06.10.107 URL database version -   cloud   : 2013.06.10.107 ( last update time 2013/06/11 15:54:22 ) URL database status : good URL protocol version - device : pan/0.0.2   PAN-DBは日次の更新はなく、代わりに必要に応じてURLのエントリーが取得されます。Palo Alto Networksファイアウォールは更新を自動でチェックし、8時間おきに最新のURLフィルタリングデータベースがダウンロードされたかを示すシステムログが生成されます(訳注:2018/02/28現在、PAN-OS 7.1.15環境で15分おきにチェック、ログ生成が行われています)。   参照 How to Install and Activate PAN-DB for URL Filtering   著者: kprakash
記事全体を表示
TShimizu ‎02-27-2018 07:47 PM
5,457件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to See Traffic from Default Security Policies in Traffic Logs https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-See-Traffic-from-Default-Security-Policies-in-Traffic/ta-p/57393   PAN-OS 7.0 以前 概要 Paloalto Networks 次世代ファイアウォールにはデフォルトルールとして以下のセキュリティ ポリシーがあります: ゾーン間トラフィックの拒否 ゾーン内のトラフィックの許可 デフォルトでは、これらのデフォルトのポリシーにマッチするトラフィックは、トラフィックログに記録されません。トラブルシューティングにおいては、同一の送信元と宛先ゾーンを持つトラフィック、あるいはどのようなトラフィックが許可されずにデフォルトのルールによって拒否されたかの確認、といった情報が必要になる場合があります。一時的に暗黙のブロック ルールによるログを出力するには、以下のコマンドを実行します:   > set system setting logging default-policy-logging <value>   (value は"0-300"秒で指定)   注:PAN-OS 6.1以降ではこれらのデフォルトのポリシーはPocilies > セキュリティに緑の背景色(訳注:PAN-OS 7.1以降は黄色)で表示されます。 ルールはゾーン内(intrazone)、ゾーン間(interzone)、または両方の性質(universal)のいずれかに分類されます。 詳細はPAN-OS 6.1 New Features Guide: Security Policy Rulebase Enhancementsをご参照ください。     詳細 該当するトラフィックをトラフィックログで確認する方法はいくつかあります:   同じゾーン内のトラフィック Policies > セキュリティに移動し、以下の例のように送信元と宛先ゾーンが同じ通信を許可するセキュリティ ポリシーを作成します: 異なるゾーン間のトラフィック Policies > セキュリティに移動し、以下の例のようにゾーン間の通信を許可するセキュリティ ポリシーを作成します:   重要:  上記のポリシー例が示すとおり、ネットワークをセキュアに保つため、信頼されないトラフィックが信頼されたネットワークのゾーンへ流入することを許可するのは望ましくない場合があります。従って、どのようなルールの個別作成が必要かを検討するには、トラフィックをまとめて許可してしまうのではなく、クリーンアップ用ルールとして全て拒否するポリシーを使います。以下が、クリーンナップ用の拒否のポリシーの一例です。   全て拒否(DENY ALL) 以下は外部からのGlobalProtectのみを許可するよう指定した例です。全て拒否のポリシーが設定されているのと同時に、全ての信頼されたゾーンとDMZのトラフィックの出力を許可し、全ての信頼されたゾーン間のトラフィックを許可、そして同じゾーン間のトラフィックを許可します。DENY ALLの上にあるルールにマッチしないトラフィックは、DENY ALLルールにてキャッチされ、denyとしてログに残ります。 トラフィックログ中で拒否されたトラフィック、そしてその中から許可が必要な特定のトラフィックを確認します。これにより新しい何らかのトラフィックや、望まないトラフィックがネットワークを危険にさらすことを防ぐ事ができます。 注:全て拒否のポリシーはデフォルトの同じゾーン内通信を許可するポリシーをオーバーライドします。詳細は次のドキュメントをご参照ください: Any/Any/Deny Security Rule Changes Default Behavior.   PAN-OS 7.0以降   PAN-OS 7.0以降ではゾーン内通信、ゾーン間通信のポリシーは可視化、ログの有効化ができます。 著者: glasater  
記事全体を表示
TShimizu ‎11-20-2017 07:26 PM
7,373件の閲覧回数
0 Replies
 本ガイドにて、 PA シリーズファイアウォール ( 以下、 PA Firewall) を使った運用方法をご紹介します。    大きく以下の内容で構成されています。   ACC ( Application Commands Center ,以降 ACC )の基本的な使い方 各種ログの使い方 ( 絞り込み方法 ) セキュリティ対策方針の例 セキュリティ調査の流れ レポート機能の説明     PA Firewall には強力なセキュリティイベントの可視化機能が多数あり、その中でも ACC は、ネットワーク内のアクティビティに関する実用的なインテリジェンスを提供する強力な分析ツールです。     ACC の基本的な使い方や各種ログの絞り込み方法をご紹介した後に、いくつかの脅威イベントの例を用いて、ある脅威が発生した場合の確認ポイントをご紹介します。    弊社提供の正式ドキュメントと併用して頂き、日々のインシデントの対応にご活用ください。     ※ )            以下の設定画面は PAN-OS 8.0 を基にしています。 適用する PA の OS が異なる場合は、該当する OS のドキュメントを参照してください。
記事全体を表示
Masahiko ‎11-13-2017 11:48 PM
8,784件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Receive Email Threat Notification from the Firewall https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Receive-Email-Threat-Notification-from-the-Firewall/ta-p/58911     脅威検知を電子メールで通知するログ転送プロファイルを作成するには、以下を設定します。 電子メール サーバー プロファイルの設定。 ログ転送 プロファイルの作成。 関連するセキュリティ ポリシーに脅威プロファイルを割り当てます。 関連するセキュリティ ポリシーにログ転送プロファイルを割り当てます。   電子メール サーバー プロファイル Device > サーバープロファイル > 電子メールに移動し、"追加"をクリックして以下の例で示す情報を入力します。(訳注1) 名前: 電子メール設定の名前を入力 サーバー: 電子メールサーバーのラベルを半角1-31文字で入力。 表示名: 電子メールの送信者フィールドに表示される名前 送信者 IP(訳注2): 送信者となる電子メールアドレスを入力。 宛先: 受信者の電子メールアドレスを入力。 Cc: 他の受信者の電子メールアドレスを入力(オプション)。 ゲートウェイ: Simple Mail Transport Protocol のIPアドレス、またはホスト名を入力。   ログ転送プロファイル Objects > ログ転送に移動します。 以下の例で示す情報を入力します。   セキュリティ ポリシー 以下の例で示すとおりトラフィックに関する既存、または新しいルールを作成します。 名前: Outbound 送信元ゾーン: TrustL3 宛先ゾーン: UntrustL3 プロファイル: アンチウイルス: Default 脆弱性防御: Default URL フィルタリング: Default   脅威プロファイルの割当 まだ設定していない場合は、セキュリティ ルールに脅威プロファイルを割り当てます。   ログ転送プロファイルの割当 ログ転送プロファイルをセキュリティ ポリシーに適用します。 オプションからログ転送プロファイルを選択してください。          変更をコミットします。 ポリシーをテストするには、ワークステーションからテスト ウイルスのダウンロードを試みます。例えばeicar.orgからテストファイルをダウンロードします。 脅威プロファイルのアクションが'block'に設定していれば、ブロックページがブラウザ上で表示されます。 脅威ログをチェックするために、 Monitor > ログ > 脅威に移動します。 該当のトラフィックがきっかけとなり、電子メールが送信されます。   訳注1:英語、日本語ともPAN-OS Version毎に項目の名称に差異があります。本文書はPAN-OS 7.0に準拠しています。 訳注2:英文では本項目は"From"であり、送信者 ”IP"は日本語GUI上の誤記となります。PAN-OS 8.0から"送信者"に修正しています。   著者: ppatel
記事全体を表示
TShimizu ‎11-06-2017 05:46 PM
5,506件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Useful CLI Commands to Troubleshoot LDAP Connection https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-Agentless-User-ID/ta-p/...   概要 このドキュメントでは、グループ情報を参照するために LDAP サーバーへの接続が成功したことを確認することができる CLI コマンドについて説明します。   詳細 Device > サーバー プロファイル > LDAP にて LDAP サーバー プロファイルを設定する際、LDAP サーバーへの接続が成功するとデバイスは自動的にベース DN を取得します:   グループ マッピングに LDAP サーバー プロファイルを使用している場合は、show user group-mapping state all コマンドを使用して LDAP 接続に関する情報を表示できます。 例: > show user group-mapping state all Group Mapping (vsys1, type: active-directory) : grp_mapping   Bind DN    : pantac2003\adminatrator   Base       : DC=pantac2003,DC=com   Group Filter: (None)   User Filter: (None)   Servers    : configured 1 servers           10.46.48.101 (389)                   Last Action Time: 2290 secs ago(took 71 secs)                   Next Action Time: In 1310 secs   Number of Groups: 121   cn=administrators,cn=builtin,dc=pantac2003,dc=com   cn=ras and ias servers,cn=users,dc=pantac2003,dc=com   cn=s,cn=users,dc=pantac2003,dc=com   LDAP サーバー プロファイルで設定されたバインド DN が正しくない場合は、コマンド実行結果として "invalid credentials" が表示されます。 次の出力例は、バインド DN に "cn=Administrator12" (正:"cn=Administrator")が設定された場合となります: > show user group-mapping state all Group Mapping (vsys1, type: active-directory) : grp_mapping   Bind DN    : CN=Administrator12,CN=Users,DC=pantac2003,DC=com   Base       : DC=pantac2003,DC=com   Group Filter: (None)   User Filter: (None)   Servers    : configured 1 servers           10.46.48.101 (389)                   Last Action Time: 0 secs ago(took 0 secs)                   Next Action Time: In 60 secs                    Last LDAP error: Invalid credentials   Number of Groups: 0   次のコマンドを使用して useridd ログからエラー メッセージを取り出すことができます: > less mp-log useridd.log Dec 30 15:59:07 connecting to ldap://[10.46.48.101]:389 ... Dec 30 15:59:07 Error: pan_ldap_bind_simple(pan_ldap.c:466): ldap_sasl_bind result return(49) : Invalid credentials Dec 30 15:59:07 Error: pan_ldap_ctrl_connect(pan_ldap_ctrl.c:832): pan_ldap_bind()  failed Dec 30 15:59:07 Error: pan_gm_data_connect_ctrl(pan_group_mapping.c:994): pan_ldap_ctrl_connect(grp_mapping, 10.46.48.101:389) failed Dec 30 15:59:07 Error: pan_gm_data_connect_ctrl(pan_group_mapping.c:1061): ldap cfg grp_mapping failed connecting to server 10.46.48.101 index 0 Dec 30 15:59:07 Error: pan_gm_data_ldap_proc(pan_group_mapping.c:1942): pan_gm_data_connect_ctrl() failed Dec 30 15:59:14 Warning: pan_ldap_ctrl_construct_groups(pan_ldap_ctrl.c:546): search aborted Dec 30 15:59:16 Error: pan_ldap_ctrl_query_group_membership(pan_ldap_ctrl.c:2384): pan_ldap_ctrl_construct_groups() failed Dec 30 15:59:16 Error: pan_gm_data_update(pan_group_mapping.c:1431): pan_ldap_ctrl_query_group_membership()  failed Dec 30 15:59:16 Error: pan_gm_data_ldap_proc(pan_group_mapping.c:1976): pan_gm_data_update() failed Dec 30 16:00:07 connecting to ldap://[10.46.48.101]:389 ... Dec 30 16:00:07 Error: pan_ldap_bind_simple(pan_ldap.c:466): ldap_sasl_bind result return(49) : Invalid credentials Dec 30 16:00:07 Error: pan_ldap_ctrl_connect(pan_ldap_ctrl.c:832): pan_ldap_bind()  failed Dec 30 16:00:07 Error: pan_gm_data_connect_ctrl(pan_group_mapping.c:994): pan_ldap_ctrl_connect(grp_mapping, 10.46.48.101:389) failed   LDAP サーバーへの接続を再確立するコマンド: > debug user-id reset group-mapping <grp_mapping_name>   useridd ログの LDAP に関する debug レベルを変更するコマンド: > debug user-id set ldap all   useridd の debug をオンに変更するコマンド: > debug user-id on debug   useridd の debug をオフに変更するコマンド: > debug user-id off   MGT インターフェイスを使用して LDAP サーバーと通信している場合に、LDAP 通信をキャプチャするコマンド: > tcpdump filter "port 389"   MGT インターフェイスを使用して LDAP サーバーと通信している場合に、LDAPS (SSL) 通信をキャプチャするコマンド: > tcpdump filter "port 636"   MGT インターフェイスで取得した pcap の内容を確認するコマンド: > view-pcap mgmt-pcap mgmt.pcap   上記で取得した pcap を scp や tftp で外部のホストにエクスポートするコマンド: > scp export mgmt-pcap from mgmt.pcap to username@host:path > tftp export mgmt-pcap from mgmt.pcap to <tftp host>   著者: sdarapuneni
記事全体を表示
tsakurai ‎11-06-2017 05:37 PM
3,192件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Updater Error Codes https://live.paloaltonetworks.com/t5/Management-Articles/Updater-Error-Codes/ta-p/62421     以下はダイナミック更新によるシグネチャ更新において最新バージョンのダウンロードに失敗した場合に返されるコードのリストです。 これらのエラー コードはテクニカル サポート ファイルの ms.log に表示されます。   エラー コード一覧: case   -1: return "generic communication error" case   -2: return "command error" case   -3: return "file I/O error" case   -4: return "network failure" case   -5: return "SSL verification failure" case   -6: return "authentication failure" case   -7: return "protocol error" case   -8: return "server error"   以下は ms.log ファイルの抜粋例です: Length: 4250 (4.2K) [text/xml] Saving to: `/tmp/.contentinfo.xml.10008.tmp'   0K 100% 3.05M=0.001s 2014-07-11 18:07:08 (3.05 MB/s) - `/tmp/.contentinfo.xml.10008.tmp' saved [4250/4250] NO_MATCHES 2014-07-11 18:07:20.116 -0700   updater error code:-4 2014-07-11 18:07:20.116 -0700 Error: pan_jobmgr_downloader_thread(pan_job_mgr.c:710): DOWNLOAD job failed 2014-07-11 18:07:22.722 -0700 Error: pan_mgmt_get_sysd_string(pan_cfg_status_handler.c:367): failed to fetch cfg.platform.uuid   著者: sgantait
記事全体を表示
tsakurai ‎08-14-2017 07:47 PM
6,941件の閲覧回数
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,217件の閲覧回数
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,555件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Determine How Much Disk Space is Allocated to Logs https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Determine-How-Much-Disk-Space-is-Allocated-to-Logs/ta-p/53828   ログが使用しているディスク容量を確認するためには: CLI より次のコマンドを実行します: show system disk-space   出力は以下のようになります > show system disk-space Filesystem            Size    Used   Avail Use% Mounted on /dev/sda3             3.8G    1.1G    2.5G  31% / /dev/sda5             7.6G    2.1G    5.1G  29% /opt/pancfg /dev/sda6             3.8G    2.7G    932M  75% /opt/panrepo tmpfs                   487M   37M     451M   8% /dev/shm /dev/sda8             125G   403M    118G   1% /opt/panlogs   panlogs で終わる行から、ログに割り当てられているディスク容量が分かります。 ログはその割り当て量を超えると消去されるため、容量の 95% を超えないように割り当て、バッファ容量に多少の余地をもたせることが推奨されます。   ログ種別ごとのディスク割り当ては、CLI または GUI の [Device] > [セットアップ ] > [ 管理 ] > [ ロギングおよびレポート設定 ] から確認することができます。     > show system logdb-quota Quotas:              traffic: 32.00%, 38.123 GB               threat: 16.00%, 19.061 GB               system: 4.00%, 4.765 GB               config: 4.00%, 4.765 GB                alarm: 3.00%, 3.574 GB                trsum: 7.00%, 8.339 GB          hourlytrsum: 3.00%, 3.574 GB           dailytrsum: 1.00%, 1.191 GB          weeklytrsum: 1.00%, 1.191 GB                thsum: 2.00%, 2.383 GB          hourlythsum: 1.00%, 1.191 GB           dailythsum: 1.00%, 1.191 GB          weeklythsum: 1.00%, 1.191 GB              appstat: 6.00%, 7.148 GB               userid: 1.00%, 1.191 GB             hipmatch: 3.00%, 3.574 GB    application-pcaps: 1.00%, 1.191 GB         threat-pcaps: 1.00%, 1.191 GB   debug-filter-pcaps: 1.00%, 1.191 GB          hip-reports: 1.00%, 1.191 GB             dlp-logs: 1.00%, 1.191 GB Disk usage: traffic: Logs: 53M, Index: 78M threat: Logs: 8.1M, Index: 340K system: Logs: 18M, Index: 2.1M config: Logs: 29M, Index: 244K alarm: Logs: 16K, Index: 16K trsum: Logs: 25M, Index: 720K hourlytrsum: Logs: 508K, Index: 576K dailytrsum: Logs: 396K, Index: 620K weeklytrsum: Logs: 72K, Index: 196K thsum: Logs: 276K, Index: 276K hourlythsum: Logs: 264K, Index: 264K dailythsum: Logs: 256K, Index: 256K weeklythsum: Logs: 40K, Index: 40K appstatdb: Logs: 448K, Index: 696K userid: Logs: 56K, Index: 24K hipmatch: Logs: 16K, Index: 16K application-pcaps: 156K threat-pcaps: 4.0K debug-filter-pcaps: 4.0K dlp-logs: 4.0K hip-reports: 1.1M wildfire: 4.0K   著者: mbutt
記事全体を表示
kishikawa ‎01-05-2017 12:36 AM
7,637件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Using Packet Filtering through the WebGUI https://live.paloaltonetworks.com/t5/Management-Articles/Using-Packet-Filtering-through-the-WebGUI/ta-p/56363     訳注:本文書で紹介する機能はPAN-OS:5.0以降で対応しています。   概要 この資料は、WebGUIを利用したPCAPについて詳述しています。ここでは、GUIを利用したフィルターの設定方法を扱っており、パケットのキャプチャ方法や、どのパケットがどのステージへ向かうのかを決める方法について説明しています。   いつパケットをキャプチャを必要があるのか? ネットワーク トラフィックを分析する際にパケットキャプチャを行います。PAN-OSは、3種類のパケット キャプチャに対応しています: フィルター PCAP/デバッグ フィルター 送信元/宛先IPアドレス、および送信元/宛先ポートに基づいてパケットをキャプチャするため。 アプリケーション PCAP 特定のApp-IDのパケットをキャプチャするため (特にApp-IDが該当のアプリケーションを検出せず、アプリケーション欄に"incomplete"と表示されている状況)。 "Incomplete"とは、TCP 3ウェイ ハンド シェイクが完了していないということを意味しています。Palo Alto Networksファイアウォールは、クライアントからのSYNパケットの確認はしたが、サーバーからSYN-ACKを得ることはなかった、ということです。それには、2つの理由が考えられます: サーバーは、SYN-ACKの返答を一度もしなかった。これは、サーバーに問題があるということを意味しています。 サーバーは、SYN-ACKを返答したが、SYN-ACKが異なるルートを通ったため、Palo Alto Networksデバイスを通過しなかった (非対象ルーティングとも呼ばれます)。 この問題を解決するためには、フィルターとキャプチャを設定して、Palo Alto NetworksデバイスがSYN-ACKを確認しているかを判断する必要があります。 Unknown PCAP "unknown-tcp"や"unknown-udp"、"unknown-p2p"のパケットをキャプチャするため。 Palo Alto Networksデバイスが、App-IDを使用してアプリケーションを特定できない場合、パケットは、"unknown-tcp"、"unknown-udp"または"unknown-p2p"に分類されます。 キャプチャしたファイルはハード ディスク上に保存されます。ファイアウォールは、PCAPをログ毎に20MBずつ保存し、1時間ごとにディスクの空き容量を確認しています。ディスクの使用量が90%を超えた場合、パケット キャプチャは、90%以下になるまで、古いものから順番に削除されていきます。 注:ファイルのサイズを制限するために、オフ ピーク時にトラフィックをキャプチャすることの考慮が必要となる場合があります。   キャプチャする前にフィルターを設定することが重要である理由 フィルターに合致するパケットだけがキャプチャされるように、フィルターを定義します。パフォーマンスの低下を最小限に抑えたり、他の不要なデータがキャプチャされないことを保証するために、キャプチャを有効にする前に、フィルターを定義することが重要です。同様に、PCAPを取得後は、フィルターを解除する前にキャプチャを無効にすることが重要です。 そのようにしないと送信元IPアドレスだけをフィルターする代わりに、すべてのトラフィックがフィルターの対象となり、 Palo Alto Networksファイアウォールのパフォーマンスが低下することになります。     フィルターとキャプチャを設定するためのステップ バイ ステップ ガイド   WebGUIを利用したPCAP フィルタリング [ Monitor ] > [ パケット キャプチャ ] を選択します: フィルターを設定する前に、以前の設定が不要である場合、「すべての設定をクリア」を選択して、すべてのPCAP設定を削除します。 最初にフィルターを設定する方がより安全です。それにより、フィルターに合致するパケットだけをキャプチャすることができます。フィルターを設定するために、「フィルタの管理」を選択し、「追加」をクリックして新しいフィルターを設定します。 以下の情報を指定します: ID:フィルターを識別するためのIDを入力します。 入力インターフェイス:ファイアウォールのインターフェイスを入力します。 送信元:送信元IPアドレスを入力します。 宛先:宛先IPアドレスを入力します。 送信元ポート:送信元ポートを入力します。 宛先ポート:宛先ポートを入力します。 非 IP:非 IPトラフィックを扱うためのオプションを1つ選択します。 None:IPフィルターを使用しない。 Exclude Include Only:IPだけを含めるフィルター。 IPv6:IPv6パケットを含めるには、チェックボックスにチェックを入れます。 フィルタリングと事前解析一致を有効にします: 注:事前解析一致は、高度なトラブルシューティングのためのものです。あるパケットが入力インターフェイスに入ってきた際に、何らかの失敗によりそのパケットはフィルタリングのステージまで到達しないことがあります。しかし、この設定を有効にすることで、ファイアウォールはフィルタリングのステージに到達しないパケットもキャプチャします。   キャプチャ キャプチャを有効にする前に、以下のステージを設定します: 「追加」をクリックして、キャプチャされるパケットのステージを設定します。パケットは、以下の4つのステージでキャプチャされます: Drop:エラーが原因で、Palo Alto Networksデバイスによってドロップされたパケットが、Dropステージに入ります。 Firewall:Palo Alto Networksデバイスが、パケットを処理している時のパケットのステージです (キャプチャされたパケットは、ポリシーやIPS機能などを通過していきます)。 Receive:Palo Alto Networksデバイスによって受信されたパケットは、このステージでキャプチャされます。 Transmit:送信元から送出されるパケットは、(Firewallステージ後に) このステージでキャプチャされます。 パケット キャプチャを有効にします。ダイアログが表示されますので、OKをクリックします。 注:特定のトラフィックのパケットだけがキャプチャされるように、キャプチャを有効にする前に、フィルターが有効になっていることを確認します。そうでない場合、作成されたすべての新しいセッションがキャプチャされてしまい、データ プレーンのパフォーマンスを著しく低下させることになります。 パケットをキャプチャするために、送信元からのトラフィックを生成します。 画面を更新して、PCAPファイルがキャプチャされたかどうかを確認します。 パケット キャプチャ画面の右側にPCAPファイルが表示された後、キャプチャとフィルターを無効にします。 注:フィルターを無効にする前に、キャプチャを無効にすることが重要です。さもないと、すべてのトラフィックがフィルターの対象となり、ファイアウォールのパフォーマンスを低下させてしまうことになります。   すべての設定は以下の「すべての設定をクリア」を使用することで削除することができます:   シナリオ例 "10.1.1.1"を使用している端末からのトラフィックをキャプチャします。 送信元が"10.1.1.1"であるフィルターを設定します。 4つのキャプチャ ステージを設定し、各ステージに対して個々にファイル名を付けます (Receive、Firewall、Transmit、Drop)。 フィルタリングと事前解析一致を有効にします。 キャプチャを有効にします。 パケット キャプチャを有効にすると、ファイアウォールのパフォーマンスに影響を与えるという旨のリマインダーとして、警告が表示されます。 必要なトラフィックを生成します。 更新アイコンをクリックします。 PCAPファイルが表示されます。最初にキャプチャを無効にし、次にフィルタリングを無効にします。 4つのキャプチャしたファイル (各ステージにつき1つ) をダウンロードし、Wiresharkを使用して開きます。 注:ステージに関連付けられたファイルは、トラフィックがキャプチャされた場合のみに作成されます。例えば、パケットが1つもドロップしない場合は、そのステージに関連付けられたファイルは何も作成されません。     著者:mvora
記事全体を表示
hshirai ‎08-23-2016 12:05 AM
7,200件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Basics of Traffic Monitor Filtering https://live.paloaltonetworks.com/t5/Featured-Articles/Basics-of-Traffic-Monitor-Filtering/ta-p/65244     フィルタリングの方法と使用例 この資料では、Palo Alto Networksファイアウォール上で、特定のタイプのトラフィックをフィルタリングしたり、見つけ出す方法をいくつか例を挙げて説明しています。フィルタのカテゴリとして、ホスト、ゾーン、ポート、日付/時間があります。一覧の最後の方では、より包括的に検索するために、様々なフィルタを組み合わせた例をいくつか記載しています。   以下は、手始めとなる基本的なフィルタの例です。   ホストのトラフィック フィルタの例        ホスト a.a.a.a から           (addr.src in a.a.a.a)           例:(addr.src in 1.1.1.1)            説明:IPアドレス 1.1.1.1 に合致するホストからのすべてのトラフィックを表示        ホスト b.b.b.b へ           (addr.dst in b.b.b.b)           例:(addr.dst in 2.2.2.2)            説明:2.2.2.2 に合致するホストの宛先アドレスのすべてのトラフィックを表示       ホスト a.a.a.a からホスト b.b.b.b へ           (addr.src in a.a.a.a) and (addr.dst in b.b.b.b)           例:(addr.src in 1.1.1.1) and (addr.dst in 2.2.2.2)           説明:1.1.1.1 のIPアドレスを持つホストから2.2.2.2 の宛先アドレスを持つホストへのすべてのトラフィックを表示       ホストのIPアドレスの範囲から           注:実際のIPアドレスを特定できませんが、あるアドレスのネットワークの範囲を特定するために、CIDRの表記法を使用することができます。           (addr.src in a.a.a.a/CIDR)           例:(addr.src in 10.10.10.2/30)           説明:10.10.10.1 - 10.10.10.3 の範囲のアドレスからのすべてのトラフィックを表示        送信元/宛先ホスト a.a.a.a           (addr in a.a.a.a)           例:(addr in 1.1.1.1)            説明:1.1.1.1 に合致するホストの送信元アドレス、あるいは宛先アドレスのすべてのトラフィックを表示     ゾーンのトラフィック フィルタの例        zone_a ゾーンから           (zone.src eq zone_a)           例:(zone.src eq PROTECT)           説明:PROTECTゾーンからのすべてのトラフィックを表示        zone_b ゾーンへ           (zone.dst eq zone_b)           例:(zone.dst eq OUTSIDE)           説明:OUTSIDEへのすべてのトラフィックを表示        zone_a から zone_b へ           (zone.src eq zone_a) and (zone.dst eq zone_b)           例:(zone.src eq PROTECT) and (zone.dst eq OUTSIDE)           説明:PROTECTゾーンからOUTSIDEゾーンへ出て行くすべてのトラフィックを表示     ポートのトラフィック フィルタの例        送信元ポート aa から           (port.src eq aa)           例:(port.src eq 22)           説明:送信元ポート22からのすべてのトラフィックを表示        宛先ポート aa へ           (port.dst eq bb)           例:(port.dst eq 25)           説明:宛先ポート25へのすべてのトラフィックを表示        送信元ポート aa から宛先ポート bb へ           (port.src eq aa) and (port.dst eq bb)           例:(port.src eq 23459) and (port.dst eq 22)           説明:送信元ポート23459から宛先ポート22へのすべてのトラフィックを表示        送信元ポート aa 以下のすべてのポートから           (port.src leq aa)           例:(port.src leq 22)           説明:送信元ポート1 - 22からのすべてのポートを表示        送信元ポート aa 以上のすべてのポートから           (port.src geq aa)           例:(port.src geq 1024)           説明:送信元ポート1024 - 65535からのすべてのトラフィックを表示        宛先ポート aa 以下のすべてのポートへ           (port.dst leq aa)           例:(port.dst leq 1024)           説明:宛先ポート1 - 1024へのすべてのトラフィックを表示        宛先ポート aa 以上のすべてのポートへ           (port.dst geq aa)           例:(port.dst geq 1024)           説明:宛先ポート1024 - 65535へのすべてのトラフィックを表示        aa から bb までの送信元ポート範囲から           (port.src geq aa) and (port.src leq bb)           例:(port.src geq 20) and (port.src leq 53)           説明:送信元ポート20 - 53の範囲からのすべてのトラフィックを表示        aa から bb までの宛先ポート範囲へ           (port.dst geq aa) and (port.dst leq bb)           例:(port.dst geq 1024) and (port.dst leq 13002)           説明:宛先ポート1024 - 13002へのすべてのトラフィックを表示     日付/時間のトラフィック フィルタの例        特定の日時のすべてのトラフィック           (receive_time eq 'yyyy/mm/dd hh:mm:ss')           例:(receive_time eq '2015/08/31 08:30:00')           説明:2015年8月31日 午前8時30分に受信したすべてのトラフィックを表示        ある日時か、それ以前に受信したすべてのトラフィック           (receive_time leq 'yyyy/mm/dd hh:mm:ss')           例:(receive_time leq '2015/08/31 08:30:00')           説明:2015年8月31日 午前8時30分か、それより以前に受信したすべてのトラフィックを表示        ある日時か、それ以降に受信したすべてのトラフィック           (receive_time geq 'yyyy/mm/dd hh:mm:ss')           例:(receive_time geq '2015/08/31 08:30:00')           説明:2015年8月31日 午前8時30分か、それ以降に受信したすべてのトラフィックを表示        ある期間に受信したすべてのトラフィック           (receive_time geq 'yyyy/mm/dd hh:mm:ss') and (receive_time leq 'YYYY/MM/DD HH:MM:SS')           例:(receive_time geq '2015/08/30 08:30:00') and (receive_time leq '2015/08/31 01:25:00')           説明:2015年8月30日 午前8時30分から2015年8月31日 午前1時25分の間に受信したすべてのトラフィックを表示     インターフェイスのトラフィック フィルタの例        インターフェイス interface1/x でのインバウントのすべてのトラフィック           (interface.src eq 'ethernet1/x')           例:(interface.src eq 'ethernet1/2')           説明:Palo Alto Networksファイアウォールのインターフェイス Ethernet 1/2 で受信したすべてのトラフィックを表示        インターフェイス interface1/x でのアウトバウンドのすべてのトラフィック           (interface.dst eq 'ethernet1/x')           例:(interface.dst eq 'ethernet1/5')           説明:Palo Alto Networksファイアウォールのインターフェイス Ethernet 1/5 で送信されたすべてのトラフィックを表示     許可/拒否のトラフィック フィルタの例        ファイアウォールのルールによって許可されたすべてのトラフィック           (action eq allow)           OR          (action neq deny)           例:(action eq allow)           説明:ファイアウォールのルールによって許可されたすべてのトラフィックを表示。'eq' の前に 'n' を置くことは、'not equal to' を意味します。そのため、'deny' ではないもの、つまり、許可されたすべてのトラフィックが表示されます。        ファイアウォールのルールによって拒否されたすべてのトラフィック           (action eq deny)           OR          (action neq allow)           例:(action eq deny)           説明:ファイアウォールのルールによって拒否されたすべてのトラフィックを表示。'eq' の前に 'n' を置くことは、'not equal to' を意味します。そのため、'allow' ではないもの、つまり、拒否されたすべてのトラフィックが表示されます。     トラフィック フィルタの組合せ例        送信元がOUTSIDEゾーンで、かつ 10.10.10.0/24 のネットワーク内からで、かつ宛先がホスト 20.20.20.21 で、かつPROTECTゾーンへのすべてのトラフィック:           (zone.src eq OUTSIDE) and (addr.src in 10.10.10.0/24) and (addr.dst in 20.20.20.21) and (zone.dst eq PROTECT)        送信元ホストが 1.2.3.4 で、宛先ホストが 5.6.7.8、かつ2015年8月30日 0時0分から2015年8月31日 23時59分59秒までのすべてのトラフィック           (addr.src in 1.2.3.4) and (addr.dst in 5.6.7.8) and (receive_time geq '2015/08/30 00:00:00') and           (receive_time leq '2015/08/31 23:59:59')     著者:reaper
記事全体を表示
hshirai ‎08-19-2016 01:34 AM
16,672件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 GUI Error 'opaque: Failed to check content upgrade info due to generic communication error' https://live.paloaltonetworks.com/t5/Management-Articles/GUI-Error-opaque-Failed-to-check-content-upgrade-info-due-to/ta-p/60791     症状 日常的に、ファイアウォールは以下のエラーを報告します: opaque: Failed to check Content content upgrade info due to generic communication error   アップデート サーバーへの接続は確認されましたが、問題は何も見つかりませんでした。   問題 このエラーは、2つ、あるいはそれ以上のコンテンツのアップデートが、同時刻に実行されるように予定が組まれている場合に発生します (例:アンチウィルスやURLデータベース)。   解決方法 [ Device] > [ ダイナミック更新 ] 画面から、コンテンツのデータベース毎に予定を変更し、更新時間が同じか、あるいは近い時間にならないようにします。     著者:rvanderveken
記事全体を表示
hshirai ‎07-27-2016 09:00 PM
5,850件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Configure Email Alerts for System Logs https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-Email-Alerts-for-System-Logs/ta-p/60279   詳細 システム ログを Email で送信するための手順は以下となります: 電子メール サーバー プロファイルの作成 Device > ログ設定 - システム へ移動し、電子メール プロファイルを設定する   電子メール プロファイルの設定 Device > サーバー プロファイル > 電子メール へ移動し、追加をクリックし必須項目を入力します (以下の例を参照): プロファイル名(Name): 電子メール サーバー プロファイルの名前を入力 サーバ名(Name): サーバーの識別に使用する名前を入力 (1-31 文字) 電子メール表示名(Display name): 電子メールの [送信者] フィールドに表示される名前を入力 送信者IP(From): 送信元のEmailアドレスを入力 宛先(To): 受信者のEmailアドレスを入力 その他の受信者(Cc): CCとして同時に送信する宛先Emailアドレスを入力 (オプション) 電子メールゲートウェイ(Gateway): Emailの送信に使用するSMTPサーバのIPアドレスまたはホスト名を入力   システムログの設定 Device > ログ設定 > システム に移動します Emailを送信したいシステム ログの重大度を選択します。下記の場合、"重大度 = critical" のみEmailで送信するよう設定されています。 重大度をクリックし、電子メールのプルダウンから上記で設定したプロファイルを選択します。 著者: mvenkatesan  
記事全体を表示
tsakurai ‎07-27-2016 01:01 AM
9,223件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Deal with Conficker using DNS Sinkhole https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Deal-with-Conficker-using-DNS-Sinkhole/ta-p/52920     訳注:本文書で紹介するDNSのシンクホール機能はPAN-OS 6.0から対応しています。   概要 Confickerは2008年11月に初めて見つかり、Windowsを実行しているコンピューターに最も広く感染したワームの1つです。 Palo Alto Networksは、Confickerワームを見つけ、遮断することができるシグネチャ群を作成しました。それらの中でもConfickerの亜種によって使用されるDNSドメインを見つけることのできるアンチ ウィルス/アンチ スパイウェアのシグネチャがあります。 このドメインは、Confickerの亜種が見つかるとすぐに更新されます。WildFireライセンスが使用されている場合、新しく見つかったドメインは、WildFireシグネチャをとおして、1時間ごとにPalo Alto Networksファイアウォールに展開されます。ライセンスを使用していない場合、シグネチャは24時間ごとに展開され、すべてのPalo Alto Networksデバイスに対して、ダイナミック アップデートによってダウンロードされます。次回の更新時に、新しいAVシグネチャに対してもアップデートが実施されます。この保護は、ネットワーク内のユーザーが「悪意ある」ドメインを要求している時に機能します。ログの分析を行うことで、感染したドメインに対する要求が、ローカルのDNSサーバーから来ていることを確認することができます。これは、DNSの階層構造により発生します。   詳細 すべてのPalo Alto Networksプラットフォームは、有害なドメインに対するクエリに対して、シンクホール機能を実装しています。この機能を使用して、Palo Alto Networksファイアウォールは、ネットワーク内の感染したホストを見つけることができ、セキュリティの管理者に通知を行うことができます。これにより、そのネットワークから感染した端末を隔離することができます。   一連の動作: 感染したコンピューターは、ローカルのDNSサーバーから、感染したドメインの名前解決を依頼します。 ローカルのDNSサーバーは、公開されているDNSサーバーにクエリを送ります。 Palo Alto Networksデバイスは、最新のシグネチャを使用して、そのクエリー内容から有害なドメインを見つけます。 管理者が設定したIPアドレス (シンクホール アドレス) を付与してDNS要求に対する回答を上書きし、クライアントに対して改変された回答を送ります。 クライアントは、シンクホールのIPアドレスに接続しようとします。 Palo Alto Networksは、そのトラフィックを遮断し、その試みをログに記録します。 ファイアウォールの管理者は、そのイベントの通知を受け取ります。 有害なクライアントは、ネットワークから隔離、除去されます。   手順 DNSシンクホール機能を設定するために、こちらをご覧ください: How to Configure DNS Sinkholing on PAN-OS 6.0 L3インターフェイスが、シンクホール インターフェイスとして設定されているPalo Alto Networksデバイスを使用して(ループバック インターフェイスを使用することもできます) 、以下の手順を行います: 仮想 ルーターとセキュリティ ゾーンに、以下の例のようにインターフェイスを追加します。このゾーンは、ユーザーが接続を開始するものとは異なります。有害なコンピューターはトラフィックを送り出すかは定かではありませんが、ベストプラクティスとしてはこのインターフェイスに対して新しいシンクホール ゾーンを作成します。 新しい"sinkhole"ゾーンの作成にし、作成したループバック インターフェイスを"loopback.222"を追加します。 現在使用されておらず、管理者に対して分かりやすいIPアドレスをインターフェイスに割り当てます。 社内でIPv6が使用されている場合、インターフェイスにIPv6アドレスも割り当てます。 [ Objects ] > [ セキュリティ プロファイル ] > [ アンチ スパイウェア ] を開き、インターネット ユーザーに割り当てられるプロファイルを選択(あるいは作成)します。 DNS シグネチャ タブ内で、DNSクエリ時のアクションとして"シンクホール"を選択します。"ブロック"を選択した場合、有害なドメインに対してのクエリを遮断し、ログにはローカルのDNSのみが"attacker"として表示されます。先ほど作成したシンクホールIPアドレス (222.222.222.222) を選択します。 IPv6のDNSクエリ用には、IPv6のIPアドレスを選択します。 「パケット キャプチャ」欄で、シグネチャをトリガーにしたパケットだけではなく、より多くのパケットをキャプチャするために、"extended-capture"を選択します。この値は、[ Device ] > [ セットアップ ] > [ コンテンツ ID ] > [ コンテンツ ID 設定 ] で定義されています。 アンチ スパイウェア プロファイルをセキュリティ ルールに適用し、「セッション終了時にログ」を有効にします。 コミットをクリックして、設定を反映させます。   検証 設定の反映が完了した後、トラフィックがキャプチャされることを確認し、有害なコンピューターを特定します。 ファイアウォールの背後にある検証機を使用します。 Confickerドメインの1つに対して、DNSトラフィックを開始します(この検証では"fetyeq.net"を使用します)。 注:他のConfickerドメインを確認するためには、Palo Alto Networksデバイス上にインストールされているダイナミック アップデートのアンチウィルス リリース ノートを開きます。Palo Alto Networksは、これらのドメインを定期的に更新しており、アンチウィルス シグネチャのリリース ノート内で確認することができます。 [ Device ] > [ ダイナミック更新 ] > [ アンチ ウィルス ] > [ リリース ノート ] を開き、"conficker"を検索すると、約1,000件のドメインを見ることができます。 脅威ログにて、アクションが"sinkhole"となっているログを確認します。 必要に応じて、パケット キャプチャを確認します。 クエリ ビルダーにて、フィルタとして"( action eq sinkhole)" を使用してカスタム レポートを作成します。毎日実行するために、スケジュール設定にチェックを入れます。 翌日、データが収集、表示されていることを確認するために、レポートを確認します。 上記の手順に従うことで、特定のネットワーク内の有害なコンピューターを追跡したり、隔離することができます。     著者:ialeksov
記事全体を表示
hshirai ‎07-22-2016 01:43 AM
6,455件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Export Logs https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Export-Logs/ta-p/59928     手順 注: 下記では、トラフィック ログをエクスポートする方法を例として取り上げております。他のどのログをエクスポートするに際しましても、操作手順は同様です。   Monitor > ログ > トラフィック へ移動します。 CSVアイコンをクリックしてエクスポートします。 "Exporting Logs"画面が表示されます。 "Download file"をクリックします。 CSVファイルがローカルPCにダウンロードされます。 CSVファイルをExcelで開きます。   注: フィルターされたログをエクスポートすることもできます。参照:How to Add, Save, Load, and Clear Log Filters  フィルターを適用したら、上記と同様の手順でログをエクスポートします。   SCPサーバ、あるいはFTPサーバーへログをエクスポートする 以下のコマンドを実行して、ログ ファイルをエクスポートします: SCP > scp export log traffic start-time equal 2011/12/21@12:00:00 end-time equal 2011/12/26@12:00:00 to <value> Destination (username:password@host) or (username@host) FTP > ftp export log traffic start-time equal 2011/12/21@12:00:00 end-time equal 2011/12/26@12:00:00 to <value> Destination (username:password@host) or (username@host)     著者:ppatel
記事全体を表示
hshirai ‎07-15-2016 12:40 AM
9,156件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Display the Log Filter Expressions https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Display-the-Log-Filter-Expressions/ta-p/54161   概要 ログで利用可能なフィルタ式は、 [Monitor] タブの下の適切なログのフィルタ式ボタンを選択することで表示することができます。   詳細 Attirubute 配下のさまざまな操作オプションで作成されるログ フィルタが変更されます:   次の例では、"google" という単語を含むURLログをフィルタします:   次の例では 10.10.10.0 - 10.10.10.255 の範囲の IP アドレスを検索します:   "or" コネクターを使用して、複数の送信元アドレスを検索します。例えば:   著者: panagent
記事全体を表示
dyamada ‎07-13-2016 05:29 AM
7,226件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How To Packet Capture (tcpdump) On Management Interface https://live.paloaltonetworks.com/t5/Management-Articles/How-To-Packet-Capture-tcpdump-On-Management-Interface/ta-p/55415   管理インターフェイスを介してトラフィックが送信/受信されているかどうかの解析/検証が必要となる場合があります。その一例は、認証試験中にリクエストが LDAP または RADIUS サーバーにデバイスから送信されているかどうかの確認があります。別の例としては、デバイスが SNMP サーバーにポーリング/到達されているかどうかを確認することもあります。 PAN-OS 5.0 以降では、管理インタフェイス宛/発の PCAP トラフィックを知ることができます。使用するオプションは厳密に CLI の tcpdump に基づいています。   以下例: このキャプチャは厳密に/暗黙的に管理インターフェイスを利用するため、通常の tcpdump のように手動でインターフェイスを指定する必要はありません。例えば: 注: フィルタは引用符で囲む必要があります。: > tcpdump filter "host 10.16.0.106 and not port 22"   キャプチャが完了したら、 Ctrl-C を押しキャプチャを停止します: CLI でのPCAP を表示するには、view-pcap コマンドを実行します。例: > view-pcap mgmt-pcap mgmt.pcap   パケット キャプチャ セッションの例: > tcpdump filter "host 10.16.0.106 and not port 22" Press Ctrl-C to stop capturing   tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 68 bytes ^C506 packets captured 1012 packets received by filter 0 packets dropped by kernel   > view-pcap mgmt-pcap mgmt.pcap   21:19:30.264789 IP 10.16.0.106.61942 > 10.30.14.108.https: . 2376621033:2376621034(1) ack 1605246872 win 505 21:19:30.266422 IP 10.16.0.106.61952 > 10.30.14.108.https: . 996999225:996999226(1) ack 1613111617 win 353 21:19:30.274892 IP 10.16.0.106.61950 > 10.30.14.108.https: . 385255393:385255394(1) ack 1621385090 win 251 21:19:30.294503 IP 10.16.0.106.61951 > 10.30.14.108.https: . 3013860059:3013860060(1) ack 1619361601 win 254 21:19:31.696061 IP 10.16.0.106.61948 > 10.30.14.108.https: . 3206764451:3206764452(1) ack 1612181557 win 256 21:19:31.714608 IP 10.16.0.106.61949 > 10.30.14.108.https: . 3271787020:3271787021(1) ack 1618663520 win 727 21:28:00.170383 IP 10.16.0.106.54641 > 10.30.14.108.snmp:  GetRequest(26) [|snmp] 21:28:15.866735 IP 10.16.0.106.61949 > 10.30.14.108.https: . 20220:20221(1) ack 30253 win 608 21:28:15.944086 IP 10.16.0.106.61948 > 10.30.14.108.https: . 25004:25005(1) ack 31229 win 1175 21:28:16.095081 IP 10.16.0.106.61952 > 10.30.14.108.https: . 23198:23199(1) ack 32575 win 656 21:28:16.234194 IP 10.16.0.106.61950 > 10.30.14.108.https: . 65220:65221(1) ack 68539 win 256 21:28:16.244155 IP 10.16.0.106.61951 > 10.30.14.108.https: . 32492:32493(1) ack 44141 win 254 21:28:16.444185 IP 10.16.0.106.61942 > 10.30.14.108.https: . 23502:23503(1) ack 38660 win 640   以下は参照/利用/適用可能なフィルタの一例(これらに限定されるものではありませんが)です。: ポートによるフィルタ > tcpdump filter "port 80" 送信元IPによるフィルタ > tcpdump filter "src x.x.x.x" 宛先IPによるフィルタ > tcpdump filter "dst x.x.x.x" ホスト (送信元 & 宛先) IP によるフィルタ > tcpdump filter "host x.x.x.x" ホスト (送信元 & 宛先) IP によるフィルタからSSHを除外する > tcpdump filter "host x.x.x.x and not port 22"   また、手動で SCP または TFTP を通じて PCAP をエクスポートすることができます。例: > scp export mgmt-pcap from mgmt.pcap to   <value>  Destination (username@host:path)   > tftp export mgmt-pcap from mgmt.pcap to   <value>  tftp host   注: PA-200、PA-500、PA-2000では、デフォルトでパケットあたり最大68バイト(Snap Length) の制限があります。 PA-3000、PA-4000、PA-5000の場合は、デフォルトの制限はパケットあたり96バイトです。この制限を拡張するには、"snaplen" オプションを使用します。.   以下も参照 Tcpdump Packet Capture Truncated   著者: bryan
記事全体を表示
dyamada ‎07-13-2016 05:22 AM
11,130件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Generate and Upload a Tech Support File Using the WebGUI and CLI https://live.paloaltonetworks.com/t5/Featured-Articles/How-to-Generate-and-Upload-a-Tech-Support-File-Using-the-WebGUI/ta-p/60757   概要 本ドキュメントでは、WebGUIもしくはCLIを使用した、tech support fileを作成方法/アップロード方法を説明しています。   手順 Tech Support Fileの作成  WebGUIを使用した場合: Device > Supportの順にクリックします。Panoramaの場合, Panorama > Supportの順にクリックします。 Tech Support Fileの下にあるGenerate Tech Support Fileをクリックします。 Note: Device Administratorの権限をもつユーザーでログインしていた場合、本機能は使用できません。Web UIからTech Support Fileを作成するには、Super Userの権限が必要です。 Tech Support Fileが作成されるまで待ちます。 注意: Tech Support Fileが最後に作成された時間が Web UIから確認することができます。 Download Tech Support Fileが表示されたら、Click Download Tech Support Fileをクリックし保存します。 Device > Support , showing you where to generate the Tech Support file from the WebGUI. CLIを使用した場合: SSHもしくはTelnetを使用して、Palo Alto Networks deviceに接続します。 注意: ファイルが保存できるTFTP/SCPサーバが必要となります。 Tech Support Fileを作成するために以下のコマンドを実行します。 > request tech-support dump 準備しているサーバに応じ、Tech Support Fileを保存するため、 以下のいずれかのコマンドを実行します。 > tftp export tech-support to <tftp host> > scp export tech-support to <username@host:path>   Tech Support File をアップロード 以下のいずれかの方法で、Palo Alto Networks support caseの調査用のTech Support fileをアップロードします。Tech Support fileをアップロードするためには、事前にケースオープンが必要です。   方法 1: Palo Alto Networks Support Portalを利用する場合  https://support.paloaltonetworks.comから、Palo Alto Networks Support Portalにログインします。 Case Managementをクリックします。 Palo Alto Networks Support Portal showing where the Case Management option is. case numberもしくはcase subjectをクリックします。注意: edit ボタンはクリックしないでください. Case Filesを表示させるため、画面を一番下までスクロールさせます。 Upload File(s)をクリックし、Tech Support Fileをアップロードします。 Upload file option inside of Support site.   方法 2: TAC Upload Service を利用する場合 tacupload.paloaltonetworks.com にアクセスします。 ケース番号とケースオープン時に利用した email addressを入力します。 ログインします。 .Tech Support File をChoose Fille から選択し、Upload ボタンでアップロードします。 注意: 一度に一つのファイルのみ選択/アップロードできます。 正常にファイルがアップロードされると, 自動送信されたメールにより通知がされます   方法 3: CLIでTAC Upload Server に直接アップロードする場合 SCP export tech-support to xxxxxxxx @ tacupload.paloaltonetworks.com:/   xxxxxxxxはケース番号になります。ケース番号には、最初に00が続きます。 例: 00654321@tacupload.paloaltonetworks.com:/   実行するには、ケースオープン時に利用したemail addressをパスワードとして入力する必要があります。     よく聞かれる質問:  'Tech support file' にはどういったデータが含まれるのでしょうか?装置に関わる設定ファイルはすべて含まれるのですか?PaloAltoサポートに提供することは安全なのでしょうか。   答え: Tech Support fileには、装置に関わる構成ファイル、システムに関わる情報、ログ等が含まれます。(Trafficログは含まれません。) PaloAltoサポートでは、提供された情報を安全に管理します。Tech Support fileは、サポートエンジニアがお客様の設定を理解する上で必要な情報で、調査を円滑に進めることを可能にするものです。すべての情報は安全に管理されます。
記事全体を表示
kkawachi ‎07-12-2016 08:12 PM
11,305件の閲覧回数
0 Replies
1 Like
※この記事は以下の記事の日本語訳です。 How to Configure a Custom Syslog Sender and Test User Mappings https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-a-Custom-Syslog-Sender-and-Test-User-Mappings/ta-p/52896   PAN-OS 6.0, 6.1   概要 PAN-OS 6.0からパロアルトネットワークス・ファイアウォールをSyslogリスナーとして使うことができ、違うネットワーク エレメントや、ユーザーとIPアドレスをマッピングさせてSyslogを収集することができます。それらはセキュリティ ルールやポリシーで使われます。この機能を有効にすると、Syslogリスナーは自動的に設定され、UDPを選択した場合は、ポート番号514を、SSL暗号化を選択した場合は、ポート番号6514が使われます。 このオプションはファイアウォールに限定されたものではなく、Windowsサーバ上にインストールされたUser-IDエージェントでも設定できます。Windowsエージェントでは、SSLは使われず、UDP/TCPともにポート番号514が使われます。   この文章では、どのようにしてパロアルトネットワークス・ファイアウォールでカスタム フィルターを設定するのか説明します。 注 : アプリケーション コンテンツ バージョン418より、パロアルトネットワークスは事前設定されたSyslogセンダーのリストを含みます。アプリケーションのアップデートは、WebUI (Device > Dynamic Updates)からダウンロード、インストールができます。   要求要件 : Syslogセンダー・ログ 送信者のIPアドレス ログの送付方法(暗号化されているか、暗号化されないか) ユーザーがアクセスしているドメインとログインした時に使われている“domain\”表記方法 フィールドもしくはRegex 識別子を使用するのかの決定   この文章では、ファイアウォールに直接設定する方法について記述しています。しかしながら、User-IDエージェントに設定を実行する場合も手順は同様です。   ステップ ログの解析 一部のログを取得し、User-IPマッピングに必要なフィールドを決定します。常に必要なのは、ユーザ名、IPアドレス、フィールドに必要な区切り文字(デリミター)そしてイベント・ストリングです。イベント・ストリングはファイアウォールにユーザがログインに成功して、ユーザ名、IPアドレスが収集され、User-IPマッピング・データベースに登録されたことを通知します。   以下のSyslogサンプルは、アルーバ・ワイヤレス・コントローラーからのログ出力例です。 2013-03-20 12:56:53 local4.notice Aruba-Local3 authmgr[1568]: <522008> <NOTI> <Aruba-Local3 10.200.10.10>  User Authentication Successful: username=ilija MAC=78:f5:fd:dd:ff:90 IP=10.200.27.67 2013-03-20 12:56:53 local4.notice Aruba-Local3 authmgr[1568]: <522008> <NOTI> <Aruba-Local3 10.200.10.10>  User Authentication Successful: username=jovan MAC=78:f5:fd:dd:ff:90 IP=10.200.27.68 role=MUST-STAFF_UR VLAN=472 AP=00:1a:1e:c5:13:c0 SSID=MUST-DOT1X AAA profile=MUST-DOT1X_AAAP auth method=802.1x auth server=STAFF 2013-03-20 12:56:57 local4.notice Aruba-Local3 authmgr[1568]: <522008> <NOTI> <Aruba-Local3 10.200.10.10>  User Authentication Successful: username=1209853ab111018 MAC=c0:9f:42:b4:c5:78 IP=10.200.36.176 role=Guest VLAN=436 AP=00:1a:1e:c5:13:ee SSID=Guest AAA profile=Guest auth method=Web auth server=Guest 2013-03-20 12:57:13 local4.notice Aruba-Local3 authmgr[1568]: <522008> <NOTI> <Aruba-Local3 10.200.10.10>  User Authentication Successful: username=1109853ab111008 MAC=00:88:65:c4:13:55 IP=10.200.40.201 role=Guest VLAN=440 AP=00:1a:1e:c5:ed:11 SSID=Guest AAA profile=Guest auth method=Web auth server=Guest   上記のSyslogサンプルを参照すると、構文解析には、フィールド識別子使われているのが解ります。 イベント・ストリングには “User Authentication Successful:”フレーズを探します。 ユーザ名の接頭語は“username=”です ユーザ名の区切り文字は “\s”です アドレスの接頭語は “IP=” です アドレスの区切り文字は“\s” です   注: Syslog中の区切り文字が空白の場合によくある間違えが、区切り文字フィールドとして空白や “ ”が使われることです。これは正しくなく、例えRegex識別子が使われていなくとも'\s'が正しい区切り文字としての空白スペースの表記方法です。しかしながら、User-IDエージェントで同様の設定した場合、空白スペースを区切り文字として使う必要があります。なぜなら、'\s'はデバッグ ログで認識されず、エラーとなるからです。   設定 ファイアウォールをリスナーとした際に、送られてくるSyslogに使われるSyslog解析プロファイルを定義します。 Device > User Identification > User Mappingに移動します。 "Palo Alto Networks User ID Agent Setup"セクションで編集を選択します。 Syslog Filterタブに移動し、新しいSyslog解析プロファイル追加を選びます。 ログの複雑度からプロファイル・タイプを選択します(Regex識別子かフィールド識別子)。 フィールドの値を上記の解析結果から入力します。 サーバー・モニターを設定します。 Device > User Identification > User Mappingに移動します。 Server Monitoringセクションで、新しいServer Monitorを追加します。 Syslogセンダーのタイプを選択します。 Syslogセンダーの適切なConnection Type、Filter(この設定例では、前のステップで設定したものを選択しています)、Default Domain Nameなどの設定を選んで)を選択します。 注:  Default Domain Nameが使われた場合、入力されたドメイン名がこのサーバー・コネクション経由で発見されたユーザーすべてに付与されます。 全ての設定が完了したら、コネクションを確立するための特定のインターフェイスを許可します。 Network > Network Profiles > Interface Mgmtに移動 接続タイプによって、User-ID-Syslog-Listener-UDPかUser-ID-Syslog-Listener-SSLのコネクション・タイプを選択します。 ManagementプロファイルをEthernetインターフェイスのAdvancedタブで選択します。 接続試験を実施して、サーバーから生成されたログを解析確認してください。 送付されてきているサーバーから受信されているか確認してください。そしてファイアウォール上でマッピングが生成されているか確認してください。 サンプル例 : > show user server-monitor state all UDP Syslog Listener Service is enabled SSL Syslog Listener Service is disabled   Proxy: ilija-syslog(vsys: vsys1)   Host: ilija-syslog(10.193.17.29) number of log messages                            : 1 number of auth. success messages                  : 1   > show user ip-user-mapping all type SYSLOG IP              Vsys   From    User                             IdleTimeout(s) MaxTimeout(s) --------------- ------ ------- -------------------------------- -------------- ------------- 10.200.40.201   vsys1  SYSLOG  al.com\1109853ab111008 2696      2696         Total: 1 users   著者 :  ialeksov    
記事全体を表示
kkondo ‎07-12-2016 12:38 AM
3,170件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Forward Threat Logs to Syslog Server https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Forward-Threat-Logs-to-Syslog-Server/ta-p/59980   Threat ログを Syslog サーバーに転送するには、3 つの手順が必要です。 Syslog サーバー プロファイルを作成する Syslog サーバーへ転送される Threat ログを選択するためのログ転送プロファイルを作成 セキュリティ ルールでログ転送プロファイルを使用する 変更を Commit する     注: Informational の Threat ログには、URL、Data Filtering 及び WildFire ログが含まれます。   Syslog サーバー プロファイル Device > サーバー プロファイル > Syslog へ移動します。 名前 : Syslog サーバーの名前を指定します。 サーバー : ログが転送されるサーバーの IP アドレスを指定します。 ポート : デフォルトのポート番号は 514 です。 ファシリティ : 要件に応じてドロップ ダウンから選択します。 ログ転送プロファイル Objects > ログ転送に移動します。 Threat ログを転送するサーバーが設定された Syslog サーバー プロファイルを選択します。   一度設定すると、ログ転送は以下のように表示されます。     セキュリティ ルール Policies > セキュリティに移動します。 ログ転送が必要なルールを選択し、セキュリティ プロファイルをルールに適用します。 アクション > ログ転送に移動し、ログ転送プロファイルをドロップダウン リストから選択します。   変更を Commit します。    著者: ppatel  
記事全体を表示
hfukasawa ‎07-09-2016 12:24 AM
9,261件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です CLI Commands to Export/Import Configuration and Log Files https://live.paloaltonetworks.com/t5/Management-Articles/CLI-Commands-to-Export-Import-Configuration-and-Log-Files/ta-p/52661   詳細 以下の 4 つのコマンドを使って、複数のログとコンフィグ ファイルをエクスポート及びインポートすることができます。administrator であること以外は、このコマンドを実行するのに特別な権限は必要ありません。SCPオプションは、LinuxまたはUnixサーバーに対してのみ使用できます。 注:PAN-OS 7.0 でのインポート、エクスポート手順については以下の PAN-OS CLI Quick Start を参照してください。 Use Secure Copy to Import and Export Files   > scp export log data      data threat    threat traffic   traffic url       url   > scp export log-file control-plane      Use scp to export control-plane log-file data-plane0        Use scp to export data-plane0 log-file data-plane1        Use scp to export data-plane1 log-file data-plane2        Use scp to export data-plane2 log-file management-plane   Use scp to export management-plane log-file   > tftp export log-file control-plane      Use scp to export control-plane log-file data-plane0        Use scp to export data-plane0 log-file data-plane1        Use scp to export data-plane1 log-file data-plane2        Use scp to export data-plane2 log-file management-plane   Use scp to export management-plane log-file   以下の4つのコマンドを実行するには、「ダイナミック」のロールを設定したSuperuser、Superuser(読み取り専用)、CLI の superuser、superreader のいずれかの管理者ロール権限が必要です。 > scp export configuration remote-port   SSH port number on remote host source-ip     Set source address to specified interface address from          from to            Destination (username@host:path)   >  tftp export configuration remote-port   SSH port number on remote host source-ip     Set source address to specified interface address from          from to            Destination (username@host:path)   > scp import configuration remote-port   SSH port number on remote host source-ip     Set source address to specified interface address from          Source (username@host:path)   > tftp import configuration remote-port   SSH port number on remote host source-ip     Set source address to specified interface address from          Source (username@host:path) 以下の "scp import logdb" 及び "scp export logdb" コマンドは、PA-7000シリーズを除くPalo Alto Networks ファイアウォール、及び PAN-OS 5.1 以上のPanorama VM でのみ実行可能です。 > scp import logdb remote-port   SSH port number on remote host source-ip     Set source address to specified interface address from          Source (username@host:path)   > scp export logdb remote-port   SSH port number on remote host source-ip     Set source address to specified interface address to            Destination (username@host:path_to_destination_filename) 著者: panagent  
記事全体を表示
hfukasawa ‎07-08-2016 11:56 PM
9,361件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Viewing the Log Collector system log in the Panorama appliance (PAN-OS 6.0.x or later) https://live.paloaltonetworks.com/t5/Management-Articles/Viewing-the-Log-Collector-system-log-in-the-Panorama-appliance/ta-p/78493     問題 Panorama アプライアンスとログ コレクタをPAN-OSを6.0.x以降にアップグレードすると、Panoramaに送られているはずのログ コレクタのシステム ログを確認することができません。    "request log-fwd-ctrl action start-from-lastack device"コマンドを実行しても本事象は解決しません。 この問題は、ローカル ログ コレクタの設定がPAN-OSのアップグレード前に削除されていた場合に発生します。     原因 PAN-OS 6.0.x以降にアップグレードする際、M-100(Panorama)はsdb変数がないことにより初期化に失敗します。 この変数はコレクタ グループ コミットにより、コレクタ グループに設定をプッシュする際にセットされます。 しかし、ローカル ログ コレクタを含むログ コレクタ グループが存在しないと、コレクタ グループ コミットを行うことができません。この問題はPAN-OS5.1から6.0でのデザイン変更によって生じています。 解決策 Panorama自身をローカル ログ コレクタとして設定し、そのログ コレクタを含むコレクタ グループを作成します。 Panoramaにてコミットを行うと設定がコレクタ グループにプッシュされます。 それからコレクタ グループとローカル ログ コレクタを削除して コミットします。 sdb変数は一旦セットされれば、その後にローカル ログ コレクタを削除しても、恒久的に維持されます。     復旧手順 Panorama自身を管理対象コレクタ(ローカル ログ コレクタ)として登録   M-100 PanoramaのGUIにログインし、[Panorama]タブ > [管理対象コレクタ]メニューを選択 [追加]をクリックし、[コレクタ]ダイアログの[コレクタシリアル番号]の欄に、Primary Panoramaのシリアル番号を入力し、[OK]をクリック →登録したPrimary Panoramaのシリアル番号が画面に表示されることを確認 [追加]をクリックし、[コレクタ]ダイアログの[コレクタシリアル番号]の欄に、Secondary Panorama のシリアル番号を入力し、[OK]をクリック →登録したSecondary Panoramaのシリアル番号が画面に表示されることを確認 [コミット]をクリックし、[コミット]ダイアログのコミットタイプ「Panorama」ラジオボタンを選択し、[OK]をクリック →結果:OK、詳細:「Configuration committed successfully」と表示されることを確認 手順1で追加したコレクタのコレクタ名をクリックし、[コレクタ]ダイアログにて[Disks]タブをクリック ダイアログ下部の[追加]をクリックし、[ディスク ペアの有効化]欄にディスクペアを追加します。A,B,C,D全てを登録し、[OK]をクリック 手順3で追加したコレクタの コレクタ名 をクリックし 、[コレクタ]ダイアログにて[Disks]タブをクリック ダイアログ下部の[追加]をクリックし、[ディスク ペアの有効化]欄にディスクペアを追加します。A,B,C,D全てを登録し、[OK]をクリック [コミット]をクリックし、[コミット]ダイアログのコミットタイプ「Panorama」ラジオボタンを選択し、[OK]をクリック →結果:OK、詳細:「Configuration committed successfully」と表示されることを確認します。   登録されたM-100 Panorama (ローカル ログ コレクタ)をコレクタ グループに追加   [Panorama]タブ > [コレクタ グループ]メニューをクリック [追加]をクリックし、[コレクタ グループ]ダイアログの[全般]タブにて[名前]欄に任意の名前(例:Panorama_LLC_1)を入力 [ログ転送]タブを選択し、[コレクタ グループのメンバー]欄下部[追加]を選択し、Primary PanoramaとSecondary のPanorama(例:Panorama_LLC_1)を選択して、 [コレクタ グループのメンバー]欄に 追加。[OK]をクリック [コミット] をクリックし、[コミット]ダイアログの コミットタイプ「Panorama」 ラジオボタンを選択し、 [OK] をクリック →結果:OK、詳細:「Configuration committed successfully」と表示されることを確認します。 再度[コミット]をクリックし、[コミット]ダイアログのコミットタイプ「コレクタ グループ」ラジオボタンを選択 全コレクタ グループ名横のチェックボックスにチェックを入れて[OK]をクリック →最終コミット状態:「commit succeeded」と表示されることを確認   ログ転送の復旧確認 [Monitor] > [ログ] > [システム]を選択 →[デバイスのシリアル番号]欄に登録済みログコレクタのシリアル番号が表示されていることを確認します Primary PanoramaにCLIでログインし、 "> show logging-status S/N of the Log Collector >"コマンドを実行します。 →以下の出力例のように、ログを受信した日付が更新されることを確認   > show logging-status device [S/N of the Log Collector] Type Last Log Rcvd Last Seq Num Rcvd Last Log Generated config N/A N/A N/A system 2016/05/13 17:32:00 2301 2016/05/13 17:32:00 threat N/A N/A N/A traffic 2016/05/13 17:53:25 2301 2016/05/13 17:52:13 hipmatch N/A N/A N/A  
記事全体を表示
TShimizu ‎07-07-2016 02:14 AM
2,961件の閲覧回数
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
18,628件の閲覧回数
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,142件の閲覧回数
0 Replies
  ※この記事は以下の記事の日本語訳です。 Not-Applicable, Incomplete, Insufficient Data in the Application Field https://live.paloaltonetworks.com/t5/Management-Articles/Not-Applicable-Incomplete-Insufficient-Data-in-the-Application/ta-p/65711   概要 このドキュメントは、Applicationフィールドに見られる様々な項目について記述することを目的としています。   Incomplete Imcomplete は 3 ウェイ TCP ハンドシェイクが完了しなかった、もしくは 3 ウェイ TCP ハンドシェイクは完了したがその後アプリケーションを特定するデータの送受信が無かったことを意味します。つまり、確認されたトラフィックが実際にアプリケーションではなかったことを意味します。 例えば、クライアントがサーバーに SYN を送信し、Palo Alto Networks デバイスがその SYNに対してセッションを生成したが、サーバーが一度もクライアントに SYN ACKを返信しない場合、そのセッションは incomplete となります。   Insufficient data Insufficient data はアプリケーションを特定するための十分なデータが無いことを意味します。例えば、3 ウェイ TCPハンドシェイクが完了した後、1個のデータパケットの送受信があったが、その1個のデータパケットのみでは判定に不十分で、Palo Alto Networksのシグニチャのいづれにもマッチしなかった場合、Trafficログの Applicationフィールドに Insufficient dataが確認できます。   Unknown-tcp Unknown-tcpは ファイアウォール が 3 ウェイ TCPハンドシェイクを確認したがアプリケーションを特定できなかったことを意味します。これは ファイアウォール が該当するシグニチャを持たないカスタム アプリケーションを使用していることによると考えられます。   Unknown-udp Unknown-udpは未知のUDPトラフィックにより生成されます。   Unknown-p2p Unknown-p2p は一般的な P2P ヒューリスティックに該当します。   Not-applicable Not-applicable は、トラフィックが着信したポート/サービスが許可されていないために破棄されるデータを、Palo Alto デバイスが受信したこと、もしくは、そのポートまたはサービスを許可するルールやポリシーが無いことを意味します。 例えば、Palo Alto デバイスにルールが1つだけ設定されていて、そのルールが ポート / サービス 80番のみ使用する Web-browsingのアプリケーションのみを許可しており、かつ、トラフィック (Web-browsing またはそれ以外のいかなるアプリケーション) が 80番以外のポート / サービスを使用して Palo Altoデバイスに送信された場合、そのトラフィックは破棄またはドロップされ、Applicationフィールドに "not-applicable" が記録されたセッションが確認できます。  
記事全体を表示
kishikawa ‎04-14-2016 10:22 PM
12,071件の閲覧回数
0 Replies
Ask Questions Get Answers Join the Live Community