denyhostsの微妙な問題


 導入三日目の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も調子に乗って入れてみるかなあ。でも不急の物は入れない方がいい気もするな。当分このままでいいか。

(Visited 21 times, 1 visits today)

コメントを残す

メールアドレスが公開されることはありません。

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください