PR

【VPS】SSHポート変更でBAN件数が99%減?fail2banログ分析(2026年3月)

VPSのSSHポート変更により不正アクセス(fail2banのBAN件数)が約99%減少した様子を示すログ分析イラスト。サーバーとLinux端末、減少グラフでセキュリティ効果を可視化(2026年3月) VPS・RentalServer
この記事は約8分で読めます。
記事内に広告が含まれています。
スポンサーリンク

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%減少しています。

2026年3月の日別のBAN件数で、ポート番号を変更してからBAN件数が大きく減少している。

なぜポート変更で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週以降はほぼゼロに収束しています。

2026年3月の週別のBAN件数の棒グラフで第2週からBAN件数が大きく減少している。

第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.2332026/2/222026/3/3137日間0回
80.94.95.1152026/2/222026/3/2733日間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 BAN0件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:18sshdBan(24時間)
3/31 03:18sshdUnban
3/31 05:12sshdBan(24時間・再BAN)
3/31 05:12recidiveBan(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 が正常に発動しました。ツールは設定して終わりにせず、ログで動作を確認することの重要性を改めて感じました。

コメント

タイトルとURLをコピーしました