VPN ゲートウェイにおける Fail2ban：何を直し、何を直さないか

公開されたサービスはどれも同じ助言を受ける。fail2ban を入れろ、と。VPN ゲートウェイにとってその助言は間違いでも十分でもなく、ハードニングのチェック項目として扱うことが、何も役に立たない jail を残す原因になる。fail2ban は指定した失敗記録を読み、一致する送信元を BAN するよう enforcement バックエンドに要求する。その価値はすべて、どの認証面が記録を生んだか、記録内のアドレスが本当のクライアントか、そのアドレスの背後にいる全員がどうなるかにかかっている。

fail2ban の仕組み

フィルターがログの行を照合し、jail が送信元ごとに一致を数え、アクションがファイアウォールのバックエンド経由で BAN を適用する。可動部は三つあり、どれも独立して間違えうる。

三つのどれも認証経路には触れない。fail2ban は事後に証拠へ反応するだけで、自ら資格情報を検証することはない。したがって jail が正常に動いていても、名指しした面は以前とまったく同じだけ露出したままになる。

トンネルのリスナーはログインフォームではない

OpenVPNリスナーがtls-authまたはtls-cryptで保護されていれば、通常の TLS 処理が始まる前に制御チャネルの保護を持たないパケットを破棄する。鍵を一度も持たないスキャナーは、フィルターが数えられるものを何も生まない。証明書認証は推測できるパスワードがないため、もう一つの関門を加える。Fail2ban プロジェクトは一般的なログ駆動モデルを文書化しているが、汎用の VPN フィルターが未認証パケットを意味のある失敗イベントに変えるわけではない。

ゲートウェイが証明書だけを受け入れるなら、あなたが防いでいるブルートフォースの話は、そのポートにはそもそも存在しないかもしれない。

では、どの面を守っているのか。

同じホストが三つの異なるものを公開していることが多い。トンネルのリスナー、クライアントプロファイルやセルフサービスのポータル、そして管理ページだ。ポータルと管理ページにはパスワードフォームがあり、フィルターが数えられるログ行を生む。トンネルはまったく別の意味を持つハンドシェイクエラーだけを生むかもしれない。jail は製品名ではなく面に合わせる。

間違ったログを見張る jail は、何もないより悪い。覆いのない安心感を生むからだ。ログインフィルターをトンネルのハンドシェイクエラーに向ければ、鍵を一度も持たなかったスキャナーでカウンターが動き、ポータルへのパスワード攻撃は数えられない。jail の数字を信じる前に、フィルターが照合するログ行を読む。

送信元の帰属が弱い環だ

BAN は狙ったアドレス以上には良くならない。サービスがローカルのリバースプロキシの後ろにあると、ログ内のクライアントアドレスはプロキシかもしれず、それを BAN すると全員が消える。信頼できない送信元からの転送ヘッダーを信じれば、攻撃者に任意のアドレスを BAN する能力を与える。UDP では送信元アドレスを偽装できるため、完了した TCP ログインを数える以上に慎重であるべきだ。

送信元の帰属方法を jail の README に記録する。信頼できないホップからの転送ヘッダーは BAN を武器に変える。

巻き添えの代償は他の人々だ

一つのオフィス NAT の背後にいる複数の従業員が同じアドレスを共有するため、古い保存パスワードが一つあるだけで、しきい値を超えた瞬間にオフィス全体が締め出される。ログが示すのは失敗した一つの送信元と一つのアカウントであって、拠点全体の障害ではない。

短い BAN と控えめなしきい値がそれを減らし、文書化された解除手順が、それでも起きたときのサポート負荷を下げる。アドレスは身元ではなく粗い信号であり、チケットを開く人はしきい値ではなく障害を説明する。

いつ導入し、いつ別のものを直すか

自分が管理する面で、実際に帰属でき、繰り返すオンラインログインの失敗があり、enforcement バックエンドがその面を実際に覆っているときに導入する。問題が弱い資格情報ポリシー、インターネットに露出した管理ページ、侵害されたために正常にログインしてしまうアカウントなら、別のものを直す。BAN はそのどれも修復できず、すでに上流回線を飽和させたトラフィックを吸収することもできない。最後の問題は上流、パケットがあなたに届く前にフィルタできる誰かのものだ。

すべての jail を一つの面に結び付け、誤検知を見直し、BAN したアドレスの数ではなく回避できた認証作業を測る。