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

ニュースホームページ作成
スポンサーリンク/Sponsored Link

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

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

スポンサーリンク/Sponsored Link

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

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

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

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

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

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

弊社電話番号を悪用したスパムにご注意ください | アシストマイクロ株式会社

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

スポンサーリンク/Sponsored Link

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

初回~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のリクエストが並んでいます。

スポンサーリンク/Sponsored Link

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
スポンサーリンク/Sponsored Link

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による攻撃である限り、防げるはずです。

スポンサーリンク/Sponsored Link

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

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

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

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

 

スポンサーリンク/Sponsored Link

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

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

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

パソコン教室・キュリオステーション志木店からのお知らせ
レッスンはオンラインで受講できます

パソコン教室・キュリオステーション志木店では、本年よりオンラインでの在宅レッスンを実施しております。
教室の全コースがオンラインで受講可能。実際にインストラクターがご対応いたします。
1時間の無料体験レッスンはいつでも予約できます。詳しくは公式ページをご覧ください。

スポンサーリンク/Sponsored Link
キュリオステーション志木店運営をフォローする
志木駅前のパソコン教室・キュリオステーション志木店のブログ

コメント

  1. Kouji より:

    突然失礼します。
    Wordpressの「MW WP FORM」プラグインを使っている場合でも、「Invisible reCaptcha for WordPress」を有効にした場合「MW WP FORM」にも効果はありますか??

  2. アツ より:

    全く同じ手口でqq.comから大量のスパムが10/6〜送られてきました。
    弊社で確認したIPアドレスも同様のものでした。(以下)
    おそらく、だいすけ様へのIPも同様のものです。

    送信者のIPアドレス:124.6.159.231
    送信者のホスト名:124.6.159.231

    私もこちらのページで大変参考になりました。
    現在、被害は止まっております。ありがとうございました。

    • コメントありがとうございます。お役に立ててよかったです。やはり同じIPアドレスから送信しつづけているのですね。IPアドレスも変わらない程度の攻撃だったら、ぜひこのIPアドレスを周知して、未然にふせいでいきたいものですね!

  3. だいすけ より:

    突然失礼いたします。
    同一の被害を受けているものです。問い合わせフォームからだとIPアドレスの特定ができないのですが、どのようにしてできるのでしょうか。

    • コメントありがとうございます。送信元のIPアドレスは、ブログ本文中にありますように、ご利用のサーバーのログ機能を使って特定します。 Xserverの場合は、サーバーパネル→アクセスログ からダウンロードできます。 その他のサーバーをお使いの場合は、お使いのサーバーのマニュアルを参照するか、提供会社にお問い合わせ下さい。  qq.comからのスパムの場合は、もしかしたら当ブログ投稿中のIPアドレスと同じかもしれません。

    • もうひとつの方法は、入力フォームそのものに送信元IPアドレスを管理者あてで送信する機能を実装してしまう方法です。 例えば、Wordpressの「MW WP FORM」プラグインの場合は、次のサイト様の情報が参考になります →  https://www.narugaro.com/web/mw-wp-form%E3%81%AE%E7%AE%A1%E7%90%86%E8%80%85%E5%AE%9B%E3%83%A1%E3%83%BC%E3%83%AB%E3%81%AB%E9%80%81%E4%BF%A1%E8%80%85%E6%83%85%E5%A0%B1%E3%82%92%E4%BB%98%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/

タイトルとURLをコピーしました