前回は予定を変更して急遽「らじる★らじる」の話題をとりあげたため，少々間が空いてしまったものの，今回は前々回の続きで"Fail2ban"の話題を取りあげます。

Fail2banの概要

前々回に設定ファイル等を紹介しながら説明したものの，だいぶ時間も経ったので，改めてFail2banについて簡単に復習しておきましょう。

Fail2banはPythonで作成された常駐プロセス（デーモン）タイプのログファイル監視ソフトで，起動するとシステムに常駐して指定されたログファイルを監視し続け，総当たり攻撃的なエラーメッセージを見つけると，パケットフィルタリングによる攻撃元アドレスの接続拒否等，あらかじめ指定しておいた処理を自動実行してくれます。

どのログファイルを監視し，攻撃を検出した場合にどのような対応を行うかは，/etc/fail2banディレクトリにあるjail.confファイルで指定します。ただし，このファイルはFail2banを更新すると上書きされてしまうので，サイトごとの設定はjail.confをヒナ型にしてjail.localで行うのがよいでしょう。

jail.{conf,local}では，監視したいサービスごとに，対象とするログファイル，チェックしたいメッセージパターン，攻撃された場合の対応方法，を指定します。

「チェックしたいメッセージパターン」とは，正規表現で記述された「ログイン失敗」を意味するエラーメッセージで，一定期間内に，指定した回数以上，そのパターンにマッチするメッセージがログファイルに出力された場合，「⁠総当たり攻撃が行われている」と判断します。各種サーバ用に練りあげられたメッセージパターンは，/etc/fail2ban/filter.dディレクトリに用意されています。

攻撃された場合の対応は，Linux用のiptablesを使ったパケットフィルタリングを始め，TCP Wrapper用にhost.denyを書き替えたり，BSD系Unixが採用しているipfwやipfを用いたり，攻撃元のIPアドレスをメールで通知するなど，さまざまな処理が/etc/fail2ban/action.dディレクトリに用意されています。

これらの設定ファイルを組み合わせて，さまざまな総当たり攻撃を早期に検出し，攻撃元からの接続を遮断して更なる攻撃を不可能にしよう，というのがFail2banの考え方です。

fail2ban-serverとfail2ban-client

システムに常駐してログファイルを監視し続けるFail2banの仕組みは，デーモンとして動作するfail2ban-serverと，このデーモンを操作するためのfail2ban-clientという2つのツールから構成されています。

実際にシステムに常駐して，ログファイルの監視や攻撃を受けた際の処理を行うのはfail2ban-serverで，fail2ban-serverを起動したり終了させたりするのがfail2ban-clientの仕事です。

起動・終了以外にも，fail2ban-clientはfail2ban-serverの状況確認や各種設定を変更する機能を持っています。たとえば"status"を引数にしてfail2ban-clientを起動すると，fail2ban-serverの動作状況が得られます。

$ sudo fail2ban-client status
[sudo] password for kojima: *****
Status
  |- Number of jail:    10
  `- Jail list: recidive, ssh-iptables, postfix, sendmail-auth, couriersmtp, cyrus-imap, dovecot-auth,
     courierlogin, sendmail-reject, solid-pop3d

この例ではjailと呼ばれる監視設定が，recidive,ssh-iptables等，10個あることがわかります。なお，fail2ban-serverは各種ログファイルを読み込むためroot権限で動作しており，それと通信するfail2ban-clientにもroot権限が必要となるため，sudo経由で起動しています。

それぞれのjailの動作状況を確認するには，"status <JAIL>"を指定してfail2ban-clientを実行します。たとえば，postfix jailの動作状況は以下のようになります。

$ sudo fail2ban-client status postfix 
Status for the jail: postfix
|- filter
|  |- File list:      /var/log/maillog 
|  |- Currently failed:       0
|  `- Total failed:   5945
`- action
   |- Currently banned:       13
   |  `- IP list:     124.150.143.188 115.206.172.140 201.140.188.113 183.158.118.92 153.142.9.238
   |                  125.122.250.242 115.193.104.55 218.219.167.110 220.184.214.0 221.225.170.109
   |                  163.21.10.8 125.120.202.175 115.198.38.194 
   `- Total banned:   492

この結果から，postfix jailが監視しているログファイルは/var/log/maillogで，過去3分以内（設定ファイルのfindtime）については総当たり攻撃の痕跡は見つからなかったものの，起動してからのトータルでは5945件の攻撃を検出し，現在，接続禁止（ban）になっているIPアドレスは124.150.143.188以下13件で，累計では492ヵ所からの接続が禁止された，ということがわかります。

他にもfail2ban-clientには，設定ファイルを再読み込みさせる"reload"，動作しているかを確認する"ping"，各種設定情報を調べるために"get"，それらを動的に変更するための"set"等，さまざまな機能が用意されており，これら機能の詳細についてはfail2ban-clientのmanページ等をご確認ください。

recidive jail

Fail2banは各種サーバのログファイルを元に総当たり攻撃をチェックします。一方，Fail2ban自身も，いつ，どのようなIPアドレスをアクセス禁止（ban）したのかを記録したログファイルを残します。

このFail2ban自身のログファイルを調べれば，繰り返しban対象となっているIPアドレスがわかるので，そのようなアドレスは総当たり攻撃の常習者とみなして，通常よりも長い期間banしよう，というのが"recidive jail"です。

手元では，/etc/fail2ban/jail.localの最後に，jail.confからコピーしたrecidive jailの設定を加えています。

# Jail for more extended banning of persistent abusers
# !!! WARNING !!!
#   Make sure that your loglevel specified in fail2ban.conf/.local
#   is not at DEBUG level -- which might then cause fail2ban to fall into
#   an infinite loop constantly feeding itself with non-informative lines
[recidive]

enabled  = true
filter   = recidive
logpath  = /var/log/fail2ban.log
action   = iptables-allports[name=recidive,protocol=all]
           sendmail-whois-lines[name=recidive, dest=kojima@linet.gr.jp]
bantime  = 604800  ; 1 week
findtime = 86400   ; 1 day
maxretry = 5

この設定を使うと，1日（findtime=86400）の間に5回以上banされたIPアドレスは，そこから一週間（bantime=604800）アクセス禁止になります。

以下は筆者自身の失敗談ですが，本稿を書くためにFail2banのログを調べていたところ，8月の中旬くらいまで週に1，2件は"recidive jail"でbanされたアドレスが記録されていたものの，それ以降，このjailに引っかかるアドレスは見つからなくなりました。

「おかしいな？」と思って各種jailの設定を確認したところ，8月の中旬くらいにデフォルトのbantimeを3600（1時間）から36000（10時間）に変更していました。多分，ban回数のあまりの多さに辟易してbantimeを10倍にしたのだと思いますが，1度のbantimeを10時間にしてしまうと1日に最大でも2回しかbanされなくなるため，5回以上が対象の"recidive jail"には該当しなくなり，より長期のban対象にはならなくなっていました。

「Fail2banのログ自身をFail2banの監視対象にする」という"recidive jail"の考え方は面白いものの，実際に使う際には，この失敗例のように他のjailとの関係も確認する必要があるようです。