OpenConnect csd-wrapper：ログイン前にスクリプトを監査する

プロファイルに --csd-wrapper を追加すると、ローカルスクリプトがログイン時にそれを実行するデーモンに渡されるため、目の前の判断はコードレビューであり、設定の切り替えではありません。このオプションはゲートウェイのホストチェックコンポーネントを差し替えるために存在し、利用者が用意したスクリプトへのパスを受け取ります。以下はすべて、導入の担当者がどの姿勢チェックが必要かをすでに決めていることを前提とし、その部分がまだ未決なら先に決めてください。手順は四つです：失敗した段階を特定し、スクリプトを読み、実行される ID を選び、結果を証明します。

ステップ 1：失敗した段階を特定する

クライアントの最後のメッセージは通常クッキーに関するもので、それは連鎖の終わりであって始まりではありません。HTTPS ログイン、サーバー証明書の確認、認証のやり取り、姿勢コンポーネントはすべてそのメッセージの手前にあります。

使用中のバージョンとログイン先アドレスを記録し、詳細出力を自分の端末に残したまま試行を繰り返します。再試行ではない最初のエラーを読み、記録の最終行は読みません。 ログが評価コンポーネントの名前を出す前に止まるなら、ラッパーはまだ問題ではありません。その時点で加えても、後で守るべき範囲が広がるだけです。

openconnect --version
openconnect --verbose --user="$VPN_USER" vpn.example.com </dev/null

クッキーと認証応答はアクセス用の素材なので、記録はローカルに保ちます。チャットに貼ったトレースは、評価手順が無害に見えても資格情報の漏えいになります。共有するのはエラーの文面と、フローのどこで出たかという点だけであり、ペイロードは決して共有しません。

ステップ 2：プロファイルに入る前にスクリプトを読む

ラッパーは自分が確認したリビジョンと同じだけしか信頼できないので、そのリビジョンを固定し、ハッシュを承認メモの隣に保存します。次の二つのコマンドは、一行も読む前に指紋と安価な構文チェックを与えてくれます。また次の担当者に固定の参照を与え、ファイルがパッケージ管理の外にあるときにはそれが重要です。どちらのコマンドもスクリプトが何をするかは教えないので、実行してから読み続けてください。

sha256sum ./vpn-csd-wrapper.sh
bash -n ./vpn-csd-wrapper.sh

ファイル全体を四つの問いを念頭に読んでください：外向きの HTTP 呼び出しをするか、資格情報ファイルや環境変数を読むか、一時ディレクトリの外に書くか、何も測定せずに合格の姿勢を報告する分岐があるか。最後のパターンは、ログ行を添えたポリシー回避です。コピーされたラッパーは、もっともらしく見えるチェックの裏にそれを紛れ込ませがちです。スクリプトがデバイスを見る前にデバイスは問題ないと判断するなら、そこで止めてください。

読めるヘッダーはファイルの残りについて何も証明しないため、詰め込まれたペイロードも確認します。フォーラムのスレッドからスクリプトをダウンロードしても、名前が実在のホストチェックコンポーネントに似ているからといって信頼できるわけではありません。誰が導入したか、どこから来たか、どう更新されるかを記録します。

grep -nE 'base64 -d|xxd -r|eval |curl |wget ' ./vpn-csd-wrapper.sh

ステップ 3：ラッパーが実行される ID を選ぶ

--csd-user は CSD、TNCC、HIP のプログラムが実行される間、権限を下げます。そのアカウントはローカルの実行の取り決めの一部であり、ゲートウェイに提出するユーザー名ではありません。

ラッパーには、対話シェルも sudo 権限も不要なグループ所属も持たない専用アカウントを与えます。スクリプトとそれが検査する特定のファイルに読み取り権限を与え、VPN プロファイルに触れる前に権限降下を試します。ここで問題を見つけるほうが、クライアントの中で見つけるより安く済みます。

sudo -u vpn-csd /usr/local/libexec/vpn-csd-wrapper.sh

権限を下げれば、不出来なスクリプトが与えられる損害は限られます。ただしコードをレビューするわけでも、報告を正直にするわけでも、ゲートウェイ管理者がこの実装をデバイスポリシー遵守として受け入れることを示すわけでもありません。

ステップ 4：変更を元に戻せるようにする

編集する前にプロファイルをバックアップし、ラッパーをバージョン管理下に置くので、ロールバックはコピーを探すのではなく既知のハッシュを復元します。スクリプトのパス、ハッシュ、実行ユーザー、承認者を一か所に書き留めます。

元に戻すには、オプションを外し、クライアントを再起動し、元のエラーが戻ることを確認します。ロールバック後もゲートウェイがログインを拒否するなら、何か別のものも変わっているので、その差分を見つけるのがラッパーを再試行するより先です。変更ウィンドウの間は以前のコピーを保持しますが、多くのチームではそれは次のメンテナンス枠が過ぎるまでを意味します。

配備が成功したら、トンネルが上がることと、姿勢チェックに失敗すべきデバイスが依然として拒否されることの二つを確認します。全員につながることは、評価が変更を生き延びた証拠にはなりません。

二つ目の問題を生む近道

必要なチェックを実行せずにヘルパーに準拠状態を報告させてはいけませんし、別のオペレーティングシステムに合わせてプラットフォーム ID を上書きしてはいけません。別のプラットフォームだと主張しても、実際のデバイスがポリシーを満たす証拠にはなりません。そうすると、今後のすべてのログインで嘘をつくクライアントが残ります。

サーバー検証を無効にし、古いクッキーを再生し、未レビューのスクリプトを積み重ねることは、いずれも見える失敗を見えない失敗に置き換えます。導入済みのクライアントがサポートされるフローを完了できないなら、手元のものを曲げるのではなく、承認済みの代替を求めてください。

OpenConnect のマニュアル --csd-wrapper と --csd-user を別々に記述しており、これが重要なヒントです。スクリプトと ID は二つの判断なので、別々にレビューして両方を書き留めてください。そうすれば、ログインのプロンプトはコードを貼り付けて解く謎ではなくなります。