このサイトを含め、僕はいくつかのWordPressサイトを運営しているのですが、そのほとんどをAmazon Web Services(AWS)というクラウドサービスで構築しています。
で、以前にそのAWSのSESというメール送信サービスを利用するとメールサーバーを持たなくて済むよ、ということを書いたのですが……
先々週末ぐらいからメールが異常な件数(数万件)送られるようになっていました。普段はWebサイトからのメール送信(e.g. お問い合わせフォームからの連絡、アップデート通知)でしか使わないので、週に100件もいかない程度。
スパムでは?
まず最初に疑ったのは、「なんらかの改竄が行われ、メール送信スパムの踏み台にされていたのでは?」ということです。この場合、2パターンあります。
- SESのSMTP(メール送信)認証情報が流出し、SESが直接実行されている。
- WordPressが乗っ取られ、メール送信が実行されている。
そこでとりあえず以下を試しました。
- SESの認証情報を廃棄し、新しい情報を設定。
- WordPressでSESを利用しているサイトのSMTPプラグインをすべて停止。
- 改竄ファイルがないかどうか、サーバーにログインしてチェック。
wp core verify-checksums
とかそういうコマンドでできます。
ここまでやって様子をみましたが、まだ5分あたり200通のメールが送信されています。秒速1,2通……なんでや……。
正規の情報で送信されていた!
SESではメールの送信状況をログに残すことができて、CloudWatchというのを使うとある程度詳細な情報を残すことができます。この設定もやってみたのですが、メールアドレス自体をログに残すことはできないので、原因は特定できず。
そこで「正規のメール送信がなんらかのバグで繰り返されているのでは?」とあたりを付けました。
このサイトで以前紹介した方法では、「メールファイルをS3に保存して転送する」でしたが、このメールファイルを直接確認してみます。そうすると、全部同じメールでした。mailer-daemonさんからのメール、つまり、メールが不達だったときの自動返信メールです。
まとめると……
example@takahashifumiki.com
にメールが届く。- SES -> S3 -> Lambda という順序でメール転送機能が発動。
example@gmail.com
に転送。 - しかし、
example@gmail.com
は存在しないので、mailer-daemonさんが「このメールアドレスは存在しません」というメールを返送。 - メールを受け取った
example@takahashifumiki.com
がそのmailer-daemonメールを「メール届かなかったよ!」を再びexample@gmail.com
に転送。 - 以下、無限ループ。
なぜこういう地獄のようなことになったかというと、この転送プログラムは「転送先メールアドレスは必ず存在すること」を前提としていたからです。
実際に、ここ2年ぐらい普通に動いていたのですが、原因はこんなところだと思います。
- 転送先はGmailで、Google Apps利用。
- 転送先はGoogle Appsのグループ。
- このグループがなんらかの理由でメールを受け付けることができなくなった。
というわけで、組んだ時は可用性に長けたシステムでも、外部サービス(今回はGoogle Apps)の都合で簡単に壊れてしまうということですね。
なお、メールアドレスをグループメールではないものに変更したところ、送信数は一気に減りました。いまグラフをみてみると、いかにも「無限ループ」という感じですね。
今回の被害額は10,000円程度と、クラウド破産するほどではありましたが、次のような学びを得ました。
- クラウドサービスでは必ず異常値検出を入れよう。
- 複数サービスの結合は簡単に壊れると心得よ、テクノロジー企業は息を吸うように仕様変更する。
というわけで、貴重な週末の自由時間を潰して得た知見がほかの誰かの役に立つことを祈って筆を置きます。
Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)
価格¥3,520
順位217,177位
著佐々木 拓郎, 林 晋一郎, 瀬戸島 敏宏, ほか
発行SBクリエイティブ
発売日2018 年 1 月 20 日