前回は予定を変更して急遽「らじる★らじる」の話題をとりあげたため、少々間が空いてしまったものの、今回は前々回の続きで"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, [email protected]]
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との関係も確認する必要があるようです。

Fail2banから見る総当たり攻撃の状況

さて、それではFail2banを使うことでどれくらい総当たり攻撃を防げたのかを検討してみましょう。筆者がFail2banを使っているのはメーリングリストの運用に使っているサーバで、主に監視しているサービスはPostfixとDovecot、Postfixに関してはfilter.d/にあるpostfix.confを使ってsmtpdに対する不正な接続を監視し、Dovecotでは同じディレクトリのdovecot.confを使ってPOP3/IMAPへの総当たり攻撃を監視しています。

6月の下旬から10月中旬までの4ヵ月弱（約110日）の間のログを調べたところ、postfix jailによるbanは2363回、dovecot jailによるbanは660回記録されていました。単純に平均するとPostfixに対する不正接続は1日約20回、Dovecotに対する不正アクセスは約6回生じていることになります。

もっとも、ban回数は日付ごとにずいぶん多い少ないがあり、Postfixの場合は7月5日が最大で289回、以下6月27日が168回、7月6日が131回、6月29日が124回、7月19日が86回となり、7月2日、3日、8月20日、9月9日が最も少ない4回になっていました。

Dovecotの場合は、7月4日が最大で24回、以下、7月19日が22回、7月11日と22日が18回で、8月19日、9月5日、9月7日等、計12日が1回のみのbanにとどまっていました。

この結果を見ると、SPAMにしろ不正ログインにしろ、毎日同じペースで来るわけではなく、ピーク時と閑散時は数十倍程度の差があることがわかります。今回の場合、7月4日（JSTだと7月5日）は米国の独立記念日にあたるので、恐らくそれに便乗したSPAM等が流行した結果、平均の10倍強のban回数が記録されたのでしょう。

一方、banされたIPアドレスについて調べてみると、postfix jailでは総計1298のIPアドレスがbanされており、そのうち895のアドレスは1回のみのbanなのに対し、最大では72回もbanされたIPアドレスがありました。

dovecot jailでは総計418のIPアドレスがbanされ、そのうち181のアドレスが1回のみのban、複数回banされているアドレスは4回banされたのが2ヵ所、3回が1ヵ所、2回が234ヵ所で、Postfixに比べると攻撃元は分散しているようです。

Postfix, Dovecotそれぞれについて、banされた回数の多いIPアドレスとそのアドレスを運用しているISPを整理すると、下表のような結果となりました。なお、Dovecotの2回banは234ヵ所あるので、そこから10件のみ抽出してみました。

この表を眺めると、SPAM型のPostfixに対する攻撃元は欧米から中国まで広く分散しているのに対し、不正アクセス型のDovecotへの攻撃元は中国が大半を占めているようです。中国はインターネット利用者数が世界一なので、利用者が多い分悪用者が多くなるのも当然なのかも知れませんが、個人が趣味で運用しているレベルのサーバでは、悪用者の多い地域からのアクセスはあらかじめIPアドレスレベルで拒否しておくのも手かなぁ、と考えていたりします。

今回、Fail2banのログを眺めていて「面白いな」と思ったのは、監視対象にしていたにもかかわらず、sshdに対する総当たり攻撃は記録されていなかったことです。恐らくその理由は、このホストを運用しているホスティング会社の方針で、sshdのポート番号がデフォルトの22から別の番号に変更されているせいでしょう。

もちろん、ポートスキャン等をかければ、どのポート番号が反応するかを外部から調べることも可能ですが、「⁠総当たり」のような野蛮な方法を使おうとする攻撃者は、そういう余計な手間をかけるよりも、デフォルトのポート番号のまま運用しているサーバを探す方が簡単だしパスワード設定が甘いことも多い、と思っているようです。

そう考えると、SMTPのように世界中の不特定のメールサーバと通信しなければならないサービスのポート番号は変更できないものの、SSHやPOP/IMAPのように利用者を特定できるサービスでは、あらかじめポート番号をデフォルト値から変更しておく、というのは、簡単なものの、案外有効なセキュリティ対策なのかも知れません。