本当に Windows で fail2ban を動かせますか？

有用な形では動きません。fail2ban は Python と iptables に依存し、syslog 形式のテキストログを追うことを前提としています。Windows には iptables も syslog もなく、認証失敗はバイナリのセキュリティイベントログにあります。WSL 上で動かしても保護されるのは WSL 環境であって、Windows ホストの RDP ではありません。必要なのは Get-WinEvent と Windows ファイアウォールの上に作られたツールです。

1 台なら PowerShell スクリプトで十分ですか？

毎日運用して目を通す 1 台なら十分です——上の 30 行は実際の攻撃者を遮断します。ホワイトリスト、サブネット処理、死活確認の追加に 1 日を見込み、壊れ方が沈黙であることを受け入れてください。スケジュールされたタスクは再起動やパスワード変更のあと、誰にも知らせずに止まります。

遮断した IP ごとの規則より、1 つの規則が良いのはなぜですか？

Windows ファイアウォールは規則を順に評価し、数千の小さな規則より、大きなアドレス一覧を持つ少数の規則をはるかにうまく扱います。アドレスごとの規則は、この種のスクリプトが死ぬ定番の形です。数週間は問題なく動き、やがて規則の評価に数分かかるようになり、管理コンソールも使い物にならなくなります。

ファイアウォールでの遮断は強いパスワードの代わりになりますか？

なりません——なくなるのは量であって、要件ではありません。強いパスワードと NLA は通り抜けてくる試行を止め、ファイアウォール遮断は推測そのものを Windows に到達させません。後者が守るのは CPU、監査ログ、そしてその中から本物のイベントを見つけ出す能力です。どちらか一方ではなく、両方です。

Windows 版 fail2ban：現実的な代替手段

Windows に fail2ban はありません。自作の PowerShell 版がどんなものか、どこで壊れるのか、そして代替手段が実際に何をもたらすのか。

約 8 分で読めます2026-08-26 更新

この問いが繰り返される理由

Linux では、fail2ban はパスワード推測に対する反射的な答えです。ログを追い、失敗行を正規表現で照合し、しきい値を越えたアドレスにファイアウォール規則を挿入します。小さく、標準的で、この 15 年に書かれたあらゆる堅牢化ガイドに載っています。

Windows へ移る管理者は同じツールを探し、何も見つけられません。fail2ban は Python と iptables であり、Windows では意味のある形では動きません——追うべき syslog も、書き込むべき iptables もないからです。Windows にあるのは代わりにセキュリティイベントログと Windows ファイアウォール、同じ 2 つの材料が、つながっていない状態で存在しています。

つまり本当の問いは「Windows に fail2ban をどう入れるか」ではありません。「イベント 4625 とファイアウォール規則を何がつなぐのか、そのうちどれだけを自分で作らなければならないのか」です。

自作版と、その代償

自作の答えは、スケジュール実行の PowerShell タスクです。骨格は実際に短く、これは直近 10 分の失敗を読み、送信元ごとに集計し、しきい値を超えたものを遮断します：

powershell

$Threshold = 10
$RuleName  = 'Block-BruteForce'

$offenders = Get-WinEvent -FilterHashtable @{
    LogName='Security'; Id=4625; StartTime=(Get-Date).AddMinutes(-10)
  } -ErrorAction SilentlyContinue |
  ForEach-Object { ([xml]$_.ToXml()).Event.EventData.Data |
    Where-Object Name -eq 'IpAddress' | Select-Object -ExpandProperty '#text' } |
  Where-Object { $_ -and $_ -ne '-' } |
  Group-Object | Where-Object Count -ge $Threshold | Select-Object -ExpandProperty Name

$rule = Get-NetFirewallRule -DisplayName $RuleName -ErrorAction SilentlyContinue
if (-not $rule) {
  New-NetFirewallRule -DisplayName $RuleName -Direction Inbound -Action Block `
    -RemoteAddress $offenders | Out-Null
} else {
  $existing = ($rule | Get-NetFirewallAddressFilter).RemoteAddress
  $rule | Set-NetFirewallRule -RemoteAddress @($existing + $offenders | Select-Object -Unique)
}

スクリプトが漏れ始めるところ

この 30 行は今夜、実際の攻撃者を遮断します。しかしそれと「1 年放っておけるもの」の間の差は、地味な問題の積み重ねでできており、そのどれもが本番でしか発見されません：

自分を締め出します。上のコードにホワイトリストはありません。自社オフィスのアドレスの調子が悪い午後——古い保存済み資格情報がループで再試行するのが典型です——が最初に来たとき、あなたは RDP でしか到達できないサーバーの外側にいます。
単一アドレスでは足りません。ボットネットはレンジ内を巡回します。203.0.113.47 の遮断は .48 が始まるまでの 1 時間を買うだけです。/24 の遮断はその一連を終わらせますが、CIDR レンジを正しく計算して統合するのは、上の断片よりはるかに難しい仕事です。
ポーリング窓がイベントを取りこぼします。10 分ごとに実行すれば、1 つの窓に収まったバーストを見逃すか、2 つの窓にまたがって二重に数えます。負荷が高いとセキュリティログはあなたの間隔より速く回り、読む前にイベントが消えます。
止まったことを誰も教えてくれません。スケジュールされたタスクは静かに失敗します——再起動後、実行アカウントのパスワード変更後、PowerShell のポリシー更新後。3 月から保護が動いていなかったと、数か月後に気づくことになります。
RDP ポートが 3389 とは限りません。移設されていた場合、スクリプトは送信元を遮断し続けますが、規則がどのポートを覆うべきかを検証するものはなく、FTP と MS SQL はまったく覆われていません。
遮断は再構築を越えません。状態は 1 台のファイアウォールの中にあります。イメージから復元すれば、学習したすべての攻撃者は忘れられます。

Windows が標準で持っているもの

この文脈で推奨されるネイティブ機能は 2 つあり、それぞれが何をするのかは正確に述べる価値があります。

アカウントロックアウトポリシーは、N 回の失敗後にアカウントを無効化します。インターネットに面した RDP に対しては、防御というより弱点です。攻撃者がアカウント名を選ぶため、誰でもどこからでも、好きなときにあなたの Administrator アカウントをロックできます。内部アカウントには妥当な統制ですが、境界では不適切です。

ネットワークレベル認証は、セッション作成前にクライアントの認証を要求します。1 回あたりのコストを実際に下げ、認証前の脆弱性の一群を取り除くので、有効にすべきです。ただし試行回数は減りません。ボットはいずれにせよ認証を行うからです——下手に、永遠に。

どちらもイベントログとファイアウォールをつなぎません。そのつながりこそ fail2ban が実際に提供しているものであり、Windows はそれを同梱していません。

選択肢を並べて比べる

かける費用と得られるもので並べると：

PowerShell スクリプト——無料、完全な制御、書くのにおよそ 1 日、そして継続的な保守義務。頻繁に目を配る 1 台なら十分です。壊れ方は沈黙です。
前段の VPN または RDP ゲートウェイ——最も強い答えであり、運用上は最も高くつきます。全利用者が VPN に到達できるなら、それを使い、ここで読むのをやめて構いません。多くの環境には、それがどうしても成立しない委託先やスマートフォンがあります。
ファイアウォールでの IP 許可リスト——正規のアドレス集合が小さく固定的なら極めて有効で、誰かがホテルから働いた瞬間に使えなくなります。
マネージドエージェント——インストーラー、何かを遮断する前に埋まるホワイトリスト、サブネット遮断、自動検出されるポート、そしてまだ動いているかを示すコンソール。RDP Protector はこの分類に入ります。

マネージドエージェントがスクリプトに加えるもの

どれほど上手に書いても、スクリプトには持ちえないものが 2 つあります。

1 つ目は運用の土台です。インストール時点であなたのアドレスがホワイトリストに入り、数千ではなく 1 つの統合ファイアウォール規則があり、ポートはレジストリと待ち受けソケットから検出され、遮断は再起動を越えて残り、そして「これは生きているのか」に答えるダッシュボードがある——実際に痛い目を見るのは、まさにこの壊れ方です。

2 つ目はそもそも単独では作れません。保護されたすべてのサーバーが共有レピュテーションデータベースに寄与するため、昨日誰かを攻撃したアドレスは、あなたのところに届く時点ですでに遮断されています。1 台のサーバー上のスクリプトは、そのサーバーへの攻撃からしか学べません。

判断は引き続きエージェント側のローカルで下されるため、保護がクラウドの到達性に依存することはありません。接続が切れても、ローカルポリシーが動き続けます。

FAQ

本当に Windows で fail2ban を動かせますか？: 有用な形では動きません。fail2ban は Python と iptables に依存し、syslog 形式のテキストログを追うことを前提としています。Windows には iptables も syslog もなく、認証失敗はバイナリのセキュリティイベントログにあります。WSL 上で動かしても保護されるのは WSL 環境であって、Windows ホストの RDP ではありません。必要なのは Get-WinEvent と Windows ファイアウォールの上に作られたツールです。
1 台なら PowerShell スクリプトで十分ですか？: 毎日運用して目を通す 1 台なら十分です——上の 30 行は実際の攻撃者を遮断します。ホワイトリスト、サブネット処理、死活確認の追加に 1 日を見込み、壊れ方が沈黙であることを受け入れてください。スケジュールされたタスクは再起動やパスワード変更のあと、誰にも知らせずに止まります。
遮断した IP ごとの規則より、1 つの規則が良いのはなぜですか？: Windows ファイアウォールは規則を順に評価し、数千の小さな規則より、大きなアドレス一覧を持つ少数の規則をはるかにうまく扱います。アドレスごとの規則は、この種のスクリプトが死ぬ定番の形です。数週間は問題なく動き、やがて規則の評価に数分かかるようになり、管理コンソールも使い物にならなくなります。
ファイアウォールでの遮断は強いパスワードの代わりになりますか？: なりません——なくなるのは量であって、要件ではありません。強いパスワードと NLA は通り抜けてくる試行を止め、ファイアウォール遮断は推測そのものを Windows に到達させません。後者が守るのは CPU、監査ログ、そしてその中から本物のイベントを見つけ出す能力です。どちらか一方ではなく、両方です。