VPNログは送る前に読む：項目ごとの確認

サポートチケットを開き、クライアントが生成した診断エクスポートを添付して待ちます。そのファイルには閲覧履歴がまったく含まれていないことが多く、だから安心に思えるのです。それでも、あなたが誰か、どのマシンを使ったか、どの内部アドレスにいつ到達したか、ときには設定を記録するクライアントがコピーした秘密鍵まで含まれています。送る前にファイルを一通り見るのに約五分かかり、それが恒久的な開示を防ぎます。

開いて最初の四十行を読む

まずは先頭から、クライアントが通常バージョン、プラットフォーム、設定を吐き出す場所から見ます。最初の数行でファイルの詳細度がわかり、残りのどこまで気にするべきかが決まります。既定のログとデバッグログは露出の異なる別物です。

head -n 40 vpn-support.log
sed -n '1,40p' vpn-support.log | grep -nE 'version|platform|config|option'

何かを読む前に、ファイルの大きさと形も確認します。同じ出来事が繰り返される二メガバイトのテキストファイルは簡単に切り詰められます。同じフォルダにあるバイナリ取得はまったく別の問題で、エクスポートを求めた相手と別の会話が必要です。

Windowsでは相当するものがそれぞれ一つのcmdletで、最初のものは自分で作っていないファイルに対して実行する価値があります：

Get-Content .\vpn-support.txt -TotalCount 40
Get-Item .\vpn-support.txt | Select-Object Length,LastWriteTime

個人を特定する項目

ユーザー名は、認証に使うアカウント、証明書のサブジェクト、ホームディレクトリ配下のプロファイルパス、実名を符号化していることの多いマシン名など、人が予想しない場所に現れます。アカウント項目だけを編集してホームパスをそのままにしたログは、何も編集していません。

サポート担当者が一つのセッションをファイル全体で追う必要があるとき、完全性より一貫性が重要です。値を削除するのではなく安定したラベルに置き換えて、同じユーザーの出現がどれも同じユーザーとして読めるようにします。項目を丸ごと削除すると担当者に必要な糸が切れ、ファイルが安全になるわけでもありません。

タイムスタンプも全体としては個人データです。あるアカウントが接続した時刻を一か月分集めると、勤務時間や移動を描き出します。質問が全期間を必要としないなら、ファイルを出来事の周辺の期間に切り詰めます。

ネットワークを特定する項目

エンドポイントアドレス、内部ルート、プッシュされるオプションは、プライベートネットワークの形を描き出します。それは攻撃者がぜひ欲しがる情報であり、通常はチケットが必要とするよりはるかに詳しく含まれています。

使われているアドレスファミリーを、期待したものだけでなく探します。デュアルスタックのクライアントはIPv6エンドポイントと、レビューが点付き四つ組だけを探したために誰も編集しようと思わなかったIPv6ルートの集合を記録することがあります。

grep -nEo '([0-9]{1,3}\.){3}[0-9]{1,3}' vpn-support.log | sort -u | head -n 40
grep -nEo '([0-9a-fA-F]{0,4}:){2,7}[0-9a-fA-F]{0,4}' vpn-support.log | sort -u | head -n 20

一意の一覧が要点です。ファイルがいくつの異なるアドレスに言及しているかがわかり、それはスクロールしているときの印象よりずっと少ないのが普通です。編集のためのチェックリストと、すべてを網羅したことを示す手段も与えてくれます。十個のアドレスなら五分の作業で、百個ならエクスポートが質問より広いとわかります。

担当者が必要とするならトポロジーは残します。サブネットの関係を保ったまま第二と第三オクテットを置き換えれば、範囲を公開せずに質問に答えます。同じ技はIPv6プレフィックスにも使えます。担当者が必要とするのは障害の形であり、その形は一貫した置換のあとも残ります。

秘密はラベルではなく形に隠れる

秘密鍵の近くに「password」という語は必要ありません。区切り行に挟まれたブロック、長いbase64文字列、あるいはインラインの設定ダンプとして現れます。トークンはクエリパラメータとして、資格情報はクライアントがそのまま記録したURLの中に現れます。

grep -nE 'BEGIN [A-Z ]*PRIVATE KEY|password|passwd|token|secret|psk|auth-user-pass' vpn-support.log
grep -nE 'https?://[^ ]*:[^ ]*@' vpn-support.log

二つ目のパターンは人が忘れるものです。スキーム、ユーザー、パスワード、ホストという形のURLは完全な資格情報であり、クライアントはプロキシやフィードがインライン認証で設定されるたびにそのようなURLを記録します。

編集していないことを証明するために元のファイルを送ってはいけません。運用担当者が未変更のエクスポートを求めるなら、何に使うのかを尋ね、その検証済みのサポート経路で送り、その後で手元のコピーを削除します。その要求は正当ですが、公開の貼り付けはそうではありません。

編集済みのコピーを作り、抜粋を送る

コピーで作業し、原本は保護された場所に置き、手作業ではなく繰り返せるコマンドで編集します。アドレスのパターンに一度通せば大半を捕まえられます：

cp vpn-support.log vpn-support.original.log
sed -E 's/([0-9]{1,3}\.){3}[0-9]{1,3}/ADDR/g; s/[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+/USER@DOMAIN/g' \
  vpn-support.original.log > vpn-support.redacted.log
grep -cE 'PRIVATE KEY|password|token' vpn-support.redacted.log

最終的な件数はゼロであるべきです。そうでなければ編集の処理が形を見落としており、何かを送る前にその行を見るべきです。編集後のファイルは、スクリプトがパターンを捕まえても文脈は捕まえないので、自分の目でも一度読みます。

障害がまだ見える最小の抜粋を送ります。エラーの前後十行でたいてい足り、二メガバイトのファイルよりずっと確認しやすいものです。その後、ラベルと実際の値の対応は、次の質問で必要になるので、自分が管理する場所に保管します。

OpenVPNのログ記録のドキュメントは、詳細度が何を記録するかをどう変えるかを説明しており、問題がファイルのどれだけを本当に必要とするかを決めるのに役立つ文脈です。