ある特定レンジ(範囲)のIPアドレスからスパム着弾が続き、システムの負荷が上昇してしまった。そこで、DNSの逆引きやwhoisを利用してそのIPアドレスについて調査してみた。すると、ダイヤルアップ接続などに利用されるIPアドレス群であることが確認できたので、OSレベルのパケットフィルタでまとめて拒否してしまうことにした。その設定を行って、とりあえず対策は終了したのである。
それからずいぶん経ったある日のこと、「取引先からのメールが届かない」という社内営業担当者からのクレームが届いた。そんなはずは……と思いつつも調べてみると、スパム発信に用いられていたIPアドレスレンジの中に、この取引先のMTAが含まれていることが発覚。先方からのメールがフィルタリングによってはじかれていたことが明らかになった。
●反省点
パケットフィルタで主にフィルタリングの基準として用いられるのは、「source」(発信元)と「destination」(宛先)のIPアドレスという2つの要素である。このため、届いたメールが本当にスパムなのかどうかは、IPフィルタリングのログを見るだけでは判別できない。
そもそも、IPアドレスをレンジ単位で拒否すること自体に問題があった。もしそうするとしても、せめてMTAで「Envelope-From」と「Envelope-To」をログとして採取し、メール配送に影響がないかを確認した上で拒否するようにすべきであった。
あるエンドユーザーから「海外の取引先に出したメールがエラーで返ってきてしまう」という相談を受けた。
エラーメールを確認したところ、自社のメールサーバが、DNSBL(DNS-based Blackhole List)に登録されてしまい、DNSBLを参照している先方のメールサーバから受信拒否されているようだった(DNSBLとは、スパムメールの送信元や中継を行っているホストのIPアドレスをまとめたデータベースだ。これを参照することで、スパムメールのフィルタリングを行える)。
そこで利用したのが「rblcheck」というコマンドだ。これを用いていくつかの主要なDNSBLへの登録状況を調べてみたところ、やはり自社のメールサーバのIPアドレスが登録されてしまっていたことが分かった。
今度は、なぜ登録されたかを調べるために、メールサーバのログをさかのぼって調査してみた。すると、社内から大量のメールが外部に送信されていることが判明。送信していたのは社内にあった1台のクライアントPCだ。どうやらそのPCがボットに感染しており、今なおスパムを送信し続けているようだった(関連記事)。
実は自社では、スパムの踏み台にならないための対策として、ファイアウォールの設定により、社外向けのSMTP接続を閉じていた。だが今回のボットは、クライアントが直接スパムを送信するのではなく、普段利用しているメールサーバを経由してスパムを送り出すタイプのものだった。
最近はOP25Bに対抗するために、メーラーに指定してあるSMTPサーバを利用してスパムを送信するものがあるようだ。このような場合は、そのメールサーバのIPアドレスがDNSBLに載ってしまうために、より致命的な障害となり得る。
●対策
まずは、ボットに感染したPCをネットワークから切り離し、スパム送信を停止。それから最新の状態にアップデートしたウイルス対策ソフトで該当PCをスキャンしたところ、やはりボットが検出された。
メールサーバにも、エラーとなってダブルバウンス状況となった大量のエラーメールがスプールにたまってしまい、これがメールサーバの処理能力低下を引き起こしていた。つまりは、エラーメールが行ったり来たりして、雪だるま式に処理待ちのメールがたまってしまっていたのだ。
当面の対策として、スプールファイルの中からとにかくスパムと考えられるものだけ抽出して削除し、サーバの動作を正常状態に戻した。そのうえで各DNSBLに対し「当方ではこのように対策を実施した。ついてはブラックリストから削除してほしい」と申請を行って、やっとこの騒動は収まった。
こうした事態を招かないためには、メールサーバのログやスプールの量を監視し、閾値を越えた場合にはアラートを出すなどして管理者がすぐに異常に気付くようにしておくことが重要だ。あるいはメールの流量制限を行い、メールサーバ経由で一度に大量のメールを送信できないよう設定しておくことでも被害を軽減できる。
続く記事では、DoS攻撃やDHA攻撃を受けた際の対処などを紹介していこう。
Copyright © ITmedia, Inc. All Rights Reserved.