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

CentOS

さくらの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ヘッダーの一致で拒否していましたが、ずっと気になっていたメールログです。やっぱりPostfixの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: 」で拒否されるでしょう。
これで根本的な解決ができました。

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

2019.12.16 パスワードが盗まれていた?

12月の初めにSSL証明書の自動更新に失敗していることに気が付き、そういえばwordpressにしたからかということで、自動更新できるように修復しました。その間、メールサーバがおかしくなっていたようです。パートナーに NDRレポートがいっぱいといわれていたんだけども、メールサーバが落ちていた影響だと思い込んでスルーしていました。本日、 NDRレポートの数の多さから調査したところ、またもや不正ログインが行われメールを不正に送信しようとしたために NDRレポートが大量にたまっていたようです。
今回は以下を行いました。

  1. ログインパスワードを変更
  2. 不正ログインが失敗していることを確認
  3. メールキューにたまったNDRレポートを削除
  4. dovecotにIPアドレスによるアクセス制限を追加

今回はパスワードの入手方法が特定できなかったため、パスワードを変更しただけでは繰り返される可能性が高いと判断し、自宅以外からログインできないようにアクセス制限をすることにしました。このアクセス制限の方法については以下の通りです。

dovecotでallow_netsオプションを使用

dovecot.confにoverride_fieldsを追加しました。allow_netsに指定したIPアドレスからのアクセスのみ許可するようです。

passdb {
  driver = sql
  args = /etc/dovecot/mysql.conf
  override_fields =  allow_nets=127.0.0.1/8,<ISPから付与されている自宅のWAN側IPアドレス>/32
}

<ISPから付与されている自宅のWAN側IPアドレス>は実際のグローバルIPアドレスに置き換えてください。あと、必要であればIPv6アドレスの分も追加してください。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

大阪府門真市に生まれ、高校卒業まで京都府福知山市で育ち、大学は工学部電子工学科を卒業。半導体設計会社に勤務ののちインフラエンジニアとして監視基盤の運用設計業務に就く。現在は都内の施設に勤務。横浜在住。人の役に立てることができればいいなと日々思っています。

目次