今回は、「VPSのセキュリティを段階的に高めていく」シリーズの続きとして、
fail2banを実運用する中で見えてくる
繰り返し攻撃への対策（recidive）と日常的な確認方法
について整理する記事です。
前回のfail2ban基本編では、
- fail2banの役割
- sshd jail を使った基本的なBAN
- まずは動かすための最小構成
について紹介しました。
今回はその続きとして、
一度BANして終わりではない攻撃に、どう向き合うかを考えます。
fail2banを運用して分かること
fail2banを導入すると、不正なログイン試行は確実にBANされるようになります。
しかし、しばらく運用していると、次のような状況に気づくことがあります。
- 同じIPアドレスが何度も現れる
- 時間を空けて再度攻撃してくる
- 一度のBANでは抑止にならない
これはfail2banが正しく動いていないのではなく、攻撃側がしつこいだけです。
この「しつこさ」に対応するための仕組みが、recidiveです。
recidiveとは何か
recidiveは、特定のサービス（sshdなど）を見るjailではありません。
- 過去にBANされた履歴を横断的に監視し
- 一定期間内に何度もBANされるIPを
- より長期間BANする
ための 再犯対策用のjail です。
つまり、
- 通常のjail：その場の異常を止める
- recidive：繰り返す異常をまとめて扱う
という役割分担になります。
fail2banのBAN設定の考え方
ここからは、fail2banのBAN設定について整理します。
重要なのは、「この数値が正解」というものは存在しないという前提です。
以下は、個人運用のVPSで現実的だと感じている一例です。
jail.local への設定記述
fail2banのカスタマイズは、jail.conf を直接編集せず、jail.local に記述します。
前回の記事で作成した jail.local を開き、通常BANおよび長期BANの設定を追記します。
sudo nano /etc/fail2ban/jail.local以降の設定例は、この jail.local に追記していきます。
通常BAN（sshd）の設定例
開いたjail.local に以下をそのまま記述します。
[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1hこの設定では、
- 10分間に5回失敗すると
- 1時間BANされる
という挙動になります。
一時的な操作ミスや、たまたまの認証失敗を過度に罰しない設定です。
長期BAN（recidive）の設定例
通常BANの設定の下に、以下をそのまま記述します。
[recidive]
enabled = true
maxretry = 5
findtime = 1d
bantime = 1wこちらは、
- 1日の間に何度もBANされるIPを
- 1週間BANする
という考え方です。
1回の異常ではなく、「繰り返す性質」を見るための設定になります。
なお、sshd や recidive が監視するログファイルは、fail2ban の標準設定であらかじめ定義されているため、個別のログパス指定は行っていません。
fail2banの再起動
設定が終わったら、fail2banを再起動します。
sudo systemctl restart fail2banなぜ、いきなり永続BANにしないのか
1週間のBANではなく、「永続BANにした方が良いのでは？」と感じるかもしれません。
しかし、個人運用のVPSでは、いきなり永続BAN（ずっと遮断し続ける）にする前に、いくつか確認しておきたい点があります。
まず、攻撃してくるIPアドレスは「固定」とは限りません。プロバイダーや回線の都合でIPが変わったり、同じ攻撃者でも別のIPに切り替えてくることがあります。
そのため、あるIPを永久に止めても効果が続くとは限らず、終わりのない対策になりがちです。
次に、誤検知のリスクです。
たとえば自分の操作ミスでログインを何度か失敗したり、ネットワークが不安定で認証がやり直しになった結果、BAN対象になるケースも考えられます。
個人運用ではアクセス元が限られるため、自分のIPを永続BANしてしまうと、復旧の手間が一気に増えます。
最後に、運用の戻しづらさです。
永続BANは「何を・なぜ止めたか」が分からなくなりやすく、後から設定を整理しにくい傾向があります。
特にiptablesを直接触る形の永続BANは、トラブル時の切り分けも難しくなります。
そのためこの記事では、
- 通常のjailで短期BAN
- しつこい場合にrecidiveで長期BAN
という 段階的な対応 を基本にします。
この方が「やりすぎず、でも放置しない」個人運用に向いた設計だと考えています。
ここまでで得られる安心感
通常BANと長期BANを設定することで、
- 単発の不正アクセスは自動BAN
- 繰り返す攻撃は長期BAN
- 常に人が見ていなくても抑止が効く
という状態になります。
完全に防げるわけではありませんが、放置している状態ではありません。
この点が、日常運用における大きな安心材料になります。
日常的にfail2banの状況を確認する
fail2banは、設定して終わりのツールではありません。
とはいえ、毎日細かくログを追う必要もありません。
最低限、ここを見ておけば安心できる確認方法を整理します。
fail2banが稼働しているか確認する
sudo systemctl status fail2banactive (running) と表示されていれば正常です。
有効なjailを確認する
sudo fail2ban-client statussshd や recidive が表示されていれば、設定は正しく反映されています。
sshdのBAN状況を確認する
sudo fail2ban-client status sshd- Currently banned
- Total banned
を確認します。
Total banned が増えていれば、fail2banは実際に機能しています。
recidive（長期BAN）の状況を確認する
sudo fail2ban-client status recidiveここにIPが表示されていれば、短期BANから回復後に再度攻撃しているIPが存在しているという判断材料になります。
ログを確認する（必要なときだけ）
sudo less /var/log/fail2ban.log- 設定を変更した直後
- BANが想定より多いと感じたとき
など、必要な場面だけで十分です。
日常運用としてのおすすめ頻度
個人運用のVPSであれば、
- Daily
- fail2ban-client status を軽く確認
- Weekly
- sshd / recidive のBAN状況を確認
- 気になったとき
- fail2ban.log を確認
この程度で、無理なく運用できます。
まとめと次回予告
本記事では、
- fail2banのBAN設計の考え方
- recidiveによる再犯対策
- 日常的な確認方法
を整理しました。
これで、
- ufw
- SSH
- fail2ban（基本＋運用）
という、VPSセキュリティの基礎的な構成は一通り整いました。
次は、これらのログをもう少し俯瞰して見るために、Logwatchを使ったログの確認・分析に進んでいきます。
