と言っても変な意味じゃないぜ。

　長期的な遮断はTCP Wrapperで、と思ってたら、何ぞPostfixが素通りしてた。ふむ。ldd /usr/sbin/postfix、と。libwrap無し、と。
　もういいやめんどくせえからFail2ban停止な。ついでにShorewallも6to4が半端に通らなくて調べるのめんどいから停止。残骸が残ってたのでiptablesをリスタートして、と。

　とりあえず、Logwatchに膨大なログを流し込む奴だけiptables -A INPUT -s x.x.x.x -j REJECT --reject-with icmp-host-prohibitedとか手作業で突っ込んでけばいいんじゃねーの、もう。これならIPv6もip6tablesでばっちり対応出来るね！
　このままだと後々になって挙動を変えたくなった時にあれだから、disallowed-inputとかのチェーンにreject処理を分離しとくか。一度service iptables saveしといて、あとはもう/etc/sysconfig/iptablesを編集すればいいだけだな。作業的には楽勝ですね。

　と、ここまでやっといて何だが、手作業なんぞ納得行かなくて必ず自動化したくなるのが目に見えているので、やっぱりどうにかしてFail2banを使おう、と思い直す。割とだらけたサーバだから、SnortとかOSSECとかも何か違うしなあ。うーん。
　まあ、極力単純な動作に設定して、問題の原因をもう一度探ってみるか…。

　iptablesへの登録が失敗したぞー、というログが確認出来た。もちろん全然弾いてくれない。おのれ。調べてみると、何やらカーネル古い説などが浮上。確かにCentOSのカーネルは古めであるが。こんなことの為にカーネルをアレしたりはしないな、さすがに。
　Fail2banのクライアントはPythonで書かれているが、一行だけsleep入れたら直ったという話も出ていて、非常に手軽に試せる話ではあるが、例によって今回はyum updateで済まなくなりそうなことはしない方針なので、この方法も除外。
　つーか無理に使わなくてもと思いつつ、何となく意地で考えてみる。自己監視をする都合上、二種類の遮断方法が必要となるが、tcpwrapperとShorewallを使ってみてはどうだろうか。
　という訳で、Shorewall導入。ちょいちょいと初期設定を弄って起動。こりゃiptablesを直接叩くよりずっと楽だな。

　何かもう、原形を留めないくらい設定を弄りまくったFail2banだが、これで動いてくれるかなあ。駄目ならもう外してもいいんじゃないか。sshdはポート変えただけでアタック来なくなってるし。ログがうざいのはSMTPリレー狙いくらいだし、どうせDHCPなアドレスなんだろうし。そもそも、セキュリティの為にやってる訳でもないし（笑）。

　前にも書いたけど、使ってるサーバソフトの実装とREの書き方によっては、インジェクションで簡単にDoS攻撃が出来てしまうのだよな。確認するにはテストするのが一番早いか…。
　んー、何か考えるのめんどくなってきたなー。「誰がそんな微妙な嫌がらせをわざわざうちみたいなところに」という考え方もありではないでしょうか。どうですか。
　まあ、少しだけちゃんとREを検討してみるか。少しだけ。どうせブルートフォースの検出なんだから、例外的なログを見落としても大きな問題にはならないし。

　「どうせ動くだろ！」「動かなくても死にはしない」「たぶんね」って感じでテストもせずに半日放置してみたが、何かちゃんと動いてないっぽいような。おかしいなあ。一つのログファイルを三回も監視してるのが駄目なのかな。複数のREで監視とか出来るのだろうか。

failregex = RE
            RE
            ...

これで出来るっぽいな。それじゃ、メール関係は一つにまとめよう。

　そして、

• SMTP Open Relayの監視を554じゃなく554 5\.7\.1に修正
• むしろカッとなって書き起こし
• [Definition]の書き忘れに気付かず延々とConfigParserに怒られる
• ていうか標準でConfigParserなんて物があったのか
• ログの出力先がSYSLOGになってたので自己監視に失敗
• ↑「デフォは/var/log/fail2ban.logだよ」と書いてあるので、指定を削除
• ↑ログが出力されなくなったので明示的に/var/log/fail2ban.logを指定

といった流れを経て、また半日くらい放置してみよう、と。別にちゃんと動かなくてもいいのだ。誤爆さえしなければ。