最近、ラズパイサーバに fail2ban を導入しました。

fail2ban とは、簡単に言えば SSH で複数回パスワード認証に失敗したり(対ブルートフォース攻撃)、Apache の HTTP(S) サーバで無効な URL に複数回アクセスしたり(対ディレクトリ・トラバーサル攻撃)したときに、IP アドレスごとファイアウォールでブロックしておくことで攻撃者によるアクセスを自動的に遮断するツールです。

せっかくだから SSH ハニーポットに fail2ban を適用し、ブルートフォース攻撃にどんな影響が現れるのか気になったので自分の環境で試してみました。

環境

  • Ubuntu 24.04.1 LTS
  • Raspberry Pi 5 (RAM 8GB)

背景

自分の環境では、既にブルートフォース攻撃対策で SSH パスワード認証は無効化して鍵交換方式 only にしていますし、ポート番号はデフォルトの 22 番以外に変更しています。HTTP サーバの方も自作 web API 関連のファイルを除いて全然何も置いていません。

しかし、今後どんな脆弱性がカーネルや各種アプリケーションに出てくるかわかりませんし、備えあれば憂いなしということで fail2ban を導入しました。

で、ただ fail2ban を導入して BAN IP が増えていく様を眺めるのもいいのですが、それだけじゃつまらないですね。本物の SSH サーバの方はパスワード認証を禁止にしているので、まともな bot ならブルートフォース攻撃の対象にはしないはずです。

ということで、わざと 22 番ポートに SSH ハニーポットを設置し、攻撃元からパスワード認証ができるように見せかけることで攻撃元 IP を BAN し続けたら、ブルートフォース攻撃にどんな変化が現れるのか?1日でどれだけ BAN IP が増えるのか?を検証していきたいと思います。

SSH ハニーポット

SSH ハニーポットはなんぞや?というと、偽物の SSH サーバです。攻撃者に対してあたかも SSH ポートが開放されていて、パスワード認証できるように見せかけることで、ブルートフォース攻撃におけるパスワード入力内容の傾向を探ったり、攻撃元 IP を記録したり、どんな手法で攻撃を仕掛けようとしてくるかをログから観察することができます。

SSH ハニーポットツールはいくつか公開されています。中にはログインに成功したように見せかけて偽物のシェルを表示させるものもあるようですが、今回は毎回パスワード認証に失敗するタイプのハニーポットツールを採用しました。

fail2ban

フィルタ定義

fail2ban はアクセスログなどを解析して失敗した回数を IP アドレスごとにカウントしていき、基準値に達したら BAN します。そのためアクセスログの解析用のフィルタを定義しなければなりません。

fail2ban には OpenSSH や Apache2 用のフィルタは用意されていますが、今回使う SSH ハニーポットは独自のフォーマットでアクセスログを記録していきますので、自分で用意する必要があります。

まず、ログファイルがこんな感じ(/var/log/sshpot_auth.log)。IP アドレスは伏せてあります。

2025-03-05 09:36:42	81.***.***.***	Supervisor	Supervisor	
2025-03-05 09:39:12	122.***.***.***	Operator	uploader	
2025-03-05 09:39:42	59.***.***.***	User	logon	
2025-03-05 09:41:50	49.***.***.***	Default	webadmin	
2025-03-05 09:47:28	60.***.***.***	Support	123abc	
2025-03-05 09:49:55	171.***.***.***	Supervisor	qwerty	
2025-03-05 09:51:08	218.***.***.***	Config	qwerty12	
2025-03-05 09:51:09	183.***.***.***	Config	asdfgh	
2025-03-05 09:52:03	74.***.***.***	Default	Default	
2025-03-05 09:58:29	80.***.***.***	Unknown	dietpi

フォーマットに落とし込むと

日付 [Tab] 時間 [Tab] IPアドレス [Tab] 試行ユーザ名 [Tab] 試行パスワード

という形です。

このログファイルに対応したフィルタを作成するため、新しいファイルを作成して下記のように定義し、/etc/fail2ban/filter.d/ssh-honeypot.conf として保存しておきました。

[Definition]
failregex =  ^.*\t<HOST>\t.*\t.*\t$
ignoreregex = 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16

failregex に対しては失敗したパターンのログを正規表現で示します。<HOST> は IP アドレスを指します。これは fail2ban が BAN すべき IP アドレスを抽出するための識別子です。

ignoreregex は除外する IP アドレスです。自分自身やローカル IP アドレスは除いておきます。

SSH ハニーポットを登録

/etc/fail2ban/jail.local にて jail に SSH ハニーポットのフィルタとログファイルの場所、その他設定を登録しておきます。

  • filter:フィルタ名
  • logpath:解析するログファイルの場所
  • maxentry:BAN する基準の試行回数
  • findtime:BAN する基準の観測時間(findtime 秒中に maxentry 回試行すると BAN)
  • logtimezone:ログファイルのタイムゾーン
  • datepattern:日時のパターン
[ssh-honeypot]
enabled = true
filter = ssh-honeypot
logpath = /var/log/sshpot_auth.log
maxretry = 3
findtime = 86400
logtimezone = UTC
datepattern = ^%%Y-%%m-%%d %%H:%%M:%%S

フィルタ名は先ほど作成したファイルから拡張子 .conf を除いたファイル名になります。

BAN の基準ですが、今回は「1日(86400秒)に3回試行したら BAN する」としました。登録当初はもっと短い時間(30分程度)に10回としていたのですが、1時間に1回ずつ試行する輩が現れたため条件を厳しくしました。

logtimezone は、今回使用した SSH ハニーポットが時刻を UTC で記録するため設定。時刻の記録がシステムのタイムゾーン通りであれば個々の設定は不要なはずです。

観察結果

SSH ハニーポットと fail2ban を起動して放置し、早2ヶ月弱。どんな感じで引っかかったか見てみましょう。

fail2ban のログを見てみる

まず、BAN IP 数と合計の試行回数がこちら。

スクリーンショット 2025-03-05 23.35.33のコピー

わずか2ヶ月弱で7742回ものブルートフォース攻撃があったようです。活況ですね(白目)

BAN された IP アドレスは計1022個。踏み台攻撃の可能性も考慮して一応伏せておきますが、ほとんど海外からのアクセスです。

次に、/var/log/fail2ban.log で BAN とアクセスの傾向を見てみましょう。まずはハニーポット設置当初の様子がこちら。

スクリーンショット 2025-03-05 23.46.13

最初は同一 IP からのまとまった攻撃が多い傾向にありました。当時は10回失敗したら BAN されるはずにもかかわらず、画像では14回の攻撃を許してしまっていますね。短時間に大量の攻撃が生じた場合、fail2ban による BAN 実施までの間に若干のタイムラグがあるようです。

この後、3回のログイン失敗で BAN するように変更しました。

その後、最近の傾向がこちら。

スクリーンショット 2025-03-05 23.50.11

最近の傾向として、多数の IP アドレスから、基準に満たない程度にチマチマと長期スパンを空けてブルートフォース攻撃を実行する傾向が見られます。

攻撃者側がどのようなボットネットを利用しているのかわかりませんが、もしかしたらボット間で「この IP アドレスはこの間隔で失敗すると BAN されて、これだけの間隔(= 1日)を空けておけば BAN されない」という fail2ban 対策の情報が共有されているのかもしれません。まあ、君等が攻撃している先はハニーポットなので永遠にログイン成功することはないんだけどね。

ハニーポットのログを見てみる

どんなユーザ名とパスワードが試行されたのか見てみましょう。

試行が多かったパスワードがこちら。

スクリーンショット 2025-03-06 0.06.53

…まあセキュリティガバガバマシンありがちなのが多いですね。

ユーザ名で多かったものがこちら。

スクリーンショット 2025-03-06 0.09.13

圧倒的に「root」が多いです。パスワードといいユーザ名といい、簡単なユーザ名やパスワードにしてしまいがちな組織内の共有アカウントに向けたものが多いのかな?という気がしています。

おわりに

迂闊にポート開放しないようにしましょう。パスワードは適宜変えましょう。