【VPS初期構築ガイド⑥】fail2banによる不正アクセス防止と監査ログ（auditd）の活用
（AlmaLinux 10／X-SERVER VPS対応）
ここまででVPSの基本的な設定ができていますが、
セキュリティとしてはまだ不十分な状態です。
本章では不正アクセス検知のための、fail2banの導入方法と、auditdについて説明します。
⚙️ 前提条件
このシリーズは、初心者向けに必要最小限の内容でまとめています。
- 対応環境：AWS・さくらのVPS・X-SERVER VPSなど主要環境で再現可能
- 前提知識：Linuxの基本コマンドとvi操作を理解していること
- 想定ユーザー：Windowsユーザー（Macの場合はクライアント側の用語や実行コマンドが一部異なりますが、サーバー操作は同じ手順で実施可能）
💡 参考記事
基礎操作が不安な方は、こちらを先にチェックしておくと理解がスムーズです👇
👉 難しくない、慣れれるだけ！VPSで始めるLinuxサーバーの構築前に覚える基本コマンドとviの使い方
👉 前章：第5章：【VPS初期構築ガイド⑤】firewalld・SELinuxの基本理解と安全な設定
1.なぜ fail2ban が必要なのか
firewalld や SELinux を正しく設定していても、
「攻撃を受けているかどうか」までは分かりません。
VPSを公開した瞬間から、SSH には以下のような通信が常に飛んできます。
- 総当たり（ブルートフォース）によるログイン試行
- 存在しないユーザー名を使ったスキャン
- 古い脆弱な鍵方式を狙った自動攻撃
これらは 成功しなくてもログには残り続けます。
fail2ban は、
「成功しなかった攻撃」を可視化し、
一定回数を超えた相手を自動的に遮断する仕組み
です。
🔍 fail2ban で「できること」「できないこと」
✅ fail2ban ができること
- ログを監視し、不正なアクセスパターンを検知
- 一定回数以上失敗した IP を自動で遮断
- SSH / Web / Mail など、ログがあるサービスを対象にできる
- 攻撃の事実を「数字」で把握できる
❌ fail2ban ができないこと
- 0day 脆弱性の防御
- DDoS 攻撃の防止
- 正規ユーザーを装った高度な侵入検知
つまり fail2ban は
「最後の防御壁」ではなく「異常検知と初動対応」 です。
2.AWS・GCPでは不要なのか？
結論から言うと、
クラウドでも fail2ban の考え方は必要
ただし「実装場所」が変わります。
AWS / GCP で外部的にできること
- セキュリティグループ / VPC Firewall によるIP制限
- WAF による Web 攻撃対策
- SSH を踏み台経由に限定する設計
これらは 入口で防ぐ仕組み です。
VPS（X-SERVER / さくら等）の現実
- グローバルIPに直接SSHが公開される
- WAFや高度なFirewallは自前
- 侵入試行はOSレベルで受けるしかない
そのため VPS では、
OS自身が「怪しい挙動」を検知し、
自律的に遮断できる仕組み
として fail2ban が非常に有効になります。
3.firewalld・SELinux・fail2banの役割分担
このシリーズの思想に合わせて整理すると、以下の関係です。
| 機能 | 役割 |
|---|---|
| firewalld | 通してよい通信を制限する |
| SELinux | 通過後の「振る舞い」を制限する |
| fail2ban | 異常な試行を検知し遮断する |
| auditd | 何が起きたかを後から確認する |
fail2ban は
「ログがあって初めて意味を持つ」 点が重要です。
4.fail2banの導入(SSH用)
sudo dnf install -y fail2ban
sshd用の設定
sudo vi /etc/fail2ban/jail.d/sshd.local
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/secure
maxretry = 5
findtime = 600
bantime = 3600
banaction = firewallcmd-rich-rules
ignoreip = 127.0.0.1/8
ignoreipは追加してほしくないIP、結構重要です。
⚠️ なぜ ignoreip が重要なのか
ignoreip = 127.0.0.1/8
この設定は 必須 です。
理由は単純で、
- VPN
- 踏み台サーバー
- 自宅固定IP
などを登録していないと、
自分自身をBANする事故
が簡単に起きます。
特に SSH の設定変更直後は
ログイン失敗が連続しやすいため、
運用を始める前に必ず設定してください。
5. fail2ban と auditd を併用する理由
fail2ban は 「止める」 仕組みですが、
auditd は 「後から調べる」 仕組みです。
- fail2ban：今まさに起きている異常への対応
- auditd：侵入後・設定変更後の証跡確認
この2つを併用することで、
「防いだ」「起きた」「確認できる」
という 運用としてのセキュリティ が成立します。
6.まとめ fail2banは「安心材料」ではなく「観測装置」
fail2banを入れたから安全、ではありません。
- 何が起きているかを知る
- 異常を検知できる状態にする
- 手動対応が必要になる前に止める
この “観測と初動対応” が目的です。
守る前に、まず整える。
fail2banはその「整った状態」を維持するための道具です。
⚠️ 最後に：侵入されないサーバーは存在しない
侵入されないサーバーはありません。
重要なのは 「侵入を前提に、どう被害を最小化するか」 です。
- firewalld・SELinux で 通せるものを制限する
- fail2ban で 異常な試行を検知し、即座に遮断する
- auditd で 何が起きたかを後から追跡できるようにする
この3つが揃って、はじめて
「運用として成立するセキュリティ」 になります。
セキュリティとは、リスクをゼロにすることではありません。
リスクを限りなくゼロに近づけ、
侵入されても被害を最小化できる状態を維持すること
HTTPD / Nginx や FTP、MySQL、PostgreSQL など
Webサイトを運営するためには、他にも行う作業は多く存在します。
本シリーズでは、それらを行う前に
最低限やるべきこと を段階的に整理してきました。
機会があれば、これらの構成についても
本シリーズに併せて掲載していく予定です。
🔎 補足：自動化しないセキュリティは、いずれ破綻する
原理がわかったら、あとは IaC（Infrastructure as Code）を使って自動化することが必須です。
セキュリティリスクの最大の要因は「人間」です。
手作業による設定は、
- 設定漏れ
- 記憶違い
- 環境差分
- 作業者依存
といった ヒューマンエラー を必ず生みます。
一方で IaC を使えば、
- 同じ設定を 何度でも再現 できる
- 設定内容が コードとしてレビュー可能
- 変更履歴が 差分として残る
- 復旧や再構築が 数分で可能
という状態を作れます。
人が覚えなくていい状態を作ること
それ自体が、最も強力なセキュリティ対策です。
エンジニアの仕事は、知識を体系化し、再現可能な形に落とし込むことです。
次回以降はインフラから少し離れ、
設計（DDD）をテーマにしたシリーズ を掲載していく予定です。