RDP ブルートフォース攻撃の実際の姿

平たく言えば、これは何か

RDP ブルートフォース攻撃は、あなたを狙った作戦ではありません。それは量産品です。誰かがボットネットを借り、IP レンジの一覧を食わせ、ポート 3389 で応答するすべてのマシンにログインを試させる。パスワードの一覧は短く退屈です——Administrator に Password1、admin に admin、社名に今年の西暦。ボットはあなたのサーバーが何をしているか知りませんし、気にもしません。

これを絶え間ないものにしているのは経済です。1 回のログイン成功はランサムウェア用アクセス市場で実際の金額になり、1 回の試行のコストはほぼゼロ。だからボットは決して止まりません。新しい Windows Server を公開 IP に置いて RDP を開ければ、最初のログイン失敗はたいてい 1 時間以内に届き、1 週間後には 1 日あたり数千件で安定します。

重要なのはその量です。人間があなたのパスワードを推測するのは物語ですが、入れ替わるアドレスから月に 10 万回という試行は気象現象です。前者を前提にした防御は、後者にはまったく役に立ちません。

自分の身に起きているかを見分ける

Windows はログイン失敗をすべてセキュリティログのイベント ID 4625 として記録します。イベントビューアーを開き、「Windows ログ → セキュリティ」に移動して 4625 で絞り込んでください。静かなサーバーなら、パスワードを打ち間違えた利用者による数件が見えるだけです。攻撃を受けていれば、壁が見えます。

手がかりは件数そのものではなく、その形です。打ち間違えた利用者は、1 つのアドレスから、実在するアカウントに対して 2、3 回失敗し、そこで止まります。ボットは、あなたのマシンに存在したことのないアカウント名——admin、sql、backup、test、scanner、user1——に対して長い連続を生み、取引したこともないホスティング事業者のレンジから、一晩中一定のペースで届きます。

次のコマンドで、直近 24 時間の失敗が多い送信元アドレスが分かります：

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-1)} |
  ForEach-Object { ([xml]$_.ToXml()).Event.EventData.Data |
    Where-Object Name -eq 'IpAddress' | Select-Object -ExpandProperty '#text' } |
  Group-Object | Sort-Object Count -Descending | Select-Object -First 20 Count, Name

定番の助言が半分しか効かない理由

どの堅牢化チェックリストも「強いパスワードを使う」から始まります。正しいのですが、それだけでは足りません。強いパスワードとは、ボットが当てられないという意味です——しかしボットは永遠に試し続け、1 回ごとにスレッド 1 本、監査ログ 1 行、CPU のひとかけらを消費させます。攻撃を受け続けるサーバーは測定できるほど遅くなり、セキュリティログは速く回りすぎて、本当に必要だった 1 件が消えています。

次に来るのはたいてい「アカウントロックアウトポリシーを有効にする」です。これには注意が必要です。ロックアウトはアカウント単位で失敗を数え、ボットは一覧からアカウント名を推測します。Administrator を 5 回の失敗でロックする設定にすれば、パスワードを当てる見込みなど皆無だった攻撃者が、そのアカウントをどこからでも好きなときに、永久に無効化できるようになります。迷惑行為を、自分自身へのサービス拒否に変えてしまったわけです。

ネットワークレベル認証（NLA）は本当に効きます。セッション作成前にクライアントの認証を要求するため、認証前の脆弱性を突く攻撃を一群まとめて排除し、1 回あたりの負荷も下げます。有効にしてください。ただし試行の頻度は下がりません。

RDP の前段に VPN を置くのは利用可能な最強の答えであり、同時に多くの組織が現実には採用できない答えでもあります。委託先も、スマートフォンも、深夜 3 時の緊急ログインも、保守と費用が必要な追加インフラを経由することになるからです。可能ならやるべきです。しかし、いま攻撃を受けているサーバーの大半は、それができない人たちのものです。

試行を実際に減らすもの

量を変えるのは、送信元と話すことを拒むことだけです。それ以外はすべて、送信元と交渉しているに過ぎません。

つまり、失敗のストリームを監視し、あるアドレスがしきい値を超えたら、Windows が何かを費やす前にそのパケットを破棄するファイアウォール規則に加えるということです。これは Linux で fail2ban がやっていることで、Windows には組み込みの相当品がありません——だからこれほど多くの管理者が、最終的にスケジュール実行の PowerShell スクリプトを書く羽目になります。

持ちこたえる防御と、漏れる防御を分ける要点は 3 つです：

• アドレスではなくサブネットを遮断する。ボットはホスティング事業者のレンジ上で動きます。203.0.113.47 を遮断すれば、1 時間後に .48 が始まります。/24 全体を遮断すればその一連を一度に終わらせられますし、正規の利用者がスキャナーと同じ /24 を共有することはまずありません。
• 恒久的に遮断し、再起動を越えて残す。1 時間の遮断は、同じボットネットが今夜また来るという意味です。規則はメモリではなくファイアウォールに置かれなければなりません。
• 何かを有効にする前に、まず自分をホワイトリストに入れる。これが失敗する最も一般的な形は、RDP でしか到達できないサーバーから自分のオフィスの IP を締め出してしまう管理者です。

規則をまとめないと、ファイアウォールが詰まる

本番でしか表に出ない点があります。Windows ファイアウォールは、数千の小さな規則よりも、少数の大きな規則をはるかにうまく扱います。遮断するアドレスごとに New-NetFirewallRule を呼ぶスクリプトは 2 週間ほど見事に動き、その後、規則の数が 5 桁に達して評価に数分かかり始めます。

解決策は、攻撃者ごとに規則を作るのではなく、1 つの規則のアドレス一覧を書き換え続けることです。小さな設計上の判断ですが、半年後にその防御がまだ機能しているかどうかを決めます。

スクリプトを書かずに同じものを得る

RDP Protector は、そのロジックを署名済みの Windows エージェントとしてまとめたものです。あなたが読むのと同じ 4625 のストリームを読み、判断はローカルで行い——だからネットワークが落ちても動き続け——遮断したすべてのレンジを含む 1 つの統合ファイアウォール規則を維持します。

インストール時にレジストリと待ち受けソケットから実際の RDP・FTP・MS SQL ポートを検出するため、3389 から移設済みのサーバーも設定なしで保護され、何かを遮断する前に、あなたが接続している IP をホワイトリストに登録します。

ひとりでは作れない部分が、共有されたレピュテーションです。他の利用者を攻撃したアドレスは、あなたのところに届く前にすでに遮断されています。1 台は永年無料なので、自分のマシンで実際の攻撃ストリームを観察し、証拠に基づいて判断するには十分です。