Ubuntu 24.04でFail2banをインストールしてSSHを守る方法

Fail2ban の実際の動作

Fail2ban はログを読み取るデーモンです。SSH の認証メッセージを監視し、短期間に同一アドレスから複数回の失敗が検知されると、ファイアウォールコマンドを実行してそのアドレスを一定期間ブロックします。これが基本的な仕組みです。設定は 1 つのファイル内の約 30 行で構成されます。Ubuntu 24.04 では、apt コマンド 1 つでインストールが完了し、設定を変更する前から保護が開始されます。

Fail2ban の機能と限界を正しく理解してください。Fail2ban は認証を行わず、暗号化も行いません。また、単発の執拗なログイン試行を阻止することもできません。阻止できるのは、同一ソースからの繰り返される試行のみです。Fail2ban は「鍵」ではなく、ノイズフィルタおよびレートリミッターです。その役割は、ポート 22 への絶え間ないスキャンによる CPU、帯域幅、およびログ容量の浪費を防ぐこと、そして単一のアドレスからしか攻撃できないように攻撃者のペースを落とすことです。

Fail2ban で代替できないもの

Fail2ban は第3層の防御であり、第1層ではありません。サーバーが依然として SSH パスワードを受け付ける設定の場合、数千の IP アドレスに分散したボットネットによる攻撃を防げません。各アドレスが ban 閾値に達しない限り、攻撃は継続されます。これに対する真の防御策は key-only authentication です。これを使用すれば、試行回数に関わらずパスワードの推測攻撃は不可能になります。key-only authentication と併用する Fail2ban には、2つの利点があります。ログから brute-force のノイズを排除すること、およびスキャナーを早期に排除してポートへの攻撃を停止させることです。Fail2ban は defence in depth（多層防御）として考えてください。これは key authentication と firewall の背後で機能するものであり、それらの前置されるものではありません。

前提条件と Ubuntu 24.04 の実態

root または sudo 権限を持ち、SSH が動作している Ubuntu 24.04 の VPS が必要です。SSH は鍵認証を使用することが推奨されます。Fail2ban のリソース消費は少なく、数MB程度の RAM しか使用せず、制限値の調整も不要です。

ここで、古いガイドに共通する誤りを説明します。長年、「Fail2ban をインストールした後、backend = systemd を追加する」というアドバイスがありました。これは Ubuntu が /var/log/auth.log の書き込みを停止したためです。このアドバイスは、実際の変更に基づいています。最新のサーバーやクラウドイメージには rsyslog が含まれておらず、SSH ログは systemd journal にのみ出力されるため、テキストファイルは存在しません。しかし、Ubuntu 24.04 の Fail2ban パッケージは、この変更に既に対応しています。パッケージをインストールすると /etc/fail2ban/jail.d/defaults-debian.conf が適用されます。サーバーが実際に使用するのは、アップストリームのデフォルト設定ではなく、このファイルです。

[DEFAULT]
banaction = nftables
banaction_allports = nftables[type=allports]
backend = systemd

[sshd]
enabled = true

作業を始める前に、以下の点を確認してください。backend = systemd により、SSH jail は journal を読み取ります。したがって、auth.log が存在しなくても問題ありません。banaction = nftables により、ban は nftables を介して実行されます。これは Ubuntu 24.04 が標準で使用しているファイアウォールであり、従来の iptables ではありません。また、[sshd] enabled = true により、初回起動時から jail が有効になります。結論として、Ubuntu 24.04 の標準的な apt install fail2ban は、インストール直後から SSH のブルートフォース攻撃をブロックします。主な作業は、動作確認、ポリシーの調整、および自身がロックアウトされないように設定することです。

以下の3つの状況では、依然として古い auth.log の罠に陥る可能性があります。

• apt ではなく pip で Fail2ban をインストールしたため、defaults-debian.conf が存在しない。
• systemd journal が読み取れない、権限のないコンテナ内で実行している。
• 古いチュートリアルに従って、動作しているデフォルト設定を上書きするように backend = auto を jail.local に貼り付けた。

各ケースの詳細は、「failure-modes」セクションで説明しています。

Step 1: インストールと動作確認

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04にはFail2ban 1.0.2が搭載されています。このパッケージはpython3-systemdを必須の依存関係として含むため、journal backendに必要な条件はすべて揃っています。サービスは自動的に有効化され、起動します。

sudo systemctl status fail2ban

active (running)を確認してください。次に、すでに動作しているjailを確認します。

sudo fail2ban-client status sshd

公開されているVPSでは、公開から数分で失敗のカウントやIPアドレスの禁止が確認できることがよくあります。これは、インターネット上のスキャナーが常にport 22をスキャンしているためです。これが、デフォルト設定が機能している証拠です。ここからは、ゼロから構築するのではなく、設定を微調整していく作業になります。

Step 2: jail.local を編集してください。jail.conf は編集しないでください

Fail2ban は /etc/fail2ban/jail.conf にデフォルト設定を保持しています。そのファイルは編集しないでください。パッケージの apt upgrade がそのファイルを置き換える可能性があり、変更内容は警告なしに消失します。Fail2ban は決められた順序でファイルを読み込みます。最初に jail.conf、次に jail.d/ 内のすべてのファイル、最後に jail.local を読み込み、最後に読み込まれた値が適用されます。.local ファイルはユーザー専用であり、パッケージのアップグレードによって変更されることはありません。このルールは filters にも適用されます。*.local ファイルは、同梱されている filter.d/*.conf を上書きします。

必要な設定のみを上書きする小さな jail.local を作成してください。jail.conf とパッケージに含まれる jail.d/defaults-debian.conf は、参照用としてそのままにしておきます。

Step 3: /etc/fail2ban/jail.local を作成する

sudo nano /etc/fail2ban/jail.local

ignoreip 行のアドレスを自身のパブリックIPに変更して、以下の内容を書き込んでください：

[DEFAULT]
# Ubuntu 24.04 already sets these two in jail.d/defaults-debian.conf.
# Pinning them here documents the dependency and survives if that
# file is ever removed or changed by an upgrade.
backend   = systemd
banaction = nftables

# Ban for one hour ...
bantime  = 1h
# ... if an address fails ...
maxretry = 5
# ... 5 times within 10 minutes.
findtime = 10m

# Never ban these. PUT YOUR OWN IP HERE.
ignoreip = 127.0.0.1/8 ::1 10.0.0.24

# Longer bans for repeat offenders: 1h, 2h, 4h ... up to a week.
bantime.increment = true
bantime.maxtime   = 1w

[sshd]
enabled = true

各行の役割は以下の通りです：

• bantime、findtime、maxretry はポリシーの設定です。デフォルトの bantime は10分間ですが、1時間程度に設定するのが適切です。10分間に1つのアドレスから5回の失敗があると、BANされます。通常のユーザーは1、2回パスワードを打ち間違えますが、10分間に5回の失敗はスクリプトによる攻撃です。
• ignoreip は安全のための設定です。Fail2banによって自身がサーバーからロックアウトされるのを防ぐため、接続元となるパブリックアドレスをここに記述してください。IPアドレスが変動するホーム接続を使用している場合は、最後に説明するVPN方式を推奨しますが、この行を省略しないでください。
• bantime.increment = true により、BANの期間が繰り返されるたびに長くなります（1時間、2時間、4時間と、最大 bantime.maxtime まで）。繰り返し攻撃を試みるアドレスは、段階的にロックアウトされます。

サーバーではなく、SSH接続元のマシンから、ホワイトリストに登録すべきアドレスを確認してください：

curl -s ifconfig.me

ポートやBANポリシーに合わせて調整された jail.local をここで生成し、ファイルを編集する際に貼り付けてください：

Step 4: 再起動して journal が読み込まれているか確認する

sudo fail2ban-client -t
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

-t は最初に設定テストを実行します。そのため、jail.local にタイポがあると、サービスが起動しないままになるのではなく、ここでエラーが表示されます。正常な jail のステータスは以下の通りです。

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     14
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 1
   |- Total banned:     3
   `- Banned IP list:   10.0.0.66

Fail2ban が正しくログイン情報を読み取っていることを示す数値は Total failed です。この数値が 0 より大きい場合、または別のマシンから意図的にログインに失敗して数値が増加する場合、journal は正常に読み取られています。設定は完了です。もし、何度ログインに失敗しても 0 のままの場合（かつ、ignoreip のアドレスからテストしていないことが確実な場合）は、以下のトラブルシューティングを確認してください。

Journal matches の行にまだ sshd.service と表示されている点に注意してください。Ubuntu の SSH ユニットは実際には ssh.service ですが、付属の filter は _COMM=sshd にも一致します。また、OpenSSH 24.04 は sshd という名前のプロセスから失敗ログを出力するため、マッチングが機能します。この詳細は、新しい OpenSSH（9.8 以降、per-connection worker が sshd-session のもの）を使用している場合にのみ関係します。その場合は、以下のトラブルシューティングで対応可能です。

Step 5: 実際のBANを確認する、またはテスト用に手動でBANを実行する

パブリックなVPSであれば、数分以内に実際のBANが発生します。ログを確認するには、以下のコマンドを実行してください。

sudo tail -f /var/log/fail2ban.log

BANが発生した際のログは以下の通りです。

2026-07-15 10:31:40,502 fail2ban.filter  [812]: INFO    [sshd] Found 10.0.0.66 - 2026-07-15 10:31:40
2026-07-15 10:31:44,118 fail2ban.actions [812]: NOTICE  [sshd] Ban 10.0.0.66

待機せずに一連の動作を確認するには、ドキュメント用のIPアドレスを手動でBANしてください。自身のIPアドレスは絶対に指定しないでください。

sudo fail2ban-client set sshd banip 10.0.0.66

1 と表示され、fail2ban-client status sshd の Banned IP list にアドレスが追加されます。次に、ファイアウォールで実際にブロックされているか確認します。Ubuntu 24.04 では、iptables ではなく nftables が使用されます。

sudo nft list table inet f2b-table

10.0.0.66 を保持する addr-set-sshd という名前の set と、その set 内のソースを拒否する f2b-chain という chain が表示されます。fail2ban-client でアドレスがBANされていると表示されるのに、nft list に何も表示されない場合は、BANのアクションがファイアウォールの設定と一致していません。failure modes にある nftables/iptables に関する注意点を確認してください。

Step 6: 自分自身をアンバンし、ロックアウトされた場合の復旧手順

誤って自分自身のIPアドレスをバンした場合は、以下のコマンドで削除してください：

sudo fail2ban-client set sshd unbanip 10.0.0.66

成功すると 1 が返されます。すべてのjailに対してすべてのバンを解除するには、以下のコマンドを実行します：

sudo fail2ban-client unban --all

既存のSSHセッションが維持されるとは考えないでください。nftablesによるバンは、バンされたアドレスからport 22へのすべてのパケットを拒否します。これには確立済みの接続も含まれるため、バンが適用された瞬間にセッションは停止します。自分自身をバンし、かつ ignoreip のエントリがない場合、バンが期限切れになるまでロックアウトされます。その場合は、SSHを経由しないプロバイダーのウェブコンソール（VNCまたはシリアルコンソール）から復旧してください。そこで bantime の経過を待つか、アンバンコマンドを実行してください。

Step 7: 凍結（ban）の永続化と段階的強化

Fail2banは、アクティブなban情報を /var/lib/fail2ban/fail2ban.sqlite3 のSQLiteデータベースに保存します。これにより、サービスの再起動やシステムの再起動後もban情報は保持されます。既に追加した bantime.increment の行により、繰り返し違反を行うIPアドレスに対して、banの期間が段階的に延長されます。期間は1時間から約1週間まで、段階的に倍増していきます。

さらに、システム全体に「3回の違反」というポリシーを適用する場合、Fail2banには recidive jailが用意されています。このjailは自身の /var/log/fail2ban.log を監視し、すべてのjailで繰り返しbanされたアドレスに対して、長期のbanを適用します。[DEFAULT] が systemd backend を使用しているため、このjailが読み取るべきログファイルを明示的に指定してください。

[recidive]
enabled  = true
backend  = auto
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
maxretry = 5

logpath を明示的に指定した backend = auto では、recidive が fail2ban.log を読み取るようになります。Ban の行は、このログファイル内に記録されます。グローバルに設定した systemd のデフォルト設定では、ログが journal を指してしまい、正しく読み取れません。

Step 8: SSHの鍵認証との併用、およびVPNの利用

Fail2banは、鍵認証と併用することで真価を発揮します。/etc/ssh/sshd_config.d/内のドロップインファイル（例：/etc/ssh/sshd_config.d/00-hardening.conf）に以下を設定してください。

PasswordAuthentication no
KbdInteractiveAuthentication no

設定後、sudo systemctl restart sshを実行します。パスワード認証を無効にすれば、ブルートフォース攻撃は完全に防げます。この状態でのFail2banの役割は、ログのノイズを減らし、スキャナーを早期に排除することです。さらにセキュリティを高めるには、SSHをパブリックインターネットから完全に隔離してください。WireGuard VPNを使用してSSHを背後に配置し、ファイアウォールでport 22を制限して、トンネル経由でのみ応答するようにします。到達できないポートに対してブルートフォース攻撃は不可能です。これにより、Fail2banは第一防衛線ではなく、バックアップとしての役割を担います。

Fail2banの用途はSSHに限りません。ログイン失敗をログに記録するサービスであれば、何でもjail（監獄）として設定可能です。メールサーバー、nginxサイト、あるいはcredential stuffing（リスト型攻撃）を避けたいセルフホストのVaultwardenパスワードマネージャーなどが該当します。WebアプリをLet's Encrypt証明書を適用したnginxサイトの背後に配置した場合は、SSH jailがjournalを参照するように、そのaccess logをFail2banのfilterに向けてください。

発生するエラーメッセージと失敗のパターン

"Have not found any log file for sshd jail" と表示され、Fail2ban が起動しない。 これは旧来の auth.log 問題です。Ubuntu 24.04 では、パッケージのデフォルト設定が上書きされている場合にのみ発生します。具体的には、defaults-debian.conf が設定されていない pip インストール、journal が存在しないコンテナ、または jail.local に貼り付けられた誤った backend = auto が原因です。/var/log/auth.log がないファイルバックエンドを使用している場合、sshd jail がログを見つけられず、デーモン全体が停止します。fail2ban.log には以下が表示されます。

ERROR   Failed during configuration: Have not found any log file for sshd jail

このエラーは致命的であるため、サービスは起動しません。その結果、fail2ban-client status に以下の二次的な症状が報告されます。

ERROR  Failed to access socket path: /var/run/fail2ban/fail2ban.sock. Is fail2ban running?

"socket path" という行は、Fail2ban 自体が壊れていることを意味しません。1つの jail がログを見つけられなかったために、起動に失敗したことを意味します。[DEFAULT] 内の backend = systemd を設定することで（Ubuntu パッケージは既にこれを設定済みです）、両方のメッセージを同時に解決できます。

Jail は active だが Total failed が増えない。 デーモンは実行されており、journal も読み取られていますが、journalctl -u ssh で実際の失敗が蓄積している一方で、カウンターは 0 のままです。まず、明らかな原因を除外してください。ignoreip にリストされているアドレスからテストしている場合、仕様により自身の失敗は除外されます。それが原因でない場合、使用している OpenSSH のビルドにおいて、接続ごとのワーカーが sshd-session (9.8 以降) であり、その journal _COMM が sshd-session であって sshd ではないため、標準の match では検知できません。[sshd] ブロックの match 条件を広げてください。

[sshd]
enabled      = true
backend      = systemd
journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd + _COMM=sshd-session

再起動し、ignoreip に含まれないアドレスから意図的にログインに失敗させ、Total failed が上昇することを確認してください。

自分自身を BAN した場合: Connection refused。 自身のドレスを ignoreip から除外した状態で、ログインに数回失敗すると、以下の状態になります。

ssh: connect to host 10.0.0.10 port 22: Connection refused

タイムアウトせずに拒否されるのは、nftables のデフォルトの verdict である reject が機能しているためです。ステップ 6 の手順で修正してください。BAN されていない別のアドレスのセッション、またはプロバイダーのコンソールから unban を実行してください。BAN されたアドレスから既に開いているセッションは、凍結されたままになります。再発を防ぐため、自身のアドレスを ignoreip に追加してください。

Fail2ban はアドレスが BAN されていると表示するが、接続が可能。 status sshd のカウンターは増えていますが、そのアドレスで依然として port 22 に到達できます。これは ban-action と firewall の不一致が原因です。Ubuntu 24.04 では、iptables レイヤーのない環境で、古いガイドからコピーした banaction = iptables-multiport によって、動作していた banaction = nftables を上書きしたことがほとんどの原因です。fail2ban.log には以下が表示されます。

fail2ban.actions [812]: ERROR  Failed to execute ban jail 'sshd' action 'iptables-multiport'

その上書き設定を削除し、パッケージ標準の nftables action を使用してください。もし ufw でファイアウォールを完全に管理しており、BAN をそこに反映させたい場合は、[DEFAULT] で banaction = ufw を設定してください。再起動後、sudo nft list ruleset | grep f2b でルールが適用されていることを確認してください。

jail.local を編集した後、Fail2ban が起動しない。 タイポ（誤った見出しや不正な時刻値）があると、サービスは起動しません。実行前に設定ファイルのチェックを Fail2ban に要求してください。

sudo fail2ban-client -t

問題のあるファイル名と jail 名（例: Errors in jail 'sshd'. Skipping...）が表示されるため、推測することなく原因を修正できます。

FAQ

Ubuntu 24.04 の標準 Fail2ban は SSH 攻撃を実際に BAN するのか？

はい。このパッケージには /etc/fail2ban/jail.d/defaults-debian.conf が含まれています。これにより sshd jail が有効になり、backend = systemd が設定されて /var/log/auth.log の代わりに systemd journal を読み取ります。また、banaction = nftables によって Ubuntu の実際の firewall を通じて BAN が適用されます。標準の apt install fail2ban が初回起動時から SSH を保護します。sudo fail2ban-client status sshd で確認し、Total failed が 0 でないことを確認してください。

なぜ自分の環境で Fail2ban が何も BAN しないのか？

以下の 3 つの一般的な原因を順に確認してください。まず、ignoreip のアドレスからテストしている場合、設計上除外されます。次に、古いガイドの backend = auto を jail.local に貼り付けた場合、auth.log が存在しないイメージでは journal の読み取りに失敗します。あるいは、systemd journal が存在しないコンテナ内で実行している可能性があります。fail2ban-client status sshd 内の Total failed を確認してください。journalctl -u ssh で実際の失敗が記録されているのに数値が上がらない場合は、jail が誤った場所を読み取っています。

自分の IP アドレスの BAN を解除するには？

sudo fail2ban-client set sshd unbanip YOUR.IP.HERE を実行してください。成功すると 1 が返されます。すべての BAN をクリアするには sudo fail2ban-client unban --all を実行します。SSH からロックアウトされた場合は、プロバイダーの Web コンソールまたは VNC コンソールを使用して同じコマンドを実行してください。BAN はアドレスから port 22 へのすべてのパケットを拒否するため、既に確立されているセッションも切断されます。再発を防ぐには、アドレスを ignoreip に追加してください。

jail.conf と jail.local の違いは何か？

jail.conf には Fail2ban のアップストリームのデフォルト設定が含まれています。パッケージのアップグレード時に上書きされるため、ここを編集しても設定は失われます。Debian/Ubuntu のパッケージは、jail.d/defaults-debian.conf を介して独自の lavers を追加します。ユーザーの変更は jail.local に記述してください。これは最後に読み込まれるため、両方の設定よりも優先され、アップグレードの影響も受けません。jail.conf は参照用として、編集しないでください。

Fail2ban は鍵認証による SSH 認証に取って代わるものか？

いいえ。Fail2ban は単一のアドレスからの連続した失敗に対して rate-limit を適用します。各アドレスが閾値未満に収まるような、低速かつ分散型の攻撃には効果がありません。鍵認証のみ（PasswordAuthentication no）を使用すれば、パスワードの推測自体が不可能になります。その上で Fail2ban を使用すれば、ログのノイズを減らし、スキャナーを早期に排除できます。両方を併用し、理想的には SSH をパブリックインターネットから完全に遮断してください。