【VPS】fail2banのfindtimeを変えたら、攻撃が翌日97%減った話（2026年6月ログ分析）

これまでの VPS セキュリティ強化シリーズをまとめたページはこちらです。

【VPSセキュリティ実践まとめ】Ubuntu Serverを段階的に安全にする設定ガイド

個人運用のVPSを安全に保つためのセキュリティ設定のまとめページです。Ubuntu Serverを対象に、ファイアウォール(ufw)からSSHの安全対策、fail2banによる自動防御まで、初心者が無理なく段階的に進められる実践手順を解説します。

lifework-blog.com

2026/03/08

前回の記事はこちらです。

【VPS】fail2banだけでは見えない攻撃があった——LogWatchとの照合で判明したこと（2026年5月・3ヵ月比較）

fail2ban の BAN 件数は5件でも、月末に Web 攻撃が1日44件急増していました。LogWatch との照合で fail2ban だけでは見えない攻撃の実態が分かった2026年5月の VPS ログ分析レポートです。3ヵ月の推移データ・攻撃者の試行ユーザー名・スロー攻撃ボットのその後も掲載。

lifework-blog.com

2026/06/12

4月・5月と、2ヵ月連続で月間 BAN 件数が「5件」でした。

同じ数字が2ヵ月続いたので、正直なところ「もうこのサーバーへの攻撃は落ち着いたのかもしれない」と思い始めていました。

その油断は、6月のログを開いた瞬間に崩れました。

月間 BAN 件数、157件。

5月の5件から、約31倍です。

ただし、慌てて対策を取る前に立ち止まって考えてみると、この「157件」という数字はそのまま鵜呑みにできるものではありませんでした。中身を詳しく見ていくと、まったく違う姿が見えてきたのです。

この記事では、6月に何が起きていたのかを、実際のログデータをもとに解説します。

この記事で分かること

• BAN 件数が31倍になった本当の理由（「平均」を鵜呑みにしてはいけない話）
• fail2ban の findtime（時間窓の設定）を変更したら、翌日から攻撃が激減した実例
• 新しく追加した監視ルール「nginx-env-scan」が初月からどれだけ働いたか
• LogWatch との照合で分かった、攻撃者の「試みるユーザー名」の変化
• 前回修正したはずの recidive（長期 BAN）で、再び気になる動きが見つかった話

1. 分析環境のおさらい

まず、今回の分析対象となるサーバー環境と、fail2ban の設定内容を整理します。

• OS： Ubuntu Server 24.04 LTS
• SSH ポート： 2026年3月に変更済み（詳細は過去記事参照）

fail2ban には「Jail（ジェイル）」と呼ばれる監視ルールをいくつか設定しています。
Jail とは、「どのログを見て」「何回失敗したら」「どれくらいの期間 BAN するか」をまとめた1つの監視単位のことです。
今回のサーバーで有効にしている Jail は以下の通りです。

sshd の設定にある「10分間に3回」「24時間以内に3回」という表現は、fail2ban の findtime（何分間・何時間の間に）と maxretry（何回失敗したら）という2つの設定値の組み合わせで決まります。
この2つのダイヤルをどう調整したかが、今回の記事の中心テーマになります。

2. BAN 157件の内訳——不正アクセスの実態は「たった4日間」の集中攻撃だった

まず、6月全体の BAN 件数を確認します。

「5件 → 157件」という数字だけを見ると、6月は1ヵ月を通してずっと攻撃を受け続けていたように見えます。

しかし、日別の内訳を見ると、まったく違う実態が浮かび上がりました。

フェーズ②（6/8〜6/10）とフェーズ④（6/30）を合わせると、わずか4日間で全体の約77% を占めていました。

言い換えると、6月の「平常運転」に近い日の BAN 件数は、これまでの4月・5月とそう変わらない水準だったということです。
「157件」という月間合計だけを見ると急増しているように見えますが、実態は「特定の数日間に起きた突発的な事件」 だったのです。

なお、5月の5件から6月の157件で「約31倍」という数字になりますが、これは前月の分母が5件と極端に小さいために倍率が大きく出ている面もあります。
倍率の大きさだけでなく、実数と内訳の両方を見ることが大切です。

6/8〜6/10：何が起きていたのか

6月8日（月）から3日間、sshd への攻撃が急増しました。
特に6月10日は Found（検知）件数が557件に達し、6月全体でもっとも激しい1日でした。

6/30：月末の大規模ボットネット攻撃

6月30日は1日だけで50件の BAN が発生しました。
BAN された IP を確認すると、103.171.69.186・103.171.69.187・103.171.69.188 のように、末尾の数字が連続した IP アドレスが複数含まれていました。

このように IP アドレスの一部（ここでは末尾の数字）が連続しているケースは、同じ組織が管理する複数のサーバーやクラウドインスタンスから、同時にアクセスしてきた可能性を示しています。
個別のボットがバラバラに攻撃してきたというよりも、ある程度組織的・計画的な攻撃だったと考えられます。

3. findtimeを変えたら、翌日から攻撃が激減した

6月のログの中で、もっとも印象的だったのがこの結果です。

何を変更したのか

6月11日、sshd Jail の findtime（検知の時間窓）を変更しました。

• 変更前：findtime = 600（600秒＝10分間に3回失敗したら BAN）
• 変更後：findtime = 86400（86400秒＝24時間以内に3回失敗したら BAN）

これまでの設定は「10分間に3回」でした。
攻撃者側からすると、10分間に2回だけ試して、11分待ってからまた2回試す、というように間隔を空ければ BAN を回避できてしまうという弱点がありました。

そこで、判定の時間軸を24時間に広げることで、「1日のうちに合計3回失敗したら BAN する」という、より厳しい条件に変更しました。

変更の手順（nano での編集方法）

同じ設定を試してみたい方向けに、実際の変更手順を紹介します。

まず、fail2ban の設定ファイルを nano エディタで開きます。

sudo nano /etc/fail2ban/jail.local

ファイルの中から [sshd] セクションを見つけ、findtime の行を以下のように書き換えます。

変更前：

[sshd]
enabled  = true
findtime = 600
maxretry = 3
bantime  = 86400

変更後：

[sshd]
enabled  = true
findtime = 86400
maxretry = 3
bantime  = 86400

書き換えが終わったら、Ctrl + O （保存）→ Enter （ファイル名確定）→ Ctrl + X （nano の終了）の順にキーを押します。

最後に、変更を反映させるため fail2ban のサービスを再起動します。

sudo systemctl restart fail2ban

これで設定変更は完了です。

効果は「翌日」から出た

変更前後で、1日あたりの Found（検知）件数がどう変化したかを比較しました。

さらに、変更した6月11日の前後で日ごとの数字を比べると、効果の出方がより鮮明になります。

6月10日に557件だった Found 件数が、変更翌日の6月12日には16件まで落ち込みました。
下落率にすると約97%減です。

「10分間に3回」から「24時間以内に3回」に変えただけで、攻撃者が閾値をすり抜けにくくなり、継続的な攻撃が事実上できなくなったと考えられます。

findtime の変更による効果がとても大きかったです。
10分間という閾値をすり抜けるように、ゆっくりと攻撃してくるボットもあるということにも驚きましたが、設定変更による効果の大きさにも驚きました。

4. 新入りの見張り番「nginx-env-scan」が初月から大活躍

6月14日、.env ファイルへのスキャン攻撃を専門に見張る新しい Jail 、nginx-env-scan を追加しました。

.env ファイルとは、Web アプリケーションが使うデータベースの接続情報や API キーなど、本来は外部に公開されるべきではない設定情報を書いておくファイルのことです。
攻撃者は /.env や /config/.env といった URL に次々とアクセスし、このファイルが誤って公開されていないかを探ってきます。

nginx-env-scan を追加した結果、初月（6/14〜6/30の17日間）だけで以下の実績となりました。

追加した翌日の6月15日には、早くも3件の BAN が発生しています。

この数字から分かるのは、.env ファイルを狙ったスキャン攻撃が、想像していた以上に日常的に来ていたということです。
これまでは nginx 側の設定で該当リクエストを 444（応答を返さず接続を切断する特殊なステータス）でブロックしていましたが、攻撃元の IP そのものを BAN する仕組みがなかったため、この Jail を追加するまでは同じ IP から何度もアクセスされ続けていた可能性があります。

5. LogWatch で分かった攻撃者の変化

前回（5月分）の記事から、fail2ban のログだけでなく LogWatch のレポートとも突き合わせる分析を始めました。今回もこの照合を実施しています。

試行ユーザー名が209種類に多様化

LogWatch の SSHD セクションから、SSH 接続の試行で使われたユーザー名を集計しました。

5月は「test・test1・ubuntu」という似たパターンのユーザー名が多く、同一の攻撃ツールが使われている可能性を紹介しました。
6月は一転して、ユニークなユーザー名の総数が 209種類 に増えています。

特に気になったのは、oracle・postgres という、データベース製品の初期ユーザー名を試すケースが上位に入ってきたことです。
SSH 経由でデータベースの初期アカウントを試す動きは、単なる無差別攻撃というよりも、サーバーを踏み台にしてデータベースへの侵入を狙っている可能性を示唆しています。

fail2ban には映らない Web 攻撃も継続

LogWatch の httpd セクションを確認したところ、6月は30日中29日で何らかの Web 攻撃（既知の攻撃パターンへの合致）が記録されていました。合計は163件です。

fail2ban の BAN 件数だけを見ていると、nginx-wp・nginx-limit-req・nginx-botsearch の3つの Jail はいずれも0件のままでした。
5月の記事でもお伝えした通り、「fail2ban の BAN 件数がゼロ」であることは「攻撃が来ていない」ことを意味しないという点を、6月も改めて確認する結果となりました。

6.【調査中】recidive が沈黙している件

6月のログを確認したところ、気になる状況が見つかりました。

• recidive の BAN 件数：0件
• 一方で、Unban 後に再び BAN された「出戻り」IP は 22件

3日以内に2回 BAN される条件を満たしていそうな IP が22件もあるのに、recidive が一度も発動していません。

ログを確認したところ、以下のようなエラーが記録されていました。

ERROR Command ['recidive'] has failed. Received Exception('Invalid command')

このエラーが6月中から断続的に発生していたのか、あるいは他の原因（fail2ban 再起動によるタイムラインの分断など）があるのかは、現時点では断定できません。
7月分のログと合わせて、原因調査を進める予定です。

まとめ

6月のログ分析で分かったことを整理します。

• BAN 件数は157件（5月比31倍）となったが、実態は6/8〜6/10と6/30のわずか4日間で全体の約77%を占める突発的な事件だった
• sshd の findtime を10分間から24時間に変更したところ、翌日には Found 件数が約97%減少した
• 新設した nginx-env-scan は初月から14件の BAN・322件の検知を記録し、.env スキャン攻撃が日常的に来ていることが裏付けられた
• LogWatch との照合で、攻撃者が試すユーザー名が209種類に多様化していることが分かった
• recidive（長期 BAN）が再び機能していない疑いがあり、7月に原因調査を行う

「BAN 件数が31倍」という数字だけを見ると身構えてしまいますが、中身を分解してみると「特定の数日間の出来事」と「日常的に効いている対策の成果」が混ざっていることが分かりました。
月次の合計だけで一喜一憂せず、日別・週別の推移まで見ることの大切さを、今回は強く感じました。

今日からできること

今回の分析を踏まえて、Ubuntu Server で VPS を運用している方に向けたチェックリストです。

• sshd Jail の findtime を見直し、短時間の閾値をすり抜ける攻撃に備える
• .env ファイルへのアクセスをブロックするだけでなく、専用の Jail を作って BAN 対象にする
• sudo fail2ban-client status recidive を定期的に実行し、意図通りに動作しているか確認する
• fail2ban の BAN 件数だけでなく、LogWatch など別のログも定期的に確認する

次回は、7月分の fail2ban ログ分析について解説します。
recidive の原因調査結果もあわせてお伝えする予定です。公開までしばらくお待ちください。