Ubuntu 24.04でFail2banを導入しSSHボットを止める

Fail2ban の実際の動作

Fail2ban はログを読み取るデーモンです。SSH の認証メッセージを監視し、短い時間内に 1 つのアドレスから複数回の認証失敗が発生すると、ファイアウォールコマンドを実行して、そのアドレスを一定時間ブロックします。これが基本的な仕組みです。設定は 1 つのファイルに約 30 行記述するだけで、Ubuntu 24.04 では、編集しなくても保護が有効になる単一の apt コマンドでインストールできます。

Fail2ban の機能と限界を明確に理解してください。Fail2ban はユーザーを認証せず、暗号化も行いません。また、1 回だけのログイン試行を阻止するものではなく、同じ送信元からの繰り返し試行だけを阻止します。これはロックではなく、ノイズフィルターおよびレート制限機能です。ポート 22 に対する常時のバックグラウンドスキャンによって CPU、ネットワーク帯域幅、ログ領域が浪費されるのを防ぎ、攻撃者が 1 つのアドレスから順番に接続する必要がある場合に、その攻撃を遅らせることが目的です。

Fail2ban が置き換えられないもの

Fail2ban は第 3 層であり、第 1 層ではありません。サーバーが SSH パスワード認証を受け付ける状態のままだと、数千のアドレスに分散したボットネットが推測を続けられます。各アドレスの試行回数が ban のしきい値を下回り、ban が発動しないためです。これに対する本当の防御は、鍵のみの認証です。これにより、試行回数に関係なくパスワード推測が不可能になります。鍵のみの認証に Fail2ban を追加すると、2 つの効果があります。ログからブルートフォース攻撃によるノイズを減らせます。また、スキャナーを早期に排除し、ポートへの攻撃を止められます。Fail2ban は多層防御の一部として扱ってください。鍵認証とファイアウォールの後段に配置し、決してそれらの前段には置きません。

前提条件と Ubuntu 24.04 の実情

Ubuntu 24.04 を実行する VPS が必要です。root または sudo を使用でき、SSH がすでに動作している必要があります。認証方式には、できれば鍵認証を使用してください。Fail2ban のメモリ使用量は少なく、数十 MB 程度です。制限値の調整も必要ありません。

ここからは、古いガイドの多くが誤って説明している点です。長年、標準的な手順は「Fail2ban をインストールし、その後 backend = systemd を追加する」でした。これは、Ubuntu が /var/log/auth.log への書き込みを停止したためです。この説明は実際の変更に基づいています。現在のサーバーイメージやクラウドイメージには rsyslog が含まれていないため、SSH のログは systemd journal にのみ記録され、そのテキストファイルは存在しません。しかし Ubuntu 24.04 では、Fail2ban パッケージがこの変更に対応済みです。パッケージは /etc/fail2ban/jail.d/defaults-debian.conf を配置します。サーバーで実際に実行されるのは、upstream のデフォルトではなく、このファイルの設定です。

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

[sshd]
enabled = true

この内容は注意して読んでください。設定を変更する前に、2 つの点を確認できます。backend = systemd は、SSH jail が journal を読み取ることを意味します。そのため、auth.log がなくても問題ありません。banaction = nftables は、ban が nftables によって適用されることを意味します。nftables は Ubuntu 24.04 が実際に使用するファイアウォールであり、従来の iptables ではありません。また、[sshd] enabled = true は、最初の起動時から jail が有効であることを意味します。つまり、Ubuntu 24.04 の標準的な apt install fail2ban は、追加設定なしで SSH のブルートフォース攻撃を遮断します。主な作業は、その状態を確認し、ポリシーを調整し、自分自身を締め出さないようにすることです。

古い auth.log の問題は、現在でも次の 3 つの状況で発生します。pip ではなく apt を使用して Fail2ban をインストールしたため、defaults-debian.conf が存在しない場合です。systemd journal を読み取れない非特権コンテナ内で実行している場合も該当します。また、古いチュートリアルに従い、動作しているデフォルト設定を上書きする backend = auto を独自の jail.local に貼り付けた場合も該当します。それぞれの状態で発生する問題は、障害モードのセクションで具体的に説明します。

手順 1: インストールし、すでに禁止処理が行われていることを確認します

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04 には Fail2ban 1.0.2 が収録されています。パッケージは python3-systemd を必須依存関係として導入するため、journal バックエンドに必要なものはすべてそろっています。サービスは自動的に有効化され、起動します。

sudo systemctl status fail2ban

active (running) になることを確認します。次に、すでに機能している jail を確認します。

sudo fail2ban-client status sshd

公開 VPS を数分間でも到達可能な状態にしていると、失敗回数がすでに記録され、アドレスが禁止されていることがよくあります。インターネットからはポート 22 に対するスキャンが継続的に行われるためです。これで、標準設定が機能していることを確認できます。ここから行うのは、設定をゼロから構築することではなく、調整することです。

手順 2: jail.local を編集し、jail.conf は編集しない

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

そのため、必要な設定だけを上書きする小さな jail.local を作成し、jail.conf とパッケージ付属の jail.d/defaults-debian.conf は参照用として変更せずに残します。

手順 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 を生成し、ファイルに貼り付けることができます。

手順 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 の unit は実際には ssh.service ですが、同梱のフィルターは _COMM=sshd にも一致します。また、OpenSSH 24.04 は失敗を sshd というプロセス名で記録するため、一致します。この点が問題になるのは、新しい OpenSSH（9.8 以降）を使用している場合だけです。この場合、接続ごとのワーカーは sshd-session です。該当するケースについては、障害要因の説明で扱います。

ステップ 5: 実際に ban が適用されることを監視するか、テストのために強制的に適用します

公開 VPS では、実際の ban は数分以内に自動的に発生します。監視するには、ログを tail します。

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

待機せずに一連の処理を最後まで確認するには、自分のアドレスではなく、ドキュメント用のアドレスを手動で ban します。

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 action とファイアウォールの設定が一致していません。failure modes の nftables/iptables に関する注記を参照してください。

手順 6: 自分自身の ban を解除し、アクセス不能になった場合に復旧する

誤って、自分のアドレスを ban した場合は、次のコマンドで解除します。

sudo fail2ban-client set sshd unbanip 10.0.0.66

成功すると 1 が返ります。すべての jail の ban を解除するには、次を実行します。

sudo fail2ban-client unban --all

すでに開いている SSH セッションが助けになるとは考えないでください。nftables の ban は、確立済みの接続を含め、ban されたアドレスから port 22 へのすべてのパケットを拒否します。そのため、既存のセッションも ban が適用された時点で停止します。自分自身を ban し、ignoreip エントリがない場合は、ban の期限が切れるまでアクセスできません。SSH を経由しない VNC または serial の provider の web console から復旧し、bantime が経過するまで待つか、そこで ban を解除するコマンドを実行してください。

手順 7: BAN を永続化し、段階的に強化する

Fail2ban は有効な BAN を /var/lib/fail2ban/fail2ban.sqlite3 の小さな SQLite データベースに保持するため、サービスの再起動やシステムの再起動後も BAN は維持されます。すでに追加した bantime.increment の行により、同じ違反を繰り返す接続元には、約 1 時間から 1 週間へとおおむね倍増する、段階的に長い BAN が適用されます。

これに加えてシステム全体に「3 回で BAN」というポリシーを適用するには、Fail2ban に付属する recidive jail を使用します。この jail は自身の /var/log/fail2ban.log を監視し、すべての jail で繰り返し BAN されたアドレスに長時間の BAN を適用します。現在の [DEFAULT] は systemd バックエンドを使用しているため、この 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 が参照されますが、そこには対象の行が記録されません。

ステップ 8: 鍵認証のみの SSH と組み合わせ、さらに VPN を使用する

Fail2ban は、鍵認証と組み合わせて初めて効果を発揮します。/etc/ssh/sshd_config.d/ 配下の drop-in ファイル（たとえば /etc/ssh/sshd_config.d/00-hardening.conf）で、次のように設定します。

PasswordAuthentication no
KbdInteractiveAuthentication no

次に sudo systemctl restart ssh。パスワード認証を無効にすると、ブルートフォース攻撃は成功しません。Fail2ban の役割は、ログのノイズを減らし、スキャナーを早期に排除することになります。さらに強固にするには、SSH をパブリックインターネットから完全に隔離します。自己ホスト型の WireGuard VPN の背後に SSH を配置し、ポート 22 へのアクセスをトンネル経由だけに制限します。到達できないポートに対してブルートフォース攻撃は実行できないため、Fail2ban は最前線ではなく、追加の防御策になります。

Fail2ban は SSH 専用ではありません。ログイン失敗を記録するサービスには、メールサーバー、nginx サイト、または 自己ホスト型の Vaultwarden パスワードマネージャーなど、いずれも jail を設定できます。Web ログインをクレデンシャルスタッフィングにさらしたくない場合に有効です。Web アプリを Let's Encrypt 証明書を使用する nginx サイトの背後に配置したら、SSH の jail が journal を参照するのと同じ方法で、アクセスログを Fail2ban のフィルターに指定します。

障害パターンと表示される正確な文字列

「sshd jail のログファイルが見つかりません」と表示され、Fail2ban が起動しない。 これは古い auth.log の問題です。Ubuntu 24.04 では、パッケージのデフォルト設定が上書きされている場合、pip を defaults-debian.conf なしでインストールした場合、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?

この「ソケットパス」の行は、Fail2ban が壊れていることを意味しません。1 つの jail がログを見つけられなかったため、Fail2ban が起動しなかったことを示しています。[DEFAULT] で backend = systemd を設定すると、Ubuntu パッケージがすでに設定しているため、両方のメッセージを同時に解消できます。

jail は有効だが、Total failed がまったく増えない。 デーモンは実行中で journal も読み込まれています。しかし、実際の失敗が journalctl -u ssh に蓄積しているのに、カウンターは 0 のままです。まず、明らかな原因を確認します。テスト元のアドレスが ignoreip に登録されているため、設計上、自分自身の失敗は除外されています。該当しない場合は、接続ごとのワーカーが sshd-session になっている OpenSSH ビルド（9.8 以降）を使用している可能性があります。この場合、journal _COMM は sshd-session であり、sshd ではないため、付属のマッチ条件に一致しません。[sshd] ブロックのマッチ条件を広げます。

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

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

自分自身を禁止した: Connection refused。 自分のアドレスを ignoreip に登録しないまま、ログインに数回失敗すると、次の状態になります。

ssh: connect to host 10.0.0.10 port 22: Connection refused

サイレントタイムアウトではなく接続が拒否されるのは、nftables action のデフォルトの reject verdict が機能しているためです。Step 6 と同じ方法で修正します。別の禁止されていないアドレスから開いたセッション、またはプロバイダーのコンソールを使って unban してください。禁止されたアドレスからすでに開いているセッションも停止します。その後、再発防止のため自分のアドレスを ignoreip に追加します。

Fail2ban ではアドレスが禁止済みと表示されるが、接続できてしまう。 status sshd のカウンターは増えるのに、そのアドレスから port 22 に到達できます。これは ban action と firewall の不一致です。Ubuntu 24.04 では、古いガイドからコピーした banaction = iptables-multiport で正常に動作する banaction = nftables を上書きしており、iptables 層がないサーバーで実行している場合にほぼ必ず発生します。fail2ban.log には次のように表示されます。

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

その上書き設定を削除し、パッケージに含まれる nftables action を使用します。ufw だけで firewall を管理し、禁止ルールを ufw に表示したい場合は、[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 を設定して、ban を Ubuntu の実際のファイアウォールで適用します。通常の 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 アドレスを unban するにはどうすればよいですか？

sudo fail2ban-client set sshd unbanip YOUR.IP.HERE を実行してください。成功すると 1 が返ります。すべての ban を解除するには sudo fail2ban-client unban --all を実行します。SSH から締め出された場合は、プロバイダーの Web コンソールまたは VNC コンソールを使って同じコマンドを実行してください。ban はポート 22 への、対象アドレスからのすべてのパケットを拒否するため、すでに確立しているセッションも停止します。その後、再び ban されないように、アドレスを ignoreip に追加してください。

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

jail.conf には Fail2ban の upstream のデフォルト設定が格納されています。パッケージのアップグレードごとに上書きされるため、ここでの変更はいずれ失われます。Debian/Ubuntu パッケージは、jail.d/defaults-debian.conf を通じて独自の設定を上書きレイヤーとして適用します。変更は jail.local に記述してください。このファイルは最後に読み込まれ、両方の設定より優先されます。また、アップグレードで変更されません。jail.conf は参照用の読み取り専用ファイルとして扱ってください。

Fail2ban は鍵ベースの SSH 認証を置き換えますか？

いいえ。Fail2ban は、1 つのアドレスから繰り返される認証失敗をレート制限します。各アドレスがしきい値未満に収まる、低速で分散した推測攻撃には効果がありません。鍵のみの認証（PasswordAuthentication no）を使えば、パスワード推測を直接不可能にできます。そのうえで Fail2ban によりログのノイズを減らし、スキャナーを早期に排除できます。両方を使用し、可能であれば SSH 自体をパブリックインターネットに公開しないでください。