さくらのVPSで運用しているメールサーバで、メールアカウントのパスワードが漏洩し、大量の迷惑メールが送信される事案発生しました。

本件は、サーバそのものに侵入された形跡はなく、正しいメールアカウントとパスワードを使ってSMTP認証を突破されています。

この記事では、
何が起きたのか／どう発見したか／なぜ既存対策では防げなかったのか／実施した恒久対策／今後の課題
をまとめます。

1. メールサーバ構成

今回のメールサーバは AlmaLinux10 上で運用しており、主な構成は以下です。

• freenginx：メールProxyサーバ、メール認証用Webサーバ
• Postfix：SMTPサーバ（送信/受信）
• Rspamd：送信側ではDKIM/ARC署名/Virusチェックに利用
• Dovecot：IMAP/POPサーバ（メールボックス）
• 389 Directory Server：アカウント情報管理サーバ
• Valkey：認証失敗回数等の管理(認証用phpで利用)

既存の認証制限機能

過去7日間に認証成功履歴がないIPであれば、同一プロトコル(smtp/pop/imap)で短期間に3回失敗した時点で最大30日間そのIPをブロックする。
同一IPからの攻撃には強い、毎回IPを変更する攻撃には効果がない。

2. 何が起きたのか

不正利用されたメールアカウントは A と B の2つでした。
ただし、大量のスパム送信に利用されたのはAのみです。Bについて確認された不正利用は、IMAPによるメールボックスへのアクセスでした。

被害内容

• メール配送件数：45,078
• 外部への配送(宛先はユニークで集計)
  • 成功件数(Sent)：19,047
  • 一時エラー件数(Deferred)：4,922
  • エラー件数(Bounced)：21,624
• ユニーク認証成功クライアントIP数：13,131

アメリカ (US) が不自然なほど少ない

3. 攻撃のタイムライン

■ 8月26日〜29日：アカウントAの認証突破、テスト送信

8月26日：20:53 にアカウントAのSMTP AUTHに成功し、特定宛先（u1@frosttree.xyz）へメールを1通送信
8月29日：10:41 - 12:46 に同様に同宛先に3通送信
→ 認証情報が使えるかの確認をしていたと考えられる。

■ 8月29日 22:26：アカウントAを使用して大量送信フェーズ開始

不特定多数へのスパム送信が本格化。

■ 9月3日：アカウントBの認証突破、不正利用

• 9月3日 11:59 ベトナムから IMAP 認証成功
• 9月3日 13:39 ドイツから IMAP 接続
  • 仮想通貨取引サイトからメール受信可否の確認と思われる操作（アカウント作成まではされていない）
  • IMAP接続後、仮想通貨取引サイトからのメールを受信し、受信したメールの削除

メールログとZabbixのトラフィックデータから、既存メールを読み出した形跡はありませんでした。

4. 発見の経緯（なぜ気づけなかったか）

■ 9月5日 10:00：別作業中に ps -ef を確認したところ、Postfix のプロセスが多いことに気付きました。

プロセスが滞留することに違和感を感じ調査を開始、すぐに大量送信を発見。

緊急対応として、

1. Postfix停止
2. ログ調査
3. キュー削除
4. パスワード変更

を実施し、不正送信を停止しました。

パスワードを変更したことで不正送信は停止したが、その後もしばらく認証試行は続き、すべて認証に失敗していることを確認。
9月8日 8:25 を最後にアカウントAへのSMTP認証試行も確認されなくなりました。

発生時に発見できなかった理由は、

• 7月にメールサーバをRocky Linux9 から AlmaLinux10 にリプレースし、メールログの監視を後回しにしていた
• アカウントAにはリターンメールが大量に届いていたが、メールの送受信に利用していなかった

5. パスワード漏洩の原因（流出経路は不明）

アカウントとパスワードの状況

• Aのメールアドレスは他サービスに登録していないが、Aのパスワード自体は自宅メールサーバー内の別アカウント3つでも使っていた
• 上記別アカウントとBで外部サービスを利用する時はAのパスワードを使用していた
• アカウントB のパスワードは昨年変更したもので別サービスに変更後のパスワードは設定していない

6. OS侵入の有無（侵入の痕跡なし）

SSHは公開鍵認証のみ＋非標準ポートで運用しており、ログにも侵入の痕跡はありませんでした。
今回の不正利用は SMTP AUTH による悪用であり、OS侵入を示す証拠は確認されていません。

7. 既存対策が効かなかった理由

既存対策は「ブルートフォース/ディクショナリーアタック」「送信者詐称」を前提にした防御だったため、
正しいパスワードを使った正規送信には無力だった。

• Nginx Mail Proxy と Valkey を組み合わせた対策
  → アカウントA/B 共に、いきなり正しいパスワードで認証成功しているため発動せず

• sender_login_mismatch
  → From が正規アカウントのため発動せず

8. 実施した恒久対策（多層防御へ）

■ 対策1：認証済みメールにも Rspamd の迷惑メール判定を適用

送信メールにも Rspamd を適用し、スパム判定・流量制限(メールアドレス毎に1分間に2通まで)を導入。
認証成功後にもGPTプラグインなどでそのメールが正常かを確認し、スコアが1.0以上の場合は送信拒否。

# /etc/rspamd/local.d/settings.conf
outbound_authenticated {
    priority = 10;
    authenticated = true;

    apply {
        actions {
            reject = 1.0;   # 1.0点以上で送信拒否（露骨なスパムは確実に遮断）
        }

        symbols_disabled = [
            "R_SPF_FAIL",
            "R_SPF_SOFTFAIL",
            "R_SPF_PLUSALL",
            "R_DKIM_REJECT",
            "R_DKIM_PERMFAIL",
            "DMARC_POLICY_REJECT",
            "DMARC_POLICY_QUARANTINE",
            "DMARC_POLICY_SOFTFAIL",
            "MX_INVALID",
            "MX_NONE",
            "ONCE_RECEIVED",
            "ONCE_RECEIVED_STRICT"
        ];
    }
}

# /etc/rspamd/local.d/ratelimit.conf
action = "soft reject";

rates {
    user_strict_limit = {
        selector = "user.lower";
        bucket = [
            {
                burst = 2;
                rate = "2 / 1min";
            }
        ];
    }
}

■ 対策2：Postfix の宛先数制限

smtpd_recipient_limit = 5
→ 1回の SMTP トランザクションで指定できる宛先数を制限。

■ 対策3：GeoIP2 による国外アクセス拒否

freenginx の auth_http にて指定している認証用スクリプトに指定した国のみ認証を許可する機能を追加。
JPからのアクセスのみ認証に進めるように動作を変更。
今回の攻撃はほぼ海外からだったため、この効果が大きい。

■ 今後追加したい対策

• OTPを組み合わせた何か
• Webメールからの認証対策がまだなので何か
• 日本からの正しいパスワードを使用した攻撃の初回も防げるような何か
• 異常の早期検知

9. まとめ

これだけあらゆる企業が不正アクセスを受けているのに自分のパスワードがバレて不正アクセスをされるとは考えてもいなかった意識の低さが今回の原因だろう。
対応してから2週間以上経過するがまだ Google には受信を拒否されている。昨日Postmaster Tools から解除して頂けませんか？の問い合わせをした。
今回SPAMメールを送信してしまった方々、企業様、大変申し訳ありませんでした。