About kkawachi

※この記事は以下の記事の日本語訳です。 Unable to see Japan WildFire analysis report from GUI after upgrading deployment from 6.1.x to 7.1.x https://live.paloaltonetworks.com/t5/Management-Articles/Unable-to-see-Japan-WildFire-analysis-report-from-GUI-after/ta-p/193950 症状 下記の条件に合致していた場合、PANOSを6.1.x から7.1.xにバージョンアップした後に、Japan WildFire 分析レポートがGUIから確認できない症状が発生致します。こちらの症状が発生した場合、 WildFire分析レポートが表示される代わりに、 " Fetching WildFire server  jp.wildfire.paloaltonetworks.com :443 info failed! Please examine service route or proxy setting!"といったメッセージが表示されます。   1. 6.1.xをご利用だった時に、 "jp.wildfire.paloaltonetworks.com" をWildFire Serverとして利用していた。 2. WildFire Serverに接続するために、Firewallにおいてプロキシサーバを指定していた。 3. 6.1.x から 7.1.xにバージョンアップした後、 "jp.wildfire.paloaltonetworks.com"が WildFire Private Cloudとして設定されている。   原因 PANOS 7.0.xから、 WildFire Hybrid Cloudの機能がサポートされたことが起因しています。   WildFire Hybrid Cloudのサポートにより、本機能をご利用でいなかったとしても、6.1.x から 7.1.xにバージョンアップした結果、"jp.wildfire.paloaltonetworks.com"が WildFire Private Cloudとして自動的に設定されます。   解決策 こちらの症状が発生した場合、WildFire Private Cloudから"jp.wildfire.paloaltonetworks.com"を削除の上、 変更をコミットしてください。その後、WildFire分析レポートがGUI ("Monitor=>WildFire Submissions") から確認できるようになります。   https://live.paloaltonetworks.com/t5/Management-Articles/Unable-to-see-Japan-WildFire-analysis-report-from-GUI-after/ta-p/193950     著者: kkawachi ... View more

※この記事は以下の記事の日本語訳です。 Python script for querying a firewall for all available apps, their details and write results to CSV https://live.paloaltonetworks.com/t5/API-Articles/Python-script-for-querying-a-firewall-for-all-available-apps/ta-p/60483   添付されたスクリプトで、ご利用のFirewallに接続し(FirewallのマネジメントIP,管理ユーザー名、パスワードはスクリプトの引数として指定していただく必要があります)、インストールされているApplication Signature database から、利用可能なApplicationのリストと個々のApplicationの詳細を取得し、その内容をCSV形式で保存することが可能です。 CSVファイルは、MS Excelを使用して編集等を行うことができます。 注意: このスクリプトは、FirewallにHTTPSで接続し、 XML-APIで利用可能なApplicationのリストと個々のApplicationの詳細を取得するリクエストを送ります。   スクリプトの前提条件: Python 2.7.5/6   実行するために必要なPython libraries : sys httplib argparse lxml logging re csv   本スクリプトは以下の環境でテストされています。: - Windows 7 Enterprise Service Pack 1 (64-bit)  + python 2.7.5 - Ubuntu 14.04.1 LTS 64-bit + python 2.7.6   変更履歴: ** 1.0.0 - script作成 ** 3.0.0 - script修正(個々のApplicationのobsolete属性取得機能の追加のため） 修正されたscriptは、添付されたapp_list_export3.zipで提供されています。 scriptのサンプル出力は、applist657.zipで提供されています。 制約事項: - -oオプションの引数において、ファイルシステム形式のフルパスの指定には対応しておりません。   利用方法: app_list_export.py [-h] -i IPアドレス [-u ユーザー名] [-p パスワード] [-o csvのファイル名] 引数の説明:   -h, --help            ヘルプのメッセージを表示します。   -i IPアドレス, --IP IPアドレス        Firewallの管理IPアドレスを指定します。   -u ユーザー名, --user ユーザー名  Firewallにログインするユーザー名; デフォルトは 'admin'   -p パスワード, --password パスワード                         Firewallにログインするユーザー名のパスワード; デフォルトは 'admin'   -o csvのファイル名, --output csvのファイル名                         scriptがインストールされているディレクトリ上に出力されるファイル名; デフォルトは'app.csv'   利用例: 10.66.18.91のFirewall(パスワードとユーザー名がadmin/admin)に対して、スクリプトを利用し、出力をapplist.csvに保存する場合、実行例は以下のようになります。: $ python appv2.py -i 10.66.18.91 -u admin -p admin -o applist.csv   上記のコマンドにより、 applist.csvは、コマンドを実行した同一ディレクトリ内に生成されます。サンプルの出力は、applist455.csvという名前でこちらのKBに添付されています。   ライセンス: 本スクリプトは、Creative Commons Attribution 3.0 Unported Licenseに基づき作成されています。スクリプトのご利用ならびに配布については、特に制限されているものではございません。スクリプトのバグ等については、Palo Alto Networks DevCenterにご連絡ください。   著者: goku123 ... View more

概要 Content Version 734 より追加されたPAN-DB URL カテゴリ “Command-and-Control”に伴い、test urlコマンドにて "Command-and-Control"のカテゴリが正しく認識されるかどうかの確認方法を本KBで紹介致します。   前提条件 -弊社FirewallのURL Filtering機能において、PAN-DB URL Filteringをご利用であること -Content Update 734以降をインストールしていること   確認手順  手順1：ご利用のFirewallの管理WebGUIにアクセスし、管理者権限のユーザーでログインします。URLはhttps(もしくはhttp)://Firewallの管理IPになります。   手順2：Device=>Content-IDの順にクリックし、PAN-DB Serverにおいて値が指定されていないことを確認します。(画面1参照)　値が指定されている場合は、削除し、Commitしてください。 画面1   手順3：管理CLIに管理者権限のユーザーでログインします。ログイン後、"test url urlfiltering.paloaltonetworks.com/test-command-and-control"を実行します。画面2のように、"urlfiltering.paloaltonetworks.com/test-command-and-control command-and-control (Cloud db)”と表示されていれば、ご利用FirewallのPAN-DB URL Filtering機能により、正しく"Command-and-Control"のカテゴリが認識されていることを 示します。 画面2           ... View more

※この記事は以下の記事の日本語訳です。 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 カテゴリの確認方法 ... View more

対象 弊社FirewallのURL Filtering機能において、PAN-DB URL Filteringをご利用のお客様   ※FirewallのURL Filtering機能において、Bright Cloud URLFilteringをご利用の場合は該当致しません。   概要 Content Version 734以降のContent Updateをインストールすると、全てのPANOSにおいて、PAN-DB URL カテゴリ Command-and-Controlが追加されます。追加されたCommand-and-Controlのデフォルトアクションについては、PAN-OS 8.0.1 以前ではallow、PAN-OS 8.0.2以降ではContent Version 738以降のバージョンにてblockとなります。Command-and-Controlの推奨アクションについては、blockとなり、お客様により変更していただく必要がございます。   ※  Content Version 734にてリリースされた Command-and-Controlカテゴリは前準備であり、実際の利用開始については Content Version 734のリリースより30日後の2017年10月中旬を予定しております。   ※ PAN-OS 8.0.2以降でデフォルトアクションがblockになるのは事前定義されているdefaultプロファイルのみです。URL Filteringプロファイルを新規で作成する場合はすべてのアクションがallowになるため、事前に定義されているdefaultプロファイルをコピーして使用していただくことを推奨します。また、過去に作成されたURL Filteringプロファイルも同様にCommand-and-Controlカテゴリのアクションはallowになりますので、以下の手順にしたがってblockに変更してください。   Command-and-Controlのデフォルトアクションを、allowのまま御利用いただいている場合、Command-and-Controlの利用開始に伴い、C2Cサーバへの通信がblockされない結果に繋がりますので、必ずblockに変更いただくようお願い致します。   変更手順 手順1：御利用のFirewallで、PAN-DB URL Filteringを利用し、かつContent Version 734以降のContent Updateがインストールされているかどうか、show system infoの出力内容から確認します。ご利用のFirewallにて、以下の画面1のように、url-db: paloaltonetworksとapp-version: 734-4212となっていた場合、本件に該当致します。該当している場合、手順2以降を実施します。   ※Content Version 734以降のContent Updateをインストールしていた場合、app-versionには、インストールされているバージョンが表示されます。Content Version 735をインストールしていた場合、app-version: 735-4213となり、同様に手順2以降の操作が必要です。   ※こちらの手順は、PANOS8.0での実施例となりますが。他のPANOSでも同じ手順にて実施が可能です。   画面1：   手順2：ご利用のFirewallの管理WebGUIにアクセスし、管理者権限のユーザーでログインします。URLはhttps(もしくはhttp)://Firewallの管理IPになります。   手順3：ログイン後、"Objects"をクリック、" URL Filtering"をクリックします。画面2が表示されます。   画面2： 手順4：ご利用のURL Filtering Profileをクリックし(画面3)、"URL Filtering Profile"画面(画面4)を表示させます。 "URL Filtering Profile"画面にて、"command-and-control"の"Site Access"allowとなっていることを確認します。   ※画面3では、"kkawachi"という URL Filtering Profileが設定されている例となります。   画面3：   画面4：   手順5："URL Filtering Profile"画面にて、"command-and-control"の"Site Access"の"allow"をクリックし、プルダウンメニューから"block"を選択します。(画面5)   画面5：   手順6："command-and-control"の"Site Access"で"block"を選択されていることを確認し、"OK”を押し、"URL Filtering Profile"画面を閉じます。(画面6)　Commitをクリックします。(画面7)。"Commit"画面が表示されたら、Commitボタンを押します。(画面8)。これで必要な変更手順は完了致します。   画面6:   画面7：   画面8：     ... View more

対象 旧WildFire Japan クラウド wildfire.paloaltonetworks.jp をご利用されていた全てのお客様   概要 旧WildFire Japanクラウドドメイン(wildfire.paloaltonetworks.jp)に接続されてるファイアウォールに 対し、実施しておりました、現WildFire Japanクラウドドメイン(jp.wildfire.paloaltonetworks.com)へ のリダイレクト処理についてですが、2017年4月15日16:00(日本時間)まで延長させていただくことに致しました。   これにより、下記の”WildFire Japan アップデート”にてご案内致しておりましたリダイレクト期間は、下記のとおり延長させていただくことになりました。   　　移行期間開始日：2016年12月15日((日本時間) 　　移行期間終了日：2017年 4月15日(日本時間)   ”WildFire Japan アップデート”の内容をご確認いただく場合、こちらのURLの情報をご参照ください。 https://live.paloaltonetworks.com/t5/%E3%83%8A%E3%83%AC%E3%83%83%E3%82%B8%E3%83%89%E3%82%AD%E3%83%A5%E3%83%A1%E3%83%B3%E3%83%88/WildFire-Japan-%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88/tac-p/132607#M251 お客様の機器で旧WildFire Japanクラウド(wildfire.paloaltonetworks.jp)が指定されていた場合、2017年4月15日16:00(日本時間)まではWildFireにて提供される、シグニチャのアップデートと脅威防御の機能をご利用いただけます。 2017年4月15日16:00(日本時間)以降上記のリダイレクト処理を停止致しますので、旧WildFire Japanクラウドドメイン(wildfire.paloaltonetworks.jp)に接続されてるファイアウォールはWildFire Japanクラウドへの接続処理やサンプルの転送が適切に実施されません。そのため、2017年4月15日16:00(日本時間)までに、下記の移行手順を実施くださいますようお願いいたします。移行手順を実施いただいていないファイアウォールは、FirewallによるWildFireクラウドへの未知の検体の転送処理/ならびに防御が正常に実施されません。   実施していない場合、Firewallでtest wildfire registrationを実施した場合、失敗し、wildfire registration:の結果がfailedとなります。以下がtest wildfire registrationコマンドが失敗した際のサンプル出力となります。 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> admin@PA-200> test wildfire registration This test may take a few minutes to finish. Do you want to continue? (y or n) Test wildfire Public Cloud Testing cloud server jp.wildfire.paloaltonetworks.com ... wildfire registration: failed >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   移行手順 ファイアウォール上にて、WildFire Japan クラウドドメインの設定を jp.wildfire.paloaltonetworks.com に変更します。 WildFire Test PEファイルを使用し、新しいWildFire Japanクラウド設定が機能していることを確認します。 参考資料 1. PAN-OS 設定変更 PAN-OSにおけるWildFire クラウドのドメイン変更方法は以下に記載されています。 https://www.paloaltonetworks.com/documentation/70/pan-os/pan-os/getting-started/enable-wildfire WildFire 管理者ガイド: https://www.paloaltonetworks.jp/content/dam/paloaltonetworks-com/ja_JP/Assets/PDFs/technical-documen... WildFire FAQ 日本語版: https://live.paloaltonetworks.com/t5/Threat-Articles/WildFire-Japan-FAQ-日本語版/ta-p/54621 2. APIの変更 APIを使用する際もドメインをwildfire.paloaltonetworks.jp からjp.wildfire.paloaltonetworks.comへの変更が必要です。 例えば、WildFire Japanクラウドから検体のVerdictを取得するcurlコマンドは以下のようになります。 curl -F 'こちらにご利用のAPIキ-を指定してください' -F 'hash=こちら に対象のサンプルのsha256を指定してください' 'https://jp.wildfire.paloaltonetworks.com/publicapi/get/verdict' 以下はWildFire API に関するドキュメントとなります。 https://www.paloaltonetworks.com/documentation/71/wildfire/wf_api/about-the-wildfire-api ... View more

対象 旧WildFire Japan クラウド wildfire.paloaltonetworks.jp をご利用されていた全てのお客様   概要 2017年3月15日16:00 (日本時間) に、WildFireクラウドのバージョンアップの移行期間（90日）の完了をもちまして、wf10.wildfire.paloaltonetworks.jpを停止させていただきます。 これにより、wf10.wildfire.paloaltonetworks.jpを使用したWildFireポータルから、2016年12月15日9:00(日本時間) 以前に作成された以下のデータの取得が実施できないようになります。 ・過去のレポートの取得 ・Malware検体の取得 ・PCAPファイルの取得 WildFire Japan アップデート： https://live.paloaltonetworks.com/t5/ナレッジドキュメント/WildFire-Japan-アップデート/tac-p/132607#M251 2016年12月15日9:00(日本時間)以後に作成されたレポート/マルウェア検体/PCAPファイルについては、現状のWildFireクラウドのFQDN (jp.wildfire.paloaltonetworks.com) のWildFireポータルからの取得が行えます。 ※上記はWildFireポータルのほか、WildFire API、PAN-OS、Trapsからも可能です。 ※現状のWildFireクラウド (jp.wildfire.paloaltonetworks.com) のデータ保存期間については,以下のKBに添付 されておりますドキュメントをご参照ください。 https://live.paloaltonetworks.com/t5/Threat-Articles/WildFire-Japan-FAQ-日本語版/ta-p/54621 旧ドメイン(wildfire.paloaltonetworks.jp)に接続されているFirewallについては、 お客様の作業にて、新ドメイン (jp.wildfire.paloaltonetworks.com) をWildFireの設定情報として 変更する必要があります。実施いただかない場合、FirewallによるWildFireクラウドへの未知の検体の転送処理/ならびに防御が正常に実施されません。 上記の構成変更を実施していない場合、Firewallでtest wildfire registrationを実施した場合、失敗し、 wildfire registration:の結果がfailedとなります。 以下がtest wildfire registrationコマンドが失敗した際のサンプル出力となります。   >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> admin@PA-200> test wildfire registration This test may take a few minutes to finish. Do you want to continue? (y or n) Test wildfire Public Cloud Testing cloud server jp.wildfire.paloaltonetworks.com ... wildfire registration: failed >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 参考資料: PAN-OSにおけるWildFire クラウドのドメイン変更方法は以下のURLもしくは、WildFire 管理者ガイドをご参照ください。 https://www.paloaltonetworks.com/documentation/70/pan-os/pan-os/getting-started/enable-wildfire   WildFire 管理者ガイド: https://www.paloaltonetworks.jp/content/dam/paloaltonetworks-com/ja_JP/Assets/PDFs/technical-documentation/wildfire-70/WildFire_Administrator_Guide-7.0-Japanese.pdf ... View more

※この記事は以下の記事の日本語訳です。 Firewall unable to respond 'reset' to malicious content and HTTP response https://live.paloaltonetworks.com/t5/Management-Articles/Firewall-unable-to-respond-reset-to-malicious-content-and-HTTP/ta-p/98405   症状 Antivirus Profile Actionにreset-bothを適切に構成していても、脅威の存在するコンテンツとHTTPレスポンス コードがひとつのパケットで送信された場合では、FirewallがRSTで応答しないケースがあります。   この動作については制限事項となり、本ナレッジベースではその詳細を説明しております。本制限事項は、eicar test file (eicar_com.zip)を、Eicarのサイト(http://www.eicar.org/)からダウンロードする試験をした場合、発生することがあります。 その際、以下の点が確認できます。   ブラウザからeicar test file (eicar_com.zip)を、Eicarのサイト(http://www.eicar.org/)よりダウンロードした場合、Firewall は "Virus/Spyware Download Blocked" ページをブラウザに応答します。 "Virus/Spyware Download Blocked" ページが応答に使用されているにも関わらず、構成されたアクション(今回の場合は、reset-both) がThreat logのイベントにおいて、トリガされたアクションとして記録されます。 対して、お客様がeicar test file (eicar_com.zip) を、お客様社内のWebサーバ上に置き、Firewallを経由して eicar test file (eicar_com.zip)をダウンロードする試験をした場合、以下の点が確認できます。   "reset-both" が期待通り応答に利用され、FirewallからブラウザにRST が送信される。 構成されたアクション(今回の場合 reset-both)が期待通り、Threat logのイベントにおいてトリガされたアクションとして記録されます。   ケース 1 ケース1では、本制約がどのように症状に関わってくるのかを説明しております。 例として、ブラウザからeicar test file (eicar_com.zip)を、Eicarのサイト(http://www.eicar.org/)よりダウンロードした場合にやり取りされるHTTP通信を使用します。この通信では、EicarのサイトのIPアドレスを188.40.238.250、ブラウザのIPアドレスを1.1.1.4とします。   以下のスクリーンショットは、 eicar test file (eicar_com.zip)をEicarのサイト(http://www.eicar.org/)よりダウンロードした場合にやり取りされるHTTP通信のパケットキャプチャとなります。 ブラウザとEicarのサイト間で実施されているHTTP通信において、以下の内容が順番に発生していることが上記のスクリーンショットから判ります。   ブラウザが、No 809 のパケットで "GET /download/eicar_com.zip HTTP/1.1"を送信しています。 Eicarのサイトが、No 812のパケットで EicarのTestvirusのパターンとHTTPレスポンスコード200を一つのパケットとして送信しています。 Firewallが、No 813のパケットで "HTTP/1.1 503 Service Unavailable" を"Download of the virus/spyware has been blocked in accordance with company policy. Please contact your system administrator if you believe this is in error"とともにブラウザに対し送信しています。(RSTが送信されていない。) 以下のスクリーンショットは、ケース1の通信により発生したイベントがThreat Logに記録された内容となります。 Firewallが"HTTP/1.1 503 Service Unavailable"をブラウザに送信しているにも関わらず、reset-both がThreat logのイベントにおいて、トリガされたアクションとして記録されています。 ケース 2 ケース2では、FirewallがEicarのTestVirusに対し、 構成されたアクションのとおりRST を送信している動作を説明しております。例として、ブラウザからeicar test file (eicar_com.zip)を、お客様の社内サイトよりダウンロードした場合にやり取りされるHTTP通信を使用します。この通信では、お客様の社内サイトのIPアドレスを10.128.128.218、ブラウザのIPアドレスを1.1.1.4とします。   以下のスクリーンショットは、 eicar test file (eicar_com.zip)をお客様の社内サイトよりダウンロードした場合にやり取りされるHTTP通信のパケットキャプチャとなります。  お客様の社内サイトよりダウンロードした場合に、お客様の社内サイトがEicarのTestvirusのパターンとHTTPレスポンスコード200を2つのパケットに分割して、No 2004 とNo 2005のパケットで送信している点に留意してください。上のスクリーンショットで赤く囲われた箇所が、パケットの分割が実施されている様子を示す内容です。   ブラウザとお客様の社内サイト間で実施されているHTTP/TCP通信において、以下の内容が順番に発生していることが上記のスクリーンショットから判ります。   ブラウザが、No 2002のパケットで、"GET /download/eicar_com.zip HTTP/1.1"を送信しています。 お客様の社内サイトが、No 2004とNo 2005のパケットにおいて、EicarのTestvirusのパターンとHTTPレスポンスコード200を2つのパケットに分割して送信しています。 次に、No 2010のパケットで、FirewallがRSTをブラウザに送信しています。("HTTP/1.1 503 Service Unavailable"ではなく) さらに以下のスクリーンキャプチャでは、 No 2002とNo 2010 のパケットが同じTCPストリームで扱われていることが判ります。 以下のスクリーンショットでは、No 2004とNo 2005のパケットにおいて、2つに分割されたEicarのTestvirusのパターンとHTTPレスポンスコード200をお客様の社内サイトから受信した後に、FirewallがRSTをブラウザに送信している様子が判ります。   以下のスクリーンショットは、ケース2の通信により発生したイベントがThreat Logに記録された内容となります。 FirewallがRSTを送信し、reset-bothが期待通り、Threat logのイベントにおいて、トリガされたアクションとして記録されています。   著者: kkawachi ... View more