FortiGateにおいて、ファイルサイズによって精査がかからなくなる仕様がありますが、
PaloAltoにおいても精査がかからなくなる仕様を見つけました。
すこしわかりにくい部分があったため、説明や計測値を添えて情報を展開したいと思います。
目次
概要
PaloAltoのGUIより、DEVICE > Setup > Content-IDにおいて、下記の設定項目があります。
- Forward Segments Exceeding TCP Content Inspection Queue
- Forward Datagrams Exceeding UDP Content Inspection Queue
- Allow HTTP partial response
後述しますが、ネットワークのパフォーマンスにも影響するため、導入時などに考慮しておかないと、のちのち設定を変更することは難しくなる設定です。
各項目の内容について
メーカのドキュメントはこちらになります。
ドキュメントのみでは直感的にわかりにくい部分や情報を補完する解説を含めたいと思います。
Forward Segments Exceeding TCP/UDP Content Inspection Queue
当項目のデフォルト値は有効になっていますが、メーカは無効化を推奨しています。
有効化している場合、TCP/UDPのコンテンツ検査キューがいっぱいになると
コンテンツ検査をスキップして、通信を転送します。
スキップした場合、ctd_exceed_queue_limitカウンタが増加します。
無効化している場合、TCP/UDPのコンテンツ検査キューがいっぱいになると
そのセグメントをドロップします。
TCPの場合にはTCP Retransmission(再送処理)により、パケットが再び送信されます。
ドロップした場合、ctd_exceed_queue_limit_dropカウンタが増加します。
いずれのカウンタが増加している場合、下記のCLIコマンドを実行すると、
当該のカウンタが表示されます。※
show counter global filter packet-filter yes delta yes
※参考：WildFire Upload Cancelled by DP
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Cme4CAC
コンテンツ検査キューの上限は、TCP/UDPいずれも、1セッション※あたり、最大64セグメントとなっています。
※CLIより当該オプションを表示すると1セッションあたりとの記載があります。
1パケットのサイズが1500Byteである場合、TCPセグメントサイズは1460Byteになるため、最大91.25KBまでキューに入る計算になります。
では、91.25KBよりも大きなデータを転送したらかならず検査がかからないのか、というとそうではありません。データ転送側がデータを1パケットずつに分割して送信するため、一挙にデータがPaloAltoに到達するわけではありませんし、PaloAltoもコンテンツ検査キューに入り次第精査がかけていくため、64セグメントを埋め尽くすには、かなり大きなデータを転送する必要があります。
弊社の検証機（PA-220）及びLAN環境では、6～7Mbyteのファイル転送をすると、コンテンツ検査キューがいっぱいになるようでした。※
※データの転送速度、PaloAltoのトラフィック処理性能に依存するため、あくまで目安となります。
データのサイズに関わらず、脅威と判定されるデータが最大セグメントに到達する前のパケットに含まれる場合には、コンテンツ検査キューとして精査がかかるため、ブロックすることができます。遮断されるかどうかは精査対象のリソースのどこに悪意あるデータが存在するのかにも依存します。
Allow HTTP partial response
当項目はPaloAltoがPartial Responseを許可/拒否するかの設定であり、
デフォルト値は有効になっています。
HTTP範囲(Range)リクエストについて
始めにHTTPのHTTP範囲(Range)リクエストについて説明をします。
HTTPでは、通常はリソース取得対象データの全体を取得しますが、ユーザエージェント（クライアント）がRangeヘッダを用いることで、リソースに対し、「リソース内のどの部分が欲しい」と要求することができます。
これをHTTP範囲(Range)リクエストと言います。
サーバがHTTP範囲リクエストに対応していれば、ステータスコード206と併せて、範囲リクエストの応答に必要な、いくつかの情報とリソースを返します。
ここで、悪意のあるファイルを2つに分割して取得し、最終的にそれらを連結させた場合を考えます。
PaloAltoではシグネチャベースの精査をするため、分割されて、それぞれ別のセッションによるダウンロードが行われる場合、検知することができません。
そのため、HTTP範囲リクエストを許可すると、悪意のあるファイルを取得できてしまうリスクが高まるということです。
では、この項目が有効な場合（HTTP範囲リクエストの許可）に高いリスクがあるのかというとそうではなく、本項の最初に記載の通り、ダウンロードを行ったユーザ上のリソースを操作し、分割してダウンロードしたファイルを連結させる必要があることから、上記の仕組みを悪用するのは通常は困難と思われます。
それに対して、PaloAlto Networks社は、Webブラウザでのファイルダウンロードにおいて、ダウンロード中断後に再開を行ったときにHTTP範囲リクエストが行われた場合に、最終的に二つのファイルを結合する場合、悪用される恐れがあると記述しています。
※How Does Palo Alto Networks handle HTTP range extension?
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000PLjPCAW
PaloAlto TECHDOCS
https://docs.paloaltonetworks.com/pan-os/11-2/pan-os-web-interface-help/device/device-setup-content-id
Webブラウザでのファイルダウンロードにおいて、事象が本当に再現するのか確認
Linux版のGoogle Chromeを用いてダウンロード再開時の挙動を確認してみたところ、事象が再現しました。
（環境上の制約でLinuxを利用しており、Windowsにおいても同じ挙動をすると考えられます。）
Eicarファイルと他のファイルを圧縮したファイルを用意します。(comp-1M-eicar.tar.gz)
当該ファイルのダウンロード進行中に、eicarが検出されると、下記のような「Check internet connection」という表示が発生します。
PaloAltoのログを確認すると、reset-bothによってクライアントとサーバへRSTパケットが送られていることがわかります。
パケットキャプチャの取得結果
ファイルのダウンロードが止まってしまったため、「Resume (再開)」をクリックします。
Partial Contentがサーバから応答されていることが確認できます。
ダウンロードが完了したため、ダウンロードフォルダをチェックすると、対象のファイルが取得されています。
解凍を行うと、eicarファイルが存在していることも確認できました。
PaloAltoのログは最終的に以下のように出力されました。
設定値についての考察
- Forward Segments Exceeding TCP Content Inspection Queue
TCPの再送処理が行われること、1セッションでコンテンツ検査キューがいっぱいになるほどのリクエストは多くないことを考慮すると、無効化として導入しても顕著な障害は起きないと思われます。
本項目を有効化(Default値)したときと無効化したときにダウンロード完了にどれくらい時間がかかるのかを比較してみました。
| ファイルサイズ | ダウンロード完了時間(秒) |
|---|---|
| 10KB | 0.014769 |
| 1MB | 0.104753 |
| 10MB | 0.270038 |
| 100MB | 1.570933 |
| 1GB | 10.128634 |
| ファイルサイズ | ダウンロード完了時間(秒) |
|---|---|
| 10KB | 0.015125 |
| 1MB | 0.114325 |
| 10MB | 1.002401 |
| 100MB | 13.643584 |
| 1GB | 121.426358 |
1MBから10MBあたりから徐々にデータ転送時間に差がうまれています。
環境によってはこれを許容できない可能性があります。
環境との相談にはなりますが、大容量ファイルを頻繁にやり取りしないのであれば、
無効化することを検討してもよいかと思います。
- Forward Datagrams Exceeding UDP Content Inspection Queue
UDPについては、UDPのプロトコル自身には再送の処理が無いため、
データグラムがドロップされることによる影響が発生します。
例えば、VoIP通話やライブストリーミングなど、リアルタイム性の高い通信では、
データロスが直接的に音声・映像の途切れや品質低下につながります。
DNSやQUICなどでは、アプリケーション側で再送やリトライが実装されているため、影響を受けにくいことも想定されますが、すべてのUDPアプリケーションにおいて再送処理が実装されているものではないため、環境に応じて検討する必要があります。
- Allow HTTP partial response
Webブラウザでのファイルダウンロード再開時のセキュリティリスクはあるものの、Partial ResponseはYoutubeなどのメディア配信で利用されており、PaloAltoによってPartial Responseの転送を無効化することは難しいと思われます。
PaloAlto社もドキュメントに記載している通り、無効化する際には業務利用のアプリケーションに影響がないか入念に確認する必要があります。
また、対策を考えると、社内ユーザにネットワークエラーが発生した場合、むやみに再開をせずに、改めてダウンロードするように周知をするほか、アンチウィルスのログが発生したら当該のユーザにヒアリングをするという対応になるかと思います。
ただ、GatewayのPaloAltoにおいて、エンドポイント保護を保障することは難しいため、Partial Contentをどうするかに頭を悩ませるよりもEDR/EPPを導入して担保をするほうが、費用対効果が見込めるかと思います。
まとめ
私が調べた結論として、本記事で紹介した項目は、PaloAltoにおいてはデフォルト値を採用し、エンドポイントの悪意あるファイルの検知はEDR/EPP、IPSによってWebアプリケーションを保護している場合には、WAFを導入するような方針にするべきだと思いました。
ただ、UTMを入れることの意味がないのかというと、そういうわけでもないと思います。
今回は小さなサイズの筐体と、通信が即時に到達するLAN環境にて検証をしているため、かなり尖った検証結果になっている可能性があります。
この仕様による攻撃通信のすり抜けを問題視するならば、定期的にPaloAlto上でcliを叩ける仕組みを使って、通信量と時間帯で検査をすり抜けた通信を特定して、ユーザの端末上で異常がないかをチェックするような方法をとるしかないと思われます。
記載されている会社名、システム名、製品名は一般に各社の登録商標または商標です。
当社製品以外のサードパーティ製品の設定内容につきましては、弊社サポート対象外となります。
