前回は予定を変更して急遽
Fail2banの概要
前々回に設定ファイル等を紹介しながら説明したものの,
Fail2banはPythonで作成された常駐プロセス
どのログファイルを監視し,
jail.{conf,local}では,
「チェックしたいメッセージパターン」
攻撃された場合の対応は,
これらの設定ファイルを組み合わせて,
fail2ban-serverとfail2ban-client
システムに常駐してログファイルを監視し続けるFail2banの仕組みは,
実際にシステムに常駐して,
起動・
$ 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と呼ばれる監視設定が,
それぞれの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
この結果から,
他にもfail2ban-clientには,
recidive jail
Fail2banは各種サーバのログファイルを元に総当たり攻撃をチェックします。一方,
このFail2ban自身のログファイルを調べれば,
"recidive"はオランダ語で
手元では,
# 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
この設定を使うと,
以下は筆者自身の失敗談ですが,
「おかしいな?」
「Fail2banのログ自身をFail2banの監視対象にする」