後方散乱メール/配信不能レポートスパム対策

さくらのVPSで独自ドメイン用のメールサーバを構築していますが、最近になってパートナーのメールアドレスへ後方散乱メール/配信不能レポートスパムが届くようになりました。

後方散乱メール/配信不能レポートについては「後方散乱メール (Backscatter)/配信不能レポート (NDR) スパムについて」がわかりやすいと思います。

どうしてターゲットになってしまったのか?

独自ドメインは2ドメイン運営しています。
しかし、ターゲットになっているのはパートナーのドメインのうち1ユーザのメールアドレスのみです。
独自ドメインでそれぞれ別のWEBサイトも運営していますが、管理ユーザのメールアドレスは私のメールアドレスにしてあります。WEBサイトからどうこうではないようです。
考えられうのは過去に届いたフィッシング詐欺メールの可能性が高いです。
楽天カード関連かアップルID関連の偽装メールでメール本文のリンク先をクリックしてしまったそうです。

事象

スパムメールはスパム対策(ブラックリスト)によりほぼ拒否(REJECT)できています。
また、milter-managerによりウィルススキャンとspamチェックを行いspamと判断されればヘッダー内容を変更して受信しています。
問題のメールはFrom:とTo:が偽装され送られてきます。
From:には当ドメインのメールアドレスです。
To:やcc:には第3者のメールアドレスが複数記載されています。
外部のMTAからこのメールを受信するとまずsmtpdで処理されます。
smtpdからcleanupサーバに渡されここで偽装されたFrom:に書き換えられます。
そして、/var/spool/postfix/incomingキューにメールを置きます。
ここまでがメールの受け取り( receiving )です。
次に、cleanupから通知を受けincomingキューにあるメールをqmgrが処理してsmtp(リモート配送)、local(ローカル配送)、lmtp(lmtpを使用したローカル配送)、virtual(バーチャルドメインメール配送)、pipe(外部プログラム配送)、error(エラーメール配送)のそれぞれに配送します。この一連の操作がメールの配送(delivering)です。今回は、smtp(リモート配信)を行おうとしてerrorが発生しています。

アクセス制限は、smtpd_client_restrictions、smtpd_helo_restrictions、smtpd_sender_restrictions、smtpd_recipient_restrictions、smtpd_data_restrictions、smtpd_etrn_restrictionsで行えます。
これらはsmtpdのそれぞれのコマンドのEHLO/HELO、MAIL FROM、RPCT TO、DATA、ETRNでアクセス制限が行えます。
rblブラックリストのサーバは以下の3つを使用しています。

reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client sbl.spamhaus.org,

zenだけでもいいようにおもいますが念のためsblも追加しています。

メールの第3者への配送は失敗しています。
スパムメールのブラックリストサイトにも当ドメインは登録されていませんでした。
しかし失敗したメールはdefferedキューもしくはbounceキューに入ってしまいます。これらは設定にもよりますが有効期間中は間隔を変えながら再送を試みます。
送信者がローカルのメールアドレスに書き換えられているため、これによってキューには4000通以上のNDRレポートが蓄積されていました。
当然、新たにスパムメールも次々配信されてきますのでたまる一方です。
当サイトではmysqlにも影響を与えます。

対処

キュー一覧の表示

# postqueue -p

キューのクリア

# postsuper -d ALL

※すべてのキューを削除していますが個別に削除も可能です。

対策

header_checksを追加

もともとこの機能は利用していましたが、添付ファイルの拡張子で拒否判定をしていただけでした。

header_checks                       = pcre:/etc/postfix/header_checks

/etc/postfix/header_checksにFrom行の文字列一致で拒否を追加しました。

/^From:.*\"CANADA PHARMACY\" <.*@.*>/ REJECT

From:が"CANADA PHARMACY" <メールアドレス>に書き換えられているのでこの部分にマッチするものをREJECTしています。
これによってキューに残らなくなりました。

ips.backscatter.orgを追加

smtpd_recipient_restrictions        = permit_mynetworks,
                                              .....
                                              check_sender_access hash:/etc/postfix/check_backscatterer,
                                              .....
# cat check_backscatterer
<>  reject_rbl_client ips.backscatterer.org
postmaster reject_rbl_client ips.backscatterer.org

これについてはこちらを参照してください。
※postconf -mでサポートテーブルタイプがわかります。dbmはサポートしていなかったのでhashにしています。hashの場合はpostmapを実行してdbを作成してください。

# postmap check_backscatterer
# systemctl reload postfix

今回は以上で対策できましたが、別のサイトから狙われるとパターンが変わるのでまた対策が必要です。

DSN をすべて拒否

今回のスパム送信者は配送状態通知(DSN)を利用していたため、無効にしても当システムには影響ないので拒否するように設定しました。

smtpd_discard_ehlo_keywords         = silent-discard, dsn

2018.9.13追記 メールのパスワードが盗まれていた

MailFromヘッダーの一致で拒否していましたが、ずっと気になっていたメールログです。やっぱりリモートでSMTPS認証に成功しているようにしか思えません。

Sep 13 13:03:03 MTAホスト名 postfix/smtpd[7649]: Anonymous TLS connection established from unknown[186.216.156.42]: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
Sep 13 13:03:07 MTAホスト名 postfix/smtpd[7649]: 37FCF20156D2: client=unknown[186.216.156.42], sasl_method=CRAM-MD5, sasl_username=当該メールアドレス

もう一度、パートナーにヒヤリングをしてみることにしました。
その中で、メールに貼り付けられたリンクボタンから楽天のログインページにアクセスしてアカウント(メールアドレス)とパスワードを入力までして、楽天カードは入会していないからおかしいと気が付いてページを閉じたそうです。しかし、楽天では身に覚えのない商品が注文されていて・・・、楽天の方は対処してパスワードも変更したそうです。
それではなんでメールサーバにログインできるかというとメールのパスワードと変更前の楽天のパスワードが同じだったからです。
メールのパスワードは変更していなかったのでそのままリモートでログインされていた。というのが真実のようです。

SMTP認証にはdovecot-saslを使用しています。
mysqlデータベースで管理しているためメールのパスワード変更方法が特殊でその方法を教えていなかった責任を感じました。
本日、パスワード変更をしたので「authentication failed: 」で拒否されるでしょう。
これで根本的な解決ができました。

なにかあるとすべてのパスワードが流出してしまうことになるためパスワードの使いまわしはやめましょう!!
そんなにたくさんのパスワードを覚えられないという方は、信頼できるパスワード管理ツールの利用を検討するとよいと思います。

ディストリビューション

CentOS 7.x