Firewallが悪意のあるコンテンツを含むHTTPレスポンスに対しresetで応答しない

Printer Friendly Page

※この記事は以下の記事の日本語訳です。
Firewall unable to respond 'reset' to malicious content and HTTP response
https://live.paloaltonetworks.com/t5/Management-Articles/Firewall-unable-to-respond-reset-to-malicio...

 

症状

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通信のパケットキャプチャとなります。

packetforeicar.PNG

ブラウザと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に記録された内容となります。

threatlogeicar.PNG

  • 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通信のパケットキャプチャとなります。

packetforprivate.PNG

 お客様の社内サイトよりダウンロードした場合に、お客様の社内サイトが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をブラウザに送信している様子が判ります。

resetsentfromfw.PNG

 

以下のスクリーンショットは、ケース2の通信により発生したイベントがThreat Logに記録された内容となります。

threatloggeneratedbyreset.PNG

  • FirewallがRSTを送信し、reset-bothが期待通り、Threat logのイベントにおいて、トリガされたアクションとして記録されています。

 

著者: kkawachi