インターネット上にVPSなどのサーバーを公開すると、
どれくらいの頻度で不正アクセスの試行が行われるのでしょうか。
当ブログ（LIFEWORK Blog）を稼働させているUbuntuサーバー環境において、
不正アクセス対策ツールである「fail2ban」のログデータを1ヵ月分（2026年2月）抽出し、
分析を行いました。
この記事では、実際のログデータから確認できた攻撃の実態と、
ログを確認して初めて気がついた設定の不備について説明します。
fail2banとは？（不正アクセスを防ぐ仕組み）
分析結果を見る前に、簡単に「fail2ban」について触れておきます。
fail2banは、サーバーのログを監視し、「一定回数以上ログインに失敗したIPアドレスを、自動的に一時遮断（BAN）するツール」 です。
SSHの鍵認証などと組み合わせることで、手当たり次第にパスワードを試してくるような自動化された攻撃（ブルートフォース攻撃）からサーバーを守ってくれます。
fail2banの基本的な仕組みや導入方法については、以下の記事で詳しくまとめています。
分析の前提条件
今回の分析対象となるサーバー環境と、fail2banの主な設定値は以下の通りです。
- OS: Ubuntu Server 24.04 LTS
- fail2banの主な有効Jail（監視ルール）:
sshd：SSH接続の失敗を監視（10分間に5回失敗で24時間BAN）nginx-wp：WordPressへの不審なアクセスを監視（10分間に5回失敗で24時間BAN）recidive：再犯者を監視（3日以内に2回BANされたら1週間BAN）
1ヵ月で1,100件超え！不正アクセス（BAN）の全体像
まずは、2026年2月（28日間）の総BAN件数を確認します。
| 項目 | 件数 |
|---|---|
| 総BAN回数 | 1,199 件 |
1ヵ月間で1,199件（1日平均約43回） のアクセス遮断が記録されていました。
個人の小さなサーバーであっても、これだけの攻撃が絶え間なく来ていることが分かります。
特筆すべき点として、これらの遮断はすべて sshd（SSH接続）に対するものであり、WordPressを狙った nginx-wp でのBANは0件でした。
このことから、サーバーの根本的な乗っ取りを狙う攻撃が多数を占めていると考えられます。
ボットの活動パターン？週別・曜日別の攻撃傾向
次に、この攻撃を週別および曜日別に集計しました。
週別のBAN件数
| 週 | BAN件数 |
|---|---|
| 第1週 (2/1〜2/7) | 277 件 |
| 第2週 (2/8〜2/14) | 332 件 |
| 第3週 (2/15〜2/21) | 296 件 |
| 第4週 (2/22〜2/28) | 294 件 |
週ごとの件数に大きな変動はなく、常に一定数の攻撃を受け続けている状態です。
曜日別のBAN件数
| 曜日 | BAN件数 |
|---|---|
| 月曜日 | 281 件 |
| 火曜日 | 99 件 |
| 水曜日 | 153 件 |
| 木曜日 | 188 件 |
| 金曜日 | 159 件 |
| 土曜日 | 134 件 |
| 日曜日 | 185 件 |
曜日別で見ると、月曜日が281件と突出して多く、火曜日が99件と最少になっています。
これは人間による手動の攻撃ではなく、週末にスキャン先をリストアップし、週明けに一斉に自動スクリプトを実行するようなボットネットの挙動であると私は推測しています。
攻撃者はどこから来るのか？BANされたIPの国別ランキング
IPアドレスの地理情報から、BANされたIPアドレスの所在国を特定しました。
上位5カ国は以下の通りです。
| 順位 | 国名 | BAN件数 | 全体比 |
|---|---|---|---|
| 1 | Netherlands（オランダ） | 585 件 | 48.8% |
| 2 | United States（米国） | 113 件 | 9.4% |
| 3 | Vietnam（ベトナム） | 54 件 | 4.5% |
| 4 | Germany（ドイツ） | 45 件 | 3.8% |
| 5 | India（インド） | 42 件 | 3.5% |
全体の約半数（48.8%）がオランダからのIPアドレスと判定されました。
しかし、これは悪意のある攻撃者の所在国を示しているものではありません。
攻撃者は、通常、セキュリティの甘いサーバーを介することで身元を隠して攻撃してきます。
オランダには多数のデータセンターが存在するため、悪意のある攻撃者がホスティングされているVPS（仮想サーバー）などを踏み台として利用している可能性が高いと考えられます。
【注意】完璧なはずの長期BAN（recidive）が機能していなかった
設定したfail2banのルールが意図通りに機能しているかを確認するため、2月中に最も多くBANされたIPアドレスのログを時系列で抽出しました。
| 日時 | Jail | アクション |
|---|---|---|
| 2026-02-01 02:36:34 | sshd | Ban |
| 2026-02-02 02:36:34 | sshd | Unban |
| 2026-02-03 02:01:38 | sshd | Ban |
| 2026-02-04 02:01:38 | sshd | Unban |
ログ上では、BANされた正確に24時間後にUnban（解除）されており、sshd の1日BAN設定は正常に機能していることが確認できました。
しかし、このタイムラインを確認したことで、ある重大な設定が機能していないことに気がつきました。
私の環境では、同じIPが何度も攻撃してくるのを防ぐために、再犯対策用の recidive という設定を入れています。
この設定では「3日以内に2回BANされた場合は、悪質な再犯者として1週間BANする」としていました。
しかし上記のログを見ると、2月1日にBANされ、解除された翌日の2月3日には再びBANされています。
発動条件を満たしているにもかかわらず、recidive による1週間の長期BANへの切り替えが行われず、sshd による1日BANが繰り返されていました。
まとめと次回予告
今回は、2026年2月のfail2banログを分析しました。
個人のサーバーであっても、1ヶ月で1,000回以上の無差別なSSH攻撃試行を受けている事実と、fail2banによるアクセス遮断の有効性を確認することができました。
一方で、ログを分析したことで「設定したはずの長期BAN（recidive）が機能していない」という問題を発見しました。
ツールは設定して終わりにするのではなく、実際のログを確認して動作検証を行うことの重要性を実感しました。
次回は、「なぜ1週間BAN（recidive）が機能しなかったのか」という原因と、Ubuntu環境における解決手順について書きたいと思います。
コメント