VPS のセキュリティ対策として fail2ban を導入してから、毎月ログを分析しています。
3月は SSH のポート番号をデフォルトの22番から別の番号に変更したところ、
1日あたりの BAN 件数が 約99%減少するという劇的な変化がありました。
4月の fail2ban ログを開いて、最初に目に入った数字は「5」でした。
月間 BAN 件数が、5件。
2月は1,199件、3月は781件。3桁の数字を毎月見続けてきたので、
最初は集計ミスかと思いましたが、間違いなく5件でした。
3月の途中に SSH ポートを変更したのですが、
1ヵ月間で月間BAN件数が5件、
ここまで劇的な効果があるとは思いませんでした。
この記事では、ポート変更から1ヵ月が経過した4月のログを分析した結果をまとめます。
今回は、過去2ヵ月の分析ではまだやっていなかった「時間帯別の分析」に初挑戦しました。
「不正アクセスは深夜に多い」というイメージを持っている方は多いと思います。
実際のログデータで検証すると、まったく違う結果が出ました。
この記事で分かること：
- 月間 BAN 5件——ポート変更の効果は4月も続いているか（3ヵ月推移）
- 不正アクセスが多い時間帯はどこか（深夜神話の検証）
- 月曜最多・火曜最少のパターンは3ヵ月連続で続くか
- 37日間 BAN を逃れ続けた「スロー攻撃ボット」のその後
- 同じ攻撃グループが「別の IP」で再登場したケース
分析の前提条件
サーバー環境と fail2ban の設定に変更はありません。
- OS： Ubuntu Server 24.04 LTS
- fail2ban の有効 Jail（監視ルール）：
sshd：SSH 接続の失敗を監視（10分間に3回失敗で24時間 BAN）nginx-wp：WordPress への不審なアクセスを監視（10分間に5回失敗で24時間 BAN）recidive：再犯者を監視（3日以内に2回 BAN されたら1週間 BAN）
- SSH ポート： 2026年3月8〜9日に、デフォルトの22番から50022番に変更済み
なお、4月中に nginx-limit-req（Nginx へのリクエスト数制限違反の監視）と nginx-botsearch（ボットによるディレクトリスキャンの監視）という2つの監視ルールを新たに追加しました。
これについては記事の後半で触れます。
4月全体の BAN 件数——月に5件という現実
2026年4月（30日間）の総 BAN 件数から確認します。
| 項目 | 件数 |
|---|---|
| 総 BAN 件数 | 5件 |
| 試行検知（Found）件数 | 31件 |
月に5件、試行そのものも31件。
2月の1,199件（試行検知はさらに多い）と比べると、攻撃のボリューム自体が桁違いに減少しています。
BAN 件数だけでなく「試行検知（Found）も31件と少ない」という点が重要です。
fail2ban が防いだというよりも、そもそも攻撃の試みそのものが激減していることを示しています。
ポート変更後1ヵ月——3ヵ月の推移で見る変化
3ヵ月間の主要指標
3月8〜9日の SSH ポート変更を挟んだ3ヵ月間の推移です。
| 項目 | 2月（28日間） | 3月（31日間） | 4月（30日間） |
|---|---|---|---|
| 総 BAN 件数 | 1,199件 | 781件 | 5件 |
| 1日平均 BAN 件数 | 42.8件 | 25.2件 | 0.2件 |
| sshd BAN | 1,199件 | 781件 | 5件 |
| nginx-wp BAN | 0件 | 0件 | 0件 |
| recidive BAN | 0件（不具合） | 16件（修正後） | 0件 |
| BAN 件数ゼロの日 | ほぼなし | ほぼなし | 26日 / 30日 |
3ヵ月間の1日平均 BAN 件数の推移です。
左から「2月 42.8件」「3月前半（3/1～3/8） 95.9件」、「3月後半（3/9～3/31） 0.6件」「4月 0.2件」と、SSH ポート番号を変更してから劇的に減少しています。
ポート変更前後の詳細比較
3月はポート変更が月の途中（3/8〜3/9）に行われたため、前後で分けると変化がより鮮明になります。
| 期間 | 日数 | BAN 件数 | 1日平均 |
|---|---|---|---|
| 3月ポート変更前（3/1〜3/8） | 8日間 | 767件 | 95.9件 |
| 3月ポート変更後（3/9〜3/31） | 23日間 | 14件 | 0.6件 |
| 4月（4/1〜4/30） | 30日間 | 5件 | 0.2件 |
ポート変更直後の0.6件/日から、4月はさらに0.2件/日へと低下しています。
ポート変更から1ヵ月が経過するにつれ、攻撃者側の「スキャン対象リスト」からこのサーバーの情報が徐々に除外されていっている可能性があります。
あるいは、UFW（ファイアウォール）への手動ブロックの蓄積による効果とも考えられます。
「BAN 件数ゼロの日」が30日中26日
4月で特に印象的なのは、30日間のうち26日（86.7%）が BAN 件数ゼロだったという事実です。
また、4月17日〜25日には9日間連続で BAN ゼロという期間もありました。
2月・3月は毎日何十件もの攻撃を受け続けていたことを思うと、わずか1〜2ヵ月でここまで変わるものかと改めて驚きます。
4月の日別 BAN 件数カレンダーです。
横軸が日付（4/1〜4/30）、縦軸が BAN 件数ですが、全体で5件なので何もない日が目立っています。
週別で見ると、第1週（4/1〜4/7）に3件、第4週（4/22〜4/28）に2件という小さな山が2つあるだけで、第2・第3・第5週は完全にゼロです。
「月に2度、ちらほらと来る」という静かな状態になっています。
【検証】不正アクセスは「深夜」に多い？——時間帯別分析
今回初めて、時間帯を分析してみた
「不正アクセスは深夜に集中する」——セキュリティの話題でよく耳にする表現です。
個人的にもなんとなくそういうものだと思っていました。
しかし、本当にそうなのでしょうか。
今回、実際のログデータで検証してみました。
分析方法
BAN と試行検知（Found）のそれぞれについて、発生した時刻を0時〜23時の24区分で集計しました。
BAN 件数は5件と少ないため、主に試行検知（Found）の件数（31件） をベースに傾向を読み取ります。
試行検知（Found）とは、fail2ban が「不正なログイン試行を1件検知した」という記録です。
BAN の閾値（10分間に3回）に達していなくても記録されるため、ブルートフォース攻撃の試みそのものの傾向を把握するのに適しています。
時間帯別の結果
| 時間帯 | BAN 件数 | 試行検知（Found） |
|---|---|---|
| 0時 | 0 | 1件 |
| 1時 | 0 | 0件 |
| 2時 | 0 | 1件 |
| 3〜9時 | 0 | 0件 |
| 10時 | 0 | 1件 |
| 11〜12時 | 0 | 0件 |
| 13時 | 2 | 8件 |
| 14〜15時 | 0 | 0件 |
| 16時 | 0 | 1件 |
| 17〜18時 | 0 | 0件 |
| 19時 | 1 | 6件 |
| 20時 | 2 | 8件 |
| 21時 | 0 | 3件 |
| 22時 | 0 | 0件 |
| 23時 | 0 | 2件 |
時間帯を3区分にまとめると
| 時間帯 | 試行検知（Found） | 割合 |
|---|---|---|
| 深夜帯（0〜5時） | 2件 | 6.5% |
| 日中帯（6〜17時） | 10件 | 32.3% |
| 夜間帯（18〜23時） | 19件 | 61.3% |
時間帯別の試行検知（Found）件数を棒グラフで表示したものです。
横軸が0〜23時、縦軸が件数で、13時と20時に突出した棒が立ち、深夜帯（0〜5時）がほぼフラットになっています。
「深夜集中」とはほど遠い分布が一目でわかります。
結果の考察——なぜ夜間帯（18〜23時）に集中するのか
深夜帯（0〜5時）はわずか6.5%、最多は夜間帯（18〜23時）の61.3%。
「不正アクセスは深夜に多い」という通説は、今回のデータでは当てはまりませんでした。
特に集中しているのは13時と20時です。
この時間帯の攻撃が多い理由として、ログに記録された IP アドレスの所在国（過去の分析では約半数がオランダなどヨーロッパ系）をもとに考えると、次のような構図が見えてきます。
| 日本時間 | ヨーロッパ中部時間（CET+1） | UTC（世界標準時） |
|---|---|---|
| 13時 | 6時（朝） | 4時 |
| 20時 | 13時（昼） | 11時 |
日本時間の13時〜20時台は、ヨーロッパの「朝〜昼」に相当します。
つまり、不正アクセスを仕掛けている攻撃者の活動時間帯と、日本時間の夜間が重なっているという構図です。
不正アクセスは、自動的に攻撃を仕掛けてきているものであり、時間帯によって集中することはない、あるいは集中するとしたら、攻撃を受ける側がすぐに反応できない深夜帯かと思っていました。
攻撃する側としても、攻撃が成功したときに何らかのアクションをとるためには、自分たちが活動している時間帯に攻撃をしているのかもしれませんね。
ただし、4月の試行検知件数はわずか31件と少なく、統計的に断言できる水準ではありません。
今後数ヵ月データが蓄積されれば、より確かな傾向が見えてくるはずです。引き続き観察を続けます。
【3ヵ月連続】月曜最多・火曜最少のパターンは続くか
時間帯の次は、曜日パターンの検証です。
2月・3月の分析で2ヵ月連続して発見された「月曜日が最多・火曜日が最少」という傾向が、4月でも再現されるかを確認しました。
| 曜日 | 2月（28日間） | 3月前半（3/1〜3/8） | 4月（30日間） |
|---|---|---|---|
| 月曜日 | 281件（最多） | 195件（最多） | 3件（最多） |
| 火曜日 | 99件（最少） | 88件（最少） | 0件（最少） |
| 水曜日 | 153件 | 76件 | 0件 |
| 木曜日 | 188件 | 48件 | 0件 |
| 金曜日 | 159件 | 96件 | 1件 |
| 土曜日 | 134件 | 110件 | 0件 |
| 日曜日 | 185件 | 154件 | 1件 |
3ヵ月連続で、月曜日が最多・火曜日が最少というパターンが再現されました。
件数が少ないので、時間帯にしても、曜日にしても、特徴を決めつけることはできませんが、週明けの月曜日の活動が最も活発であるというのが、3ヵ月も続くと、偶然だとは思えなくなります。
4月は BAN 件数が5件と少ないため、統計的な有意性は高くありません。
それでも、規模が激減した状況においても同じ曜日に集中するという事実は、ボットネット側に何らかの週次スケジュールが存在することを示唆しているように思います。
「ボットは週休二日制？」——このパターンの解釈
私の推測は、週末にスキャン対象のリストを更新・整理し、月曜の早朝に一斉攻撃を開始するボットネット（複数のサーバーを連携させた自動攻撃システム）の動作スケジュールによるものではないかというものです。
人間ではなく自動スクリプトが動いているはずのボットが、人間の「週の始まり」と同じリズムで攻撃してくる——このパターンが3ヵ月続いたという事実は、何とも不気味です。
37日間 BAN を逃れ続けたボット——その後
3月の記事で詳しく紹介した2つの「スロー攻撃ボット」の4月の状況を確認します。
これらは fail2ban の BAN 閾値（10分間に3回）をわずかに下回るペース（20〜40分に1回）でブルートフォース攻撃を続け、長期間 BAN されなかった IP アドレスです。
| IP アドレス | 活動期間（3月まで） | BAN 回数 |
|---|---|---|
185.156.73.233 | 2/22〜3/31（37日間） | 0回 |
80.94.95.115 | 2/22〜3/27（33日間） | 0回 |
4月のログには、この2つの IP は一切登場しませんでした。
ただし「諦めて攻撃をやめた」とは言い切れません。
ゆっくりと攻撃して、あえて BAN されないような動きをする IP アドレスであったため、サーバーの UFW（ファイアウォール）設定を見直して、この2つの IP はいずれも UFW の「DENY（拒否）」リストに手動で追加しました。
UFW とは、サーバーへの通信を OS レベルで制御するファイアウォールのことです。
fail2ban よりも手前の段階で通信を遮断するため、UFW で拒否されたアクセスは fail2ban のログには記録されません。
つまり、4月も攻撃を試みていた可能性はありますが、UFW が最初の段階で弾いているため、fail2ban のログには残っていないのです。
この事例から見えてくるのは、「fail2ban だけでは対応できない不正アクセスに対しては、UFW による手動ブロックが有効な補完手段になる」 という実践的な教訓です。
一方で、UFW でブロックした後は fail2ban のログにも記録が残らなくなるため、「いつ攻撃が止まったか」の確認ができなくなるというトレードオフもあります。
UFW で手動ブロックした IP は、別途メモや管理ファイルに記録しておくと、後から追跡しやすくなります。
同じグループが「別の IP」で再登場——サブネット攻撃
4月の BAN を詳しく見ていて、気になる点がありました。4月6日に BAN されたのは以下の2つの IP です：
87.251.64.145（4/6 19:42）87.251.64.147（4/6 20:00）
3月の記事で「recidive による1週間 BAN の教科書通りの事例」として紹介した IP は 87.251.64.141 でした。3つの IP を並べてみると：
| IP アドレス | 登場月 | 備考 |
|---|---|---|
87.251.64.141 | 3月 | recidive で1週間 BAN |
87.251.64.145 | 4月 | sshd で BAN |
87.251.64.147 | 4月 | sshd で BAN |
上位3つの数字（87.251.64）がまったく同じです。
IP アドレスにおいて、上位3つの数字が共通するアドレスのグループを「/24 サブネット」と呼びます。
同じ /24 サブネット内の IP は、多くの場合、同じ組織やデータセンターが管理しているアドレス群です。
3月に 87.251.64.141 を BAN し、さらに UFW でそのサブネット全体（87.251.64.0/24）をブロックしていたにもかかわらず、4月に同じグループとみられる別の IP からの攻撃が来て BAN されたということになります。
同じグループの攻撃者が、遮断された IP を使い続けるのではなく、同一ネットワーク内の別の IP に切り替えながら不正アクセスを続けている可能性があります。
個別の IP だけでなく、サブネット単位でのブロックが必要なケースがあることを、改めて実感しました。
recidive（長期 BAN）の状況
| 月 | recidive BAN 件数 |
|---|---|
| 2月 | 0件（不具合あり） |
| 3月 | 16件（修正後、正常動作） |
| 4月 | 0件 |
4月は recidive による長期 BAN が0件でした。
これは2月のような「設定の不具合」ではありません。
recidive の発動条件は「3日以内に同一 IP が2回 BAN されること」ですが、4月の BAN はすべて異なる IP アドレスによるものであったため、条件そのものが満たされなかったのです。
言い換えると、「BAN → 解除 → すぐ再攻撃」という執拗なパターンの攻撃者が4月は現れなかった、ということです。
攻撃数の減少に伴い、recidive の出番もなくなった形です。
監視ルールを2つ追加——nginx-limit-req と nginx-botsearch
4月中に、2つの新しい監視ルール（Jail）を fail2ban に追加しました。
| Jail 名 | 監視内容 | 4月の BAN 件数 |
|---|---|---|
nginx-limit-req | Nginx へのリクエスト数が制限を超えた場合に検知 | 0件 |
nginx-botsearch | ボットがサーバー上のファイルやディレクトリを無作為に探索する行為を検知 | 0件 |
4月中はどちらも BAN が発生しませんでした。
設定したものの、まだ発動するほどの攻撃が来ていない状態です。
5月以降、実際に機能するかどうかを継続して観察します。
3ヵ月間で fail2ban はどれだけの攻撃を防いだか——累計試算
最後に、fail2ban がなかった場合にどれだけの不正ログイン試行にさらされていたかを試算してみます。
計算の考え方：
BAN されたブルートフォース攻撃ボットは24時間の接続遮断を受けます。
fail2ban がなければ、その24時間の間も自由にパスワードを試し続けられます。
ここでは「10分に1回のペース」という保守的な見積もりで計算します（実際のブルートフォース攻撃はもっと高速なことが多いため、この試算は過小評価気味です）。
1回の BAN × 24時間 × 6回/時間 = 144回の追加試行を阻止| 月 | sshd BAN 件数 | 推定阻止試行数（保守的） |
|---|---|---|
| 2月 | 1,199件 | 約172,656回以上 |
| 3月 | 781件 | 約112,464回以上 |
| 4月 | 5件 | 約720回以上 |
| 3ヵ月合計 | 1,985件 | 約285,840回以上 |
3ヵ月で28万回以上の不正試行を阻止したという試算になります。
ただし、現在のサーバーでは SSH 鍵認証を設定しているため、正しい秘密鍵を持っていない攻撃者はパスワードをいくら試してもログインできません。
fail2ban の主な役割は「確実なログイン阻止」よりも「無意味なブルートフォース試行を早期に打ち切り、サーバーの負荷を下げログを見やすくする」ことにある——という点はお伝えしたいと思います。
それでも、無料ツール1つでここまでの効果が得られるという事実は、VPS を運用しているなら導入を検討する十分な理由になると感じています。
まとめ
4月のログ分析で得られた知見をまとめます。
ポート変更の効果は持続し、さらに強まった
1日平均 BAN 件数は0.2件/日となり、3月ポート変更後（0.6件/日）からさらに低下しました。
30日のうち26日が BAN ゼロという静かな月になっています。
SSH のポート番号を変えるだけでここまで変わるとは、改めて驚きます。
「深夜に不正アクセスが多い」は今回の実データでは当てはまらなかった
試行検知の61.3%が夜間帯（18〜23時）に集中し、深夜帯（0〜5時）はわずか6.5%でした。
攻撃元の活動時間帯（ヨーロッパの日中）が日本時間の夜間に重なっているためと推測されます。
ただし件数が少なく、断言はできません。
引き続き観察を続けます。
月曜最多・火曜最少のパターンが3ヵ月連続で再現
件数が激減した4月においても、月曜日が最多・火曜日が最少というパターンが続きました。
ボットネットの週次スケジュールによるものではないかと推測していますが、今後も検証を続けます。
スロー攻撃ボットは UFW で手動ブロック、4月の検知はゼロ
37日間・33日間にわたって fail2ban をすり抜け続けた2つの IP は、UFW への手動追加によって4月のログには現れなくなりました。
fail2ban と UFW の組み合わせによる多層防御が有効に機能しています。
同じグループとみられる IP が別アドレスで再登場
3月に recidive 対象となった 87.251.64.141 と同じ /24 サブネット（87.251.64.xxx）から、4月にも2件の攻撃が記録されました。
執拗な不正アクセスグループに対しては、IP 単体ではなくサブネット単位でのブロックが必要なケースがあることを示しています。
次回は、5月分のデータがまとまる6月初旬に分析結果を報告したいと思います。
過去のブログ記事へのリンクを貼っておきますので、参考にしてください。
コメント