ナレッジドキュメント

※この記事は以下の記事の日本語訳です。 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
※この記事は以下の記事の日本語訳です。 How to Use Anti-Spyware, Vulnerability and Antivirus Exceptions to Block or Allow Threats https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Use-Anti-Spyware-Vulnerability-and-Antivirus-Exceptions/ta-p/66099   この記事は、アンチスパイウェア、脆弱性防御、アンチウイルスの例外設定において、Palo Alto Networks ファイアウォールで、特定脅威のアクションを変更する方法について記述しています。    アンチスパイウェア、脆弱性防御の例外設定 この例では、アンチスパイウェアの既存プロファイル名 "Threat_exception_test_profile" の例外設定に脅威ID番号30003を追加します。 Objects > セキュリティ プロファイル > 'アンチスパイウェア' もしくは '脆弱性防御' に移動します。 既存のプロファイルを選択 "例外 (Exceptions)"タブを選択 まず、画面左下にある"Show all signatures"チェックボックスを選択し、 検索フィールドで、検索したい文字列(例:'microsoft' )もしくは脅威ID番号(例:30003)を入力し、改行ボタン、もしくは緑の矢印をクリックし、検索を実行します。 注意: もしシグネチャ検索がdynamic update直後で、検索結果が得られない場合は、GUIのキャッシュをクリアするために、WebUIをログアウトして、ログインしなおしてください。 "Microsoft Windows DCOM RPC Interface Buffer Overrun Vulnerability"(脅威ID番号30003)が表示されます。 注意: 脅威ID番号は、threatログから容易に見つけられます。 この例外を有効にするため'Enable'ボックスをクリックします。 既定の'アクション'を変更するため、通過させたい場合はAllow、落としたい場合は、Dropを選択します。 Threat Action detail - change default action. IPアドレスの例外欄は、脅威例外をIPアドレスでフィルターしたい場合に使います。もしIPアドレスが追加されれば、送信/宛先IPアドレスが例外設定と一致した場合のみ、シグネチャのルールアクションが適応されます。シグネチャ当たり100個までIPアドレスを追加できます。このオプション設定によって、特定のアドレス毎に、新しいセキュリティ・ルールを作る必要はありません。全てのトラフィックでなく特定のアドレスを除外したい場合、画面下の"IP Address Exemptions"をクリックして、追加したいIPアドレスを100個まで追加してください。 IP Address Exemption detail. IPアドレス例外設定詳細 アンチスパイウェアもしくは脆弱性防御プロファイルが適切なセキュリティ ポリシーに設定されていることを確認してください。 例外設定を有効にするためにCommitを実行します。   アンチウイルス例外設定 この例では、アンチウイルスの既存のプロファイル名 "AV_exception_test_profile" の例外設定に脅威ID番号253879を追加します。 (注意: アンチウイルスの例外設定は、全体に対して有効か無効かの設定であり、特定のIPアドレスに対しての例外設定はできません)   Objects > セキュリティ プロファイル > アンチウイルスに移動します。 既存のプロファイルを選択し、ウイルス例外 (Virus Exception) タブをクリック。 ID(この例では253879)をページ下の脅威 ID フィールドに入力し、追加をクリックします。 注意: 脅威 IDはthreat ログから見つけられます。 この例では、"Win32/Virus.Generic.koszy"の例外が作られました。 AntiVirus - Virus Excemption window detail. AntiVirus – Virus例外ウィンドウの詳細 アンチウイルス プロファイルが適切なセキュリティ ポリシーに設定されていることを確認してください。 アンチウイルス例外設定には特定IP アドレスを除外するオプションはありません。 変更を反映するためにCommitを実施します。   著者: kadak
記事全体を表示
kkondo ‎06-13-2018 10:24 PM
5,500件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Threat Database Handler (Commit Error) https://live.paloaltonetworks.com/t5/Featured-Articles/Threat-Database-Handler-Commit-Error/ta-p/120490     問題/現象 Palo Alto Networks デバイスにて以下のエラーでコミットが失敗します。   Threat database handler failed Commit failed Failed to commit policy to device     原因 AV アップデート プロセスや、コンテンツ アップデート プロセスが特別な理由もなく不意に失敗することがあります。この問題はPA-200においてよく見られますが、 PA-3000 のような他のプラットフォームでも見受けれます。壊れたAV シグネチャー データベース、またはコンテンツのデータベースがこれらのコミットの失敗を引き起こします。   回避策 CLIから Anti-Virus を手動でインストールすることによって、この問題を回避できるようになります。まず Anti-Virus ファイルを https://support.paloaltonetworks.com  > Dynamic Updates から手動でダウンロードし、そのファイルをパロアルトネットワークス ファイアウォールにアップロードします。アップロード後、以下のコマンドをCLIにて実行し、手動でAVをインストールします。   > request anti-virus upgrade install file panup-all-antivirus-2276-2715.candidate.tgz 2016/02/23 15:21:13 97473.4K panup-all-antivirus-2283-2722.candidate.tgz 2016/03/01 15:27:58 102607.3K <value>   もしこの回避策を行っても問題が解決しなければ、PAN-OS を以下に記載したバージョン以降のものにアップグレードするか、パロアルトネットワークス サポートにお問い合わせください。   解決手段 本問題に関する修正がPAN-OS バージョンの  7.1.2, 7.0.8, 6.1.13に含まれています。   トラブルシューティング 本事象のエラーが起きているかどうかは、device server ログ内に出てくる以下のAVキャッシュのエラーがあるかどうかで判断してください。   2016-02-24 01:39:29.493 -0500 [TDB] Load virus cache now 2016-02-24 01:39:29.493 -0500 load virus cache /opt/pancfg/mgmt/updates/curav/ 2016-02-24 01:39:29.493 -0500 Virus - Content Engine version: 0x7000000 version 6e308c2, min_ threat _version 92007b , path /opt/pancfg/mgmt/updates/curav/ 2016-02-24 01:39:29.814 -0500 Error: pan_tdb_do_load_virus_serialize(pan_tdb_ser.c:735) : Virus version mismatch 0x6df08be vs 0x6e308c2 2016-02-24 01:39:29.862 -0500 Error: pan_tdb_do_load_virus_cache(pan_tdb_handler.c:365) : [TDB] Load /opt/pancfg/mgmt/updates/curav//cache/virus.cache. ser-8 error, will load again 2016-02-24 01:39:29.862 -0500 [TDB] Loaded path /opt/pancfg/mgmt/updates/curav/ cache loaded 0 skip 0 2016-02-24 01:40:10.202 -0500 Error: pan_tcomp_sqlite3_compile(pan_tcomp_sqlite3.c:295) : SQL error: database disk image is malformed  
記事全体を表示
ymiyashita ‎05-03-2018 04:03 AM
3,535件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Understanding HTTP Evasion Detection Signatures https://live.paloaltonetworks.com/t5/Threat-Vulnerability-Articles/Understanding-HTTP-Evasion-Detection-Signatures/ta-p/79218   セキュリティ アプライアンスによる検出を回避するためにネットワーク上で活用される方法の1つとして、受信側のユーザーエージェントがデータを解釈できるようにしたうえで、トラフィックを検査するアプライアンスがデータを解釈できないようにHTTP通信を難読化し隠蔽する手法があります。これは一般に「回避」戦術と呼ばれます。   異なるHTTPクライアントの実装はそれぞれで動作が異なり、また多くの場合、標準規格(RFC)に準拠しておらず、独自の実装を使用するデコーダやスキャニング エンジンをバイパスするために利用されます。 PAN-OSはこれを次の2つの方法で処理します。まず、デコーダがトラフィックをhttpとしてデコードできない場合、アプリケーションは「unknown-tcp」に設定されます。または他のアプリケーションとして認識される場合もありえます。 さらに、HTTP回避に対応するために、以下のような脆弱性シグネチャを使用して保護します。 • Suspicious Abnormal HTTP Response Found (38304, 38358, 38307, 38476, 38305, 38310, 38841, 38742, 38302, 38870, 38767, 38840, 39041, 38824, 38920, 38303, 38839, 38741) • HTTP Non RFC-Compliant Response Found (32880) • Suspicious HTTP Evasion Found (39004, 39022, 38306, 38919, 38635) • HTTP Request Pipeline Evasion Found (36767) • HTTP Request Line Separator Evasion (36398, 36422) • HTTP response data URI scheme evasion attempt (33127) • HTTP various charset encoding html response evasion (33125) • HTTP utf-7 charset encoding html response evasion (33126)   標準準拠していないサーバーやWebアプリケーションは、不正な形ではあるが悪意のない応答をするときがあり、これに対応するために、脆弱性プロファイルの例外処理を利用して、細かく調整することができます。デコーダが標準コンプライアンスをシステム全体に対して実施していたら、これは可能ではなかったかもしれません。 セキュリティ全体として、ネットワーク管理者は、悪意のあるコンテンツが許可されるリスクと、正当なコンテンツが拒否される可能性のバランスを保つ必要があり、かつセキュリティ ベンダーは広まっている回避テクニックに対してシグネチャを提供する必要があります。   パロアルトネットワークスの脅威研究チームは、これらの脅威を常に監視しております。また、 大切なお客様から得られた貴重な詳細情報を元に、未対応の回避手法に対応しています。   著者: rcole
記事全体を表示
kkondo ‎04-21-2018 04:44 PM
3,535件の閲覧回数
0 Replies
※この特別勧告はパロアルトネットワークス・PSIRT(Product Security Incident Response Team :製品のセキュリティや脆弱性対応を行う専門チーム)より報告された「Urgent action recommended regarding recent security advisory PAN-SA-2017-0027」を、日本のユーザー様向けに和訳したものとなります。当勧告と合わせてPSIRTの原文もご確認いただきますようお願い申し上げます。 https://live.paloaltonetworks.com/t5/Community-Blog/Urgent-action-recommended-regarding-recent-security-advisory-PAN/ba-p/194220   パロアルトネットワークスのお客様へ   2017年12月5日、パロアルト ネットワークス・PSIRTはセキュリティ勧告PAN-SA-2017-0027を公開すると共に、PAN-OS 6.1.18とそれ以前にリリースされたバージョン、PAN-OS 7.0.18とそれ以前にリリースされたバージョン、およびPAN-OS 7.1.13とそれ以前にリリースされたバージョンが緊急性の高い脆弱性(CVE-2017-15944)の影響を受けることの情報公開を行い、推奨されるベストプラクティスを提案すると共に、修正版メンテナンスバージョンをリリースしています。   この勧告の公表以降、 Web 管理インターフェイスをインターネットに公開しており、かつ、修正版メンテナンスバージョンをご適用頂いていない極一部の環境において、この脆弱性(CVE-2017-15944)を突いた悪意のある行動が確認されておりますことをここに報告申し上げますと共に、弊社製品 (PA シリーズ、 Panorama) をご利用のお客様におかれましては、この特別勧告に沿ったご対応を改めてご確認の上、実施頂くことを推奨致します。     緊急対処が推奨される場合: 修正パッチを含むPAN-OS へのアップグレードが完了していない環境 PAN-OSにおいて、Web管理インターフェイスがパブリックIPをSourceとするアクセスを許可している(インターネット側から直接接続できる状態)環境 修正版メンテナンスリリースが未適用、かつWeb管理インターフェイスがインターネットから直接接続可能な状態の場合、リスクは極めて高くなりますので早急に対処する必要があります。   恒久的対応策、および運用回避策 修正版メンテナンスリリースのPAN-OS にアップグレード 管理インターフェイスへアクセス可能なアドレスを限定するためのベストプラクティスの適用   2017年12月5日に発行した初期の勧告にて、この脆弱性の対応は、PAN-OS 6.1.19とそれ以降にリリースされたバージョン、PAN-OS 7.0.19とそれ以降にリリースされたバージョン、およびPAN-OS 7.1.14とそれ以降にリリースされたバージョンにて完了している旨をご案内しております。従いまして、可能な限り速やかに修正版メンテナンスリリースを適用することを強く推奨致しております。 修正版メンテナンスリリースの適用が困難であり、Web管理インターフェイスがインターネットから直接接続可能な状態の場合は管理インターフェイスを防御するためのベストプラクティスを実施して頂くよう推奨致します。   注意: もしWeb管理インターフェイスを意図してインターネットに公開してない場合、例えばグローバルプロテクトのポータルもしくはゲートウェイのインターネット向けインターフェイスに誤って、HTTP もしくは HTTPS のマネージメントプロファイルを適応していただいているケースがございます。これについての詳細は、 Best Practices for Securing Administrative Access(英語版の管理者ガイド、2018/1/17時点で日本語管理者ガイドには翻訳されていません)をご参照いただくか、ご質問があればパロアルト ネットワークス・サポートチーム(https://support.paloaltonetworks.com)にケースオープン頂くようお願いします。   弊社が提案するベストプラクティスとしては、すべてのお客様において、Web管理インターフェイスをインターネットに公開(インターネット側から直接接続できる状態)する運用を回避するよう強く推奨しております。 特に修正版メンテナンスリリースを適用していない環境においては、脆弱性に伴うリスクが加算されます。弊社が提案するベストプラクティスは以下の要点についての対応を推奨致しております。   Web管理インターフェイスへの接続を制限するため、管理ネットワーク専用のVLAN、管理インターフェイスへの特定IPアドレス、もしくはその両方からのみ接続を許可する。 インターネットを介したWeb管理インターフェイス接続が必要な場合は、セキュアなVPN接続を構成する。 インターネットに直接接続可能な管理インターフェイスを設置する場合、管理インターフェイス向けトラフックに対して、SSL復号化と、脅威防御を適用頂く。[セキュリティ勧告PAN-SA-2017-0027を公開した際に、CVE-2017-15944脆弱性攻撃を防御する IPSシグネチャ(40483と40484番)をリリースしています。これらのシグネチャ設定を”Block”に設定して、攻撃を防御するよう設定して下さい。]   詳細については以下のKB もご参照ください。 PAN-OSアップグレードのベスト プラクティス パロアルト ネットワークス装置の管理アクセスを保護する方法 適切な脅威防御適用による脆弱性緩和   本件についてご不明点な点やご質問がある場合は、パロアルト ネットワークス・サポートチーム(https://support.paloaltonetworks.com)にケースオープン頂き、ケースの件名に “CVE-2017-15944”を追記して頂けますようお願いします。   敬具 パロアルトネットワークス・PSIRT    ---------------------------------------------------------------------------------------------------------------------------------------------   よくある質問   質問1 : 何の問題ですか?   2017 年 12 月上旬に修正パッチを既に提供させていただいているこの脆弱性 (CVE-2017-15944 / PAN-SA-2017-0027) は攻撃者が修正パッチをあててないファイアウォール、かつ保護策を設定していない管理インターフェイスに対してコードをリモート実行することができます。   この脆弱性はWeb 管理インターフェイスをインターネットに公開しているお客様が対象です。修正パッチをあててない、かつ Web 管理インターフェイスを公開しているお客様はシステム侵害を受ける可能性があります。さらにいくつかの事例で、グローバルプロテクトの誤った設定によって、意図せず Web 管理インターフェイスを公開しているケースが報告されています。以下の KB 記事は推奨設定のガイダンスを提供します。   How to Configure GlobalProtect How to Secure the Management Access of your Palo Alto Networks Device     質問2 : この脆弱性のリファレンスは何ですか?   PAN-SA-2017-0027 はパロアルトネットワークス・PSIRT(Product Security Incident Response Team :製品のセキュリティや脆弱性対応を行う専門チーム ) より報告されたセキュリティ勧告です。 (https://securityadvisories.paloaltonetworks.com/に掲示されています)  CVE-2017-15944 は実際の脆弱性に対するCVE (Common Vulnerabilities and Exposures)です。このシステムは独自に脆弱性を調査するセキュリティ・コミュニティです。 このセキュリティ勧告 PAN-SA-2017-0027 は脆弱性CVE-2017-15944情報を提供するとともに、提供させていただいている修正パッチにて脆弱性を修正する方法についても明記されています。     質問3 : どのパロアルトネットワークス製品が影響を受けますか?   パロアルトネットワークス・ファイアウォールで最新のPAN-OS でない場合、もしくは、 Web 管理インターフェイスをインターネットに公開している場合にリスクが生じます。最新の PAN-OS にアップグレードしてない場合でも、以下のベストプラクティスにて Web 管理インターフェイスを保護している場合、この脆弱性から十分に保護することができます。パロアルトネットワークス・セキュリティ勧告にて影響のあるプロダクト一覧が参照できます。 https://securityadvisories.paloaltonetworks.com/Home/Detail/102     質問4 : Web管理インターフェイスのベストプラクティスは?   Web管理インターフェイスを保護するベストプラクティスは以下のリンクをご参照ください。 パロアルト ネットワークス装置の管理アクセスを保護する方法     質問5 : もしWeb管理インターフェイス公開を避けられない場合、どうすればいいですか?   意思決定はファイアウォールの管理者に委ねられます。パロアルト ネットワークス装置の管理アクセスを保護する方法をご参照ください。     質問6 : 修正パッチを含む最新バージョンにアップグレードすることによって引き起こされる別の問題はありますか?   最新バージョンへのアップグレートはベストプラクティスで推奨しています。しかしながら一部のお客様ではすぐに実施することが難しい場合がございます。Panorama や他のオートメーションツールをご使用いただくことで、大規模、複雑な環境下でのアップグレードを簡素化し、実行することを支援することができます。   さらに、 最新バージョンへアップグレートすることによって、ファイアウォールと他の機器との関連性や、設定ポリシーに影響を及ぼす変更がなされる可能性があります。そのようなケースの場合、常に最新バージョンのPAN-OS にして、想定される影響を最小限にする必要があります。PAN-OSの変更、アップグレードにより影響を受ける可能性を最小化するために、全ての PAN-OS リリースノート( https://support.paloaltonetworks.com > TOOLS > Software Updates )を ご参照いただけます。       質問7 : Panorama 管理サーバも最新バージョンに上げる必要がありますか?   Panorama 管理サーバも攻撃者のリスクを最小化するためにアップグレードしていただくことを推奨します。アップグレートしようとしている PAN-OSバージョン によっては、 Panorama 管理サーバもアップグレートする必要があります。一般的なガイダンスとして、 Panorama 管理サーバのバージョンは、管理しているファイアウォールの中で利用している最も新しい PAN-OS バージョンに合わせる必要があります。       質問8 : User ID のために、ファイアウォールを syslog serverとして指定している場合に、Web 管理インターフェイスをアクセスリストにて制限した場合、 syslog 情報を送ってくるサーバも含める必要がありますか?   はい、User IDのために情報を送ってくるサーバ群のIP アドレスを全て含める必要があります。加えて全てのファイアウォール管理者、 Panorama 管理サーバ、 SNMP モニター用のサーバの IP アドレスを加えたほうがいいでしょう。管理用セグメントがある場合、そのネットワークセグメント(例 : 192.168.1.0/24を許可)を追加することもできます。しかしながら、セキュリティ・リスクをできるだけ軽減したい場合、特定アドレスを追加したほうがいいでしょう。ただし、多くのネットワーク管理ではDHCPを使用しているので、許可した特定アドレスがタイミングによっては変わっている可能性があるので注意してください。  
記事全体を表示
kkondo ‎01-16-2018 11:51 PM
4,569件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Command-and-Control (C2) FAQ https://live.paloaltonetworks.com/t5/Management-Articles/Command-and-Control-C2-FAQ/ta-p/178617   概要 URL Filteringに新しいカテゴリが追加されました。新カテゴリは“command-and-control”となります。   注意:管理者はcommand-and-controlカテゴリに対してBLOCKに設定する必要があります。 下記は、command-and-controlカテゴリに関してのFAQとなります。   これまで、C2サイトに関わるアクセスはどのように保護されていたのでしょうか?   これまで、C2サイトに関わるアクセスは、"malware"カテゴリとして分類され保護されていました。   "malware"カテゴリと"command-and-control"カテゴリの違いはどういったものでしょうか?ユーザーは注意する必要があるのでしょうか。   Palo Alto Networkは、"malware"カテゴリに属する既知のサイトを、"command-and-control"カテゴリとして分類致しました。   マルウェア(悪意のあるコンテンツや実行ファイル、スクリプト、ウィルス、コード等)は、一般的にインターネットへのユーザーアクセスにより配布されます。こういった悪意のあるアクセスについては、"malware"カテゴリとして、firewallによりBLOCKされます。   C2サイトへのアクセスは、感染したエンドポイントが、外部のC2サーバに接続を試みることで発生し、こういった悪意のある接続については、"command-and-control"カテゴリとして、firewallによりBLOCKされます。   一般にセキュリティアナリストは、インシデント調査の中で、これら2つの悪意のある接続を、まったく異なるものとして区別しており、そのため、"command-and-control"カテゴリを追加致しました。 セキュリティアナリストは、Palo Alto Networks Firewallが "malware"カテゴリにより、マルウェア(悪意のあるコンテンツや実行ファイル、スクリプト、ウィルス、コード等)の配布に関わる接続をBLOCK している事により、ネットワーク内のエンドポイントが感染してないことを把握できます。さらに、"command-and-control"カテゴリにより、特定のエンドポイントが外部のC2サーバに接続しようとしていることをBLOCKしていることにより、そのエンドポイントがマルウェアに感染している可能性があり、対応が必要なことを把握できます。 "command-and-control"カテゴリをBLOCKとしていない場合、どういったことが起きますか?   "command-and-control"カテゴリをBLOCKとしていない場合は、ネットワーク内のマルウェアに感染したエンドポイントから発生する外部 のC2サーバへの接続がBLOCKされません。   "command-and-control"カテゴリは、デフォルトでBLOCKとされていないのはなぜですか?   PAN-OS 8.0.2以降のPANOSでは、 Content Update 738以降のバージョンをインストールしている場合、 自動的に "command-and-control"カテゴリは、デフォルトでBLOCKとされます。 それ以前のPANOSは、自動更新に対応していないため、"command-and-control"カテゴリは、デフォルトでALLOWとなります。こちらの詳細については、以下のKBをご参照ください。 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/Content-Version-734-%E3%82%88%E3%82%8A%E8%BF%BD%E5%8A%A0%E3%81%95%E3%82%8C%E3%81%9FPAN-DB-URL-%E3%82%AB%E3%83%86%E3%82%B4%E3%83%AA-Command-and-Control/ta-p/177744     "command-and-control"カテゴリは、どのように定義されたカテゴリですか?   "command-and-control"カテゴリは、マルウェアにより、ユーザーから搾取した情報(プライバシー情報や、機密情報など)や悪意のあるコマンドの送受信を行うことに利用されている外部サーバのドメインやURLを分類したものです。   "command-and-control"カテゴリのリリース時期は?   "command-and-control"カテゴリは、Content Version 734以降のContent Updateでリリースされています。管理者権限にて管理GUIから確認、ならびに変更が可能です。実際の"command-and-control"カテゴリの運用が開始されるまでの間に、"command-and-control"カテゴリのデフォルトアクションをBLOCKに変更ください。"command-and-control"カテゴリのデフォルトアクションをBLOCKに変更していただくことで、"command-and-control"カテゴリが運用開始になったタイミングで、すべての"command-and-control"カテゴリに分類されているURLやドメインへの接続がBLOCKされることになります。 "command-and-control"カテゴリが運用開始時期は?   運用開始は、US時間の2017年10月25日を予定しています。日本時間では、 2017年10月26日のおおよそ AM4:00となる見込みです。   "command-and-control"が動作しているか確認する方法について   こちらのURLにアクセスいただき、ご利用のFirewallでブロックされ、それがログに残れば、ご利用のFirewallで正しく構成されていることをご確認いただけます。 https://urlfiltering.paloaltonetworks.com/test-command-and-control     今回の変更は、PAN-DBやBrightcloudに対して適用されるものですか?     いいえ、今回の変更は、PAN-DBに対して適用されるもので、BrightCloudに対しては適用されません。   本FAQについては、"command-and-control"カテゴリが運用開始となった時点でアップデート致します。     こちらについても併せてご参照ください。 Command-and-Control カテゴリの確認方法
記事全体を表示
kkawachi ‎10-24-2017 06:02 PM
5,822件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Differences between DoS Protection and Zone Protection https://live.paloaltonetworks.com/t5/Learning-Articles/Differences-between-DoS-Protection-and-Zone-Protection/ta-p/57761   DoS プロテクション ポリシーは ある程度はゾーン プロテクションと同等の目的を達するために使用されますが、いくつか主要な違いがあります。 大きな違いはClassifiedとAggregateがDoS プロテクション ポリシーにあることです。ゾーンプロテクションではAggregateが利用可能です。 Classifiedのプロファイルは一つの送信元 IPに対する閾値の作成を可能とします。 例:ポリシーにマッチするすべてのトラフィックに対して、IPごとの最大セッション レートを設定し、一つのIPアドレスが閾値に達したらブロックする。 Agregate プロファイルはポリシーにマッチするすべてのトラフィックに対しての最大セッション レートの作成を可能とします。閾値はすべてのIPを合わせた新規セッション レートに対して適用されます。閾値に達するとすべてのマッチするトラフィックに適用されます。 ゾーン プロテクション ポリシーはフラッド防御とポートスキャニング/スイープとパケットベース攻撃に対して防御することが可能となります。例としてIPスプーフィング、フラグメント、オーバーラッピング セグメント、 tcp-non-syn拒否が挙げられます。 ゾーン プロテクション プロファイルは、セッション生成前に適用されてポリシー エンジンの処理に入らないため、パフォーマンスへのインパクトが小さくなります。   著者: jteetsel
記事全体を表示
TShimizu ‎09-12-2017 11:08 PM
8,333件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 URL Category Bulk Check and Getting the List of Threat Names https://live.paloaltonetworks.com/t5/Management-Articles/URL-Category-Bulk-Check-and-Getting-the-List-of-Threat-Names/ta-p/146803     目的 複数のウェブサイトのリストが存在し、それぞれのPAN−DB (またはBrightCloud) URLカテゴリを確認したいケースを考えます。この際、Test-A-site (https://urlfiltering.paloaltonetworks.com) またはBrightCloud の URL/IP lookup ページ (http://www.brightcloud.com/tools/url-ip-lookup.php) で一個一個カテゴリを確認するのは手間で、ウェブサイトの数が多い場合、このやり方は現実的ではありません。   解決方法 ファイアウォールのCLIは一度に複数行のコマンドを受け付けることができます。よって、以下の手法を用いることができます。   "test url <url>" コマンドをまとめて記載したテキストファイルを作成します。 test url www.paloaltonetworks.com test url www.google.com   (オプション) URLフィルタリングを必要に応じて切り替えます。 > set system setting url-database <paloaltonetworks or brightcloud> https://live.paloaltonetworks.com/t5/Learning-Articles/PAN-DB-URL-Filtering-CLI-Command-Reference/ta-p/61598(英文) 上記1で作成したテキスト全体をファイアウォールのCLIへコピー&ペーストします。 > test url www.paloaltonetworks.com   www.paloaltonetworks.com computer-and-internet-info (Base db) expires in 24000 seconds www.paloaltonetworks.com computer-and-internet-info (Cloud db)   > test url www.google.com   www.google.com search-engines (Base db) expires in 0 seconds www.google.com search-engines (Cloud db) :   目的 脅威IDのとある範囲の脅威名の一覧の取得。   解決方法 "show threat id <id>" コマンドをまとめて記載したテキストファイルを作成します。 show threat id 3800000 show threat id 3800001 : このようなテキストは、以下のようなスクリプトを実行すると簡単に作成できます。 #!/bin/bash   for i in {3800000..3804000} do     echo 'show threat id '${i} >> command_list.txt done 脅威IDの範囲は、以下の記事にて確認することができます。 https://live.paloaltonetworks.com/t5/Threat-Articles/Threat-ID-Ranges-in-the-Palo-Alto-Networks-Content-Database/ta-p/59969(英文)   上記1で作成したテキスト全体をファイアウォールのCLIへコピー&ペーストします。 > show threat id 3800000   unknown spyware   > show threat id 3800001   This signature detected generic:geik.ddns[.]net   medium :   おまけTips packet-diagを実行する際の複数コマンドのリストも同じやり方でテキストとして保存し実行することができます。 https://live.paloaltonetworks.com/t5/Learning-Articles/How-to-Run-a-Packet-Capture/ta-p/62390(英文)
記事全体を表示
ymiyashita ‎07-18-2017 12:17 AM
9,295件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。  WildFire API Frequently Asked Questions (FAQ) https://live.paloaltonetworks.com/t5/Threat-Articles/WildFire-API-Frequently-Asked-Questions-FAQ/ta-p/78950     本記事では、WildFire API のよくある質問をまとめています。     1. デイリーのアップロード/クエリー上限に達するとどうなりますか? デイリーのアップロード/クエリー上限に達すると、それ以降、その日のアップロード/クエリー(上限に達した方)は行えなくなります。WildFireクラウドからは、"Quota Exceeded" のエラーが返ります。     2. デイリーのアップロード/クエリー数が残っていた場合、それは次の日に持ち越されますか? いいえ。値は日本時間の9:00 AMにリセットされます。     3. デイリーのアップロード/クエリー上限に達する前に通知メールを受け取ることはできますか? いいえ。デイリーのアップロード/クエリーの上限数の管理は、APIを使用するクライアント側で、APIの使用数を一日単位で追跡することで管理してください。     4. Carbon Black (Bit9) からWildFire API Keyを利用してファイルアップロードを行う場合、デイリーのアップロード数は消費されますか? はい。     5. Proof Point からWildFire API Keyを利用してファイルアップロードを行う場合、デイリーのアップロード数は消費されますか? いいえ。Proof Point の実装はカスタムであるため、デイリーのアップロード リミットは消費されません。     6. ファイアウォールとWildFireクラウド間の通信 (アップロード/クエリー) でAPI Keyの使用数は消費されますか? いいえ。ファイアウォールとWildFire間の通信はAPI Keyの制限は受けません。     7. 手動アップロードをした際はどうなりますか? WildFireポータルにてファイルを手動アップロードをした際にも、API Keyの使用数は消費されます。     8. WildFireポータルで表示される "manual upload limit:5" は何を意味しますか? WildFire Only ユーザは、WildFireポータルで行えるデイリー アップロードの数が5で制限されています。     9. WildFire API Key を使ったデイリーのアップロード/クエリー上限数はいくつですか? - デイリー アップロードの上限数: 1000 - デイリー クエリーの上限数: 10000   Traps用API Keyの場合: - デイリー アップロードの上限数: 1000000 - デイリー クエリーの上限数: 1000000     10. デイリーのAPI Keyの使用数はどのように消費されますか? デイリーのAPI Keyの使用数はAPIを使ったリクエストによって消費されます。リクエスト毎に数が消費されるため、全く同じリクエストをAPIを使って複数回行った場合にもその回数分消費されます。また、リクエストに対して有効なレスポンスが無かった場合も同様です。例えば、WildFireクラウドにレポートが存在しないハッシュ値でクエリー リクエストを出したとします。この際、レポートの取得はできませんがAPI Keyの使用数は消費されます。同様に、未サポートのファイルタイプの検体をクラウドにアップロードしようとした場合、アップロード自体は失敗しますがAPI Keyの使用数は消費されます。     11. WildFire API Key はどのように生成されますか? WildFire API key はCSPアカウント毎に生成されます。(ファイアウォール毎でもWildFireサブスクリプション毎でもありません。)基本的にはひとつのアカウントにつき、ひとつのAPI Keyが生成されます。 WildFireサブスクリプションを最初にアクティベートしたタイミングでAPI Keyは自動で即生成されます。ファイアウォール デバイスをあるアカウントから別のアカウントへ移動(トランスファー)した際には、そのデバイスがWildFireサブスクリプションを持っていたとしてもWildFire API Keyは自動では生成されません。このような場合はパロアルト ネットワークス カスタマー サポートにお問い合わせいただき、WildFire API Keyの生成をリクエストしてください。     12. WildFire API Key 有効期限はどのように更新されますか? ひとつのCSPアカウント配下にWildFireサブスクリプションを持つ複数のファイアウォール デバイスがある場合、そのうちの最も長い期限を持つライセンスがWildFire API Keyの有効期限として反映されます。WildFireサブスクリプションが更新されると、WildFire API Keyの有効期限もそれに合わせて更新されます。ライセンス更新の際にWildFire API Key自体は変更されません。つまり、ライセンス更新によって新しいAPI Keyが生成されるようなことはありません。 ファイアウォール デバイスをあるアカウントから別のアカウントへ移動(トランスファー)した際には、WildFire API Keyの有効期限は更新されません。このような場合はパロアルト ネットワークス カスタマー サポートにお問い合わせいただき、WildFire API Keyの有効期限の更新をリクエストしてください。  
記事全体を表示
ymiyashita ‎06-20-2017 12:38 AM
8,104件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to verify the direction of spyware signatures for downloaders https://live.paloaltonetworks.com/t5/Threat-Articles/How-to-verify-the-direction-of-spyware-signatures-for/ta-p/133412     本記事は、脅威ログに記録されるダウンローダー タイプのスパイウェア シグネチャーの方向(Direction)の確認方法について記載しています。   詳細 以下の表にあるシグネチャーは、電子メールに添付されている悪意のあるダウンローダーを検知します。これらのシグネチャーはSMTPおよびPOP3の両方で機能します。すなわち、a) 攻撃者がSMTPを利用して悪意のあるファイルを外部から送信して来た場合、b) 被害者がそのファイルをPOP3を利用してメールサーバーから受信した場合、のどちらの場合でも検知を行います。   ID 脅威名(Threat Name) 方向(Direction) 13129 JSDownloader.Gen Javascript Detection server-to-client 13606 Nemucod.JSDownloader.Gen Javascript Detection server-to-client 13996 JS.DownLoader.2332 Javascript Detection server-to-client 14119 JSDownloader.Gen javascript Detection server-to-client 14283 Locky.JSDownloader.Gen Javascript Detection client-to-server 14337 LF.JSDownloader.Gen Javascript Detection server-to-client 14542 KV.JSDownloader.Gen Javascript Detection server-to-client 14567 Nemucod.JSDownloader.Gen Javascript Detection server-to-client 14613 Locky.JSDownloader.Gen Javascript Detection server-to-client 14616 Swabfex.JSDownloader.Gen Javascript Detection server-to-client 14680 Dridex.JSDownloader.Gen Javascript Detection server-to-client 14700 Locky.LNKDownloader.Gen Script Detection server-to-client 14834 Locky.JSDownloader.Gen Javascript Detection server-to-client 14847 Cerber.JSDownloader.Gen Javascript Detection server-to-client   各シグネチャーの方向(direction)は、ID: 14283を除き、全てserver-to-clientとして定義されています。server-to-clientというのは単にログにそのように記録されるだけで、実際には前述した通りどちらの方向でも検知は行われます。ID: 14283に関しては、SMTPで検知されたという報告が多かったため、その状況に基づいて方向をclient-to-serverにする変更が施されています。     例 172.28.30.225 : POP3 サーバー / SMTP サーバー 192.168.226.225 : メール クライアント(ユーザ) 脅威 ID : 14283   悪意のあるメールがファイアウォールを経由してSMTPサーバーへ送信され、そのメールがPOP3サーバーから受信されたとします。   以下はファイアウォールからエクスポートした脅威ログの一部です。   脅威ID: 14283の方向はclient-to-serverなのでPOP3で記録されたログにおいて、あたかもユーザ(192.168.226.225)がサーバー(172.28.30.225)に対して攻撃を行っているかのように見えます。   同様に、方向がserver-to-clientとなっているその他のシグネチャーについては、SMTPの場合に脅威ログが逆方向に記録されいてるように見えます。   これは、脅威ログを生成する際の制限事項であり、期待された動作となります。     著者: ymiyashita
記事全体を表示
ymiyashita ‎01-09-2017 05:21 PM
3,160件の閲覧回数
0 Replies
1 Like
セキュリティプラットフォームによる多層防御のアプローチと、 次世代ファイアウォールの各機能について ご紹介致します。
記事全体を表示
ykato ‎09-16-2016 01:15 AM
14,118件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Vulnerability Profile Actions https://live.paloaltonetworks.com/t5/Management-Articles/Vulnerability-Profile-Actions/ta-p/61708     この資料では、脆弱性防御プロファイルで利用できる様々なアクションについて説明します。アクションはセキュリティ プロファイルの各ルールや、特定の脅威IDの例外に対して指定することができます。   アクションの種類(訳注) アクション 対象 アクションの詳細 Default (デフォルト) 重大度に基づいた定義済みのアクション ルール 脅威ごとに選択された定義済みのアクションが適用されます。 Allow (許可) セッションは許可するが、脅威ログに記録しない           ルール       脅威ログに記録しないように、イベント用の例外を作成することができます。 Alert セッションを許可し、脅威ログに記録する ルール 重大度に関係なく、すべての脅威に対してログが有効になります。 Block (ブロック) セッションのすべてのパケットを破棄する ルール パケットが破棄されます。TCPは再度パケットを転送しようとしますが、再度破棄される点にご注意ください。実質的に、セッションそのものが遮断されます。 reset-server RSTパケットをサーバーに送信する 例外 パケットは破棄され、TCPリセットがTCP コネクションのサーバー側に送信されます。 reset-both RSTパケットをクライアントとサーバーに送信する 例外 パケットは破棄され、TCPリセットがクライアントとサーバーの両方に送信されます。 reset-client RSTパケットをクライアントに送信する 例外 パケットは破棄され、TCPリセットがTCPコネクションのクライアント側に送られます。 drop-all-packets セッションのすべてのパケットを破棄する 例外 セッションに対してのすべてのパケットが破棄されます。 drop 特定のパケットを破棄する 例外 特定のパケットが破棄されます。TCPは再度パケットを転送しようとしますが、再度破棄される点にご注意ください。 実質的に、セッションそのものが遮断されます。 block-ip 送信元IPアドレスからのすべてのパケットを破棄する 例外 ある送信元IPアドレスから送られてきた、特定の期間のすべてのセッションが遮断されます。   *「セッション」という言葉は、プロトコルがUDPの時のファイアウォール テーブルへの参照という意味で使用されています。   * 脅威ログに記録されるアクションは、プロトコルよっては脅威シグネチャ毎の既定のアクションの定義とは異なる場合があります。例えば"drop"がセキュリティ プロファイルに設定されている場合、TCPセッションでは" drop-all-packets" 、UDPセッションでは"drop"がアクション欄に記録されます。   訳注:括弧内はWeb UIで言語の表記を日本語にした際の表記です。   著者:jjosephs
記事全体を表示
hshirai ‎07-25-2016 08:46 PM
12,662件の閲覧回数
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 Add Exempt IP Addresses from the Threat Monitor Logs https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Add-Exempt-IP-Addresses-from-the-Threat-Monitor-Logs/ta-p/58391     概要 この資料は、特定の脅威に対して除外をするIPアドレスを追加する手段を記載します。   手順 [ Monitor ] > [ ログ ] > [ 脅威 ] を表示します。 目的の脅威名をクリックします。この脅威に対して、除外するIPアドレスが追加することになります。 セキュリティ ポリシーに関連した脆弱性ポリシーがあるかどうかを確認します。今回の例では、脆弱性プロファイル'test123'が適用されています。プロファイルのチェックボックスにチェックを入れてハイライトし、IPアドレスを下記図のように追加します。OKボタンをクリックします。 注:下記のログ中に表示されているように、IPアドレス (送信元アドレス、あるいは宛先アドレス) は被害者にも攻撃者にもなり得ます。 脆弱性防御プロファイル画面を開き、例外タブをクリックすることで、更新されていることを確認します。この画面内の"IP Address Exemptions"をクリックしてアプレットを表示し、下記図に表示されているように、変更を確認します。 "IP Address Exemptions"ダイアログ ボックスを閉じ、アクションの下に表示されている"default (reset-both)"をクリックします。アクションを許可に変更します。     著者:rkalugdan
記事全体を表示
hshirai ‎07-21-2016 06:10 PM
3,168件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Wildfire Configuration, Testing, and Monitoring https://live.paloaltonetworks.com/t5/Management-Articles/Wildfire-Configuration-Testing-and-Monitoring/ta-p/57722   Wildfireは Palo Alto ファイアウォールと統合し、マルウェアの検出や防止を提供するクラウドベースのサービスです。 PAN-OS 7.0以前のWildfireはファイル ブロッキング プロファイルとして、PAN-OS 7.0 からは WildFire 分析プロファイルとして設定され、分析が必要なトラフィックにマッチするセキュリティ ポリシーに適用することができます。     セキュリティ ポリシーにて:   厳格なセキュリティー ポリシーが適用されている場合、管理インターフェースからインターネットへの出力トラフィックにおいて "paloalto-wildfire-cloud" アプリケーションが許可されているか確認してください。本アプリケーションは "paloalto-updates" および同様のサービスを含む既存のサービス ポリシーに追加しなければならない場合があります。また、外部インターフェースへ wildfire-cloud を統合するためには、サービス ルートを追加する必要があります。     Wildfire は ファイル ブロッキング プロファイルのフォワード アクションとしてセットアップすることができます。 Forward: ファイルは "Wildfire" クラウドへ自動的に送信されます。 Continue and Forward: ユーザーはダウンロードと Wildfire への情報転送の前に "continue" アクションを促されます。 PAN-OS 7.0 でもファイル ブロッキング プロファイルでまだ "continue" アクションを選択することができますが、WildFire 分析プロファイルでは単純に"public-cloud" または "WF-500" アプライアンスが利用可能な場合は"private-cloud"に送信するように設定することができます。   Wildfire 設定で決定したファイル タイプが Wildfire クラウドによってマッチングされます。 Palo Alto Networks ファイアウォールはファイルのハッシュを計算し、Wildfire クラウドに計算されたハッシュのみを送信します。 クラウド内のハッシュはファイアウォール上のハッシュと比較されます。ハッシュがマッチしなかった場合、Wildfire ポータル (https://wildfire.paloaltonetworks.com/) 上にアップロードされ、検査したファイルの詳細を閲覧したりできます。 ファイルは解析のために Wildfire ポータルへ手動でアップロードすることもできます。   Wildfire のテスト/モニタリング: 管理ポートが Wildfire と通信できるかCLIで "test wildfire registration" コマンドを使用することで確認することができます。 > test wildfire registration This test may take a few minutes to finish. Do you want to continue? (y or n) Test wildfire         wildfire registration:        successful         download server list:          successful         select the best server:        va-s1.wildfire.paloaltonetworks.com 有効な Wildfire ライセンスが存在する場合、デバイスは Wildfire クラウドに登録されます。   以下のコマンドは WildFire の動作を確認するために使用することができます: > show wildfire status Connection info: Signature verification: enable Server selection: enable File cache: enable WildFire Public Cloud: Server address: wildfire.paloaltonetworks.com Status: Idle Best server: eu-west-1.wildfire.paloaltonetworks.com Device registered: yes Through a proxy: no Valid wildfire license: yes Service route IP address: File size limit info: pe 2 MB apk 10 MB pdf 200 KB ms-office 500 KB jar 1 MB flash 5 MB ... cut for brevity > show wildfire statistics Packet based counters: Total msg rcvd: 1310 Total bytes rcvd: 1424965 Total msg read: 1310 Total bytes read: 1393525 ... cut for brevity > show wildfire cloud-info Public Cloud channel info: Cloud server type: wildfire cloud Supported file types: jar flash ms-office pe pdf apk email-link   Wildfireへの送信ログは Wildfire アクションの詳細を提供します: wildfire-upload-success: ファイルは WildFire クラウドへのアップロードに成功しました wildfire-upload-skip: Wildfire クラウドは既にファイルを検査しており、ファイルのアップロードはされません。Benignファイルについては、Wildfire ポータル上でレポートは作成されません。     ファイルがアップロードされているか既に過去に分析されておりアップロードされなかった場合においても、この sha256に対する ログ エントリは Wildfire レポートと共に生成されます。ファイルが直近でアップロードされている場合には、WildFire 解析がまだ完了していない可能性があり、その場合レポートはまだ利用できません。                                   著者: tpiens  
記事全体を表示
tsakurai ‎07-17-2016 05:21 PM
10,010件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 CVE-2004-0230—Guessi ng TCP Sequence Numbers and Injecting RST Packets https://live.paloaltonetworks.com/t5/Threat-Articles/CVE-2004-0230-Guessing-TCP-Sequence-Numbers-and-Injecting-RST/ta-p/65945     TCP実装において大きいTCPウィンドウ サイズを使用した際、特にBGPのような長時間接続を維持する コネクションを使うプロトコルの場合、リモートの攻撃者にとってはシーケンス番号の推測がより容易になり、TCP RSTパケットを繰り返し挿入することによってDoS攻撃 (Denial of Service attack )  やコネクション断を引き起こし易くなります。   情報元: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0230 http://www.rfc-base.org/txt/rfc-5961.txt   攻撃が成功するためには、RSTパケットがTCPの受信ウィンドウ内に入ってなくてはなりません。攻撃者は考えられ得るそれぞれのウィンドウ サイズをカバーするために、大量のRSTセグメントを作り出します。これを実際に行うためには、攻撃者はいくつかの情報を既に持っているか、あるいは推測しなければなりません。   4-タプル (双方向のコネクションのIPアドレスとTCPポート番号) RSTパケットに使用されるシーケンス番号 お互いの端末が使っているウィンドウ サイズ。この値は正確なウィンドウ サイズである必要はありません。何故なら、正しい値の代わりにより小さい値を使うことは、攻撃者にとっては攻撃に成功するまで単により多くのセグメントを生成するだけの事であるからです。しばしば攻撃者は、ある程度の確実性を持って  (攻撃対象のアプリケーションを把握していて )、コネクション上で使われる実際のウィンドウ サイズに非常に近い値を導き出せるものです。 受信ウィンドウは、送り主がACKを受信せずに転送可能なバイト数となります。   上記の情報を集めあわせた後、攻撃者は、RSTフラグをセットし、推測したTCPシーケンス番号をつけ偽装したTCPセグメントを送信し始めます。新しいRSTセグメントが送信される度に、シーケンス番号の推測値はウィンドウ サイズ分だけ増やされます。   すべてのアプリケーションは、偽装攻撃を受ける可能性に大きく影響するいくつかの要素を持っています。これらの要素は以下を含みます:   ウィンドウ サイズ サーバー側ポート番号 クライアント側ポート番号   言い換えると、攻撃が成功するまでRSTセグメントを挿入する回数の平均値は、2の31乗をウィンドウ サイズで割った数 (2^31/window) であり、2の31乗の値ではありません。これはウィンドウが大きくなればなるほど、少ない推測で済む事を意味します。   この式に当てはめてみると、ウィンドウ サイズが 32,768 の場合、TCPの受け側にて偽装したTCPセグメントが受け入れられるには平均で 65,536 のパケットが転送されなければならないことがわかります。(2^31 = 2147483648 / 32,768 =65536 )  ウィンドウサイズが 65,536であれば、この平均値は 32,768まで減少します。 昨今のアクセス帯域幅を考えれば、このサイズでの攻撃は決して不可能ではありません。   一般家庭やオフィスでの帯域幅は増えてきており、帯域幅が大きくなるほどデフォルトのウィンドウ サイズは大きくなっていくと想像されます。   少数のパケットのやり取りの間のみ継続するTCPコネクションの場合(大抵はウェブ通信)、攻撃者は十分なトラフィックを生成できないため、このような攻撃に対してはあまり影響を受けないと言えるでしょう。しかし、BGPのような幾つかのアプリケーションは、この脆弱性に対し潜在的に最も影響を受ける可能性を持っています。BGPは、ピアとの間の継続的なTCPセッションの上に成り立ちます。コネクションがリセットされてしまうと、ルーティングテーブルの再構築が必要となり、また経路フラッピングも起きるため、結果としてサービス不能の状態に陥ります。BGPのようにTCP MD5オプションが使用可能なアプリケーションに関しては、そのオプションを使用することでこの攻撃を無効化することができます。   この脅威の回避策となる RFC 5961 は PAN-OS 6.0.0 において実装されています。     著者: mmmccorkle
記事全体を表示
ymiyashita ‎07-12-2016 07:46 AM
4,171件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Block Shellshock - CVE-2014-6271 and Related CVEs https://live.paloaltonetworks.com/t5/Threat-Articles/How-to-Block-Shellshock-CVE-2014-6271-and-Related-CVEs/ta-p/62469     概要 Palo Alto Networks は、一般に  Shellshock として知られる  CVE-2014-6271 とその関連 CVE を検知するためのシグネチャをコンテンツ バージョン #458にてリリースしました。CVE-2014-6271、CVE-2014-7169、CVE-2014-6277、およびCVE-2014-6288は、脅威 ID #36729, #36730, #36731, #36732, #36736, #36737 にて検知可能です。これらの脅威は、 HTTP、DHCP、FTP、およびSIPにおいて検知されます。なお、それらのトラフィックが通過する セキュリティ ポリシーには、 脆弱性防御プロファイルが適用されている必要があります。   脅威防御 ( Threat Prevention)  のサブスクリプションを保有するセキュリティ管理者は、これらの脅威をブロックしたいのであれば、重要度が criticalで定義されている全ての脅威をブロックするように脆弱性防御プロファイルを設定するか、もしくは Shellshockをカバーする脅威シグネチャ用に別途例外処理を設定してください。   注: Palo Alto Networks は コンテンツ  バージョン #460 にて全ての Shellshock用シグネチャのデフォルトのアクションを  "alert" から "reset-both" に変更しました。そのため、 重要度が criticalの脆弱性に デフォルト アクションを適用した場合は、 コンテンツ  バージョンを #460以降にアップデートした後にこれらの脅威がブロックされることになります。以下の手順は、デフォルト アクションを使っていない場合や、既存の脆弱性防御プロファイルにて例外設定を行う場合には依然として必要となります。   手順 デバイスにて、 コンテンツ  バージョン #458 以降がインストールされていることを確認します。もし、バージョンが古ければ、ダイナミック更新を行ってください。 ウェブ UI Device > ダイナミック更新 へ移動し コンテンツ  バージョンが #458 以上であることを確認します。以下がその例です。 注: もし古い コンテンツ  バージョンのみ表示されているようであれば、「今すぐチェック」ボタンを押して更新してください。 CLI "show system info" コマンドを実行し、 コンテンツ  バージョン #458 以降がインストールされていることを確認します。 以下がその例です。 > show system info hostname: PA-NGFW ip-address: 10.0.0.1 netmask: 255.255.0.0 ... threat-version: 458-2380 threat-release-date: 2014/09/26  00:21:59 ... もし古いバージョンがインストールされていたら、以下の一連のコマンドを実行してください。 > request content upgrade check > request content upgrade download latest > request content upgrade install version latest 注: アップグレードのためのジョブが無事終了すると、デバイスは最新の コンテンツ  データベースにアップデートされます。 脆弱性防御プロファイルを作成し、脅威をブロックするように想定しているトラヒックが通過しうる全てのセキュリティ ポリシー上でそのプロファイルが適用されていることを確認してください。 Policies > セキュリティ に移動し、設定を確認します。必要に応じて脆弱性防御プロファイルを適用してください。 Objects > セキュリティ プロファイル > 脆弱性防御 に移動し、これらの脅威をブロックするために用意した脆弱性防御プロファイルの名前をクリックします。 「例外」タブをクリックします。 「すべてのシグネチャの表示」にチェックを入れます。 検索ボックスに "36729" と入力し、エンターを押すか、緑の矢印をクリックします。 注: 36729を検索した際に何も表示されなければ、GUIキャッシュをクリアするために、一度ウェブUIからログアウトしてログインしなおしてください。再ログイン後、シグネチャが表示されるようになります。 シグネチャID #36729の隣にある「有効化」のチェックボックスにチェックを入れ有効にします。 シグネチャのアクションを変更するため「アクション」にある項目をクリックし、希望するブロック アクションを選択します。 OK ボタンを押しダイアログボックスを閉じます。設定が正しいことを確認してください。 上記の手順6から9までを#36730, #36731, #36732, #36736, #36737の各シグネチャに対して行います。 注: これらの手順は、 Shellshockをブロックするために用意した全ての脆弱性防御プロファイルにおいて繰り返し行う必要があります。 OKをクリックし、脆弱性防御プロファイルのダイアログボックスを閉じます。 設定をコミットします。   参考 リサーチ センター ブログ "Palo Alto Networks Addresses Bash Vulnerability Shellshock: Mitigation for CVE-2014-6271"  (英文) Palo Alto Networks Security Advisories, PAN-SA-2014-0004  (英文) NIST National Vulnerability Database CVE-2014-7169   (英文) NIST National Vulnerability Database CVE-2014-6271    (英文) NIST National Vulnerability Database CVE-2014-6277   (英文) NIST National Vulnerability Database CVE-2014-6278   (英文)   著者: ggarrison  
記事全体を表示
ymiyashita ‎07-12-2016 01:10 AM
2,461件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 CVE-2011-3389: The BEAST Attack to TLS 1.0 https://live.paloaltonetworks.com/t5/Threat-Articles/CVE-2011-3389-The-BEAST-Attack-to-TLS-1-0/ta-p/60852     詳細 2011年、ある攻撃手法 ("BEAST"攻撃)がCBCモードを使ったSSL 3.0とTLS 1.0プロトコルに対して実演されました (CVE-2011-3389)。Palo Alto Networksから開始される、もしくは終端する全てのSSL/TLSコネクションは、CBCモードを使ったTLS 1.0の利用をサポートしますが、BEASTにより受ける影響は限られたものです。   Palo Alto Networksデバイスのマネージメント インターフェイス: BEAST攻撃が成功するためには、以下の条件を満たす必要があります。 攻撃者はデバイスのマネージメント インターフェイスへアクセス可能であること。ネットワーク セキュリティのベストプラクティスによれば、通常マネージメント インターフェイスは専用の管理ネットワークにのみ提供されていて、プロダクションのネットワーク トラフィックとは隔離されているものです。 被害を受けうる管理者は更新されていない古いブラウザを使用しており、SSL 3.0 と TLS 1.0 の通信でCBSモードを無効にするアップデートが行われていない。 被害者がPalo Alto Networksデバイスのウェブベース マネージメント インターフェイスにHTTPSでアクセスする前に、起動中のブラウザが保持している同じブラウザ セッションを使用して、攻撃者は特別に細工したリクエストを被害者のブラウザからあるHTTPSサイトに向けて生成することが可能であること。 最初のステップは、初期化ベクター(IV)を知ることであり、これは次のステップにおいてサイトに訪れたときにできるSSLセッションをエクスプロイトするのに使用されます。 注: 項目3に書かれた内容は、現実的にはかなり困難なことです。そしてこの問題自体は、項目1に書かれているように管理ネットワークとプロダクションのネットワークが隔離されてさえいれば、完全に回避可能です。   GlobalProtect ポータルとゲートウェイ: GlobalProtectクライアントから、ポータルおよびゲートウェイへのSSL VPNトンネル用のコネクションは BEAST攻撃の 影響を受けません。何故なら、GlobalProtectクライアントではウェブ ブラウザのようにIV(初期化ベクター)を割り出すような操作ができないためです。   GlobalProtectポータルにウェブ ブラウザからアクセスした場合は、管理GUIと同様、上記に記載されたように BEAST攻撃の影響を受けます。ただし、ここでの機能は GlobalProtectクライアントをダウンロードするのみでありVPNコネクションはこの時点では張られていないので、影響範囲は極めて限られています。   著者: gwesson  
記事全体を表示
ymiyashita ‎07-11-2016 10:26 PM
3,564件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 SSL 3.0 MITM Attack (CVE-2014-3566) (PAN-SA-2014-0005) aka Poodle https://live.paloaltonetworks.com/t5/Threat-Articles/SSL-3-0-MITM-Attack-CVE-2014-3566-PAN-SA-2014-0005-aka-Poodle/ta-p/61856     詳細 本脆弱性の詳細につきましては、以下のセキュリティ アドバイザリを参照してください。 Palo Alto Networks Product Vulnerability - Security Advisories  (英文)   本文書ではセキュリティ アドバイザリに補足する形で詳細を記載します。Palo Alto Networks は本脆弱性に対応するために、製品毎に別の変更を施しています。本文書で記載しているように、この攻撃はそれぞれの機能毎にその影響範囲が限られています。 注: GlobalProtect ポータル、GlobalProtect ゲートウェイ、キャプティブ ポータルにおいて、Palo Alto Networks はSSLv3を無効化するように取り組みをしています。このプロセスは2つ以上のメンテナンス リリースを経るかもしれません。追加情報があれば、都度本文書を更新してまいります。   管理ウェブ GUI サーバー Palo Alto Networks は、デバイスの管理サービスを専用のVLANに制限するか、もしくは信頼できるネットワークとしてセグメントを分け、可能な限り信頼されないホストに晒されないようにすることを推奨します。仮にそれができない場合は、ウェブGUIはSSLv3リクエストに応答することになります。 注: PAN-OS 5.0.16、6.0.8、6.1.2以降のバージョンにおいて、デバイスの管理用コネクションにSSLv3は使用しないようになっています。   GlobalProtect ポータル GlobalProtect ポータル ページはブラウザでアクセスした場合、CVE-2014-3566の影響を受ける場合があります。攻撃が成功した際に取得される情報は認証クッキーのみです(ユーザ名、パスワードは窃取されません)。 ポータル ページにおける認証クッキーはGlobalProtectクライアントをダウンロードするためだけに使用され、GlobalProtectのログインやVPN接続には使用されません。   GlobalProtect ゲートウェイ GlobalProtect ゲートウェイは実際にSSLv3リクエストに対して応答をします。ただし、CVE-2014-3566が成功するためには、攻撃者が用意したJavascriptやウェブ ソケット コードと共にブラウザがハイジャックされ、かつクッキーを含んだリクエストが被害者のサーバーに向けて発行され1バイトずつ復号化される必要があります。GlobalProtect エージェントはブラウザではないので、このような攻撃に対して影響を受けません。   キャプティブ ポータル キャプティブ ポータルはSSLv3リクエストに対して応答をしますが、キャプティブ ポータルは内部的にユーザを認証するものであり、設定が正しく成されていれば外部からアクセスはされません。ただし、内部に感染したクライアントが存在すれば、それが攻撃の起点になる可能性があります。   Panorama Palo Alto NetworksファイアウォールとPanorama間でのコネクションではSSLv3をサポートしないため、本脆弱性の影響を受けません。   著者: gwesson
記事全体を表示
ymiyashita ‎07-11-2016 10:25 PM
2,604件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 GHOST - Linux Remote Code Execution CVE-2015-0235 0-day Vulnerability https://live.paloaltonetworks.com/t5/Threat-Articles/GHOST-Linux-Remote-Code-Execution-CVE-2015-0235-0-day/ta-p/59444     2015年1月27日(火)に、いくつかのLinuxディストリビューションにおけるGetHost関数において、リモート コードを実行される脆弱性が発見されました。通称、"GHOST glib gethostbyname" と呼ばれるバッファ オーバーフローの脆弱性(CVE-2015-0235)です。   Qualysによって書かれた脆弱性のまとめの中で提供された概念実証 (proof of concept)によって実証されたように、Palo Alto Networksは本脆弱性が IPSシグネチャID #30384, "SMTP EHLO/HELO overlong argument anomaly” over SMTP によって防御されることを確認しました。攻撃に成功してしまうと、サーバーの権限の元でリモート コードを実行することが可能となります。   脅威防御サブスクリプションを保持するお客様は、Palo Alto Networks デバイス上で最新版のコンテント バージョンが当たっていること、また適切にポリシーが設定されていることを確認されることを推奨します。不明な点がありましたら、Palo Alto Networks サポート チームにお問い合わせ下さい。   この脆弱性についての詳細に関しましては、以下を参照してください。   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0235  (英文) https://community.qualys.com/blogs/laws-of-vulnerabilities/2015/01/27/the-ghost-vulnerability  (英文)   著者:  panagent
記事全体を表示
ymiyashita ‎07-11-2016 12:12 AM
2,834件の閲覧回数
0 Replies
1 Like
※この記事は以下の記事の日本語訳です。 How to Block A Threat For a Specific Time Interval https://live.paloaltonetworks.com/t5/Threat-Articles/How-to-Block-A-Threat-For-a-Specific-Time-Interval/ta-p/58181     概要 本文書では、脅威を検知した際に、予め設定した一定時間その脅威をブロックする方法について説明します。   詳細 この制御は、アンチスパイウェアと脆弱性防御の両方において設定が可能です。   アンチスパイウェア Objects > セキュリティ プロファイル > アンチスパイウェア へ移動し、「追加」をクリックします。 アンチスパイウェア プロファイル > 例外 > 名前 の欄で、名前を入力します。 「すべてのシグネチャの表示」にチェックを入れ、該当の脅威 IDを入力し、「アクション」をクリックします。 「block-ip」を選択すると、時間を設定する項目が表示されます。時間は1秒から3600秒の間で設定が可能です。「追跡」では「IPソース」または「IPソース及び宛先」のどちらかを選択してください。 設定変更後のアクションは以下のように表示されます。 実際に攻撃が検知されるとセキュリティ ポリシーに割り当てた本プロファイルが適用されます。ソースIPと宛先IPアドレスがトラックされ、3600秒の間ブロックされ続けます。   脆弱性防御 Objects > セキュリティ プロファイル > 脆弱性防御 へ移動し「追加」をクリックします。 名前を設定し、「例外」タブへ移動します。 「すべてのシグネチャの表示」にチェックを入れ、該当の脅威 IDを入力します。 「block-ip」を選択すると、時間を設定する項目が表示されます。時間は1秒から3600秒の間で設定が可能です。「追跡」では「IPソース」または「IPソース及び宛先」のどちらかを選択してください。 設定変更後のアクションは以下のように表示されます。 実際に攻撃が検知されるとセキュリティ ポリシーに割り当てた本プロファイルが適用されます。ソースIPと宛先IPアドレスがトラックされ、3600秒の間ブロックされ続けます。   著者: dantony
記事全体を表示
ymiyashita ‎07-10-2016 10:46 PM
3,917件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Change the Brute Force Trigger Criteria https://live.paloaltonetworks.com/t5/Threat-Articles/Change-the-Brute-Force-Trigger-Criteria/ta-p/62405     概要 本文書では、 Palo Alto Networksファイアウォールを通過する brute force攻撃を検知するためのシグネチャのデフォルト設定の見方と変更方法について説明します。   手順 Objects > セキュリティ プロファイル > 脆弱性防御 へ移動し、脆弱性 防御プロファイルを開きます。 「例外」タブを開きます。 必要に応じて「すべてのシグネチャの表示」をクリックします。 検索ボックスにて、"brute force" と入力するか、脅威ID を入力します。 カスタマイズするには、シグネチャ名の横にある鉛筆アイコンをクリックします。 必要に応じて、時間属性の編集を行います。集約基準は、Source、Destination、Source-and-Destinationのいずれかを選択してください。 変更が完了したら、「有効化」チェックボックスにチェックを入れ有効にします。 変更をコミットします。    参考 brute force 関連の脆弱性リストは以下の文書を参照してください。 Trigger Conditions for Brute Force Signatures (英文)   著者: sdarapuneni  
記事全体を表示
ymiyashita ‎07-10-2016 10:22 PM
2,885件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Threat landscape: Why DNS Signatures and URL categorizations for malware change https://live.paloaltonetworks.com/t5/Threat-Articles/Threat-landscape-Why-DNS-Signatures-and-URL-categorizations-for/ta-p/71052     問題 - "Suspicious DNS signature" (WildFire: 3,800,000 - 3,999,999, AV: 4,000,000 - 4,199,999) の内容が以前と異なる。 - 悪意のあるサイトがMalwareとして分類されていない、あるいは、以前はMalwareと分類されていたけれども現在は別カテゴリに分類されている。     解説 脅威は日々、変化と進化を遂げています。現在、エクスプロイト キットの作成者はセキュリティをかいくぐるための複雑なメカニズムを熟知しています。最近の事例に関しては、このリンクを参照してください。悪意のあるサイトは、サイトに訪れるユーザーに対してエクスプロイトやマルウェアを隠すように巧みにフィルターすることができます。それには、ロケーション、ブラウザの動作、クッキーの値、過去の訪問履歴、訪問した時間など、様々な要素が用いられます。   サイトが常に悪意のある行いをし、訪問する全てのユーザに対して影響を与えるようでなければ、そのサイトを運行している全てのドメインをMalwareと定義することは理想的ではありません。なぜならば、そうすることによって正規のコンテンツやサービスまでブロックされる恐れがあるためです。   DNSシグネチャは利用できるアクティブなデータを元に、短い期間で変更されていきます。WildFireのコンテンツは15分おきに更新されるため、DNSの分類も最短で15分で更新されます。ただし、この更新周期はデバイス上でのWildFireコンテンツの更新スケジュールの設定に依存します。   ブロックと防御へのアプローチは、攻撃者が利用するテクニックにマッチするために順応でなければなりません。柔軟、かつ正確に検知を行い、正規のトラフィックをブロックしないようにすることが最もな理想です。実際に悪意のあるコンテンツの配信を検知することは、評判をベースにしたブラックリストに比べれば(サイトの分類判断基準として)より正確です。   最近の脅威に常に対応できるように、我々のシグネチャは絶えず更新され続けます。仮に、現在アクティブとなっている脅威をベースとしてテスト/更新/削除がなされなければ、その防御は意味を成さないものになるでしょう。     著者: rcole    
記事全体を表示
ymiyashita ‎07-10-2016 06:46 PM
3,253件の閲覧回数
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
日々変化するサイバー脅威のトレンドと、それに対抗する弊社セキュリティプラットフォームを使った多層化防御アプローチに関する資料となります。
記事全体を表示
ykato ‎06-19-2016 11:33 PM
8,883件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to submit an Anti-Virus false positive https://live.paloaltonetworks.com/t5/Threat-Articles/How-to-submit-an-Anti-Virus-false-positive/ta-p/74600     概要 ウイルス シグネチャ誤検知を申告いただく場合、下記で記述した情報を御提供くださいますようお願い致します。     取得する情報 "show system info" コマンドの出力結果もしくは、WebGUI の Dashboard > "一般的な情報" のスクリーン キャプチャ。 AVシグネチャをトリガしたサンプル ファイル。サンプル ファイルを御提供いただく場合、必ずパスワードで圧縮し、解凍用のパスワードとともに御提供ください。 サンプル ファイルのSHA256/MD5 ハッシュ値。 トリガされた脅威イベント ログの詳細のスクリーンショット、脅威ID/脅威名。(例えば、Threat ID 2000002 | Net-Worm/Win32.Conficker.cr) ウイルス シグネチャ誤検知と判断された情報。例えば下記の情報。 - VirusTotalによるサンプル検査結果 - サンプルはお客様により作成されたもの - サンプルは第三者機関の電子署名をされている - サンプルを解析し、悪意のあるファイルではないことを確認されている     上記の情報を採取いただき、サポート ケース上にご提供いただくことで、ウイルス シグネチャ誤検知の調査が可能となります。  
記事全体を表示
kkawachi ‎06-08-2016 05:10 AM
4,766件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to create a vulnerability exception https://live.paloaltonetworks.com/t5/Threat-Articles/How-to-create-a-vulnerability-exception/ta-p/71479     以下に、脆弱性防御プロファイルにおけるシグネチャのアクション設定を変更する方法を説明します。   手順 ウェブGUIにログインします。 Objects タブに移動します。 左にあるナビゲーション メニューより、"セキュリティ プロファイル"  > "脆弱性防御" へ移動します。 変更したいプロファイルの名前をクリックします。予め用意されている "default" 及び "strict" ポリシーは読み取り専用になっており変更はできません。必要に応じて "コピー" して使用してください。 "例外" (Exceptions) タブをクリックします。 "すべてのシグネチャの表示" (Show all signatures) のチェックボックスにチェックを入れます。 脅威ID(もしくは脅威名)で検索をします。 "アクション" を変更します。 "有効化" チェックボックスにチェックを入れます。 OKボタンを押します。 変更をコミットします。   上記の手順で変更したもの以外の全てのシグネチャは、継続してデフォルトの動作をします。今回の例では、この脆弱性防御プロファイルが使用されているセキュリティ ルールにおいて、脅威ID  30419のシグネチャは "allow" アクションを取るようになります。
記事全体を表示
ymiyashita ‎06-08-2016 04:56 AM
5,264件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Check or Edit the Default Action of a Threat Signature https://live.paloaltonetworks.com/t5/Threat-Articles/How-to-Check-or-Edit-the-Default-Action-of-a-Threat-Signature/ta-p/56156     手順 ウェブGUIより、Objects > セキュリティ プロファイル > アンチスパイウェア (または 脆弱性防御) へ移動します。 任意のプロファイルをクリックし、例外タブへ移動します。 "すべてのシグネチャの表示" ("show all signatures") のチェックボックスにチェックを入れ、各脅威とそれに対応するアクションを表示します。特定の脅威に対するアクションを変更するには、"アクション" をクリックします。 注:"predefined" プロファイル(strict, default) は読み取り専用となっており、編集できません。 また、デフォルト アクションの確認は T hreat Vault ( https://threatvault.paloaltonetworks.com/ ) で行うこともできます。 (訳注: 以下のスクリーンショットは、古いバージョンのThreat Vaultをベースにしています。) 脅威ID を入力し、脅威のタイプを選択します。 脅威IDの横にある虫眼鏡アイコンをクリックすると詳細が表示されます。   著者: harshanatarajan
記事全体を表示
ymiyashita ‎06-08-2016 04:37 AM
6,291件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 What Conditions Trigger Microsoft Windows SMB Fragmentation RPC Request Attempt Alert? https://live.paloaltonetworks.com/t5/Threat-Articles/What-Conditions-Trigger-Microsoft-Windows-SMB-Fragmentation-RPC/ta-p/54033       Microsoft Windows SMB (Server Message Block) フラグメント RPC (Remote Procedure Call) を発生させる条件は以下の通りです: MSRPC データ長が2バイト未満 MSRPC データ長が MSRPC ヘッダ長より小さい MSRPC フラグメント長が現在のパケット長よりも大きい これは回避手法の検知を示すものであり、攻撃が実際に行われていることを意味するわけではありません。また、回避手法は脆弱性とは異なるため、これに該当するCVE番号は存在しません。より詳細についてはこちら(英文)を参照してください。   著者: jnguyen
記事全体を表示
ymiyashita ‎06-07-2016 06:32 PM
2,517件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Threat ID 30419 (RFC2397 data URL scheme usage detected) https://live.paloaltonetworks.com/t5/Threat-Articles/Threat-ID-30419-RFC2397-data-URL-scheme-usage-detected/ta-p/71389     問題 本記事では、脅威 ID 30419 が検出された際にどのように調査を行えばよいか、またそのシグネチャが何を示すのかについて説明します。   JWPlayer のバージョン7以前のバージョンは、ビデオ配信の一部としてエンコーディングを施されたフォント データをホストに転送する動作をします。これは事実上、悪意のあるトラヒックではありませんが、使用されるエンコーディングのフォーマットによって本シグネチャがトリガされます。   詳細 本シグネチャは、HTMLのメッセージ本文内にBase64でエンコードされたアプリケーション データが存在するかどうかをチェックします。   幾つかのアンチウイルス製品や侵入防御システムは、エンコードされたデータがHTMLメッセージ本文にある場合にマルウェアを検知できない場合があります。 HTMLのレスポンス メッセージにおいてRFC 2397に記載されているエンコーディングを使ってエンコードされたデータが含まれている場合、これらの製品はスキャンに失敗します。Mozillaをはじめとする幾つかのブラウザではこのURLスキームをサポートするため、このエンコードされたデータも正常に表示することができます。すなわち、これはアンチウイルス製品や侵入防御システムを回避しつつブラウザを通してクライアントPCを攻撃できることを意味します。攻撃者はHTMLレスポンス内にdataスキームを使ってエンコードした悪意のあるコンテンツを配信することで、この脆弱性を突きます。   このシグネチャによる検知自体は、エクスプロイトがあったことを常に指し示すものではありません。本シグネチャで検知されるエンコードされたデータを含むHTMLレスポンスであっても、正規なものとして使われているということもあり得ます。   本シグネチャは、ネットワーク管理者がいつ事象が発生したかを知るために用意されています。それは該当トラフィックが回避手段として用いられている可能性がゼロではないためです。管理がこのシグネチャを不要と判断した際には、"許可"の例外設定をし、ログが生成されないようにすることも可能です。  
記事全体を表示
ymiyashita ‎06-07-2016 06:32 PM
2,494件の閲覧回数
0 Replies
Ask Questions Get Answers Join the Live Community