WordPressスパムコメントがWordPressブログをクラッシュさせてサーバーを停止するのを防ぐ方法

公開: 2021-08-19

まず、この記事はコメントをスパムとして検出してフラグを立てる方法に関するものではないことを明確にしたかっただけです。 WordPressプラグインAkismetは、従来のWordPressスパムコメントを選別してフィルタリングするという非常に優れた仕事をすでに行っています。

代わりに、この投稿は、コメントスパムやその他の不正なアクティビティがサーバーをクラッシュさせ、ブログを停止させるのを防ぐ方法についてです。

How To Prevent WordPress Spam Comments From Crashing Your WordPress Blog And Taking Down Your Server

BoxChainによる写真

前回の記事で述べたように、私のブログへのトラフィックはこの1年で2倍になりました。

そして残念ながら、その間、スパムコメントの量も桁違いに増加しました。

念のために言うと、12月には、数秒ごとに20件を超えるスパムコメントが殺到する日が数日ありました。

はい、あなたはその権利を聞いた。 ダッシュボードを更新するたびに、Akismetフィルターに20以上のスパムコメントが表示されます。 実際、スパムの量により、サーバー上のすべてのWebサイトが非常に遅くなったり、当時の長期間アクセスできなくなったりしていました。

WordPressの問題

現在、通常の操作では、WP Super Cacheと呼ばれるプラグインがあるため、トラフィックが多い場合でもブログはかなりうまく機能します。

基本的に、このプラグインはブログ内のすべての記事の静的バージョンを作成するため、エンドユーザーに非常に迅速に提供できます。

ただし、コメントを1つずつ処理するためにサーバーが毎回WordPressを呼び出す必要があるため、このプラグインは大量のコメントの流入に対して無力です。

また、WordPressはそのようなリソースを大量に消費するため、専用サーバーを使用していてキャッシュプラグインを使用している場合でも、大量のスパムコメントがブログを簡単に削除する可能性があります。

世界最高のコメントスパムフィルターを使用するかどうかは関係ありません。すべてのスパムコメントは、サーバーリソースのかなりの部分を占めるWordPressによって処理される必要があります。

スパムボットの特徴

現在、ブログの速度が遅い、またはアクセスできないことは1つのことですが、コメントスパムは、同じサーバーで実行されている他のサイトにも影響を及ぼし、受け入れられません。 スパムボットについて調査した後、私はいくつかのことを発見しました。

  • スパムボットは通常、Cookieを受け入れません
  • スパムボットは数秒でコメントスパムを残すことができます
  • スパムボットは通常、JavaScriptを実行しません

では、これはどういう意味ですか? 非技術的な用語では、スパムボットはWebブラウザ上で通常のユーザーのように動作しません。 そして、私の問題を解決するための鍵は、WordPressを起動する代わりに、スパムボットをすぐに検出してエラーページに誘導することでした。

上記の特性に基づいて、ユーザーのマシンにCookieを配置するか、ページの読み込み後にコメントを数秒間無効にするか、スパムボットを検出するためのjavascriptコードを考え出すことで、スパムボットを検出できました。

コメントスパム問題の解決

よく検討した結果、ブログのページにアクセスするたびに、ユーザーのマシンに密かにCookieを挿入する修正を思いつきました。 次に、コメントを通過させる前に、ユーザーのマシンでこのCookieを探すことができます。

スパムボットは通常Cookieを受け入れないため、ボットを簡単に検出して静的エラーページに誘導することができます。

もともと、JavaScriptで書いたこのブログエントリにソースコードを投稿する予定でしたが(興味があれば喜んでお送りします)、数人のブロガーと話をしたところ、同じ作者であることがわかりました。 WP Super CacheのDonnchaは、Cookies For Commentsと呼ばれるプラグインをすでに作成していました。これは、基本的に、私が作成したのと同じことを実行します。

彼のプラグインは私のjavascriptプラグインよりもはるかにエレガントに書かれているので、ダウンロードすることを強くお勧めします。

ただし、DonnchaのCookies For Commentsプラグインを使用する場合は、プラグインのインストール手順とは異なる、.htaccessに次の変更を加えるようにしてください。

デフォルトでは、Donnchaのプラグインは、.htaccessファイルに次の行を挿入することを推奨しています。 (注:最後にあるすべての文字と数字の代わりに、Cookies for Commentsのドキュメントで指定されている独自のCookie値を挿入する必要があります。)

RewriteCond%{HTTP_COOKIE}!^。* 2071a9e39879b6a958b06162384d3c06。* $
RewriteRule ^ wp-comments-post.php – [F、L]


これらの2行は何をしますか? 基本的に、これらのコード行は、ユーザーのマシンに挿入されたシークレットCookieの存在を検出します。 Cookieが存在しない場合、ユーザーまたはスパムボットはWordPressの404ページまたは「ページが見つかりません」に誘導されます。

このデフォルト設定の問題は、まだ多くのサーバーリソースを必要とする404ページを処理するためにWordPressが呼び出されることです。

より良い解決策は、「error.html」がサイトの静的エラーページである次のコードを使用することです。

RewriteCond%{HTTP_COOKIE}!^。* 2071a9e39879b6a958b06162384d3c06。* $
RewriteRule ^ wp-comments-post.php error.html [L]

ここでの違いは、スパムボットが完全に静的なエラーページに誘導されるため、WordPressが完全に読み込まれないことです。

問題が解決しました??? かなりではない

したがって、上記の変更によりコメントスパムの問題は修正されましたが、数日間スムーズに実行された後、サーバーが再びクラッシュし始めました。 サーバーログを見ると、次のことがわかりました。

mywifequitherjob.com GET /oxvumirserver33.rar
mywifequitherjob.com GET /oxvumirserver33.rar
mywifequitherjob.com GET /oxvumirserver33.rar

基本的に、一部の不正なマシンは、サイトをクラッシュさせていたサーバー上の同じ存在しないファイルに何度もアクセスしようとし続けました。 現在、通常のWebサイトでは、これらの不正アクセスはサーバーにまったく影響を与えません。

ただし、WordPressは存在しないファイルへのすべてのアクセスを処理し、ユーザーをWordPressのカスタム404または「ページが見つかりません」Webページに送信します。

WordPressはリソースを大量に消費していると言いましたか? 必要なのはこれらの偽のアクセスの束だけであり、使用するキャッシュプラグインに関係なく、サーバーはダウンします。

この問題を解決する秘訣は、私のコメントスパム問題に似ています。 理想的には、サーバーリソースを節約するために、WordPressを完全に排除し、不正なユーザーを完全に静的なエラーページに送ります。

したがって、私が思いついた解決策は、.htaccessファイルに次の行を追加することでした。

RewriteCond%{REQUEST_FILENAME}!-f
RewriteCond%{REQUEST_FILENAME}!-d
RewriteCond%{REQUEST_URI}!(robots \ .txt | sitemap \ .xml(\。gz)?)
RewriteCond%{REQUEST_FILENAME} \。(css | js | html | htm | rtf | rtx | svg | svgz | txt | xsd | xsl | xml | asf |
asx | wax | wmv | wmx | avi | bmp | class | divx | doc | docx | exe | gif | gz | gzip | ico | jpg | jpeg
| jpe | mdb | mid | midi | mov | qt | mp3 | m4a | mp4 | m4v | mpeg | mpg | mpe | mpp | odb | odc | odf | odg |
odp | ods | odt | ogg | pdf | png | pot | pps | pt | pptx | ra | ram | rar | swf | tar | tif | tiff | wav | wma
| wri | xla | xls | xlsx | xlt | xlw | zip)$ [NC]
RewriteRule。* – [L]

ErrorDocument 404 https://mywifequitherjob.com/404.html

このすべてのコードは何をしますか? 基本的に、上記のタイプのいずれかに一致するファイルがサーバーから要求された場合、サーバーでWordPressを完全にバイパスする必要があります。 ファイルが存在しない場合、ユーザーは404.htmlと呼ばれる静的エラーページに移動します。

繰り返しになりますが、WordPressをバイパスすることが、クラッシュの問題を解決するための鍵です。 サーバーログの不正なプロセスが.rarファイルにアクセスしているため、この悪意のあるユーザーを、実質的にリソースをまったく使用しないエラーページにリダイレクトします。

これは私の問題をすべて解決しますか?

したがって、上記の2つの変更を数週間実行していて、サーバーは速度低下のないチャンピオンのように実行されています。 残念ながら、WordPressの記述方法では、すべての不正アクセスがサーバーをクラッシュさせるのを防ぐことは不可能です。

たとえば、誰かが私のブログにない記事にアクセスしようとすると、WordPressが読み込まれます。 したがって、理論的には、誰かがMyWifeQuitHerJob.comまたはWordPressブログを削除したい場合、彼らがしなければならないのは、サイト上の存在しないページに何度もアクセスすることだけです。

しかし、その間、私の側ではすべてが安定しているようです。 将来的には、WordPressにパッチを適用して、これらのサーバーの問題に対処できるようになることを願っています。