スパムメールの踏み台にされてしまった！

先日、管理しているメールサーバがスパムの踏み台にされてしまいました。
メールサーバのあるユーザアカウントのパスワードが漏れてしまったようで、そのアカウントを使って、スパムメールが大量に送信されました。
スパムメールの送信開始が休日の夜中に始まった為、異常に気付いて対処するまでに12時間かかってしまいました。

その顛末を公開します。

状況

パスワードが漏れたユーザアカウントを使用して、SMTP-AUTH で外部からスパムメール送信が行われました。
メールサーバに接続してきた外部のクライアントPCはのべ100台以上、各PCがSMTP-AUTH でメール送信要求をサーバに行ってきました。
これは1分間あたり200通となる割合で、これが12時間程度続き、結果的に12万通ものメール送信実行となりました。

この12万通には宛先該当なしのものが大量に含まれています。
相手先のメールサーバにすれば、大量の存在しないメールアドレス宛てにメール送信してくる、かなり怪しいサーバとしてとらえられます。

対処まで

なぜ気付いたのか？

ロードアベレージの上昇がきっかけです。
メールサーバのロードアベレージが一定以上になるとアラートメールを送信するようになっていました。
このアラートメールが流れたので、メールサーバを調べてみると、大量の postfix プロセスが起動していました。

メールキューを確認すると、数万通と言う、尋常ではない量がたまっていました。

異常事態です。

教訓
メールサーバの異常を通知できるように設定しておくこと。
今回はロードアベレージ監視によって、異常に気付くことが出来ました。

さて、メールキューに大量にたまっているのですが、具体的に何が起こっているのかが、わかりません。
最新の状況をログの末尾から見ようとしても、メールログ（/var/log/maillog）には、すごい勢いでスパムメール送信によるログが追加されるので、中々ログが見れませんでした。

教訓
異常が判明したら、まずは postfix を停止する。
次々とスパムメール送信要求が来るので、ログがどんどん増えていきます。
またこれ以上の被害を広げないためにも、まずは停止しましょう。

メールログを確認してみると、下記のようなログが大量に記録されていました。
ユーザ名 ZZZZZ の箇所が同じユーザでした。

Mar  1 23:27:19 testsv postfix/smtpd[28479]: 8C74351089D: client=unknown[xx.xx.xx.xx], sasl_method=LOGIN, sasl_username=ZZZZZ

あるユーザアカウントのパスワードが漏れて、そのユーザのアカウントを使って、SMTP-AUTH でスパムメールが大量に送信されていることがわかりました。

即刻、そのユーザのパスワードを管理者権限で変更しました。
これで、SMTP-AUTH でのスパムメール送信はこれ以上行われなくなります。

次に、メールサーバへの辞書攻撃等によってパスワードが漏れたのか、ログをチェックします。
そのような痕跡はないので、どうやら別経路でユーザのパスワードが漏れたようです。

ここで油断して、メールサービスを再開させようと、停止していた postfix を起動させてしまいました。
すると、メールキューに溜まっていたスパムメールの配信が始まってしまいましたので、慌てて再度 postfix を停止しました。

教訓
postfix を再起動しただけでは、メールキューに溜まっているスパムメールが再送されます。
メールキュー内のメールを全て削除しましょう。
まっとうなメールも未送信となってしまいますが、後でログをチェックして、そのようなメールは洗い出します。

再度 postfix を起動させて、メールサービスを開始しました。
ユーザの漏れていたと思われるパスワードを変更したので、外部からスパム送信要求してきても、SMTP-AUTH 認証が次々と失敗します。
下記の設定をしていましたので、それらのPCからの接続が次々とブロックされていき、次第に静かになっていきます。

メールサーバのSMTP-Authへの総当たり攻撃(辞書攻撃/ブルートフォースアタック)への対処

教訓
メールサーバ自体への辞書攻撃対策を行っておきましょう。
今回のようなパスワード漏れの場合、パスワード変更で対処した後に、接続してきたスパム送信元を自動的にブロックできます。

その後しばらくメールログを監視しますが、結構、相手先サーバから配信拒否をくらいます。
Trend Micro Email Reputation Services や SpamCop.net – Blocking List ( bl.spamcop.net ) で調べてみると・・・
あわわ、うちのサーバがスパム送信元として登録されています。

Gmail宛てメールも拒否されています。同様に、スパム送信元として認定されてしまったようです。

対処によって既にスパム送信は停止していますが、スパム送信元としての認定解除にいつまでかかるのでしょうか・・・
このままでしょうか・・

これは、最終的に解除されました。次の教訓で記載します。

教訓
12時間スパム送信してしまった後、スパム送信サーバの認定の解除までにかかる時間は次の通りとなる。
Gmail は 1時間。
Trend Micro Email Reputation Services は、1日
SpamCop.net – Blocking List ( bl.spamcop.net )は、２日

ことの顛末は以上です。

さて、今回のことで、反省点です。

まず、下記で紹介した、接続数制限とプロセス起動数制限です。
今回のサーバに行っていた設定ではちょっと緩かったようなので、もう少し厳しくしてみます。
これが適切に設定されていれば、スパムメール送信量をかなり減らせたはずです。

メールサーバへのSMTPサービス拒否攻撃への対処

次に下記の SMTPS-AUTH への設定です。
該当サーバはこの設定をおこなっていませんでした。
今回の件では、辞書攻撃を受けていませんでしたが、今後を考えると、SMTPS-AUTH のみにすべきと思いました。

SMTP認証へ辞書攻撃されるのでメールサーバをSMTPS-AUTH のみ利用にする

なお、該当ユーザのパスワードが漏れた経路は別途調査中です。