問い合わせフォームに大量スパム。「qq.com」のスパムを対策しました

昨日、当店のお問合せフォームに大量のスパム投稿がありました。

想定以上の挙動を示していましたので、その顛末を記します。同様なスパムに悩む方のご参考になれば幸いです。

「qq.com」ウェブフォームスパムの特徴

今回のスパムは、フォームに対して次のようなデータを送信して来ました。

• 名前　「登陆980585.com住册宋188彩金・・・」で始まる中国語(簡体字)の文字列
• メールアドレス xxxxx@qq.com  (xxxxxの部分はランダムな数字)
• 電話番号 03-5302-2981 (※実在の無関係の会社です。この会社も被害者です)

なお、この「電話番号」は、実在の、スパムとは無関係の会社の電話番号です。

このため、その会社に大変な損害を与えていると考えられます。

被害に遭っている会社様が、その被害の事実を公開しておられます。

弊社電話番号を悪用したスパムにご注意ください | アシストマイクロ株式会社
社名変更とともにHPリニューアルされ、掲載終了しています

スパムのIPアドレスや、会社様のHPの運用状況などから判断して、この会社様がスパムに関与している余地はありません。

スパムの挙動～ログからみる

初回～2回目は普通に閲覧→送信

初回のアクセス

124.6.159.231 - - [15/Jul/2018:21:23:39 +0900] "GET /page_inquiry.php HTTP/1.1" 200 12005 "https://c.89089.site/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36"
124.6.159.231 - - [15/Jul/2018:21:23:39 +0900] "GET /css/css_default.css HTTP/1.1" 200 29588 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36"
124.6.159.231 - - [15/Jul/2018:21:23:39 +0900] "GET /css/css_slider.css HTTP/1.1" 200 6608 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36"
..
中略
..
124.6.159.231 - - [15/Jul/2018:21:23:41 +0900] "GET /fonts/anzu/APJapanesefont.woff2 HTTP/1.1" 200 2527116 "https://curio-shiki.com/css/css_webfont.css" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36"
124.6.159.231 - - [15/Jul/2018:21:23:56 +0900] "GET /favicon.ico HTTP/1.1" 200 15086 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36"
124.6.159.231 - - [15/Jul/2018:21:23:57 +0900] "POST /mod_pagespeed_beacon?url=https%3A%2F%2Fcurio-shiki.com%2Fpage_inquiry.php HTTP/1.1" 204 - "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36"

2回目のアクセス

124.6.159.231 - - [15/Jul/2018:21:35:30 +0900] "GET /page_inquiry.php HTTP/1.1" 200 12005 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0"
124.6.159.231 - - [15/Jul/2018:21:35:30 +0900] "GET /Scripts/lazysizes.min.js HTTP/1.1" 200 6553 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0"
124.6.159.231 - - [15/Jul/2018:21:35:30 +0900] "GET /css/css_slider.css HTTP/1.1" 200 6608 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0"
..
中略
..
124.6.159.231 - - [15/Jul/2018:21:35:32 +0900] "GET /fonts/anzu/APJapanesefont.woff HTTP/1.1" 200 3242288 "https://curio-shiki.com/css/css_webfont.css" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0"
124.6.159.231 - - [15/Jul/2018:21:35:37 +0900] "POST /mod_pagespeed_beacon?url=https%3A%2F%2Fcurio-shiki.com%2Fpage_inquiry.php HTTP/1.1" 204 - "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0"
124.6.159.231 - - [15/Jul/2018:21:35:37 +0900] "GET /favicon.ico HTTP/1.1" 200 15086 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0"

初回～2回目は、通常通り全要素をブラウザで読み込み、POSTしています。

ブラウザが変わっているのが分かります。初回はChrome、2回目はFireFoxと出ています。

このIPアドレスは最後まで一貫しておりますので、お困りの方はこのIPアドレスをブロックしてみてください。(方法は後述)

3回目のアクセスから、直接POSTを叩きに来た

この直後、3回目のアクセスから、挙動が大きく変わります。

連続して、直接POSTメソッドで叩きにきているのです。

124.6.159.231 - - [15/Jul/2018:21:36:00 +0900] "POST /page_inquiry.php HTTP/1.1" 200 9646 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0"
124.6.159.231 - - [15/Jul/2018:21:36:02 +0900] "POST /mod_pagespeed_beacon?url=https%3A%2F%2Fcurio-shiki.com%2Fpage_inquiry.php HTTP/1.1" 204 - "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0"
124.6.159.231 - - [15/Jul/2018:21:36:05 +0900] "POST /page_inquiry.php HTTP/1.1" 200 9955 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0"
124.6.159.231 - - [15/Jul/2018:21:36:15 +0900] "POST /mod_pagespeed_beacon?url=https%3A%2F%2Fcurio-shiki.com%2Fpage_inquiry.php HTTP/1.1" 204 - "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0"
124.6.159.231 - - [15/Jul/2018:21:37:58 +0900] "POST /page_inquiry.php HTTP/1.1" 200 33420 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [15/Jul/2018:21:37:59 +0900] "POST /page_inquiry.php HTTP/1.1" 200 33417 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"

3回目はここで終わり。でも、明らかにおかしいですね。

POSTが連続するということは、問い合わせページそのものを読み込んでいないということになります。

つまり、スパムは問い合わせフォームの中身を解析し、直接メール送信につながるであろうPOSTデータをいきなり送信する挙動に変えたのです。

当店に届いた確認メールからみて、この中で成功したのは2回程度と考えられます。

つまり、さまざまなパターンのPOSTを試して、当店のフォームの構造を確認していたと考えられます。お問い合わせフォームは、お問合せいただいた本人にも確認メールを自動送信しますので、その受信状況をみて判断していたとも考えられます。

4回目以降～大量のPOSTが秒単位でおしよせる

以上で、当店のフォームの構造を確信したと思われるスパムは、少し間をおいたあと、

大量のPOSTを連続して送信し始めます。

124.6.159.231 - - [15/Jul/2018:23:00:52 +0900] "POST /page_inquiry.php HTTP/1.1" 200 42260 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [15/Jul/2018:23:00:52 +0900] "POST /page_inquiry.php HTTP/1.1" 200 42288 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [15/Jul/2018:23:01:08 +0900] "POST /page_inquiry.php HTTP/1.1" 200 42257 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [15/Jul/2018:23:01:08 +0900] "POST /page_inquiry.php HTTP/1.1" 200 42287 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [15/Jul/2018:23:01:22 +0900] "POST /page_inquiry.php HTTP/1.1" 200 42257 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [15/Jul/2018:23:01:22 +0900] "POST /page_inquiry.php HTTP/1.1" 200 42287 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [15/Jul/2018:23:01:35 +0900] "POST /page_inquiry.php HTTP/1.1" 200 42260 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [15/Jul/2018:23:01:35 +0900] "POST /page_inquiry.php HTTP/1.1" 200 42288 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [15/Jul/2018:23:01:51 +0900] "POST /page_inquiry.php HTTP/1.1" 200 42257 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [15/Jul/2018:23:01:51 +0900] "POST /page_inquiry.php HTTP/1.1" 200 42287 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
...

以下、対策終了後も含めて

累計で4500以上にのぼるPOSTのリクエストが並んでいます。

qq.comスパムの対策

休日の深夜でしたが、対策を行いました。

フォームを一時的に閉鎖し、さまざまなテストを行いましたが、

この時点ではログを詳細に解析する時間がなく、結果として効果のない対策に時間をとられることになりました。

入力画面にreCaptchaの設置は意味がないかも…

まず考えたのは、reCaptchaの設置です。

ですが、当店の場合、すでにフォームの内容を解析された後でしたので、この対策はまったく意味がありませんでした。

reCaptchaがある入力画面などすっとばして、直接POSTで叩きにきているのですから・・・。

ただし、初回～2回目までのアクセスは、実際に入力フォームを表示していますので、この段階でreCaptchaがあれば、一定の効果は示せたかもしれません。

しかし、そこだけ人間が操作して解析していれば、これも無効となります。

今後、違うIPアドレスから同種の攻撃が来た場合にも、水際で防げるようにするには、どのようにすればいいのか?

最終的に、当店では「確認画面にInvisible reCaptchaを設置する」という方法をとりました。

特定のメールアドレスを入力エラーにしても、意味がありませんでした

次にとったのは、特定の文字列を含むメールアドレスを、「入力エラー」として取り扱う方法でした。

しかし、これも、入力フォーム自体がすっとばされているわけですから、意味がありませんでした。フォームを再開すると、すぐにスパム投稿が飛んできました。

メール送信モジュールで強制停止は効果がありました

そこで、メール送信モジュールそのものの直前に、カスタムフィルターを直接コーディングして、強制停止させてみました。

(フィルターの中身は、ここでは非公開とさせていただきます)

するとさすがに、スパムは止まりました。POSTで叩きに来ても、メール送信そのものが動作しませんので。

ここで、ようやくスパムの手法の全体像がぼんやりとつかめました。

対策後もアクセス→.htaccessで、IPアドレスをブロック

以上の対策を行っても、攻撃者はまだPOSTを送り続けていました。

124.6.159.231 - - [16/Jul/2018:02:16:08 +0900] "POST /page_inquiry.php HTTP/1.1" 200 53155 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [16/Jul/2018:02:16:09 +0900] "POST /page_inquiry.php HTTP/1.1" 200 10119 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [16/Jul/2018:02:16:18 +0900] "POST /page_inquiry.php HTTP/1.1" 200 44220 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [16/Jul/2018:02:16:19 +0900] "POST /page_inquiry.php HTTP/1.1" 200 10119 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [16/Jul/2018:02:16:29 +0900] "POST /page_inquiry.php HTTP/1.1" 200 44218 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [16/Jul/2018:02:16:30 +0900] "POST /page_inquiry.php HTTP/1.1" 200 10119 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [16/Jul/2018:02:16:41 +0900] "POST /page_inquiry.php HTTP/1.1" 200 44218 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [16/Jul/2018:02:16:42 +0900] "POST /page_inquiry.php HTTP/1.1" 200 10119 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [16/Jul/2018:02:16:52 +0900] "POST /page_inquiry.php HTTP/1.1" 200 44218 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [16/Jul/2018:02:16:53 +0900] "POST /page_inquiry.php HTTP/1.1" 200 10119 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [16/Jul/2018:02:17:04 +0900] "POST /page_inquiry.php HTTP/1.1" 200 44218 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [16/Jul/2018:02:17:05 +0900] "POST /page_inquiry.php HTTP/1.1" 200 10119 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [16/Jul/2018:02:17:15 +0900] "POST /page_inquiry.php HTTP/1.1" 200 44218 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [16/Jul/2018:02:17:16 +0900] "POST /page_inquiry.php HTTP/1.1" 200 10119 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
..
中略
..
124.6.159.231 - - [16/Jul/2018:06:42:48 +0900] "POST /page_inquiry.php HTTP/1.1" 200 10119 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [16/Jul/2018:06:42:58 +0900] "POST /page_inquiry.php HTTP/1.1" 200 44218 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [16/Jul/2018:06:42:59 +0900] "POST /page_inquiry.php HTTP/1.1" 200 10119 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [16/Jul/2018:06:43:09 +0900] "POST /page_inquiry.php HTTP/1.1" 200 44220 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"
124.6.159.231 - - [16/Jul/2018:06:43:10 +0900] "POST /page_inquiry.php HTTP/1.1" 200 10119 "https://curio-shiki.com/page_inquiry.php" "Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)"

じつに4時間以上にわたって、秒単位でPOSTを送り続けているのが分かります。もう完全に人間ではなくボットですね。

けさになって、ログを解析できましたので、発信元のIPアドレスをブロックしました。

order allow,deny
allow from all
deny from 124.6.159.231

reCaptchaは使い方次第。意味がないことも・・・

以上の対策をおこない、現在は平常の運用をおこなっております。

しかし、どうしても気になるのは、reCaptchaがすり抜けられる可能性がある、という点でした。

• BOTがサイトをスクレイピングしてリストアップ
• 攻撃者自身が手動でreCaptchaを突破→フォームを送信・解析
• BOTに解析結果を入力
• BOTによる自動送信ができてしまう

この欠点をどのように補えばよいでしょうか?

効果があるreCaptcha/効果がないreCaptcha

今回のqq.comスパムの挙動から、同じようにreCaptchaを実装していても、効果が見込める場合と見込めない場合が見えてきました。

完全ではないと思いますが、当店の経験のかぎりでまとめてみます。

パターン1: reCaptchaをクリアしないと送信ボタンが押せない実装

まず、reCaptchaをクリアしないと送信ボタンが押せないパターンの実装についてです。

当店の経験としては、プラグイン「MW WP Form reCAPTCHA」のような場合です。

このパターンの実装は、バックのサーバーサイドコードをいじらなくても、Javascriptだけで実装できてしまうので、手軽なのですが、

送信ボタンでのPOSTデータそのものにreCaptchaの結果が含まれないため、今回のようにPOSTメソッドをショートカットで実行されてしまうと、まったく意味をなさない、ということが言えると思います。

この点、Invisible reCaptchaは、送信ボタンそのものがreCaptchaになるわけですから、このような事態にはなりませんね。

パターン2:入力画面にreCaptcha

次に、reCaptchaをクリアしなくても送信ボタンは押せる実装のうち、入力画面のみにreCaptchaがあるパターンです。

突破することが少しだけ困難になりますが、

これもやはり、一度人間の手で突破されてしまうと、確認画面のPOSTは再現可能であり、それをBOTで送信されるとフォームが送信されたことになってしまいます。

パターン3:確認画面にreCaptcha

これが、当店が今回採用した実装方法です。

確認画面→メール送信モジュールに行く過程でreCaptchaをチェックしています。

確認画面をすっとばすインチキをした場合、メール送信モジュールにreCaptchaの成功が伝わらず、実際にメールが送信される前に停止することができます。

バターン4:そこらじゅうにInvisible reCaptcha

まだ当店もここまではやっていませんが、

Invisible reCaptchaが登場したことにより、ユーザーの手を煩わせることなくreCaptchaのチェックができるようになりました。

入力フォームから確認画面から、そこら中の送信ボタンを全部reCaptchaにしても、利便性がまったくそこなわれないわけですから、これはやってみる価値があると思います。

少しくらい攻撃側の技術が進歩しても、多段防御でどこかの時点で停止することができるでしょう。すると、攻撃を阻止することのみならず、サーバーの負荷を軽減することにもつながり、別の意味でサイトを保護することにもなります。

とりあえず確認画面にInvisible reCaptchaを実装しました

というわけで当店としては、

確認画面にinvisible reCaptchaを実装することにしました。

こうすることで、仮に最終画面に行くためのPOSTを取得された場合でも、BOTで実行されている場合は最終画面にreCaptchaの値を渡せず、メール送信はできないはずです。

これで、仮に違うIPアドレスから違うパターンで攻撃されたとしても、それがBOTによる攻撃である限り、防げるはずです。

さらに水際対策: リファラチェックを実施

さらに、フォーム送信モジュールに「リファラーチェック」を実装しました。

自サイトのドメイン以外からPOSTのアクセスがあっても、リファラをチェックすれば遮断できます。

プラグインでの実装が難しそうだったので、直接PHPでコーディングしました。(詳細また追記します)

以上の対策で運用開始しています。

当面これで運用し、何か問題がありましたらここに追記します。

(ここに何も追記がないということは、とりあえずうまくいっているのだ、と理解してください。)