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を指定

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

　iptablesのチュートリアルを読んでいたが、えらく長大なチュートリアルであった。これ作るのも翻訳も大変だろーなー。というかぶっちゃけ途中までしか読んでない。まー、あとは人真似でも動かせるだろー、とか。

　で、待望（？）のFail2ban導入。例によってLogwatchのメールがうざいことになっているので。
　基本的には、ログから不正アクセスの試行を検出して遮断するツールの一つである。が、検出パターン(filter)は正規表現二つ（failとignore）で比較的自由に作成可能だし、検出時の動作(action)はかなり詳細に作成出来るので、例えばNginxのHttpLimitZoneModule（標準組み込み）などと組み合わせると、「ダウンロード用ポートへのn本以上の同時アクセスを禁止し、何度も引っ掛かる人は警告画面へ飛ばしつつ当分は転送速度も落とす」などの挙動も可能と思われる。iptablesのhashlimitとか使えば多分。
　つっても、今は大人しいサーバしか動かしていないので、無難な設定で十分だけど。

　んで、例によってyum install fail2banして、cd /etc/fail2banして、jail.confを見てみる。ふむ。これはあまり好みじゃないから、サンプルとしてリネームした方がいいかな。だって、例えばSMTP認証のエラーを拾った時にも25しか塞いでないし。587とかも塞ぎたいぞ。
　という訳で、スクラッチから適当にガシガシ書いていく。メール通知系のアクションはまあ、要らないかな。しかしまー、色々なフィルタが公開されてていいなあ。例えばDovecotのフィルタとかも標準添付されてないけど、Dovecot Wikiからのコピペで済ませたし。結構流行ってるのかなこれ。
　とりあえず、認証を使うサービス全部を監視対象にしたが、ついでにFail2ban自身も監視したい。"Fail2ban monitoring Fail2ban"というページで紹介されているが、要するに何度もbanされる人はもっと長期的にbanしよう、という奴。再帰的な動作なので多少の注意点はあるようだけど、多分大丈夫だろー、ということで入れてみる。

　さくらのVPSはシリアルコンソールもあるのでかなり気楽に導入してしまったが、Osukiniの方はどうすっかなー、と思ってよくよく考えると、認証が必要なサービスを外部に公開していない予感。オーケー、問題無しだ。
　待てよ、IPv6ってちゃんと塞がれるのかなこれ。えーと。iptablesに投げてるから無理じゃね。ip6tablesのactionとか入ってないしなあ。自前で書く気力は今は無いし。hostsdenyアクションとか使えば当面は行けるんだろうか。いや、そもそもIPv6アドレスを拾ってくれるのか？
　つーかIPv6ってクラッカー的には狙い目なんだろうなあ（笑）。普及してある程度落ち着くとこまで早く行って欲しいけど。

　SPFがどうにもこうにも納得行かない仕様なので、ぐだぐだ悩む記事を書きかけては公開せずに消すことを繰り返してきたが、いよいよSPFレコードを消去したい気分になった。俺の利用状況からすると、現時点ではほとんど弊害しか生まないので。
　まあ、結論から言えば消さなかったのだけど。無駄な労力だなあと思いながら、なるべく対応側にも非対応側にも人畜無害な設定にしようと努力はした。

　つーか、Gmailからの送信をSPFで許可するにはどこをincludeすりゃいいんだろうと思ってGoogleのヘルプを見たら、-allは配信に問題が発生する可能性がある、とちゃんと書いてあったのだ。理屈でそう思ってはいたし、今までも~allにしていたけれど、この文章を見たら何かの糸が切れた。
　もう、いいよね、頑張らなくても。v=spf1 mx include:_spf.google.com ?allにしちゃっていいよね。~allでも無害だろうけど、SPFに納得出来なかった思いを?allに込めるのだ。メール転送されただけで信用を下げる理由にする気など無い。

　という訳で、SPFは「送信以外の側に」普及するまでは、無難な設定で死蔵しよう。
　DKIMなら多少厳しく設定しても平気なのかなあ。