VPSの悪意あるスキャンを防ぐ方法？Fail2Banのインストールと設定詳細

Q: Fail2BanはUFWやFirewalldと併用可能か？

可能であり、むしろ理想的な組み合わせだ。Fail2Ban自体はファイアウォールではなく、あくまで司令塔である。ブロックルールを設定すると、Fail2Banはバックグラウンドでシステムのiptables、UFW、またはFirewalldに対して直接IPブロック命令を発行する。これらは完璧な上下流の共存関係にある。

核心摘要：2026年現在、SSHポートの変更だけでは世界中に蔓延する自動化スクリプトを防ぎきれない。本記事では、ログベースの侵入防御システム（IPS）であるFail2Banの導入手順を解説する。基礎ロジックと主要防御パラメータの分解から、SSH総当たり攻撃、Nginx CC攻撃、WordPress悪意スキャンの正確なブロックまで、サーバーを完全に武装させるための実践ガイドを提供する。

率直に言えば、多くの管理者はサーバーを購入し、OSをインストールしてドメインをパブリックIPに紐付けた瞬間、そのマシンは世界中の無数の自動化スクリプトに狙われている。

/var/log/auth.log を確認すれば、画面は世界中からのログイン総当たり試行で埋め尽くされているはずだ。パスワード認証を無効化していても、これらの悪意ある並列リクエストはサーバーのCPUとネットワーク接続数を激しく消費し続ける。

ウェブサイト構築の「お宝プラン」がスキャナーでダウンしたり、ボットネットの踏み台にされたりするのを防ぐため、余計な前置きは省き、Fail2Banのインストールと設定詳細というハードコア防御策を提示する。

この構成はSSH総当たり攻撃の正確なブロックに加え、Nginxと連携して悪意あるCC攻撃やWordPressへの総当たり攻撃を深度防御する。明確な結論、実データ、そしてそのまま適用可能な設定ファイルを提示し、サーバー管理者を悩ませる悪意スキャン問題を根本から解決する。

目次非表示

1 認識の転換：Fail2Banの基礎ロジック

2 高速インストールと設定ファイルの読み込みロジック

2.1 1. ワンクリックインストール

2.2 2. 設定ファイルの「暗黙のルール」（失敗回避の必須事項）

2.3 3. グローバルポリシーの編集

3 実践編 1：SSHの最終防御コンボ

4 実践編 2：WordPress防御とプリセットルール

5 実践編 3：Nginx CC攻撃と悪意あるクローラー防御

5.1 1. 高頻度CCリクエストのブロック

5.2 2. 悪意ある404脆弱性スキャナーのブロック

6 vps1111 失敗回避ガイドと多層防御戦略

6.1 💡 vps1111 失敗回避ガイド：

7 ❓ ギーク向け FAQ

7.1 Fail2BanはサーバーのCPUとメモリを大量に消費するか？

7.2 Fail2BanはUFWやFirewalldと併用可能か？

認識の転換：Fail2Banの基礎ロジック

パブリックネットワーク環境において、悪意あるスキャンは主に以下の2種類に分類される。

ポートスキャンとSSH総当たり攻撃： ボットが24時間体制で22番ポートなどを試行し、脆弱なパスワード辞書を用いてログインを突破しようとする。
Web脆弱性とCCスキャン： WordPressなどのアプリケーションを標的にし、wp-login.phpや機密プラグインディレクトリを執拗にスキャンする。あるいは、高頻度のCCリクエストを仕掛け、データベースリソースを枯渇させる。

Fail2Banの基礎ロジックは極めて合理的だ。本質的に、これはログベースの侵入防御システム（IPS）である。SSH、Nginx、システムログなど、各種ログファイルをリアルタイムで監視する。設定された時間（findtime）内に、規定回数（maxretry）を超える悪意ある動作を特定のIPが検出した場合、Fail2Banはシステムのファイアウォール（iptables、ufw、またはfirewalld）を直接呼び出し、該当IPをネットワーク層でドロップ（Drop）し、一定期間（bantime）「隔離」する。

🔥 Fail2Ban 主要防御パラメータ一覧
ハードコアデータ

主要パラメータ名	機能説明	単位/形式	推奨セキュリティ値	実戦での役割
findtime	統計周期	秒 (s) / 分 (m)	10m (600s)	攻撃判定の時間枠を定義
maxretry	最大許容回数	数値のみ	3〜5	規定回数を超えると即時ブロック
bantime	ブロック期間	時間 (h) / 日 (d)	24h または 48h	隔離ペナルティの適用時間

高速インストールと設定ファイルの読み込みロジック

VPSのOSがDebianでもUbuntuでも、インストール手順は極めて単純だ。

1. ワンクリックインストール

sudo apt update
sudo apt install fail2ban -y

2. 設定ファイルの「暗黙のルール」（失敗回避の必須事項）

インストール完了後、Fail2Banの設定ファイルは /etc/fail2ban/ ディレクトリに配置される。ここで初心者が必ず陥る罠がある：jail.conf ファイルを直接編集してはならない。

正しい読み込みロジックは以下の通りだ： システムはまず jail.conf のグローバルデフォルト設定を読み込み、その後 jail.local の設定を読み込んで同名パラメータを上書きする。将来のソフトウェアアップデート時に jail.conf は上書きされるが、jail.local に記述した設定は永続的に保持される。

したがって、最初のステップは常にローカル設定ファイルのコピーを作成することだ。

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

3. グローバルポリシーの編集

エディタで /etc/fail2ban/jail.local を開き、[DEFAULT] セクションを見つけてグローバルセキュリティベースラインを設定する。

ignoreip = 127.0.0.1/8 ::1 自身のグローバルIP （誤ブロック防止のホワイトリスト。極めて重要）。
bantime = 24h （ペナルティ時間）。
findtime = 10m （監視ウィンドウ）。
maxretry = 3 （許容回数）。

実践編 1：SSHの最終防御コンボ

「パスワード認証を無効化し、鍵認証に切り替えればFail2Banは不要だ」と考えるセキュリティ上の誤解が蔓延している。これは極めて危険な論理だ。鍵認証のみを許可していても、悪意あるスクリプトはTCP接続試行を継続し、auth.log は無効なログで溢れ、SSHデーモンはこれらのハンドシェイク処理にリソースを消費し続ける。

真の最終防御コンボは以下の通りだ：SSHデフォルトポートの変更 + Rootパスワードログインの無効化 + 鍵認証のみの許可 + Fail2Banによる最終防衛。 最初の3項目で総当たり攻撃の成功率を99%削減し、Fail2Banがネットワーク層で残りの悪意リクエストをドロップすることで、サーバーリソースの消費を最小化する。

jail.local 内の [sshd] モジュールを探し、有効化する。

[sshd]
enabled = true
port    = 2222  # SSHポートを変更した場合は必ずここで対応させる
logpath = %(sshd_log)s
backend = %(sshd_backend)s
maxretry = 3

実践編 2：WordPress防御とプリセットルール

WordPressの wp-login.php 総当たり攻撃やXML-RPC攻撃に対し、最新版のFail2Banには定義済みフィルタールールが標準搭載されている。古いチュートリアルのようにゼロから正規表現を手書きする必要は一切ない。

jail.local の最下部に以下の設定を追記し、直接有効化するだけでよい。

[wordpress]
enabled = true
port = http,https
filter = wordpress  # 標準搭載ルールを直接呼び出し
logpath = /var/log/nginx/access.log # Web環境のパスと一致させること
maxretry = 5
findtime = 10m
bantime = 24h

（ギーク向けヒント：極めてマイナーな管理パネルを使用しており、標準ルールが一致しない場合に限り、/etc/fail2ban/filter.d/wordpress.conf に手動で正規表現マッチングルールを追加する必要がある。）

実践編 3：Nginx CC攻撃と悪意あるクローラー防御

基礎チュートリアルで頻繁に見過ごされる核心領域だ。CC攻撃（Challenge Collapsar）は多数の踏み台サーバーを利用し、リアルユーザーを装ってサイトへ高頻度アクセスを仕掛け、PHPとデータベースプロセスを瞬時に枯渇させる。Nginxの limit_req モジュールと組み合わせることで、Fail2Banは完璧なカウンター攻撃を実現する。

1. 高頻度CCリクエストのブロック

Nginxの limit_req がブロックをトリガーすると、error.log にログが記録される。以下のJailを有効化し、悪意あるIPを隔離する。

[nginx-limit-req]
enabled = true
port    = http,https
filter  = nginx-limit-req
logpath = /var/log/nginx/error.log
findtime = 1m
maxretry = 10  # 1分以内に10回限流をトリガーすれば即座にブラックリスト化
bantime = 24h

2. 悪意ある404脆弱性スキャナーのブロック

攻撃者はツールを用いて機密ディレクトリ（.env、backup.zipなど）を無差別にスキャンし、大量の404エラーを発生させる。悪意あるボットに対する防御を有効化する。

[nginx-botsearch]
enabled = true
port     = http,https
filter   = nginx-botsearch
logpath  = /var/log/nginx/access.log
maxretry = 3

設定完了後、sudo systemctl restart fail2ban を実行してサービスを再起動する。sudo fail2ban-client status nginx-limit-req を使用すれば、ブロックした「敵機」の数をいつでも確認できる。

vps1111 失敗回避ガイドと多層防御戦略

セキュリティ設定で最も忌避すべきは「過剰な設定」と「ロジックの断絶」だ。インフラ運用のベテランとして、最後に失敗回避の鉄則を2つ伝える。

💡 vps1111 失敗回避ガイド：

永久ブロックの慎重な使用 (bantime = -1)： 初心者は即座に永久ブロックを設定しがちだ。実際、最新版Fail2Banと現代のマルチコアCPUであれば、数万行のiptablesルールを処理する際の性能劣化は微々たるものだ。盲目的な永久ブロックが招く真の災厄は、ファイアウォールルールチェーンが異常に長大化し、誤ブロック時の調査難易度が跳ね上がり、自動解除が不可能になる点にある。 通常環境では24〜48時間のブロック設定で十分であり、これによりコストを嫌うほとんどの自動化攻撃スクリプトが対象IPを放棄する。
「多層防御」の正しい認識： Fail2Banはシステム上で動作するアプリケーション層のソフトウェアだ。数百Gbps規模の超大規模DDoS攻撃を受けた場合、Fail2Ban単体では防ぎきれない（NICが飽和するため）。正しいアーキテクチャ戦略は以下の通りだ： 高品質なバックボーン回線（例：Arelion/Telia (AS1299) や Lumen (AS3356)）を利用し、データセンターが基礎的なDDoSトラフィック洗浄機能を備えたサーバーを選定する。まずデータセンターのネットワーク層で粗悪な大規模トラフィックを洗浄し、その後サーバー内部のFail2Banでアプリケーション層（CC攻撃、SSH総当たりなど）を正確にブロックする。これにより、完璧な多層防御体系が構築される。

このコンボをサーバーに適用すれば、サイトの基盤セキュリティアーキテクチャは市場の90%の「無防備」な競合を既に凌駕している。

❓ ギーク向け FAQ

Fail2BanはサーバーのCPUとメモリを大量に消費するか？

消費しない。Fail2Banはイベント駆動型の軽量Pythonスクリプトだ。現代のサーバーでは、通常のSSHおよびWebログの監視に要するリソースは微々たるものだ。超大規模CC攻撃に直面し、巨大な access.log の頻繁な読み込みや iptables の頻繁な呼び出しが発生した場合にのみ、わずかな性能劣化が生じる可能性がある。ウェブサイト構築用サーバーであれば、迷わずインストールして問題ない。

Fail2BanはUFWやFirewalldと併用可能か？

可能であり、むしろ理想的な組み合わせだ。Fail2Ban自体はファイアウォールではなく、あくまで「司令塔」である。ブロックルールを設定すると、Fail2Banはバックグラウンドでシステムのiptables、UFW、またはFirewalldに対して直接IPブロック命令を発行する。これらは完璧な上下流の共存関係にある。