（以下の記事は、該当鯖の管理の人から連絡があり、解決したっぽい模様なので、一部の文字列を潰しておきます）

　denyhosts導入ですっかりスマートになったsecurity run outputをニヤニヤしながら眺めていたら、何か***.***.***.***.dedicated.sakura.ne.jp (***.***.***.***)からの接続をrefuseしたぜー、とか書いてあったんで、何かしらミスしてないか気になってログを見てみる。
　ふむ、sshdに対して、nagios、mambo、rusticos、test、irc、robomail、cyrus、といったユーザー名で接続を試みて、閾値（うちのは結構緩いはず）を超えたんでrefuse登録っぽいな。普通にブルートフォース攻撃にしか見えないな。
　さらに、検索エンジンにIPアドレスを投げたら、BruteForceBlockerの公式サイトのリストにヒットした。ここまで来ればほぼ間違い無いか。

　んで、適当に調べて、dedicated.sakura.ne.jpは「さくらの専用サーバ」というサービスのドメインであることが分かる。ちなみに、さくらが提供する「専用サーバ」は別のサービスで、微妙に高くてうざい。ぶっちゃけこの辺の違いは良く分からんが。
　まあ、さくらで「専用」を付ける場合、たぶんrootも全部渡すタイプだと思うんで、普通に踏み台になってるんかなあ、と。もしそうなら深刻な問題だろうなあ。あちらにとっては。
　また、HTTPを叩いたら***.***に繋がった。何か***プロジェクトっぽいが。しかも会員登録フォームとかログインフォームとかあるぞ。大丈夫だろうか。
　うーん。何か言っといた方がいいんだろか。でも昔、母の知人からウィルス感染メールが来た時、説明が無駄に面倒だった記憶が…。うーん。
　つーかダミーサイトかもしれんしなあ。

　ちなみにdenyhostsの稼働状況だが、一日でdenyを自動解除する設定でも、再犯するホストはほとんど無いようだ。めっきり攻撃も減っていて、たまにdenyリストが全て消えることも。
　/usr/local/share/denyhosts/data/purge-historyには前科リストがあるが、前科二犯は一つしか無い。せっかくだからもう一度来て永久規制になって欲しい気持ちもあるが（笑）。

（伏字を入れたら何か妙に怪しいエントリになった気がしなくもなく）

　今日から一週間+半日ちょいで、旧鯖の契約が切れることになる。
　DNSのキャッシュ期限を一週間に設定している都合上、今日が移行期限となる。まあ、キャッシュ期限短く変更しときゃ、色々と不安も少なかったんだが。分かってて何故か放置することって良くあるよな。無いか。俺だけか。

　つーことで、WebとIRCの移行を一気に片付ける。
　IRCはircd-hybridに移行したが、大丈夫かなあ。
　旧鯖ではWebDAVも動かしていたが、何だかobsoleteな気配がしまくっているので停止。この手の身内向け共有ツールって無いんすかね。出来れば同期機能みたいなのもあるといいけど。日本語ファイル名対応でさ。ありそうだけどなあ。
　メールボックスも最後に一応見直しておいたが、完全にメール放置っぽい人が一人いた。一応新鯖に中身をコピーしといたけど、要らないんだろうなあ。

　さて、俺PCも何とかせんとな…。

　all.rbl.jpを利用した拒絶設定を試しに導入してみたものの、目に見えるほどの変化は無かった。一割くらいは減ったかなあ。
　dnsblでspamが半分以下になった、というような話を読んで導入したのだが、今はspammer側の対策も進んでいるということかもしれない。であれば、メールの到達性を下げる僅かな可能性の方が危険と思われるので、設定を素に戻した。
　また、Greet Pauseも軽く試してみたが、送信側のタイムアウトに依存する手法であり、安全な（spamでないメールを「一つも」落とさないような）運用を続けることを考えたら正直俺的には無理があると思われるので、これもやめた。

　複合的な手法が効果的、という話もあるのだが、これは設定方法が分からないのでやめた（笑）。PTRが引けないホストにだけGreet Pauseを120秒くらいかませば有効かもなあ、とか思わなくもないが。
　結局、ローカルでフィルタリングして仕分けされた物を、自己責任でざっと見渡すのが一番なのかなあ。

　つーか、お遊びサーバだった頃は気楽だったんだけど、身内の事務所のメールボックスをがっつり収容しちゃってるから、微妙に真面目にやらないとまずいんだよな（笑）。

　導入三日目のsecurity run outputは5KBだった。素晴らしい。
　…が、何やらdenyhostsを利用したsshへのDoS攻撃がある模様。同種のBlockHostsやFail2banといったログ解析denyツールにも共通する問題として、八月頃に挙がっていたっぽい。
　仕組みは単純なインジェクションのようで、甘いREをアレして誤ったdenyを誘発するっぽい。まあ、そこまでは単純ミスとして仕方ないんだが、同種ツールがことごとく引っ掛かったってのはどうなのよ。まあいいけど（笑）。

　で、問題はその先で、Fail2banやBlockHostsは作者から報告者への回答もあり、最新版では対応済みのようだが、denyhostsは無返答でパッチも更新も出していない模様（報告者のとこにはパッチ例っぽいのがあるけど）。まずいじゃん。メンテナンスする人がいないとか？
　ともあれ、そんな状況じゃ怖くて使えないので、別のどっちかに移行するかなーと思ったけど、Fail2banは何となくLinux向けっぽい雰囲気だなあ。BlockHosts行ってみるかね。雰囲気も似てるし。

　…と思ったが、よくよく見てみたらdenyhostsのPorts版はパッチ適用済みらしい。ふむ。面倒だからこのまま行くか。後々どうしようもなくなったとして、移行するのが物凄く大変になるようなツールでもないだろうし。多分。
　とは言っても、いずれは移行しそうな気がするし、導入三日目で「ヤバいんじゃね」と思ったなら入れ替え時な気もするよなあ。やっぱ入れ替えるか。

　んで、調べているうちに、何故か全く無関係なSPAMブロック設定の話に目移りする。sendmailの設定変更も適当にやってたけど、真面目にFreeBSDの作法を調べるか。
　えーと、/etc/mailに入って、ホスト名.mcを編集するのか。んで、makeしてホスト名.cfが作成され、make installでsendmail.cfにコピーされ、make restartでsendmailが再起動されるんだな。楽でいいじゃないか。
　それって依存関係次第ではmake install restartでいいのかもしれない、とか余計なことを考えたが、何しろ依存関係次第だしメリットも無いのでやめとこう。
　つーことで、FEATURE(dnsbl,`all.rbl.jp')をmcに突っ込んで、真面目に三回のmakeを実行。たぶん完了。
　rbl.jpは手堅いポリシーのようなので（だから選んだのだが）、ある程度はすり抜けてくると思うが、現状では利用者の労力を何割減らせるかが大事なので、10割じゃなくても激しく有り難いのである。
　どちらかというと誤判定が0%に近いことの方が大事だ。その点で海外のブラックリストは怖いので見送った。
　ということで、有志の人に感謝しつつ、後日また成績の報告でも。

　で、denyhostsからBlockHostsへの移行である。
　まずdenyhostsだが、多分入れた時と逆の手順で外せばいいだろう。/usr/local/etc/denyhosts stopして、/etc/hosts.allowと/etc/rc.confから関連箇所をコメントアウトして、最後にpkg_deinstallを…。
　いやいや、その前にBlockHosts入れちゃっていいよな。えーとどこにあるんだ。えーと。

　Portsに無いんじゃね？

　しばらくdenyhostsで行くか。ハハハ。
　pam_afも調子に乗って入れてみるかなあ。でも不急の物は入れない方がいい気もするな。当分このままでいいか。