【Zscaler】Zscaler Private AccesのLog Streaming Service機能を利用する際のログロストの可能性

ZscalerにてLog Streaming Service（以下、LSS）機能を利用する際に、ログロストが発生する可能性がある問題に対応する機会がありました。

そのため、今回はZscalerの当該機能とその問題について書きたいと思います。

発生の可能性がある条件例を簡単に書きますと、以下となります。

厳密にはタイムアウト等ではなく一定条件下でパケットが破棄されてしまう場合なのですが、わかりやすい条件例として上記を挙げさせていただきました。

ログロストの可能性について解説する前に、ZPAについて簡単に説明します。

ZPAとは、これまで社外環境から社内リソースへアクセスするために利用されていたVPN接続に代わる、Zscalerが提供する新たなアクセス方法のサービスです。

これまでVPN接続では、社外環境の端末から社内リソースへの入り口となるVPN装置にVPN接続を行うことで、通信途中経路のセキュリティを担保していました。

ですが、VPN装置へのアクセスできるということは、そのIPアドレスは外部からの通信を受け付けるということになります。これにより、攻撃を行いたい者に対してもそのIPアドレスが見えてしまうという、という問題がありました。

そこでZPAでは、Zscaler Client Connector（以下、ZCC）というソフトウェアを社外環境の端末側、App Connectorというソフトウェアを社内リソース側にそれぞれ配置し、それらがZPAクラウドへと接続する構成としました。

これにより、通信方向はどちらも内部から外部方向だけを許可すればよく、攻撃を行いたい者からはIPアドレスが見えなくなりました。

この構成を使い社外環境から社内リソースへアクセスすることになりますが、このサービス通信のログをsyslogサーバへ送付するための機能がLSS機能です。

続けて、LSS機能とログロストが発生する可能性について説明していきます。

LSS機能はZPAクラウドからApp Connectorがログ情報を受け取り、それをsyslogとしてsyslogサーバへ送付する機能です。

送信元はApp Connector、宛先はsyslogサーバ、プロトコルはTCPを利用し、ポート番号は指定可能です。

また、ログ再送機能が標準で用意されており、syslogサーバ側から応答が返ってこない場合でも同一のセッション情報を利用して15分間通信を試みます。

ログロストが発生する仕組みですが、上記の"同一のセッション情報を利用"が問題を発生させる要因の1つとなります。

ログロストが発生する条件は、冒頭に記述した条件例のようにsyslog通信の経路上にセッション情報を保持する機器があり、ZPA通信が一旦終了後にその機器のタイムアウト時間経過に通信が再開される状況になること、などです。

条件例の状況となった場合、syslog通信はセッション情報を保持する機器にてタイムアウト通信として処理されますが、その処理内容は一般的には単純にパケット破棄されるだけであり送信元にTCPエラーを返すことはありません。

そして、App Connectorは同一のセッション情報を利用して15分間通信を試みた後にその15分間分のログは破棄し、再度セッションの張り直してログ送付を再開します。

以上の流れから、条件が揃った場合に15分間分のログロストが発生します。

発生条件やLSS機能について少し補足があります。

条件の2番目でタイムアウト値を24時間未満としていますが、これは、LSS機能のログ送付に利用されるsyslog通信は24時間経過後にもセッションの張り直しが実施されるためです。

このため、条件として"24時間未満"と表記しましたが、24時間近いタイムアウト値であれば、通信終了からタイムアウト時間経過後に再開するという条件も考えれば、まず発生しないと思われます。

ここからは私見にもなりますが、このログロスト可能性の問題における1番の問題点なのですが、発生したことを検知することが実際には難しいという点にあると考えています。

LSS機能はZPAポータルにて設定する機能となりますが、"15分間再送に失敗したためその間のログを破棄してsyslogセッションを張り直した"ということを通知する機能は、ZPAクラウドにもApp Connectorにも用意されていません。

syslogサーバ側から見てもsyslog通信が届いていないだけなので、サービス通信がないからログが送付されてこないのか、途中経路でパケット破棄されているからログが送付されてこないのかを判別することはできません。

この問題が発生することに気づくことができたのは、たまたまとある対応中に正副のsyslogサーバでログ内容に差異があることが見つかったためです。

通常、特にメッセージ送信もアラーム通知もされていない状況ではsyslog通信の正常性を調べようとはしないでしょうし、ログ内容の比較という調査方法もしないと思われます。

ログロストの可能性への回避策ですが、例として出した構成ではFWによってタイムアウトしているセッションのパケット破棄が行われることで発生するため、syslogのkeepalive設定によってそのタイムアウトを避けることで問題に対応しました。

これは実際に私が対応した回避策の内容で、実施後にログロストが発生しなくなったことも確認できています。

同様に、このFWによるパケット破棄を理由とするものがログロストの発生ケースとして多いと思われますが、ネットワーク構成によっては原因がそうではないケースも考えられます。

その場合はそれぞれのケースにあわせて原因の特定と回避策の検討をすることになりますので、今回解説した発生条件と利用中のネットワーク構成とを考え、対応を行ってください。