VPS のセキュリティ対策として fail2ban を導入してから、毎月ログを分析しています。
2月は1ヵ月で 1,199件 もの不正アクセス遮断が記録されており、個人の小さなサーバーがこれほどの攻撃を受けていることに驚きました。
3月は途中で SSH のポート番号をデフォルトの 22番から別の番号に変更しました。
結果は驚くほど明確でした。ポート変更前後で、1日あたりの BAN 件数が 約99%減少したのです。
この記事では、実際の fail2ban ログをもとに以下の内容をまとめています。
- SSH ポート変更の前後でどれだけ攻撃が減ったか(数字で比較)
- なぜポート変更で攻撃が激減するのか、その仕組みの解説
- fail2ban をすり抜けながら37日間狙い続けたボットの正体
- 2ヵ月連続で同じ曜日パターンで攻撃が増減した不思議な傾向
- 前月に不具合だった
recidive(長期BAN)の修正結果
分析の前提条件
サーバー環境と fail2ban の設定は2月から変わっていません。
- 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)
3月全体のBAN件数
まず、2026年3月(31日間)の総 BAN 件数から確認します。
| 項目 | 件数 |
|---|---|
| 総BAN回数 | 781件 |
2月(1,199件)と比べると 約35%減 です。
ただし、この数字だけで「攻撃が減った」と判断するのは早計です。
3月はある出来事を境に、攻撃のパターンが劇的に変化しています。
SSHポート変更の前後でBAN件数を比較する
ポート変更の経緯
3月8日の深夜から翌9日の未明にかけて、SSH のリスニングポートをデフォルトの 22番から別の番号に変更しました。
ポート変更前後で BAN 件数を集計すると、以下のようになります。
| 期間 | 日数 | BAN件数 | 1日平均 |
|---|---|---|---|
| 変更前(3/1〜3/8) | 8日間 | 767件 | 95.9件 |
| 変更後(3/9〜3/31) | 23日間 | 14件 | 0.6件 |
1日あたりの BAN 件数が 95.9件 → 0.6件、約99%減少しています。

なぜポート変更でBAN件数が激減するのか
インターネット上の SSH 攻撃の大部分は、自動化されたボットによって行われています。
ボットは世界中の IP アドレスを次々とスキャンし、「ポート22番が開いているサーバー」を探します。見つかったら、自動でパスワードを総当たりする仕組みです。
SSH のポート番号を22番以外に変更すると、ボットはポートを見つけられず、攻撃対象のリストから外れます。
【ポート22のまま】
ボット → ポート22をスキャン → 発見 → ブルートフォース攻撃 → BAN
(毎日、同じことが繰り返される)
【ポートを変更後】
ボット → ポート22をスキャン → 「閉じている」→ スルー ✓
今回のログでも、ポート変更後は不特定多数のボットからの攻撃がほぼゼロになっています。
ポート変更は「万能な対策」ではない
ポート変更はとても効果的ですが、根本的なセキュリティ対策ではありません。
重要な注意点を2つ挙げます。
1. 本気でスキャンされれば特定される
ポート番号は秘密情報ではありません。全ポートをスキャンする攻撃者には、変更後のポートも特定されます。実際に、ポート変更後も特定の IP が低頻度ながら SSH 試行を続けていました(詳しくは後述します)。
2. 多層防御の一部として使うべき
「隠すことによるセキュリティ(Security through obscurity)」は、単体では脆弱です。SSH 鍵認証・fail2ban・ポート変更を組み合わせた多層防御が重要です。
週別のBAN件数
ポート変更の影響を、週別の集計でも確認できます。
| 週 | BAN件数 |
|---|---|
| 第1週(3/1〜3/7) | 709件 |
| 第2週(3/8〜3/14) | 59件 |
| 第3週(3/15〜3/21) | 10件 |
| 第4週(3/22〜3/28) | 1件 |
| 第5週(3/29〜3/31) | 2件 |
第1週から第2週にかけて急減し、第3週以降はほぼゼロに収束しています。

第2週(3/8〜3/14)に59件残っているのは、ポート変更直前の 3月8日に集中攻撃があったためです。3/8 は1日で58件の BAN が記録されており、前後の日と比べても突出した数字でした。ポート変更後の3/9以降は急速に落ち着いています。
【驚き】37日間、BAN されずに狙い続けたボットがいた
ここからは、ログを読んでいて最も驚いた事実を紹介します。
ポート変更後も、2つの IP アドレスが新しいポートを探し当てて SSH 試行を続けていました。
| IP アドレス | 初登場 | 最終確認 | 活動期間 | BAN 回数 |
|---|---|---|---|---|
185.156.73.233 | 2026/2/22 | 2026/3/31 | 37日間 | 0回 |
80.94.95.115 | 2026/2/22 | 2026/3/27 | 33日間 | 0回 |
BAN 回数がゼロ、つまり fail2ban に一度も引っかかっていません。
なぜ BAN されないのかというと、これらのボットは意図的に攻撃ペースを落としているからです。
fail2ban の sshd の設定は「10分間に3回失敗で BAN」です。これらの IP は、その閾値をわずかに下回るよう、20〜40分おきに1回だけ試行してきます。
2026-03-29 02:41 → 試行(検知)
2026-03-29 03:10 → 試行(検知)← 約30分後
2026-03-29 03:31 → 試行(検知)← 約20分後
(10分間に3回には達しないのでBANされない)
このような「閾値をすり抜けるスロー攻撃」は、fail2ban の弱点の一つです。
ポート番号を変えても諦めず、37日間にわたって延々と試し続けるボットがいるという事実は、VPS をインターネットに公開することの厳しさを改めて実感させてくれます。
185.156.73.233が2月22日に初登場してから3月31日まで37日間姿を消さなかったことは、ログを見て正直ぞっとしました。自分のサーバーが「リスト」に載ってしまったら、そう簡単には外れないのかもしれません。こういった執拗な攻撃に対しては、SSH 鍵認証を確実に設定しておくことがやはり最重要だと感じています。
【2ヵ月連続】月曜最多・火曜最少の不思議なパターン
2月のログ分析で「月曜日が最多、火曜日が最少」という曜日パターンを発見しました。
3月(ポート変更前の3/1〜3/8)でも同じ傾向が再現されたか、確認してみます。
| 曜日 | 2月(28日間) | 3月前半(3/1〜3/8) |
|---|---|---|
| 月曜日 | 281件(最多) | 195件(最多) |
| 火曜日 | 99件(最少) | 88件(最少) |
| 水曜日 | 153件 | 76件 |
| 木曜日 | 188件 | 48件 |
| 金曜日 | 159件 | 96件 |
| 土曜日 | 134件 | 110件 |
| 日曜日 | 185件 | 154件 |
2ヵ月連続で、月曜日が最多・火曜日が最少というまったく同じパターンが現れました。
これは偶然でしょうか。
私は、週末にターゲットリストを更新・整理し、月曜日の早朝に一斉攻撃を開始するボットネット(複数のサーバーを連携させた攻撃システム)の動作パターンではないかと推測しています。
人間ではなく、スクリプトが動いているはずのボットが、人間の週の始まりと同じリズムで攻撃を仕掛けてくるというのは、何とも不気味な話です。
これが本当にボットネットの「週次スケジュール」によるものなのかは確認しようがありませんが、2ヵ月続けて同じ曜日パターンが出たのは事実です。4月以降も記録を続けて、このパターンが続くかどうか観察したいと思っています。
2月との比較
2月と3月を数字で比べます。3月はポート変更という大きな変化があったため、ポート変更前の8日間を1ヵ月換算して比較します。
| 項目 | 2月(28日間) | 3月・変更前(換算) |
|---|---|---|
| 総BAN回数 | 1,199件 | 約2,970件 |
| 1日平均 | 約43件 | 約96件 |
nginx-wp BAN | 0件 | 0件 |
3月前半(ポート変更前)は、2月よりも攻撃が明らかに激しい状況でした。2月の第1週(2/1〜2/7)は277件でしたが、3月の第1週(3/1〜3/7)は709件と、約2.6倍になっています。
なぜ3月前半の攻撃がこれほど多かったのかは、正直わかりません。時期的な波なのか、自分のサーバーが何らかのリストに載ったのか。ただ「先月より減ったから安心」とはならない、というのが改めてわかりました。
nginx-wp(WordPress を狙った攻撃)の BAN 件数は、2月に引き続き3月も0件でした。SSH を狙う無差別攻撃と比べると、WordPress への攻撃は閾値に達するほどではない傾向が続いています。
【前月からの改善】recidiveが正常に機能した
前回の記事で発見した問題として、「3日以内に2回 BAN されたら1週間 BAN する」recidive の設定が機能していなかったことを報告しました。その後、原因を調査して設定を修正しています。
3月のログで確認したところ、recidive による1週間 BAN が 合計16件発動していました。2月の0件から改善されています。
教科書どおりの recidive 発動事例
特にわかりやすいのが、87.251.64.141 のケースです。
| 日時 | Jail | アクション |
|---|---|---|
| 3/30 03:18 | sshd | Ban(24時間) |
| 3/31 03:18 | sshd | Unban |
| 3/31 05:12 | sshd | Ban(24時間・再BAN) |
| 3/31 05:12 | recidive | Ban(1週間) |
Unban からわずか約2時間後に再び攻撃を仕掛けてきたため、recidive が即座に反応して1週間 BAN に切り替えています。前月に「設定したはずのルールが機能していなかった」という問題でしたが、修正後は意図通りに動作していることを確認できました。
まとめ
3月のログ分析で得られた知見をまとめます。
ポート変更の効果は想像以上だった
SSH ポートをデフォルトの22番から変更したことで、1日平均の BAN 件数が 95.9件 → 0.6件(約99%減) になりました。ボットによる無差別スキャン攻撃の大部分を、設定変更1つで排除できたことになります。
それでも諦めないボットがいる
ポート変更後も、閾値をすり抜ける「スロー攻撃」を続けた IP が2つありました。37日間・33日間にわたって活動し続け、BAN は一度もされていません。SSH 鍵認証・fail2ban・ポート変更の多層防御が重要だと改めて感じています。
月曜最多・火曜最少のパターンが2ヵ月連続で再現
2月に続き3月も同じ曜日パターンが現れました。ボットネットの週次スケジュールによるものではないかと推測しています。
recidive が正常に機能した
前月の不具合を修正した結果、3月は16件の1週間 BAN が正常に発動しました。ツールは設定して終わりにせず、ログで動作を確認することの重要性を改めて感じました。



コメント