実験的に始めたfail2banの新しい使い方です。

Debian の場合、Wheezy の時代には無かったのですが、jessie からは recidive という機能が使える様になりました。この recidive というのはオランダ語で意味は『再犯』だそうです。レシディブと発音します。
fail2ban において、一度 Ban された相手が Ban 期間が過ぎて Unban されても、懲りずに何度もアクセスを行い Ban される状況が発生した場合に、一段と長い Ban 期間を設定できる機能です。

今回はこの recidive の機能を利用して、各サーバで独立して動作している fail2ban の Ban 機能を統合してみます。

やり方はとても簡単です。

1.1台のサーバに複数のサーバで動作している fail2ban のログファイルを集めます。
2.そのログファイルを1つのログファイルにまとめ、ソートします。
→これで複数のサーバから集めたログファイルが時系列的に整列されます。
3.統合したログファイルを元のサーバへ新しいログファイル名で配信します。
※ログ集約サーバから各サーバには root アカウントに公開キーでログインできるようになっている前提です。

#!/bin/sh
cd /root/blacklist
scp site1:/var/log/fail2ban.log        fail2ban_site1.log
scp site2:/var/log/fail2ban.log        fail2ban_site2.log
scp site3:/var/log/fail2ban.log        fail2ban_site3.log
cat fail2ban_* | sort > fail2banALL.log
scp fail2banALL.log        site1:/var/log/
scp fail2banALL.log        site2:/var/log/
scp fail2banALL.log        site3:/var/log/

各サーバの recidive の設定では、この新しく配信される統合ログファイルを参照するように設定します。

現在、実験的に10分間隔でログファイルの収集と配信を行っていますが、recidive の監視間隔を考えるともう少しのんびり配信しても良いかもしれません。

以上、とても簡単な方法ですが、あるサーバに対して SSH のブルートフォース攻撃を仕掛けたり、メールサーバに不正なリレー接続を試行するようなサイトは、他のサーバに直接アクセスが無くても予め Ban しておくのは有効な対策だと思います。

現在、テスト運用中で何か副作用が出ないか検証しています。続報がありましたら、このページに追記することにします。