予想外に延々と続いたFail2banの記事も大団円を迎えようとしていた。ような。気が。
　ログを見たところ、自己監視も機能しているようなので、そろそろ設定をまとめて書いてみる。

• fail2ban.confのlogtargetを/var/log/fail2ban.logに変更。自己監視をしないなら別にどうでもいい設定。syslogにまとめる意味も別に無いが。EPELから拾った奴だと、logrotateはどちらでも動作する設定になっているようだ。
• 自己監視を設定。Fail2ban monitoring Fail2ban参照。しつこい奴を少し長めに追放する設定である。
  長期的かつ全portの遮断になるので、誤動作を考えると安易にお勧めはしにくい。さくらのVPSはシリアルコンソールがあるから最悪何とかなるだろー、という考えで導入している。fail2ban-client set fail2ban addignoreip x.x.x.xで管理端末をホワイトリストに入れておく、などの安全策はお勧めだが、手作業が嫌いな俺は多分やらない。重複チェックが無いので自動化も少し面倒。
  なお、原文でも触れられているが、アクションの種類によっては問題が出る。要は、「ban→ban→unban→unban」という流れなので、二重banを認識しない機構だと一回目のunbanでbanが全て解除されてしまうのだ。iptables系アクションはnameが異なるbanを別のチェーンに登録するので、nameがユニークなら問題は起きないはず。
• 古いカーネルの問題らしいが、iptables系アクションが初期化で失敗する現象（Fail2banのログにERRORとかreturned 100とか出る奴）を確認したので、チェーンを自前で準備する形式にする。
  具体的には、利用したいaction.d/iptables*.confのコピーを取り、actionstartとactionstopを空白にした別バージョンを作ってjail.confのaction=ではそちらを使うように指定し、actionstartに書かれていたコードを自前で解釈実行してservice iptables saveをしておく。
  actionstartの自前解釈は、例えばjail.confの中でaction = iptables-allports[name=fail2ban]とaction = iptables-allports[name=ssh]を利用しているなら、

  # iptables -N fail2ban-fail2ban
  # iptables -A fail2ban-fail2ban -j RETURN
  # iptables -I INPUT -p tcp -j fail2ban-fail2ban
  # iptables -N fail2ban-ssh
  # iptables -A fail2ban-ssh -j RETURN
  # iptables -I INPUT -p tcp -j fail2ban-ssh

  のように、名前の部分を変えてコマンドを実行する感じ。他にもあるなら適宜追加で。終わったら忘れずにservice iptables save。
  つーか問題が出ないカーネルを使ってればこんなことしなくていい。

• フィルタも適当に調整した。確か、PostfixとDovecotの監視を一つのフィルタにまとめて、554を554 5\.7\.1にしただけ。
• Shorewallは結局使っていない。

　こんなもんだろうか。
　無駄に手間を掛けた感もあるが、シンプルな設計なので触りやすかった。ただ、自作フィルタはインジェクションによるDoSも少し気になるが。あと開発止まってるような気もするが、まあ、フィルタとアクションを工夫すればどうにでもなるかも。
　IPv6への対応は、Logwatchがうざくなったらまた考えようと思う。Fail2banはセキュリティというよりLogwatch対策で入れているのだし。ははは。