スパマー・ネットワークとの闘いの記録 (qmailが二重バウンス・メールにより運用できなくなった経緯について)


概要

お家サーバーがspamメールの踏み台にされてしまったようだ。 以前からqmailが自ドメイン内のあて先がでたらめなメールに対して バウンス・メールを返すのが気になっていたのだが、 見事に悪用されてしまったようだ。

qmailの設定でなんとかなるような気もするが、そうもいっていられない 状況になっているので、この際 Postfix に変えることにした。

2005-01-14の対応

昨日から負荷が異常に高くなることがあったので、 topコマンドでプロセスを調べていると驚いた。普段めったに動いていることを 見ることのないqmail-sendなどのデーモンがいっぱい居るではないか。 乗っ取られているのか?緊張が走る。とりあえず以下のコマンドでデーモンを 止めてみた。

sudo svc -d /service/qmail
sudo svc -d /service/smtpd

異常なプロセスは止まってくれたので、乗っ取られているわけではなさそうだ。 こういう緊急を要するコマンドは、身近の分かりやすいところに書いておくべきだ とつくづく思った。

しばらくプロセスの状態を見ていたが smtpd が止まっていないので、 どんどんメールを取り込んでしまう。仕方ないので daemontools 自体を 止めることにした。/etc/inittab にある、

SV:123456:respawn:/command/svscanboot

という行をコメントにして、

kill -HUP 1

とすれば止まってくれた。こんなことはUNIXに詳しくないと とっさに出てこないかもしれない。

spam拡散の危機が少し止んだので、落ち着いて被害状況を確認することにする。 /var/qmail/bin/qmail-qstat コマンドでかなりの数のメールが送信待ち、 処理待ちになっていると出る。 (後になって調べた結果、このとき約3万通のメールがキューにたまっていたと思われる。)

qmailのキューで削除などの操作したことが無かったのでGoogleで調べてみると、 同じような被害にあった人のページ を発見、ここにあったqueue-adminというツールを貰っていくことにする。 perlスクリプトで書かれた、かなり良くできたプログラムで公開して いただいたcmfの管理人さんに感謝しつつ queue-admin --da でキューに溜まっている 全てのメールの削除を開始した。

数十分後にqueue-adminの実行が終わり、qmail-qstatで調べてみると1万通弱の メールが処理途中と出る。全部は消せないようだ。

いったいどんなメールが届いているのか気になって、postmasterの受け取り先で ある /var/qmail/alias/Maildir/new を覗いてみようとして ls コマンドが いつまでも返ってこないことに驚いた。ls -l の出力をファイルにリダイレクト して落ち着いて眺めてみる。不正メールは、2005/1/13 10:52から届き始めたようだ。 止めたのが2005/1/14: 11:51で、この間あて先不明でpostmasterに差し戻された メールは、実に40万通になっていた。差し戻されず配達されてしまったメールも あったわけで世間に迷惑をかけてしまったことになる。

削除できないメールの処理を進めるために、もう少しqmailを動かしてみることにする。 ただし、spamメールをこれ以上受け取るわけにはいかないので、smtpポートを iptablesでブロックすることにする。

sudo /sbin/iptables -F
sudo /sbin/iptables -A INPUT -p tcp --dport 25 -j DROP

ポートの公開・非公開の設定は本来、ブロードバンド・ルーターの設定なのだが、 出先からsshで操作していることもあり、iptablesでブロックした。

送信に使っていたプロバイダのメール・サーバーのアドレスを、 使えないように smtp.exmaple.jp のような存在しないアドレスに変えておく。

sudo echo smtp.exmaple.jp >/var/qmail/control/smtproutes

この状態で /etc/inittab の deamontoolsのエントリを再び有効にして kill -HUP 1とするとqueueの処理が始まったようで、qmail-qstatを 見ていると徐々に減っていくのが確認できた。

今度は実際に送信はできないはずなので、全てpostmaster差し戻しとなったはずだ。 1万通弱のメールが/var/qmail/alias/Maildir/newに再び集まってきたので、 最初の40万通と合わせて削除した。それにしても、1つのディレクトリに40万もの ファイルを入れても処理できるUNIXの懐の深さには恐れ入る。

数通だけファイル名を調べて内容を見てみた。 お家サーバーで、ssdlinuxに最初から設定されている user1 というアカウント を Return-Path に指定してバウンスでばら撒くことを期待した spam だったようだ。 user1アカウントにメールを送ったときにバウンスが返ることは気が付かなかった。 それにしても、このような設定ミスのアドレス情報はスパマーの使うネットワークで 交換されているのだろう。短時間でありとあらゆるところから user1 宛ての同様な spamが舞い込んで来るようになった。恐るべしスパマー・ネットワークだ。

MTAの選択

このままqmailを使い続けるかどうか迷うところだ。 まずは、不正なメールは受け取らないで、接続の初期の段階で切ってしまうのが 今の不正メール転送の常套手段となっているのだが、qmailを使う限りそのような 設定にするのが難しい。不明者のアドレスを受け取って捨ててしまうことはできても 受け取ったという事実だけで、どんどん同様なメールがやってくると、 ただでさえ細いADSLのネットワークを、そんなゴミのために使うのは耐えられない。

ssdlinuxには、sendmailが付いているのだが、この際 Postfix でいくことにする。 qmailで使っていたサブアドレスによるフォルダ振り分け配信という 仕組みが使えなくなるデメリットはあるが、その後の運用でなんとかなるかもしれない。

インストールの手順などは、OpenBlockS/MailServerにまとめた。 qmailをdaemontoolsで止めて、Postfixを動かし始めた。

sudo tail -F /var/log/maillog

で様子を見ていると、特定のサーバー(日本のプロバイダのメール・サーバーと思われる) から次々にspamが届いていることが分かる。 これに Postfix が

550 <user1@example.jp>: Recipient address rejected: 
User unknown in local recipient table;

とバサバサ切ってくれているところを見ると、正義の見方ウルトラマンがやってきて 怪獣をバッサと退治してくれてるみたいで頼もしい。

しかしあまりに数が多いので、特定のサーバーからの接続時に、接続できない ふりをするフィルタを設置することにした。

sudo /sbin/iptables -F
sudo /sbin/iptables -A INPUT -p tcp -s mgate24.example.jp --dport 25 -j REJECT
sudo /sbin/iptables -A INPUT -p tcp -s mgate25.example.jp --dport 25 -j REJECT
sudo /sbin/iptables -A INPUT -p tcp -s mgate28.example.jp --dport 25 -j REJECT

パケットを無視するDROPだと、相手のサーバーがタイムアウトを起こすので、 REJECT にしてあげると早くあきらめてくれるかもしれない。 時々フィルタを外して様子を見て、あまり送ってこなくなっているようなら フィルタを完全に外すようにしないと、有名なプロバイダのメール・サーバーなので 正規のメールが届かなくなる恐れがある。 正規のメールならば、1〜2日程度ならサーバーダウンだと思われているはずなので、 再送されてくるはずである。

その後

翌日、フィルタを外して様子を見ると、昨日のプロバイダのメール・サーバーからの 異常なトラフィックは止んでいた。それどころか、いろいろなところからやって来ていた spamの不正中継要求も1時間に2通程度になっているではないか。

不正に使われるのが一瞬で始まるなら、対策を行うと一瞬で何処かへ消えてしまう ようだ。恐るべしspamネットワーク。未だに止まない1時間に2通程度のトラフィックが アンテナになっていて、実際に不正中継が出来ることがわかると、乗っ取られた 世界中のPCに一斉に指令が出て不正中継ネットワーク網の一員にされてしまうの かもしれない。映画ターミネーターのような世界が本当になる日も近いのか。

DNSBL というブラック・リストがあって、 spamの発信元や不正中継を許すサーバーは、ここに載せられてしまう。 お家サーバーのドメインを検索したが該当なしだった。よかったぁ。

「トラブルは、スキルアップの母」とはよく言ったものだ。 おかげでかなり防御技術が身についた。

免責事項

ここに記載されている内容を実際に運用した場合のトラブルに関しては一切責任を負えませんのでご了承ください。
Copyright 2000-2011 Koichi Otsuka


トップ   差分 バックアップ リロード   一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2005-01-26 (水) 10:40:34 (7002d)