_ ISPのメールサーバを経由するスパム。別に今にはじまったことじゃないよね。ってゆーか、むしろ先祖返り。業者による大量送信もそうだし、ワームに感染した PC からの意図せぬ送信も昔っから。
_ 感染先をメールで広めるウィルスが出始めたころは、今と違って自力で MX 検索なんてしてなかった。MSOE のレジストリを調べて ISP 経由で送信してた。Nimda とか。Klez とか。当時は SMTP AUTH なんてまったく普及してなかったし、POP before SMTP ですら他社 ISP からローミング接続するとき以外は必要なし、なんてのがほとんどだったから、ウィルスも認証まわりの難しいことは実装しなくてもよかったんだよね。
_ 最近は海外でも OP25B が普及しつつあるようなので、spammer が手段をメールにこだわり続けるのであれば、MX ではなく契約 ISP の submission サーバに送るように先祖返りするものが出てくるのはむしろ必然。メールにこだわらないで別の手段を使う spammer も増えたけど。
_ ということで、つい最近 Gumbler やら 8080 やらがレジストリにある FTP アカウント情報を参照して勝手に web を改竄して話題になったけど、同じような手口がメールでもまた流行るかもね。ftp と違ってメールは10年前にすでにレジストリを盗まれてるので、まともな MUA ならば認証情報は暗号化して保存してると思うけど(ちゃんと調べたことはない)、実際に送るときにパスワードを聞かれないようなものは、復号に必要な情報も PC 内のどこかに存在してるわけで、それが破られたらヤバい。さらに、レジストリではなく MX でもなく、トラフィックを監視して送信先サーバを見つけるという動作をするウィルスも過去に存在したし(Hybris だったかな？)、非 SSL で平文認証だと設定が暗号化されていてもヤバい。ってゆーか、ISP 経由の spam が増えてるということは、ヤバいとかじゃなくてすでに現実になってるってことだよね。OP25B は束の間の夢でした、ということで。
_ サーバ側でこれに対策するとなると、どうするのかねぇ。とりあえず、SMTP AUTH に成功したからといって無制限に送信を許可するのではなく、認証アカウントに紐づいたアドレスでしか送信できないようにしておけば、from 詐称の spam は出せなくなるのでだいぶマシだと思う。SPF とか DKIM とかうるさいので、複数のメールアドレスを使いわける場合でもひとつのサーバから送るのではなく、アドレスごとにメールサーバを使いわけましょう、というのが最近の考え方なんで、それであんまり困らないはず(某所で実際にやってるけどクレームはない)。あとは流量制限か、submission 側にも spam フィルタを突っ込むか。
_ この前のつづき。結論: ボットネットがかしこく進化するなら難しいんじゃね。
_ ボットが MX を調べて宛先サーバに直接 spam を送る今のような挙動ではなく、SMTP AUTH の認証情報を盗んで ISP の submission サーバを経由して送信するような動作に進化するのであれば、盗んだ SMTP AUTH のアカウント情報はそのボットだけが独占するのではなく、ボットネット内で共有するようになるだろう。Gumbler のときも、web を改竄してたのは感染した PC 自身ではなく、盗んだ ftp アカウントの横流しを受けた別ホストだし。
_ となれば、たくさんのボットがたくさんのアカウントを共有してとっかえひっかえ使いまわすことになり、ひとつのボットが同じアカウントで複数回 SMTP AUTH することは少なくなる。ということは、IP アドレスあたりの流量制限はほとんど効かない。メールアドレスあたりの流量制限は、たくさんのボットが何度も同じアカウントで送信を繰り返すのならば効果があるだろうが、ボットネットが全体としてたくさんのアカウント情報を盗めればアカウントひとつあたりから送信するスパムの数はだいぶ少なくなるので、閾値を低めに設定しないとひっかからなくなる(閾値を低くしすぎるとちょっと多めにメールを使うまっとうなユーザを誤爆する)。流量制限ではなく、接続元の IP アドレスがしょっちゅう変わるユーザを検知してブロックすると、モバイラーな皆さまがとばっちりを受ける。
_ 流量制限が効くのは大量送信がおこなわれている場合だが、少数の spam source から大量投下していたのは昔のやりかた。ボットのやりかたは「広く薄く」であり、ひとつのターゲットに対してそんなに大量には送らないから、機械的な流量制限で対応するのは難しいだろう。いまどき単機能なボットなんかないので、流量制限にひっかからない程度に「薄く」調整して送ってもボットが暇になるわけではなく、web な spam に勤しんだり新たなる感染対象を探したりと仕事はたくさんあって、感染マシンのリソースを遊ばせておくことになるわけじゃない。ボットが流量制限でかんたんに引っかけられるようなアホな進化をしてくれればいいけど、それを期待するのは間違いだろう。
_ 認証に通っても from 詐称なら送れないようにするのはかなり効果があるはずだけど、bot が詐称せずに送るようになったり、そもそもポリシーでそういう制限できない場合は辛い。やっぱり根本的にボットにアカウントを乗っ取られないように認証情報を管理するしかないか。MUA はアカウント設定を固い暗号をかけて守る。サーバ側はトラフィック監視で盗まれないよう平文認証をやめる。通信経路上のどっかにいる見知らぬ誰かによる盗聴ではなく、ユーザの PC 内にいるボットによる盗聴を気にしなきゃいけないというのが悲しい。
_ ……んー、某所のログを確認してみたけど、せっかく SSL に対応してるのに、非 SSL な LOGIN 認証がけっこうあるなぁ。ボットが盗聴してたらダダ漏れ。いまどき CRAM/DIGEST-MD5 と SSL のどっちも使えない MUA なんてないだろうから(まだあったら直ちに捨てろ)、どっちかを必須にする仕様にしとけばよかった。
_ って、そういえば、上のはどこの ISP も今どき認証必須だよね、という前提で書いたんだけど、実際のところどうなんだろうか。認証さえ通れば世界中から送れる、という前提だからこそ、盗んだアカウントをボットネット内部で共有して広く薄く送るというモデルが成り立つわけなんだが、盗むべき認証情報がそもそも存在しないならそれができずむしろ安全:-)。
_ CentOS で BIND の設定。rndc-confgen を叩いて rndc を使えるようにする。
_ が、できあがったものを実際試してみると、なぜか
とか怒られて失敗する。けっこう悩んだが、わかってしまえばほんっっっっとにくだらない理由だった。Mar 17 20:46:07 ns named[1192]: invalid command from 127.0.0.1#37163: bad auth_ bind をごくふつーにコンパイルすると、rndc-confgen で生成される鍵のデフォルトの名前は "rndc-key" になるんだ。
ところが、CentOS で rndc-confgen を叩くと、$ rndc-confgen # Start of rndc.conf key "rndc-key" { algorithm hmac-md5; secret "CtZJbjonTvmCaXw9p4fLGA=="; }; ..."rndc-key" じゃなくて "rndckey" とハイフンが抜けてるよ…。$ rndc-confgen # Start of rndc.conf key "rndckey" { algorithm hmac-md5; secret "dcRb8PprUI0bRdi+koz2dQ=="; }; ..._ つーことで、こっちはふつーに "rndc-key" という名前で生成されると思いこんで named.conf を書いてるので、鍵の名前が一致しなくてコケました。ひでぇ。
_ 例によって SRPM をバラしてみたけど、どっか他のところを修正したついでの変更ではなく、ほんとにデフォルトの鍵の名前を変えるだけのアホパッチだった。挙動が気に食わないからコードを修正するとか、OS のポリシーでファイルを配置するパスを変えるとか、そういうパッチならまだわからないでもないんだけどさ、なんで動作にはまったく影響がない、こんなくだらないところを変えて混乱させるのかなぁ。いや、確認しない方が悪いんだけどさ、いちいち見なくてもどんな名前になるかわかってるから確認しないわけで。どんなメリットがあってこんなくだらないパッチを当てるんだか。