WordPressでブルートフォース攻撃を防ぐ方法（9つの保護レイヤー）

WordPressサイトが公開されている場合、おそらく現在攻撃を受けています。

自動化されたボットは継続的にインターネットをスキャンし、見つけたすべてのWordPressサイトで/wp-login.phpをテストしています。まず「admin」ログインを試し、次に最も一般的なパスワードのリストを試します。

保護されていないサイトは、毎日何百ものこのような試行に、目に見える兆候なしに、静かに攻撃されます。

さらに悪いことに、失敗した攻撃は無料ではありません。ログイン試行ごとにサーバー上でPHPプロセスが起動します。

十分な数の同時試行があると、ホスティングプランは制限に達します。

実際の訪問者はロード時間の遅延やエラーページを目にするようになります。一部のホストは自動的にアカウントをスロットルします。これは、攻撃者が侵入できなかった場合でも発生します。

攻撃が成功した場合、問題は異なります。完全な管理者アクセスは、コンテンツの変更、テーマファイルへのマルウェアの注入、バックドアアカウントの作成、投稿へのSEOスパムの埋め込み、または顧客データの漏洩を意味します。

攻撃が成功した場合の復旧は、最良の場合でも数時間かかります。クリーンなバックアップがない場合は数日かかります。

この記事では、ブルートフォース攻撃からサイトを防御するための最善の方法を紹介します。

主なポイントは次のとおりです：

• 失敗したブルートフォース攻撃でさえ、サイトに損害を与えます。PHPワーカーを使い果たし、ロード時間を遅くし、パスワードが1つも正しく推測される前にホスティングのスロットリングをトリガーする可能性があります。
• クレデンシャルスタッフィングはブルートフォースとは異なります。攻撃者は他の侵害から漏洩した実際のパスワードを使用します。これは、ユーザーが資格情報を再利用している場合、強力なパスワードだけでは不十分であることを意味します。
• WordPressには、組み込みのブルートフォース保護機能はありません。ログイン制限、2FA、WAF機能はすべてプラグインまたはサーバー構成が必要です。
• 二要素認証は、このリストの中で最もリターンの高いステップです。パスワードが正しい場合でも、ブルートフォースとクレデンシャルスタッフィングの両方を停止します。
• XML-RPCのsystem.multicallメソッドは、ほとんどのログインページ防御をバイパスします。これを無効にすると、レート制限プラグインがカバーしない別の攻撃面が閉じられます。
• ログインURLを変更すると攻撃量が減少しますが、主要な防御策ではありません。保護ではなく、手間をかけるものと考えてください。
• 復元したことのないバックアップは、実際には持っていないバックアップです。プレッシャーの下で必要になる前に、四半期ごとに復元プロセスをテストしてください。
• セキュリティプラグインが多いほど、セキュリティが高くなるわけではありません。適切に設定された1つのプラグインは、部分的に設定された4つのプラグインよりも優れています。後者は競合やオーバーヘッドを引き起こす可能性があります。

目次

ブルートフォース攻撃とは？

ほとんどの人は、総当たり攻撃を、パスワードが見つかるまでランダムなパスワードを試すボットだと考えています。それは起こりますが、それはこの攻撃の唯一のバージョンではなく、もはや最も一般的なものでさえありません。

従来の総当たり攻撃 vs クレデンシャルスタッフィング

従来の総当たり攻撃とは、自動化されたソフトウェアが、機能するパスワードを見つけるまで、考えられるすべての文字の組み合わせを試すことです。

長いランダムなパスワードに対しては、これは非現実的です。16文字のランダムなパスワードを総当たり攻撃するには、太陽が燃え尽きるまでの時間よりも時間がかかります。

クレデンシャルスタッフィングは異なり、より危険です。

攻撃者は、他のデータ侵害から漏洩したデータベースを購入またはダウンロードします。これは、侵害されたサービスからのパスワードとペアになった電子メールアドレスです。次に、それらのペアをWordPressサイトでテストします。

ユーザーの1人が、他のすべての場所で使用しているのと同じ電子メールとパスワードでサインアップした場合、クレデンシャルスタッフィングはそれらにアクセスし、最初の試行でログインできる可能性があります。

だからこそ、「強力なパスワードを使用しています」ではユーザーを完全に保護できないのです。あなたのパスワードは強力かもしれませんが、ユーザーのパスワードはそうではないかもしれません。

辞書攻撃は、その中間に位置します。すべての可能な組み合わせではなく、一般的なパスワード、既知のパターン、および実際の単語のバリエーションのキュレーションされたリストをテストします。真の総当たり攻撃よりも高速で、ランダムな推測よりもターゲットが絞られています。

XML-RPCマルチプライヤー

WordPressにはxmlrpc.phpというファイルが含まれています。これは元々、リモート公開とAPI統合のために構築されました。これはsystem.multicallというメソッドを受け入れ、1回のHTTPリクエストで数千ものユーザー名/パスワードの組み合わせを1回の呼び出しでテストできます。

これは重要です。なぜなら、ほとんどのログイン制限プラグインは/wp-login.phpを監視しているからです。xmlrpc.phpを使用したボットは、その保護を完全に回避します。XML-RPCを開いたままログインページをレート制限することは、玄関のドアに鍵をかけ、窓を開けたままにしておくようなものです。

XML-RPCを使用していない場合は、それを閉じることは、このリストの中で最もリターンの高い手順の1つです。レイヤー5でその方法を詳しく説明します。

失敗した攻撃でさえあなたに何がコストがかかるか

1つの正しいパスワードも推測しない総当たり攻撃でさえ、あなたに実質的なコストがかかります。

各ログイン試行はHTTPリクエストです。各リクエストはPHPプロセスを起動します。共有ホスティングでは、プランには有限の同時PHPワーカーが付属しています。

高ボリュームの攻撃は、実際の訪問者にサービスを提供する代わりに、それらのワーカーをログイン試行で満たします。結果は、読み込み速度の低下、タイムアウト、および深刻なケースでは、予期せぬ一時的なホスティング停止です。

また、ログのノイズによって正当なセキュリティイベントが埋もれてしまいます。攻撃者が最終的に侵入した場合、異常なアクティビティをフラグ付けしたであろう失敗した試行ログは、すでに数千のエントリで満杯になっています。干し草の中から針を探しているようなものです。

プラグインレベルの保護は損害を軽減します。サーバーレベルおよびエッジレベルの保護はそれを排除します。これが、このガイドがリストではなくレイヤーとして構成されている主な理由です。

WordPressでブルートフォース攻撃を防ぐ方法

サイトを完全に防御できる単一の設定はありません。効果があるのはレイヤー化です。各レイヤーは、前のレイヤーが見逃したものを受け止めます。

認証情報はほとんどの自動ボットを阻止します。レート制限は、すり抜けたボットを阻止します。WAFは、サーバーに到達する前にボリュームをブロックします。バックアップは、他のすべてが失敗した場合のシナリオをカバーします。

以下のレイヤーは、影響度と実装の容易さの順に並んでいます。上から始めてください。ホスティング設定で可能な限り進んでください。最初の3つのレイヤーだけでも、露出を劇的に減らすことができます。

以下に手順を示します：

• レイヤー 1: 認証情報: デフォルトの管理者ユーザー名を変更し、すべての Вアカウントで一意のパスワードを使用し、すべての管理者に2要素認証を有効にします
• レイヤー 2: ログイン試行回数を制限する: プラグイン経由でログイン失敗試行をスロットルするか、より強力な保護のためにCloudflareまたはサーバーレベルのレート制限を使用します
• レイヤー 3: デフォルトのログインURLを変更する: ほとんどのボットがターゲットとするアドレスを移動し、ログインフォームへの自動攻撃ボリュームを減らします
• レイヤー 4: CAPTCHAを追加する: ログインフォームの自動ボット送信をフィルタリングします。単独で使用するよりもレート制限と組み合わせた場合に最も効果的です
• レイヤー 5: XML-RPCを無効化または制限する: 攻撃者が単一のHTTPリクエストで数千のパスワードをテストし、ログインページ防御をバイパスできるようにする別の攻撃面を閉じます
• レイヤー 6: Webアプリケーションファイアウォール: 悪意のあるトラフィックと既知の悪質なIPをログインページに到達する前にブロックします。CloudflareのようなエッジレベルのWAFは、高ボリューム攻撃中のリソース枯渇を防ぎます
• レイヤー 7: サーバーレベルの強化: IPでwp-login.phpを制限し、Fail2banを実装し、SSHキー認証でSFTPを使用します。VPSおよび専用サーバーの所有者向け
• レイヤー 8: すべてを最新の状態に保つ: 攻撃者がより深く侵入するために総当たり攻撃を行う前に、足がかりを得るために悪用する脆弱性をパッチします
• レイヤー 9: サイトをバックアップする: 最終的な防御レイヤーです。テスト済みのオフサイトバックアップと動作する復元パスは、攻撃が成功してもサイトが終了しないことを保証する唯一の方法です

レイヤー1：資格情報から始める

すべての自動総当たりツールは、ユーザー名「admin」と最も一般的なパスワードから始まります。両方をサイトから削除するには、おそらく5分かかり、ほとんどの自動攻撃試行を即座に排除します。

完全な防御ではありませんが、このガイドのどこよりも時間の投資対効果が最も高いです。

デフォルト以外の管理者ユーザー名を使用する

サイトにWordPressが最初にインストールされたとき、デフォルトのユーザー名として「admin」が提案されました。多くのサイトではこれを変更しません。攻撃者はこれを知っており、すべての総当たりツールはそこから始まります。

異なるユーザー名を使用すると、攻撃者は1つではなく2つの未知数を推測する必要があります。洗練された標的型攻撃に対して劇的な改善ではありませんが、それでも「admin」の推測を乗り越えられない自動ボットの大部分を排除します。

現在のユーザー名を確認するには、wp-adminのユーザー » プロフィールに移動します。ユーザー名フィールドは名前設定にあります。

WordPressではユーザー名を直接変更することはできませんが、新しい管理者アカウントを別のユーザー名で作成し、コンテンツの所有権を移行してから、古い「admin」アカウントを削除することができます。

WP-CLIユーザーは、1つのコマンドでこれを実行できます。

wp user update 1 --user_login=yourname

すべての Вアカウントに強力でユニークなパスワードを使用する

サイト上のすべての管理者アカウントには、それぞれ固有のパスワードが必要です。

クレデンシャルスタッフィングは、他の侵害から既知のユーザー名/パスワードのペアをテストすることによって機能します。ユーザーがサイト間でメールパスワードを再利用し、そのパスワードがどこかで漏洩した場合、クレデンシャルスタッフィングは最初の試行でログインできる可能性があります。

WordPressには、プロフィールの画面で弱いパスワードをフラグ付けする組み込みのパスワード強度メーターが含まれています。これにより最悪の選択肢は止まりますが、最小長を強制したり、再利用を防いだりすることはできません。

より詳細な制御については、Password Policy Managerを使用すると、サイト全体のパスワード要件を設定し、それらを満たさないアカウントの強制リセットを行うことができます。

2要素認証を有効にする

2FAが有効になっている場合、正しいパスワードだけではログインできません。攻撃者は、自分が持っていない物理デバイスからの時間制限のあるコードも必要とします。

これにより、従来のブルートフォース攻撃、クレデンシャルスタッフィング、辞書攻撃が停止します。攻撃者がデータ侵害からあなたの正確なパスワードを入手したとしても、2番目の要素なしではログインできません。

WordPressコアには2FAは含まれていません。プラグインが必要です。

WP 2FAは無料で、積極的にメンテナンスされており、設定が簡単です。Google Authenticator、Authy、1Passwordなどの認証アプリをサポートしています。

miniOrange 2FAとTwo Factorプラグインは、追加の設定の柔軟性を持つ、広く使用されている他のオプションです。

パスキーは、より新しい代替手段です。これらはWebAuthn標準を使用し、設計上フィッシング耐性があります。傍受するコード、SIMスワップするSMS、侵害する認証アプリはありません。プラグインのサポートはまだ成熟していませんが、セットアップが対応している場合は、パスキーを検討する価値があります。

サイト上のすべての管理者アカウントに2FAを適用してください。あなただけではありません。攻撃者が必要とするのは、保護されていない管理者アカウント1つだけです。

レイヤー2：ログイン試行を制限する

デフォルトでは、WordPressは無制限のログイン試行を許可します。ボットは、あなたがコーヒーを淹れる時間で1万回のパスワードを試すことができます。

レート制限は、数回の試行後にそれをカットし、正しい認証情報に近づく前に、問題のあるIPをロックアウトします。

プラグインベースのログインスロットリング

ログインスロットリングプラグインは、IPアドレスごとの失敗した試行を追跡することによって機能します。一定回数の失敗の後、プラグインはそのIPを定義された期間ブロックします。攻撃者のボットは次に進みます。

Limit Login Attempts Reloadedは、最も広く使用されている無料オプションであり、わかりやすい設定画面で、ブロートウェアはありません。

Wordfenceには、より広範な機能セットの一部としてスロットリングが含まれており、複数のセキュリティレイヤーをカバーする単一のプラグインが必要な場合は検討する価値があります。

ほとんどのサイトでは、一時的なロックアウトの前に5〜10回の失敗した試行が合理的な出発点です。

しきい値を低くするとセキュリティは向上しますが、サポートの負担が増える可能性があります。企業のオフィス、大学、モバイルネットワークでは、数百人のユーザーが単一のIPを共有することがよくあります。誰かがパスワードを3回間違えると、他の全員がロックアウトされます。

ユーザーが実際にログインする方法に対して、しきい値をテストしてください。

知っておくべき制限事項の1つ：アプリケーションレイヤーのプラグインは、処理するすべてのリクエストでPHPを呼び出します。真に高トラフィックの攻撃下では、サーバーは依然としてすべてのトラフィックを受信しています。

プラグインは攻撃者が成功するのを阻止しますが、リソースの消費を阻止するわけではありません。それは次のセクションで扱われます。

保護をスタックの上位に移動するタイミング

Cloudflareの無料プランでは、/wp-login.phpおよび/xmlrpc.phpを特にターゲットにしたカスタムレート制限ルールを作成できます。

トラフィックは、サーバーに到達する前にCloudflareのエッジでフィルタリングされます。PHPワーカーは実際の訪問者のために空いたままになります。

これは、プラグインレベルの保護からの最もアクセスしやすいアップグレードであり、費用はかかりません。

レイヤー3：デフォルトのログインURLを変更する

ほとんどの自動ボットは/wp-login.phpをターゲットにします。これはWordPressがデフォルトでログインフォームを配置する場所だからです。カスタムURLに移動すると、ほとんどのボットはそれを見つけることができません。それらは404にヒットし、サイトを行き止まりとして記録し、先に進みます。

これはプライマリ防御ではなく、摩擦レイヤーです。サイトを特にターゲットにした決意のある攻撃者は、他の手段でカスタムログインURLを見つけることができます。

しかし、自動攻撃の量を減らすことには実際の価値があります：

• ログイン試行の失敗回数が少ない
• アクティビティログのノイズが少ない
• デッドリクエストを処理するスロットルプラグインからのPHPプロセスオーバーヘッドが少ない

主なリスクはURLを失うことです。カスタムログインパスを忘れ、ホストが緊急のwp-adminアクセスを提供していない場合、あなたはあなた自身のサイトにロックアウトされます。

この変更を行う前に、カスタムURLをパスワードマネージャーに保存し、ホストの緊急アクセス方法を確認してください。一部のホストは、phpMyAdminアクセスまたはサポート支援によるログインリセットを提供しています。

WPS Hide Loginは最小限の設定でこれを処理します：インストールし、カスタムパスを設定し、保存します。

このステップをより効果的にする追加機能：移動後に元の/wp-login.phpパスで403を返すCloudflareルールを作成します。

そのルールがないと、古いURLは存在し続け、応答するため、永続的なスキャナーは一般的なパスをプローブすることでそれを見つけることができます。古いURLをエッジでブロックすると、そのギャップが閉じられます。

レイヤー4：ログインフォームにCAPTCHAを追加する

CAPTCHAは、人間による操作の証明を要求することにより、自動ボットがログインフォームを送信するのを停止します。毎時数千回ログインページにヒットするスクリプトは、人間のように視覚的または行動的な課題を解決できません。

ほとんどのサイトでは、ログインフォームにCAPTCHAを追加すると、自動送信量が大幅に削減されます。

それが打ち負かせないものではないことに注意してください。CAPTCHA解決サービスが存在します：スケールで課題を解決するためにセント単位で支払われた実際の人間、または古いCAPTCHA形式をクラックするようにトレーニングされた機械学習モデル。

標的を絞り、リソースの豊富な攻撃者に対して、CAPTCHAはスピードバンプにすぎません。ブルートフォーストラフィックの大多数を占める自動ボットに対しては、効果的です。

検討する価値のある3つのオプションは、それぞれ異なるアプローチを取ります。

1. Google reCAPTCHA v3はバックグラウンドで目立たずに実行され、ユーザーの行動をスコアリングし、ユーザーに何も要求せずに疑わしいリクエストをフラグ付けします。
2. hCaptchaはプライバシー重視のスタンスを取り、直接的なドロップイン代替となります。
3. Cloudflare Turnstileは無料で、ほとんどのユーザーにとってシームレスであり、Googleに動作データを送信しません。

3つの中で、Turnstileは新しいセットアップの現在の推奨事項です。プライバシーのトレードオフがより良く、ユーザーエクスペリエンスがよりクリーンです。

WordfenceにはCAPTCHAオプションが含まれています。すでに使用している場合は、個別のプラグインを追加する前に、組み込みのCAPTCHAがログインフォームをカバーしているかどうかを確認してください。

レイヤー5：XML-RPCを無効にするか制限する

XML-RPCはWordPressの元のリモート公開APIであり、REST APIが存在する前の時代に構築されました。ほとんどのサイトではもはや使用されていません。有効のままにしておくと、攻撃者は、これまでに設定したログインページの防御のほとんどをバイパスする別の攻撃面を得ることになります。

Xmlrpc.phpは、数千ものログイン試行を単一のHTTPリクエストにバンドルするsystem.multicallというメソッドを受け入れます。

/wp-login.phpを監視するレート制限プラグインはそれを見ません。CAPTCHAはトリガーされません。攻撃は別のドアを狙っているため、防御の下に着陸します。

無効にする前に、実際に使用しているかどうかを確認してください。JetpackはXML-RPC経由でWordPress.comに接続します。一部の古いモバイル公開ワークフローはそれに依存しています。

Jetpackを使用していないか、モバイルアプリから公開していない場合は、おそらく必要ありません。

Wordfenceのようなセキュリティプラグインには、ログイン設定セクションにワンクリックで切り替えがあります。

フルセキュリティスイートをインストールしたくない場合は、Disable XML-RPC-APIプラグインが軽量な代替手段となります。

NginxまたはApacheでは、サーバーレベルでxmlrpc.phpをブロックできるため、リクエストはPHPにまったく到達しません。

Jetpackまたは他の統合のためにXML-RPCが必要な場合は、エンドポイント全体をブロックするのではなく、system.multicallを特別にブロックすることがターゲットを絞った修正です。Cloudflare WAFルールは、正当なXML-RPC機能を損なうことなくこれを実行できます。

xmlrpc.phpアクセスを知られており安定したソースとの統合のために特定のIPアドレスに制限することも別のオプションです。

新しい統合のための最新の代替手段はREST APIです。XML-RPCを使用していたであろうものを構築している場合は、代わりにREST APIに対して構築してください。

レイヤー6：Webアプリケーションファイアウォールを使用する

Web Application Firewall (WAF)は、受信トラフィックとWordPressサイトの間に配置され、リクエストを検査し、悪意のあるリクエストがログインページに到達する前にブロックします。

ネットワークエッジに近いほど、サーバーが攻撃下で行う作業は少なくなります。プラグインベースのWAFは、サーバーに到達した後に攻撃を停止します。エッジレベルのWAFは、攻撃がそこに到達する前に停止します。

プラグインベースのWAF

WordfenceやMalCareのようなプラグインWAFは、アプリケーション層でリクエストをフィルタリングします。これらは、既知の悪意のあるIPアドレス、ボット署名、および攻撃パターンのデータベースを維持し、WordPressがそれらを処理する前に一致するリクエストをブロックします。

サーバー構成にアクセスできない共有ホスティングのサイトでは、プラグインWAFが適切な出発点となります。

制限は、WAFが評価するすべてリクエストをサーバーがまだ受信することです。大規模な攻撃の下では、PHPはまだ起動し、プラグインはまだ実行され、ホスティングリソースはまだ影響を受けます。攻撃者は侵入しませんが、リソースコストは現実的です。

エッジレベルWAF

Cloudflareの無料ティアは、トラフィックがサーバーに到達する前にグローバルネットワークでフィルタリングします。ボット管理、レート制限、およびTurnstile CAPTCHAチャレンジはすべてエッジで動作します。

サーバーは、Cloudflareがすでにスクリーニングしたトラフィックのみを表示します。大量のブルートフォース攻撃中に、攻撃トラフィックが決して到着しないため、サイトは実際の訪問者にとって高速なままです。

Sucuriは、WordPress固有のルールセットとCDNレイヤーを含むマネージドWAFを提供しています。有料サービスですが、セキュリティ構成を積極的に監視する開発者がいないサイトでは、マネージドルールメンテナンスを検討する価値があります。

WP EngineやKinstaなどのマネージドWordPressホストは、ホスティングスタックの一部としてインフラストラクチャレベルのWAFを含んでいます。これらのプラットフォームのいずれかを使用している場合、おそらくすでにエッジ保護が適用されています。ホストにWAFが具体的に何をカバーしているか、およびカスタムルールが利用可能かどうかを確認してください。

実装する価値のあるCloudflareの構成の1つは、IPアドレスまたはチームのIP範囲を除くすべてのトラフィックを/wp-adminにブロックするカスタムファイアウォールルールです。

予測可能なIPからログインする小規模チーム、または共有VPNで管理されているサイトの場合、これは利用可能な最も効果的な単一ステップの1つです。自動ボットは管理エリアにまったく到達できません。

このルールを有効にする前に、サイトが/wp-admin URLを顧客向け機能（WooCommerceマイアカウントページやメンバーシップポータルログインなど）に使用していないことを確認してください。

レイヤー7：サーバーレベルの強化

独自のサーバーまたはVPSを管理している場合、PHPやWordPressコードに触れる前に攻撃をブロックし、保護をWordPressより上流にプッシュできます。

このセクションは、開発者およびVPSまたは専用サーバーの所有者向けです。サーバー構成へのアクセスなしに共有ホスティングを使用している場合は、レイヤー8に進んでください。

IPによるwp-login.phpの制限

あなたとあなたのチームが常にオフィスネットワークや共有VPNなどの予測可能なIPアドレスからログインする場合、サーバーレベルで/wp-login.phpをそれらのIPに制限できます。他のどのIPからのリクエストも、WordPressがロードされる前に403エラーが返されます。

Nginxでは、サーバーブロック内で次のようになります。

location = /wp-login.php {

allow 203.0.113.10;

deny all;

}

IPを自分のものに置き換えてください。複数のIPに対して複数のallow行を追加します。リストにないアドレスからのリクエストは、PHPに到達することはありません。

これは、WooCommerceサイト、メンバーシッププラットフォーム、または顧客がWordPress経由でログインするセットアップでは機能しません。小規模で安定した管理者チームを持つビジネスまたはポートフォリオサイトに最適です。

Fail2banの実装

Fail2banはサーバーのログを読み取り、定義したパターンに一致するIPアドレスを自動的に禁止します。WordPressの場合、これは、ファイアウォールのブロックリストにIPアドレスが追加されることを意味します。通常はiptablesまたはnftablesを介して、試行回数が重要になる前に、ログに繰り返し失敗したログインエントリを生成したIPアドレスが追加されます。

機能するにはWordPress統合プラグインが必要です。Fail2banは、解析可能な形式でログイン試行の失敗を読み取る必要があり、WordPressはデフォルトでそれらをサーバーログに書き込みません。

WP fail2banがこれを処理し、認証イベントをFail2banが直接解析できる形式で書き込みます。

結果として、ネットワークレイヤーで動作する保護が得られます。ブロックされたIPは、WordPressはもちろん、Webサーバーに到達することさえありません。ログインエンドポイントでのNginxレート制限と組み合わせると、これは利用可能な最も厳格な非エンタープライズ設定です。

SFTPとSSHキーを使用し、FTPは使用しない

ブルートフォース攻撃はログインページだけを標的にするわけではありません。FTPはポート21で実行され、認証情報をプレーンテキストで送信します。攻撃者は開いているFTPポートをスキャンし、wp-login.phpで使用するものと同じ認証情報推測アプローチを実行します。

SFTPは接続を暗号化します。ホストがサポートしている場合は、SFTPに切り替えてFTPを完全に無効にしてください。ほとんどの最新のホストはこれをサポートしており、一部はデフォルトでFTPを無効にしています。

サーバーへのSSHアクセスには、パスワード認証ではなく、キーベースの認証を使用してください。SSHキーペアは、サーバーレイヤーでのパスワード推測ベクトルを排除します。ブルートフォースするパスワードはありません。

ローカルでキーペアを生成し、公開キーをサーバーの~/.ssh/authorized_keysに追加し、sshd_configでパスワードベースのSSHログインを無効にします。

VPSを管理していて、まだこれを設定していない場合は、最初に設定する価値のあることです。

レイヤー8：WordPress、プラグイン、テーマを最新の状態に保つ

ブルートフォースは、最初の攻撃ではなく、2番目の攻撃であることがよくあります。攻撃者は、古いプラグインの脆弱性を悪用して足がかりを確立し、バックドアアカウントを作成したり、権限を昇格させたりすることがよくあります。

ブルートフォースはその後に行われ、既に存在するアカウントを標的にします。最新の状態に保つことで、そもそもブルートフォースを価値のあるものにするエントリーポイントが閉じられます。

WordPressコアは、デフォルトでマイナーバージョンの更新を自動的に処理します。メジャーリリースには手動のアクションまたはホスティングダッシュボードでの明示的な自動更新設定が必要です。

プラグインごとの自動更新は、wp-adminから直接利用できます。プラグイン » インストール済みプラグインに移動すると、各プラグインの右側の列に自動更新を有効にするトグルが表示されます。

ほとんどのサイトでは、すべての有効なプラグインで自動更新を有効にするのが正しい選択です。更新が原因で問題が発生するリスクはありますが、パッチがリリースされてから数週間も脆弱性が知られているプラグインを実行するリスクよりはるかに小さいです。

テーマも同様のロジックに従います。サーバーに置かれている非アクティブなテーマにパッチが適用されていない脆弱性がある場合、アクティブなテーマでなくても悪用される可能性があります。

使用していないものはすべて削除してください。無効になっているからといって安全とは限りません。

プラグインに関しても同様です。非アクティブ化されたプラグインのファイルはサーバー上に残っており、アクセス可能です。それらのファイルに脆弱性が存在する場合、WordPressでプラグインがアクティブであるかどうかにかかわらず、悪用される可能性があります。

プラグインを使用していない場合は、非アクティブ化して残しておくのではなく、完全に削除してください。

複数のサイトを管理するチームの場合、ManageWP、MainWP、Jetpack Manageなどのツールを使用すると、単一のダッシュボードからすべてのサイトの更新を監視および適用できます。10または20のインストールにわたって1つのサイトずつ更新を実行することは、パッチが見逃される原因となるような手間です。

レイヤー9：サイトをバックアップし、復元方法を知る

WordPress.org独自の総当たり攻撃対策ガイドは、それを明確に述べています。テスト済みでオフラインでも利用可能なバックアップを維持し、復元手順を練習してください。

このレイヤーより前のすべてのレイヤーはリスクを軽減します。このレイヤーは最悪の事態を排除します。

攻撃者が他のすべてのレイヤーを突破した場合、最新のバックアップは、1時間の復旧と完全な再構築との違いとなります。バックアップは侵害を防ぐものではありません。それは侵害が実際にどれほど深刻であるかを決定します。

「テスト済み」がその文で最も重要な言葉です。テストとは、ステージング環境で復元を実行し、サイトが正しく起動することを確認し、プレッシャーの中で実行する必要がある前に、プロセスに正確に含まれる手順を把握することです。

四半期ごとに復元テストをスケジュールしてください。1時間もかからず、最悪の瞬間のすべての不確実性を排除します。

Duplicatorでバックアップと復元を自動化する

総当たり攻撃の侵害シナリオでバックアップが特に役立つ理由：オフサイトであり、侵害されたサーバーから独立しており、WordPressが完全にロックアウトされている場合でも機能する復元パスが必要です。

Duplicator Proは、これらの要件をすべて満たしています。

自動スケジュールバックアップは、手動介入なしで、1時間ごと、毎日、毎週、または毎月の間隔で実行されます。スケジュールを一度設定すれば、常に最新の復元ポイントがあります。

ストレージの場合、Duplicator ProはAmazon S3、Google Drive、Dropbox、OneDrive、その他のサードパーティのクラウドサービスに接続します。

Duplicator CloudはDuplicator独自のストレージです。個別のアカウントは不要で、設定するサードパーティサービスもありません。他のオプションとは異なり、WordPressバックアップストレージ専用に構築されました。

何か問題が発生した場合、ファイルをサーバーに再アップロードする前に、クラウドストレージから直接復元できます。サーバーが侵害され、そこに何があるかを信頼できない場合、復元をクラウドコピーから直接プルします。

災害復旧URLは、ほとんどの人が必要になるまで知らない部分です。総当たり攻撃が成功した後、攻撃者が最初に行うことの1つは、管理者パスワードを変更したり、新しいアカウントを作成して元の所有者をロックアウトしたりすることです。

災害復旧URLはwp-adminを完全にバイパスし、ログインできない場合でも復元を開始できます。私はこれを実際のインシデントで一度使用しました。これは、1時間で復旧することと、ホスティングサポートに電話で1日費やすことの違いを生む機能です。

ワンクリック復元は、手動でのファイル転送やFTPアクセスなしで標準的な復旧を処理します。バックアップを選択し、復元をクリックして確認するだけです。それがプロセスです。

ブルートフォースアクティビティを監視する方法

ほとんどのWordPressサイトの所有者は、独自の監視からではなく、ホスティングプロバイダーからの帯域制限通知によって攻撃を受けていることに気づきます。その時点までに、攻撃はすでにサーバーリソースを消費し、ログをノイズで満たし、場合によっては成功しています。

プロアクティブな可視性の設定は1時間未満で完了し、ホストよりも早くサイトで何が起こっているかを知ることができます。

プロアクティブ監視

アクティビティログは、ログイン試行失敗、ログイン成功、ユーザーロールの変更、プラグインの有効化と無効化、設定の変更、ファイルの編集など、サイトで行われたすべての操作の完全な監査証跡を提供します。

その範囲は、ブルートフォース侵害の後で重要になります。侵入した攻撃者は単にログインするだけでなく、変更を加えます。

アクティビティログは、それらの変更を読みやすいタイムラインで表示するため、何がいつ発生したかを正確に把握できます。これは、被害の範囲を特定し、何をクリーンアップする必要があるかを知るために必要な情報です。

アクティビティログに異常なログインアクティビティのメールアラートを送信させます。これにより、ブルートフォース攻撃の後にクリーンアップするのではなく、攻撃を即座に特定して停止することができます。

ホスティングコントロールパネルは、別の監視レイヤーです。オフピーク時のPHPワーカーの急増やCPU使用率の異常は、セキュリティプラグインがアラートをトリガーするのに十分なイベントをログに記録する前に現れる、高ボリューム攻撃の最初の兆候であることがよくあります。

すでに攻撃を受けている兆候

一部の攻撃は自己主張します。他のものはより静かです。

アクティビティログでのログイン試行失敗通知の突然の急増は、最も明確な信号です。通常、1日に2〜3回の試行失敗を目撃していて、突然数百回を目撃している場合、何かが変わったということです。

実際にはログインしようとしなかったユーザーからのロックアウト通知は、より微妙な兆候です。IPベースのロックアウトは、そのIPを共有するすべてのユーザーに影響します。1人がロックアウトを引き起こすと、同じ接続上の他のすべての人をブロックできる企業のオフィスや大学ネットワークなどです。

サポートの受信トレイに、パスワードリセットを試みていない人々からの「ログインできません」というメッセージが届き始めたら、ロックアウトログを確認してください。

ホスティングのエラーログでの遅いwp-admin応答またはPHPワーカー枯渇エラーは、高ボリューム攻撃によるリソース消費を示しています。サイトはまだ機能していますが、本来よりも遅く、ログがその理由を説明しています。

セキュリティインシデントの後、wp-adminのユーザー » 全ユーザーに移動し、管理者ロールでフィルタリングします。

攻撃ウィンドウ中に作成された不正な管理者アカウントは、攻撃者が成功し、バックドアを残した兆候です。インシデントがクローズされたと見なす前に、これをチェックしてください。

機能しないもの（そして人々がまだそれを推奨する理由）

最も一般的に繰り返されるWordPressセキュリティアドバイスのいくつかは妥当に聞こえますが、実際にはほとんど保護を提供しません。違いを知ることで、偽の安心感を与えるものを実装する労力を節約できます。

国によるジオブロッキング

その魅力は明白です。攻撃のほとんどが特定の国から来ているなら、その国をブロックすればよいのです。問題は、ボットネットがそのようには機能しないことです。

ボットネットとは、侵害されたマシンのネットワークのことです。ホームルーター、サーバー、IoTデバイス、マルウェアに感染した通常のコンピューターなどです。これらのマシンは、あなたの国を含むあらゆる場所に存在します。

ロシアや中国からのトラフィックをブロックしても、米国、英国、オーストラリアにノードを持つボットネットを停止させることはできません。これらの国からの正当な訪問者をブロックするだけです。ほとんどのサイトにとって、このトレードオフは割に合いません。

HTTP認証によるwp-adminのパスワード保護

wp-adminディレクトリの前に2番目のパスワードプロンプトを追加することは、有用な追加レイヤーのように聞こえます。実際には、投稿の保存、プラグイン設定の実行、メディアアップロードの処理など、コア機能に依存するWordPress AJAXを破損させる可能性があります。

慎重なAJAX除外を伴ってこれを正しく実装したサイトは機能させることができますが、ほとんどのサイト所有者にとって、設定の複雑さはメリットを上回ります。

よくある質問（FAQ）

次の攻撃の前に、復旧できることを確認してください

ブルートフォース攻撃の実行コストは低下しています。クラウドベースのボットネット、長年の侵害から蓄積されたクレデンシャルデータベース、およびCAPTCHA解決サービスにより、WordPressサイトに対する持続的な攻撃の実行コストはほぼゼロになりました。

この投稿のすべての保護レイヤーはリスクを軽減します。ただし、どれもリスクをゼロにはしません。攻撃が成功してもサイトが停止しないことを保証する唯一の方法は、wp-adminが完全にロックアウトされた場合でも復元できる、テスト済みのバックアップです。

150万以上のWordPressプロフェッショナルが、まさにこの目的のためにDuplicator Proを使用しています。Duplicator Cloudまたは主要なクラウドストレージプロバイダーへの自動スケジュールバックアップ、侵害されたサーバーへの再アップロードなしのリモートリカバリ、ログインできない場合でもサイトを復元できる災害復旧URLなどです。

この投稿を読んでWordPressのセキュリティと復旧について考えたなら、これらのガイドも読む価値があります。

• ウェブサイトをハッカーから保護する方法（究極のセキュリティガイド）
• WordPressは安全か？真実を明らかにします
• WordPressセキュリティチェックリスト：サイトを保護するためのステップバイステップガイド
• ハッキングされたWordPressサイトを復旧する方法（専門家による9つのヒント）
• WordPressサイトのクリーンアップ方法
• WordPressデバッグマスターガイド：基本から応用テクニックまで
• 9つの最高のWordPressデータベースバックアッププラグイン（データを保護するため）