さくらインターネットのメール送信トラブル

普段あまり使っていないメールアドレスで、昨日、イベントの告知メールを送信しようとしたところエラーになりました。
メーラーに表示されたエラーメッセージは、

550 5.7.1 Command rejected, You have reached a limit for sending mail.

というもの。

？

そんな大量のメールの送信はしてないけど…何が原因だろうと、エラーメッセージで検索かけてみると、どうやらレンタルサーバーにインストールしてあるWordpressに不正なファイルが仕掛けられて、そこからリモートでスパムメール配信の踏み台にされていた様子。

設定等いろいろ気を付けてはいたつもりですが、実際のとこ、Wordpressに含まれる各種の脆弱性すべてに対応できないのは現実なので、とにかくトラブルリカバリーを進めることにします。

レンタルサーバーで金銭や売買を扱う訳ではないので、データ取り扱いにリスクはありませんが、メールが送れないのは困りますし、それこそスパムの踏み台を放置してていいこともないですので。

基本的な対応手順は以下の通り。
参考にしたサイトと同じです。

・パスワードの変更
・サーバーコントロールパネルにログインして「メール送信グラフ」画面で状況確認
・「アクセスログの設定」画面でアクセスログを残すように設定
・アクセスログから不審なファイルアクセスを特定
・不審なファイルの削除

とまぁ、こんな流れでした。

パスワードの変更

まずは、メールのパスワード、FTP/コントロールパネルのパスワードを変更します。
せっかく復旧しても、また同じ権限で不正アクセスされたら、やりなおしになるので。

メール送信数を確認

まず、サーバーコントロールパネルにログインして「メール送信グラフ」画面で状況確認します。

メールの送信数が6/22から10,000~18,000通と異常な数になってます。
スパム送信の踏み台になってるのは間違いなさそう。

さくらインターネットのスタンダードプランだとメールの送信上限数が15分ごとに250通までとなってるので、それに合わせて最大限のスパムメール送信が行われてる様子。

なんとかしないと…ですね。

アクセスログを取得

ここで不審なファイルを探すために、アクセスログの取得を行います。
といっても、これはリアルタイムでいつでも取得できるわけじゃなっくて、サーバー上にアクセスログを保存する設定をした上で、深夜12時に、1日分のアクセスログファイルを配信してもらえる…という仕組み。

幸い、この作業をしてるのは午後11時すぎだったので、「アクセスログの設定」を指定して小休止。
ログが配信されるのを待ちます。

ちなみに、このアクセスログファイルもサーバーの容量制限にカウントされるので、容量が心もとない方は、確認の終わったログはサーバー上から削除したほうがいいですし、日常的に見るのでなければ、ログは残さない設定でも問題はない…はず。

12時が過ぎてアクセルログを確認に行きます。

FTPクライアントでログインして…/home/アカウント名/log/の下にある
access_log_20170625
をダウンロードして内容の確認に取り掛かります。

不審なファイルアクセスを特定

アクセスログの取得設定をしたのは午後11時すぎですが、ちゃんと1日分のログが配信されてます。
サーバー本体は当然ながらすべてのアクセスログが取得されていて、その中で希望するユーザーのフォルダにコピーしてるだけでしょうから。

あとは丹念にログを確認していきます。

膨大な量のログなので、ちょいちょい…って訳にはいきませんが、じっくり見ていくと、妙な点が見つかってくる。
最初に疑うべきはphpファイルへの直接アクセス。

WordPressを構成するphp言語に関しては専門的にやったことはないですが、アクセルログを見る限りでは、外部から奥深いフォルダにあるphpファイルに直接アクセスするっていうのがいくつか見つかって、これは不審。

そもそも、画像のアーカイブフォルダや、jsのフォルダの中に唐突に存在するphpファイルがいくつかあって、他所のWordpress環境と比較しながら、本来存在しないはずのファイルもいつくか。

そんなのを一つ一つ丹念に探しながら、削除していきます。

結果的に、

/wp-includes/js/tinymce/utils/フォルダにあったwrycipjs.php

というファイルが今回スパムメールを大量送信していた元凶のようでした。

中身がなんだか分かりませんが、これを復号化して、スパムメールの処理を行ってたんでしょう。

他にも、同様なファイルや、そこに存在しないはずのファイルなどいつくかありましたので、まとめて削除。

送信状況を確認

最初に確認した「メールの送信グラフ」画面には、送信数の他に、直近300件分の送信先と送信時間をリストアップする機能があるので、ここで送信がやんだかどうかの確認が出来ます。

ここで、不審なファイルを削除して15分以上経過しても、新たなスパム送信が発生しなければビンゴ！というわけです。

とうわけで、アクセスログを確認しつつ、不審なファイルを削除しながら、こちらの画面で新たなスパム送信をチェックしつつ、だいたい1時間くらいで、ようやく状況を脱出できました。

疲労困憊。

さくらインターネットへの連絡

いちおう、さくらインターネットへも問合せフォームから、状況の発生と、解決した経緯は連絡してあります。
今のところ返信はありませんが、たぶん他所でも同じような現象が、年中、多発してるんじゃなかろうかと。

何かレスポンスがあれば追記します。

対策ほか

まぁ、これから考えますが、基本的な対策はそれなりに実施してたはずなので、改めて…というほどとれる対策があるわけでなし。

そもそも、サーバー側の脆弱性や、同じレンタルサーバーを共有してる別のアカウントがクラックされたりした場合は、こっちで打てる対策というのが殆ど無い。

他所で盛んにビジネスしてるクラウドとは予算の桁が2つか3つぐらい少ないわけで、この状況の中で万全とはいかないのが現実です。
大手企業だって、ちょくちょく不正アクセスで被害受けてるわけですし。

WordPress本体やプラグイン、テーマのアップデートを追いかける頻度を上げていくぐらいですかね。
最近は、未知の脆弱性が頻繁に表れてるので、これもなかなか効果的とは言い難いですが、できる範囲の中ではやってきましょう。

いずれ、今回の一件で、同様なトラブルのリカバリーは素早く（といってもアクセスログが必要なので、深夜作業になるのは確定ですが…）対応できる目途は立ちましたし。

幸いにも依頼を受けて管理してるサイトじゃなくて、自分で自由に使ってるサイトでのトラブルで済んだので、これで良しとしておきます。