VPS のセキュリティ対策として fail2ban を導入してから、毎月ログを分析しています。
これまでの VPS セキュリティ強化シリーズをまとめたページはこちらです。
前回の記事はこちらです。
5月の fail2ban ログを開いて、最初に目に入った数字は「5」でした。
月間 BAN 件数が、5件。
4月もまったく同じ5件でした。
3月に SSH ポートを変更してから、低水準が2ヵ月連続で続いています。
今月は、これまでと少し違うことをしました。
fail2ban のログだけでなく、LogWatch のレポートと突き合わせてみたのです。
そうしたら、fail2ban には一切記録されていなかった攻撃が見えてきました。
「BAN 5件」という静かな数字の裏で、月末には1日44件もの Web 攻撃が来ていたのです。
この記事で分かること：
- SSH ポート変更の効果は2ヵ月後も維持されているか（3ヵ月の推移データ）
- LogWatch との照合で初めて分かった攻撃者の試行ユーザー名
- fail2ban が沈黙している間に来ていた Web 攻撃急増の実態
- 37日間 BAN を逃れ続けたスロー攻撃ボットのその後
- Ubuntu Server を運用している人が今日から確認できること
分析環境と「3層防御」の構造
サーバー環境と fail2ban の設定
分析対象の環境と設定をまとめます。
- OS： Ubuntu Server 24.04 LTS
- SSH ポート： 2026年3月8〜9日に22番から50022番に変更済み
- sshd Jail： 10分間に3回失敗で24時間 BAN
- nginx-wp Jail： 10分間に5回失敗で24時間 BAN
- recidive Jail： 3日以内に2回 BAN されたら1週間 BAN
- nginx-limit-req Jail： 4月から追加（Nginx リクエスト数制限違反を監視）
- nginx-botsearch Jail： 4月から追加（ボットのディレクトリスキャンを監視）
「BAN 5件」という数字が意味すること
毎月の BAN 件数を語る前に、このサーバーがどのような3層構造で守られているかを整理します。
攻撃者
↓
【UFW 手動ブロック】← 過去に問題のあった IP を永続ブロック（5月時点で19ルール）
↓（すり抜けたもののみ）
【fail2ban】← 新規の不審なアクセスを検知して24時間 BAN
↓（すり抜けたもののみ）
【SSH 鍵認証】← パスワード推測は最終的に無意味fail2ban が記録する「BAN 件数」は、UFW をすり抜けた新規 IP のうち fail2ban の閾値に達したものだけです。
UFW によって事前にブロックされた IP は fail2ban のログには一切現れません。
「今月の BAN 件数は5件」という数字は、この前提を踏まえた上で読む必要があります。
5月の fail2ban ログ基本集計（3ヵ月比較）
BAN 件数の推移——ポート変更の効果は2ヵ月後も続いているか
3月に SSH ポートをデフォルトの22番から変更してから、BAN 件数には劇的な変化がありました。
変更前後から5月までの推移です。
| 期間 | BAN 件数 | 1日平均 |
|---|---|---|
| 3月・変更前（3/1〜3/8、8日間） | 767件 | 95.9件/日 |
| 3月・変更後（3/9〜3/31、23日間） | 14件 | 0.6件/日 |
| 4月（30日間） | 5件 | 0.2件/日 |
| 5月（31日間） | 5件 | 0.2件/日 |
この結果を見てあらためて SSH ポートの変更は、セキュリティ効果が高いことがわかります。
4月と5月の1日平均がまったく同じ0.2件/日でした。
ポート変更の効果が、2ヵ月が経過した後も維持されています。
試行検知（Found）件数も4月の31件から5月は23件へと減少しました。
BAN 件数だけでなく、攻撃の試みそのものが微減傾向にある可能性があります。
攻撃のパターン——前半2週間はほぼ完全ゼロ
5月は前半と後半でくっきりと分かれました。
5月1日から5月14日まで、BAN・Found ともにほぼゼロが続きました。
特に5/1〜5/10は10日間連続で BAN・Found がともにゼロという静かな期間でした。
攻撃が確認されたのは5月後半（5/15〜5/27）のみで、5件の BAN はすべてこの期間に集中しています。
BAN 件数ゼロの日は31日中26日（83.9%）でした。
LogWatch との照合——fail2ban に見えないものを見る
LogWatch とは
LogWatch は、サーバーのさまざまなログを集計してデイリーレポートを生成するツールです。
fail2ban が「どの IP を BAN・Unban したか」を記録するのに対して、LogWatch は SSH のログイン試行も含む幅広いサーバーログを横断的に集計します。
そのレポートには、どのユーザー名でログイン試行がされたか という情報も含まれています。
照合で何が見えたか
5月分の LogWatch レポート（全31日分）と fail2ban の分析結果を突き合わせたところ、以下の2点が新たに判明しました。
- 攻撃者が試みたユーザー名（fail2ban のログには記録されない情報）
- 月末の Web 攻撃急増（fail2ban には一切記録されない別種の攻撃）
なお、BAN の件数・IP・日時については fail2ban の分析と LogWatch の記録が完全に一致しており、5件というカウントが正確であることも確認できました。
発見①——攻撃者が試したユーザー名が初めて分かった
5件中3件が「test, test1, ubuntu」という同一パターン
LogWatch の SSHD セクションには、SSH 接続の失敗試行で使われたユーザー名が記録されています。
5月に BAN された5件について確認したところ、以下の結果でした。
| BAN された IP | 試行したユーザー名 |
|---|---|
| 164.90.143.148 | test, test1, ubuntu |
| 135.136.44.2 | guang, librenms, mmx |
| 165.245.172.225 | test, test1, ubuntu |
| 57.128.216.119 | chenjw, ubuntuserver, user1 |
| 165.245.164.41 | test, test1, ubuntu |
5件中3件（60%）が「test, test1, ubuntu」というまったく同じユーザー名を試していました。
「test」「ubuntu」は Ubuntu Server の初期状態や作業用として作成されやすいユーザー名です。
攻撃者がこれらを試すのは、実際に存在する確率が比較的高いからだと考えられます。
同一ボットネットが1週間後に別 IP で再挑戦してきた可能性
BAN された IP のうち、以下の2件が特に気になりました。
- 5月22日 BAN：
165.245.172.225（試行ユーザー名：test, test1, ubuntu） - 5月27日 BAN：
165.245.164.41（試行ユーザー名：test, test1, ubuntu）
この2件は試行ユーザー名がまったく同じで、同じ /16 サブネット（165.245.0.0/16）内から5日違いで来ています。
偶然の一致とは考えにくい状況ですが、同一の /16 帯域には無関係の利用者が複数存在することもあるため、同一組織による攻撃と断言はできません。
「同じ攻撃ツールが使われた可能性を示す2件」という見方が適切です。
同じ相手が IP を変えて5日後に再挑戦してきた可能性があるというデータを見て、攻撃ツールが自動的に IP を切り替えて再試行する仕組みになっているのかもしれないと感じました。
Ubuntu Server を運用している人へのチェックポイント
今回の分析から、以下の点を確認しておくことをお勧めします。
① test・ubuntu ユーザーが存在しないか確認する
次のコマンドを実行します。
grep "^test:\|^ubuntu:" /etc/passwdtest または ubuntu というユーザーが表示された場合、不要であれば削除するか、SSH ログインを禁止しておくことを検討してください。
② SSH でログインできるユーザーを明示的に制限する
/etc/ssh/sshd_config に AllowUsers を追記することで、許可したユーザー以外への SSH ログイン試行を制限できます。
現在の設定は次のコマンドで確認できます。
sudo grep "^AllowUsers" /etc/ssh/sshd_config何も返ってこない場合は、設定がされていない状態です。
発見②——fail2ban が「5件」の間に、Web へ44件の攻撃が来ていた
月末に突然始まった Web 攻撃急増
fail2ban の BAN 件数は5月を通じて5件でした。
ところが LogWatch の httpd セクションを確認すると、月末に以下のような数字が出ていました。
| 日付 | Web 攻撃件数 | 主な攻撃元 |
|---|---|---|
| 5月27日 | 37件（8ホスト） | 複数 |
| 5月28日 | 2件（2ホスト） | — |
| 5月29日 | 44件（5ホスト） | 34.12.117.172 から37件 |
| 5月30日 | 38件（4ホスト） | 34.19.225.193 から34件 |
参考として、5月前半の Web 攻撃件数は平均2〜6件/日でした。
5月27日から突然増え始め、5月29日・30日は1つの IP から30件以上の攻撃が来ていました。
この間、fail2ban の BAN 件数は5件のままです。
fail2ban の BAN 件数が「5件」のまま変わらない間に、こんな数の Web 攻撃が来ていたとは気づきませんでした。
LogWatch と照合するまで、fail2ban の設定を疑っていたほどです。
なぜ fail2ban に記録されないのか
fail2ban の各 Jail は監視対象が決まっています。
sshdJail は SSH 接続の失敗ログインを監視するnginx-limit-reqJail は Nginx へのリクエスト数制限違反を監視するnginx-botsearchJail はボットのディレクトリスキャンを監視する
今回の Web 攻撃は CGI スクリプトの脆弱性やシェルコマンドインジェクションを狙ったもので、nginx-limit-req・nginx-botsearch の監視範囲に近いものです。
ただし設定した閾値には達しなかったため、BAN は発生しませんでした。
fail2ban の BAN 件数は「各 Jail の閾値を超えた新規 IP の数」に過ぎません。
Web 攻撃自体は来ていたものの、BAN の条件を満たさなかっただけ、ということです。
今後の対応の検討
月末 Web 攻撃の主犯 IP（34.12.117.172）は、分析後に UFW で手動ブロック済みです。
nginx-limit-req・nginx-botsearch は4月の導入から2ヵ月間 BAN 件数がゼロです。
今回の月末 Web 攻撃急増と合わせて考えると、設定した閾値が実際の攻撃パターンと合っていない可能性があります。
6月以降の LogWatch レポートを見ながら、閾値の見直しを検討しようと思います。
3ヵ月の伏線回収
スロー攻撃ボット2体の「その後」
3月の記事で、fail2ban の閾値をすり抜けながら37日間・33日間にわたって活動し続けた2体のスロー攻撃ボットを紹介しました。
3月末に UFW で手動ブロックを実施した後、4月・5月の fail2ban ログへの登場はゼロでした。
| IP | 活動期間 | 4月 | 5月 |
|---|---|---|---|
| 185.156.73.233 | 37日間（BAN 0回） | fail2ban に検知なし | fail2ban に検知なし |
| 80.94.95.115 | 33日間（BAN 0回） | fail2ban に検知なし | fail2ban に検知なし |
UFW でブロック後、fail2ban のログから2ヵ月間完全に姿を消しました。
ただし「消えた」のは fail2ban の目線での話です。
UFW はパケットを受け取った時点で無言で破棄するため、「このサーバーへのアクセスを諦めた」のか「今も来ているが UFW が静かに弾いている」のかは、fail2ban のログからは判断できません。
37日間執念深く続けていたボットが UFW ブロック後は音沙汰ありません。
封じ込め完了と言いたいところですが、本当に諦めたのかは分かりません。
「月曜最多パターン」は4ヵ月目で崩れた
2月・3月・4月と3ヵ月連続して「月曜が BAN 最多・火曜が最少」というパターンが続いていました。
5月は、このパターンが崩れました。
5月の月曜は BAN 0件・Found 1件。代わりに水曜と金曜がそれぞれ2件で最多になりました。
ただし5月の総 BAN 件数は5件です。
この件数では曜日別に統計的な差を語ることは難しく、「パターンが崩れた」というより「母数が少なすぎて傾向が見えにくい」と解釈するのが適切だと思います。
3ヵ月連続していた月曜パターンは、BAN 件数が多かった時期のデータによるものでした。
ポート変更後は件数が激減したため、同じ分析手法では傾向を読み取りにくくなっています。
まとめ
5月の分析を振り返ります。
- BAN 件数は5件（4月と同数）。1日平均 0.2件/日の水準が2ヵ月連続で維持された
- LogWatch との照合で、攻撃者の試行ユーザー名（test, test1, ubuntu）が初めて判明した
- 5件中3件が同一パターンのユーザー名を使用——同一ボットネットの可能性がある
- fail2ban が沈黙している間も、月末に1日44件の Web 攻撃が来ていた
- スロー攻撃ボット2体は UFW ブロック後、4〜5月の2ヵ月間 fail2ban ログに現れなかった
今回気づいたのは、fail2ban のログだけでは見えていないことがある という点です。
BAN 件数が少ない月は「静かな月だった」と思いがちですが、別の種類の攻撃が来ていた可能性があります。
fail2ban と LogWatch を組み合わせることで、より実態に近い全体像が見えてきます。
セキュリティ自体は、鍵認証や SSH ポートの変更だけでもかなりのレベルになります。
攻撃の特徴や傾向を知るという意味では、fail2ban や LogWatch などの複数のツールを組み合わせることで、全体像が理解できることを強く感じました。
今後も分析を続けて、面白い情報があれば、ご紹介したいと思います。
Ubuntu Server を VPS で運用している方に向けて、今回の分析から実行できることをまとめます。
testユーザーやubuntuユーザーが不要であれば削除または SSH ログイン禁止にするAllowUsersで SSH ログインできるユーザーを明示的に制限する- fail2ban の BAN 件数と合わせて、LogWatch の httpd セクションも定期的に確認する
- BAN 後の IP は UFW に手動追加することで、再登場の可能性を減らせる
次回は6月分の fail2ban ログ分析について解説します。
公開までしばらくお待ちください。
コメント