インターネット公開 Windows Server の堅牢化チェックリスト

この一覧の使い方

堅牢化チェックリストが失敗する理由はたいてい 1 つです。リスク順ではなく五十音順・アルファベット順に並んでいるため、上から順に潰していくと、スクリーンセーバーのポリシーあたりで時間が尽き、リモートアクセスにはついに辿り着かない。

こちらは順序づけてあります。前半の節は、サーバーが実際に乗っ取られる経路を取り除きます。最後の節はやる価値がありますが、それだけでは救ってくれません。午後の数時間しかないなら、第 2 節と第 3 節をやって止めてください。

この一覧はインターネットから到達可能であり続けなければならないサーバーを前提にしています。あなたのサーバーがそうでないなら第 3 節は 1 行に縮み、それは良い知らせです。

1. アカウントと認証

インターネットに面した Windows サーバーの侵害は、ほぼすべてが有効な資格情報から始まります——推測された、スプレーされた、他所の漏洩から使い回された、あるいはフィッシングで奪われたもの。労力はここに割くべきです。

• 組み込みの Administrator アカウントを無効化するか改名する。どの攻撃一覧でも最初に試される名前であり、よく知られた SID を持つため改名だけでは防御になりません——別途、名前付きの管理者アカウントを用意して無効化するほうが良いです。
• リモートログインできるすべてのアカウントに多要素認証を要求する。この一覧で最も価値の高い対策です。推測されたパスワードも、第 2 要素がなければ何の価値もありません。
• 長いパスワードを強制する——15 文字の下限は、より短いパスワードに複雑さの規則を課すより、オフライン解析にはるかによく耐えます——そしてツールが対応していれば既知の漏洩パスワードを禁止します。
• 誰が実際にリモートアクセスを持っているか棚卸しする。退職者、業務が終わった委託先、もう存在しないサービスのアカウントを削除します。休眠アカウントはどれも、誰も見ていない攻撃面です。
• サービスアカウントには独自の ID を与え、対話的ログオン権限は与えず、パスワードは他のどことも共有しないこと。
• アカウントロックアウトは慎重に扱う。インターネットに面したホストでは、誰でも好きなときにあなたのアカウントを無効化できてしまいます。使うならしきい値は控えめにし、推測への防御として頼らないこと。

2. ネットワークの露出

「誰がログインできるか」の次の問いは「どこから」です。インターネットから到達できるポートはすべて、今この瞬間に誰かが試しているサービスです。

• 何が実際に待ち受けているかを外部から棚卸しする。ホストで Get-NetTCPConnection -State Listen を実行し、別のネットワークからどれが応答するか確認します。
• 境界で SMB（445）を閉じる。これは事実上インターネットに面してよいものではなく、RDP だけを公開するつもりだったサーバーでよく見つかる 2 つ目の問題です。
• WinRM（5985/5986）、MS SQL（1433）、あらゆる管理インターフェイスも同様に。インターネットから到達可能である必要がないなら、それ自体が完全な修正です。
• RDP 自体については、可能なら送信元アドレスを限定する。できないなら読み進めてください——第 3 節が代償措置です。
• ネットワークレベル認証を有効にし、未認証のクライアントにセッションが作られないようにする。
• Windows ファイアウォールだけでなくクラウドのセキュリティグループも確認する。2 層あるということは間違えられる箇所が 2 つあるということで、丁寧なホストファイアウォールの前にすべて許可のグループがある、というずれはよくあります。

3. ログイン失敗の自動遮断

多くのチェックリストが省くのがこの節であり、公開サーバーを運用する日常を実際に変えるのもこの節です。

Windows は認証失敗をすべてイベント 4625 として記録し、十分に有能なファイアウォールも同梱していますが、その 2 つをつなぐものは一切同梱していません。放っておけばサーバーは 1 日に数千回の推測を吸収します。消費される CPU、かき回される監査ログ、そして攻撃者が試し続けられる時間に上限がないこと。

必要なのは fail2ban の等価物です。失敗のストリームを監視し、送信元がしきい値を超えたらファイアウォールで破棄する。機能する実装と漏れる実装を分けるのは 3 つの性質——単一アドレスではなくサブネットを遮断する、遮断を恒久かつ再起動耐性のあるものにする、そして他の何かを有効にする前に自分のアクセスをホワイトリストに入れる。

PowerShell のスケジュールタスクとして作ることもでき、毎日目を配る 1 台であればそれは妥当な選択です。1 日を見込み、そして壊れ方が沈黙であることを理解しておいてください。スケジュールタスクは再起動やパスワード変更のあと、誰にも知らせずに止まります。RDP Protector は同じロジックをマネージドエージェントにしたもので、ホワイトリスト、サブネット処理、ポート検出、稼働状況の表示が含まれます。

4. パッチと攻撃面

資格情報が通常の侵入経路であり、未修正のサービスは記憶に残る経路です。

• 自動更新を有効にするか、実際に守れるパッチ運用サイクルを回す。RDP には認証前のリモートコード実行の脆弱性があり、これからもあります。
• 使っていない役割と機能を削除する。誰も有効にした記憶のない IIS は、他の誰かが見つけてくれるサービスです。
• イメージに同梱されていて不要なソフトウェアをアンインストールする。エージェント、ツールバー、ベンダーの更新プログラムはどれも、あなたのホスト上で権限をもって動くコードです。
• 実際に動かしているエージェント類は監視やバックアップも含めて最新に保つ。
• レガシープロトコルを無効にする——SMBv1、TLS 1.0 と 1.1、NTLMv1——本当に必要とするものがなければ。必要なら、何が必要としているのかを書き残し、後で見直すこと。

5. ログと検知

記録していないものは調査できませんし、既定の構成は思っているより少なく記録し、期待するより短く保持します。

• ログオン監査が成功だけでなく失敗も捕捉していることを確認する：auditpol /get /subcategory:"Logon" は両方を示す必要があります。
• セキュリティログの最大サイズを引き上げる。既定値は公開ホストでは数時間で埋まり、必要なイベントは見に行く前に失われます。
• イベントをホストの外へ転送する。侵害されたマシンのローカルログは攻撃者が編集できる証拠ですが、別の場所にある複製はそうではありません。
• 量ではなく意味のあることに対して警報を出す：新しい国からの成功ログオン、新しいローカル管理者、インストールされたサービス、監査ログの消去（イベント 1102）。
• 誰が成功してログインしたかを、ときどき意識的に見直す。失敗は雑音であり、説明できない成功こそが本題です。

6. 実際に復元したことのあるバックアップ

この節が最後なのは重要度が最も低いからではありません。他のすべてが失敗したことを前提とする対策だからであり、その日に問題になるバックアップの性質はただ 1 つです。

サーバー自身が到達も削除もできない複製を少なくとも 1 つ持つこと。ランサムウェアの運用者は何かを暗号化する前にバックアップ先を探しますし、侵害されたホストが書き込める共有はバックアップではなく、破壊されるのを待っている 2 つ目の複製です。

そして、1 つ復元してみること。一度も復元されていないバックアップは仮説です。計画的にテストし、どれだけ時間がかかったかを記録し、手順を知っている人間が 1 人だけにならないようにしてください。