Posted inネットワーキング

Fail2Ban: Linuxサーバーへのブルートフォース攻撃を自動遮断する

Networking tutorial - IT technology blog
Networking tutorial - IT technology blog

知らない間にサーバーが攻撃されている

今すぐSSH認証ログを確認してみてほしい:

grep 'Failed password' /var/log/auth.log | wc -l

インターネットに公開したばかりのVPSでは、数日以内——場合によっては数時間以内——にその数が数千件に達する。ボットネットはIPv4空間全体を常時スキャンし続け、脆弱なパスワードやデフォルト認証情報を探している。私が最後に新しいサーバーをセットアップしたとき、ファイアウォールの設定を終える前に3,000件以上のSSH認証失敗が記録されていた。

私はLinux本番サーバーの管理を長年行ってきた。SSHをブルートフォースから守ることは、新しいマシンをセットアップする際に最初に行う設定の一つだ——最後ではなく。対策方法はいくつかあるが、間違ったアプローチを選ぶと時間を無駄にするか、偽の安心感を生んでしまう。

ブルートフォース対策の選択肢

手動によるiptables / ufwルール

iptablesやufwを使ってIPを手動でブロックすることができる。高速で軽量だが、完全に静的だ。攻撃が発生する前にブロックすべきIPを把握しておく必要があり、本末転倒になってしまう。

ポートノッキング

秘密のポートシーケンスでSSHを隠す手法だ。理論上は賢いが、実運用では不便だ。出先でノックシーケンスを忘れたら自分のサーバーからロックアウトされる。複数人がアクセスするチーム環境でも使いにくい。

SSHのデフォルトポートを変更する

SSHをポート22から2222や8022などに変更することで、自動スキャンの大部分を排除できる。有効な補完的対策ではあるが、解決策にはならない。本気のスキャナーはフルポートスキャンを行う。真の防御策の補完として位置づけるべきで、代替としてではない。

Fail2Ban — 動的・自動バン

Fail2Banはログファイルをリアルタイムで監視する。同一IPからのログイン失敗が一定回数を超えると、そのIPを設定した期間ブロックするファイアウォールルールを自動で追加する。手動操作は不要。ログを見張るために夜更かしする必要もない。これが実際にスケールする手法だ。

Fail2Ban: 得意なことと限界

強み

  • 自動対応 — あなたが起きていなくても、気づいていなくても攻撃をブロックする。
  • 柔軟な設定 — 「ジェイル」を使ってSSH、Nginx、Apache、Postfixなど多数のサービスを保護できる。
  • ログベースの検知 — サービスが既に出力しているログをそのまま活用。追加エージェント不要。
  • 簡単なホワイトリスト設定 — 自分のIPを除外リストに追加して、誤ってロックアウトされないようにできる。
  • iptables、nftables、ufwと統合 — 既存のファイアウォールをそのまま使いながら組み込める。

実際の制限

  • 強力な認証の代替にはならない — パスワードではなくSSH鍵を使うこと。Fail2Banは時間を稼ぐだけで、脆弱な認証情報を安全にするわけではない。
  • 分散攻撃はすり抜ける — 1万台のIPを使ったボットネットが各IPから1〜2回ずつ試行する場合、バンはトリガーされない。その脅威にはCrowdSecやブロックリストベースのツールを検討すること。
  • ログローテーションの境界問題 — スキャン中にファイルがローテートされると、Fail2Banがエントリを見逃すことがある。実運用ではほとんど問題にならないが、知っておく価値はある。
  • IPv6には別途設定が必要 — デフォルトのセットアップの多くはIPv4のみをカバーしている。設定を明示的に確認すること。

推奨設定

SSHとWebスタックをカバーする標準的なLinuxサーバーで私が使っている設定はこちら:

  • 10分以内に5回失敗したらブロック。
  • 初回は1時間バン、recidiveジェイルで再犯者はエスカレートして24時間バン。
  • 他の設定を行う前に、まず自分の固定IPをホワイトリストに追加する。
  • SSH、Nginxの不正リクエスト、該当する場合はWordPressログインのジェイルを有効にする。
  • 新規バン時にメールアラートを送信 — 任意だが、後でログを確認する際に役立つ。

実装ガイド

ステップ1: Fail2Banをインストールする

Debian/Ubuntuの場合:

sudo apt update
sudo apt install fail2ban -y

RHEL/CentOS/Rocky Linuxの場合:

sudo dnf install epel-release -y
sudo dnf install fail2ban -y

ステップ2: ローカル設定ファイルを作成する

/etc/fail2ban/jail.confを直接編集してはいけない——アップデートで上書きされてしまう。代わりにローカルオーバーライドを作成すること:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

または、クリーンなカスタムファイルから始める:

sudo nano /etc/fail2ban/jail.d/custom.conf

ステップ3: SSHジェイルを設定する

custom.confに以下を追加する:

[DEFAULT]
# 自分のIPをホワイトリストに追加 — 実際のIPに置き換えること
ignoreip = 127.0.0.1/8 ::1 YOUR.STATIC.IP.HERE

# バン検索ウィンドウ: 失敗を何秒前まで遡って検索するか
findtime = 600

# バンするまでの失敗回数
maxretry = 5

# バン期間（秒）: 3600 = 1時間
bantime = 3600

[sshd]
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

ステップ4: Recidiveジェイルを追加する（再犯者向け）

このジェイルは私には欠かせない。最初のバンが切れた後に戻ってくるIPを捕捉し、1時間という甘い処罰の代わりに24時間ブロックを課す:

[recidive]
enabled = true
logpath = /var/log/fail2ban.log
banaction = iptables-allports
bantime = 86400  ; 24時間
findtime = 86400
maxretry = 3

ステップ5: サービスを有効化して起動する

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

ステップ6: 動作確認

ジェイルのステータスを確認する:

sudo fail2ban-client status
sudo fail2ban-client status sshd

出力例:

ジェイルのステータス: sshd
|- フィルター
|  |- 現在の失敗数: 3
|  |- 合計失敗数: 47
|  `- ファイルリスト: /var/log/auth.log
`- アクション
   |- 現在のバン数: 2
   |- 合計バン数: 11
   `- バン済みIPリスト: 103.45.67.89 185.220.101.12

ステップ7: IPを手動でアンバンする（必要な場合）

正規ユーザー——あるいは自分自身——がロックアウトされてしまった場合:

sudo fail2ban-client set sshd unbanip 103.45.67.89

オプション: Nginxを不正リクエストから保護する

Webサーバーを運用している場合、これらのジェイルを追加する:

[nginx-http-auth]
enabled = true
port = http,https
logpath = /var/log/nginx/error.log

[nginx-botsearch]
enabled = true
port = http,https
logpath = /var/log/nginx/access.log
maxretry = 2

実体験から学んだヒント

これらは理論上の警告ではない。ほとんどが本番環境での実際のインシデントや、もう少しで大事になりそうだった経験から得たものだ。

  • まず自分のIPをホワイトリストに追加する — テストや設定の強化を行う前に。リモートサーバーから自分がロックアウトされたことは一度ではない。クライアントが待っている深夜2時のその体験は、決して楽しくない。
  • SSH鍵認証と組み合わせる。 /etc/ssh/sshd_configでPasswordAuthentication noを設定してパスワードログインを無効化する。その時点でFail2Banは主要な防御策ではなく、安全網になる。
  • リアルタイムでログを監視してサーバーへの攻撃を正確に把握する: sudo tail -f /var/log/fail2ban.log
  • カスタムジェイルをデプロイする前にフィルターのregexをテストする: sudo fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf
  • トラフィックの多いサーバーでは、maxretryを10に増やすかbantimeを短くする。積極的なバンは共有IPの背後にいる正規ユーザーを捕捉してしまうことがある——企業のNATが最も一般的な原因だ。

Fail2Banが実際にブロックしているものを確認する

Fail2Banが追加したファイアウォールルールを正確に確認したい場合は実行する:

sudo iptables -L f2b-sshd -n --line-numbers

nftablesを使った新しいシステムの場合:

sudo nft list ruleset | grep -A5 fail2ban

Fail2Banはすべての攻撃を止められない——そんなツールは存在しない。しかし、ノイズを劇的に減らし、パスワード認証サービスを保護し、誰があなたのサーバーを探っているかを明確に把握できるようにしてくれる。設定して環境に合わせてチューニングすれば、あなたが眠っている間も静かにその役割を果たし続ける。

Share:
Tags: