その脆弱性の検出結果はどの VPN プロセスに当たるのか

スキャナの結果が示すのは、アドレス、ポート、そしてそこで折衝された何かです。そのソケットの背後にあるプロセスは示しません。VPN ホストでは複数のプロセスが同じマシンを共有でき、そのうちトンネルは一つだけです。補助ツールからバージョン文字列を読んだり、ディスク上のライブラリファイルを見つけたりしても、ホストについての証拠が増えるだけで、リスナーについての証拠にはならず、検出結果は、実行中の一つのコンポーネントに結び付けられ、その後でアドバイザリが実際に示す範囲と照合されて初めて、対応可能になります。

順序が重要で、まずコンポーネント、次にアドバイザリ、最後に修復です。

レポートが示すのはポートであり、プログラムではない

実際に評価されたエンドポイントから始めます。HTTPS 管理ポートへの検査は、Web サービス、その TLS スタック、そしてその前にあるプロキシを測っただけで、別のポートで待ち受ける OpenVPN や WireGuard については何も分かっていません。リバースプロキシや管理エージェントは、証明書とバナーがフロントエンドのものでも脆弱なライブラリがその背後のバックエンドプロセスにあるため、さらに悪化させます。

宛先、トランスポート、ポート、サービス名を結果と一緒に記録し、範囲が検出結果とともに移動するようにします。

実行中のビルドとは実際に何か

汎用ホストでは、インストール済みパッケージと読み込まれたライブラリは別の問いです。パッケージデータベースが修正済みバージョンを示していても、長時間稼働するデーモンが古い共有オブジェクトをメモリに保持していることがあり、同梱のアプライアンスイメージはどのパッケージマネージャも報告しない独自のライブラリを抱えることがあります。サービスマネージャに何が動いているかを尋ね、次にプロセスとそのリンクを調べます。

systemctl status openvpn-server@server --no-pager
ps -o pid,lstart,args -C openvpn
ss -lntup | grep -E '1194|443'
dpkg -l | grep -i -E 'openvpn|libssl'
ldd "$(command -v openvpn)" | grep -i ssl

プロセス一覧の開始時刻は、人が飛ばしがちな細部です。最後のパッケージ更新より前に起動したデーモンは起動時に読み込んだビルドをいまだに実行しており、台帳が修正済みと言いソケットがそうでないと言うのはまさにこの場合です。

ビルドをアドバイザリの範囲に合わせる

アドバイザリは製品、バージョン、ときに必要な条件を記述し、その三つの項目はパッケージのバージョンと常に一致するわけではありません。OpenVPN の 2014 年四月の Heartbleed アドバイザリは、影響を受ける Access Server のリリースを、露出が異なっていた Web サービスや VPN デーモンから切り分けているため、有用な歴史的事例です。教訓は、OpenSSL という語をパターン照合するのではなく、文面がどのコンポーネントを対象にしているかを読むことです。

そのアドバイザリも古くなっています。修正済みリリース番号は今やインストールの助言ではなく、2014 年に修正された欠陥は、今日運用しているブランチの後発の問題について何も語りません。

不一致を解消し、その後で露出を閉じる

台帳と評価が食い違うときは、両者が同じエンドポイントと同じ実行環境を指しているか、つまり別のアドレス、フロントエンドのプロキシ、二つ目のサービス、ポートにまだ結び付いた古いプロセス、パッケージマネージャが見たことのない同梱ライブラリなどを確認します。レポートを書き直す前に、その境界で解決します。

サポートされた修正を適用し、影響を受けたサービスを再起動し、新しいビルドが今動いていることを確認します。ディスク上のファイルだけが修正され、古いプロセスがまだトラフィックを処理している状態は、修復ではありません。

次に、露出期間中にコンポーネントが保持し得たものに対処します。パッチ適用と資格情報の交換は別の問いに答えるものであり、影響を受けたホストの近くに保存された証明書は、それ自体が漏えい内容の一覧ではありません。失効、セッション削除、クライアント更新についてはインシデント所有者の手順に従い、どのコンポーネントが影響を受け、なぜ証拠が当てはまり、何がそれを閉じたのかを記録します。後日のレビューが読むのは、その記録です。