WordPressセキュリティ完全ガイド：ブルートフォース攻撃対策から落とし穴まで

【注意事項】本記事はWordPressのセキュリティ対策について個人的な体験を元に教育目的で書かれています。実装する際は以下の点にご注意ください：

必ず事前にサイトのバックアップを取ってから作業を行ってください
サーバー環境によっては設定が正常に機能しない場合があります
設定ミスによりサイトにアクセスできなくなるリスクがあります
記事内のサンプルコードや例はそのまま使わず、必ず独自の値に変更してください
モバイルテザリングなどIPが変わる環境では特に注意が必要です
本記事の情報を基に行った設定や変更による問題については、筆者は責任を負いかねます

【WordPress セキュリティ強化シリーズの集大成】
この記事は3部構成のWordPressセキュリティ強化シリーズの最終部として、これまでの経験と学びをすべて集約した内容になっています。

第1部：【Cocoon】CSP/クリックジャッキング対策｜中級者ならできるセキュリティ強化
第2部：【Cocoon】.htaccessをいじったせいでAnalyticsとAdSenseが反映されなくなった話
第3部（本記事）：【Cocoon】テザリングの落とし穴！AIOSでブルートフォース攻撃設定をしたら127.0.0.1 でログインできなくなった話

時系列での体験を追いたい方は第1部から順に読むことをお勧めしますが、**実際にセキュリティ設定を実装する際は本記事（第3部）の内容をベースにしてください**。第1部・第2部で紹介した方法には、特定の環境で問題を引き起こす可能性のある設定が含まれています。本記事では、それらの問題点も考慮した、より安全で実用的な設定方法を解説しています。

Contents

はじめに
第1部：ブルートフォース攻撃からの防衛
第2部：セキュリティ設定の落とし穴と解決策
もし侵入されてしまったら？
緊急時のアクセス回復方法のまとめ
結論：多層防御の重要性と注意点
最終的な統合推奨設定：すべてを組み合わせた完全ガイド

はじめに

今回は私がWordPressサイト（Cocoonテーマ使用、ConoHaサーバーで運用中）で実施したセキュリティ対策と、その過程で経験した問題点について解説します。

この記事では2つの重要な内容を扱います：

ブルートフォース攻撃から守るための多層防御戦略
セキュリティ設定の落とし穴と解決策（特にモバイルテザリング環境）

セキュリティを強化しつつも、自分自身がサイトから締め出されないようにするバランスが重要です。

第1部：ブルートフォース攻撃からの防衛

発端：不審なログイン試行の通知

以下のようなメールが定期的に届いていました：

ログインに失敗した回数が多いか、ユーザー名が無効なため、ロックダウンイベントが発生しました:
ユーザー名: tbl-239 IP address: xxx.xxx.xxx.xxx IP range: xxx.xxx.xxx.* Org: Zenlayer Inc AS: AS21859 Zenlayer Inc

（※個人情報保護のため完全にIPアドレスを伏せています）

これが来るたびに「またか」という気持ちでしたが、80桁を超える強力なパスワードを設定していることもあり、実際に侵入されることはないだろうと6年もの間放置していました。ちなみにこのユーザー名はサイト名の頭文字と数字を組み合わせたものでしたが、すでに別のものに変更済みです。調べてみると、これはブルートフォース攻撃（総当たり攻撃）という、ハッカーが自動ツールを使って様々なパスワードを次々と試す攻撃を受けていることを示しています。

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

ハッカーがログインIDとパスワードの組み合わせを機械的に何度も試行する攻撃手法です。「admin」などの一般的なユーザー名に対し、辞書に載っている言葉や一般的なパスワードを何千、何万回と試して侵入を試みるのです。

セキュリティ対策の基本戦略

対策を考える前に、WordPress管理画面への侵入に必要な3つの要素を整理します：

ログインページのURL – 通常はサイトURL + /wp-login.php（デフォルトでは誰でもアクセス可能）
ユーザー名 – WordPress初期設定ではインストール時に「admin」となっていることが多く、変更していない人も多い
パスワード – これが強固であれば安全…だが、それだけでは不十分

私は80桁を超える複雑なパスワードを使用していました。これがどれほど安全かというと：

🔐 パスワードの安全性（豆知識） 50桁の複雑なパスワード（英大小文字+数字+記号、計94種類の文字）の場合、総当たりパターン数は約4.7×10^98通り。最新のGPUで毎秒1兆回試行できたとしても、解読には約4.7×10^86秒かかる計算になります。これは宇宙の年齢（約10^17秒）と比べても桁違いに長い時間です。つまり、理論上は解読不可能です。

しかし、ログインページのURLやユーザー名が簡単に推測できると、攻撃者は延々とパスワードを試し続けることができます。これに対する有効な戦略が「多層防御」です。複数の防衛線を張ることで、攻撃者が全てを突破する確率を下げるのです。

ユーザー名（投稿者スラッグ）の変更

まず最初に、サイトにどんなユーザー名が公開されているか確認しました。WordPressでは「投稿者スラッグ」という形でユーザー名が公開されていることがあります。

スラッグとは？

WebページのURLの一部として使われる文字列のことです。読みやすく、SEOにも影響する重要な要素です。投稿者スラッグは、著者ページのURLに使われるスラッグのことで、例えば https://あなたのサイト.com/author/あなたのスラッグ/ のような形式で表示されます。

実は私の場合、この投稿者スラッグが単純な文字列になっていて、これが攻撃の標的になっていました。また、WordPressのデフォルト設定では「author=1」というパラメータで最初の投稿者（多くの場合は管理者）の情報にアクセスできてしまう仕組みもあります。これらが推測されやすいユーザー名を露出させる原因になっているので、まずこれを変更することにしました。

投稿者スラッグの変更方法

WordPressの管理画面にログイン
「ユーザー」→「プロフィール」を選択
「投稿者スラッグ」の欄を見つけて、複雑な文字列に変更（注意：ここで入力するスラッグは非常に複雑なものにしてください。例として「xYz123AbC789」などを挙げていますが、実際はこれよりもさらに予測困難なものを使用してください）
「プロフィールを更新」ボタンをクリック

投稿者アーカイブページの非表示化

次に、投稿者アーカイブページを非表示にしました。これは「author=1」のようなURLパラメータでユーザー情報にアクセスできないようにする対策です。私の場合、Yoast SEOプラグインを使って設定しました。プロフィールを作成していなかったので初期設定は完了していませんでしたが、この機能だけは普通に使うことができました。

Yoast SEOでの投稿者アーカイブ非表示設定

Yoast SEO → 検索画面 → コンテンツタイプ → アーカイブ
「著者アーカイブを有効にする」のチェックを外す
もしくは「検索エンジンがこの著者のアーカイブを検索結果に表示することを許可しません」にチェック
設定を保存

「Yoast SEOを使っていない」という方は、別の方法もあります。WordPressテーマのfunctions.phpにコードを追加する方法です：

// 投稿者アーカイブへのアクセスをリダイレクト
function redirect_author_archive() {
    if (is_author()) {
        wp_redirect(home_url(), 301);
        exit;
    }
}
add_action('template_redirect', 'redirect_author_archive');

注意：functions.phpを編集する前に必ずバックアップを取ってください。設定ミスでサイトにアクセスできなくなる可能性があります。

この設定により、誰かが/author/あなたのスラッグ/というURLにアクセスしても、サイトのトップページにリダイレクトされるようになります。

管理画面URLの変更（核心部分！）

ここからが本記事の核心です。WordPressのデフォルト設定では、誰でも/wp-login.phpや/wp-admin/にアクセスできてしまいます。これらのURLは全世界のWordPressサイトで共通ですから、攻撃者は簡単に見つけることができます。これを変更することで、攻撃者にログイン画面の場所すら見つけられないようにします。

この設定には2つの方法があります：

.htaccessファイルを直接編集する方法
セキュリティプラグインを使用する方法

方法1: .htaccessファイルを編集する

注意：.htaccessファイルの編集は慎重に行ってください。設定ミスによりサイト全体にアクセスできなくなる可能性があります。必ずバックアップを取った上で実施してください。

まず試したのは.htaccessファイルを編集する方法です。サーバーのファイルマネージャーを使って、サイトのルートディレクトリにある.htaccessファイルを開き、以下のコードを追加しました：

# カスタムログインURL設定 
<IfModule mod_rewrite.c> 
RewriteEngine On 
# カスタムURLを設定（以下のURLは例です。実際の使用時は必ず独自の複雑な文字列に変更してください）
RewriteRule ^my-secret-login$ wp-login.php [NC,L] 
# 標準のログインページへのアクセスをブロック 
RewriteRule ^wp-login\.php - [R=404,L] 
# wp-adminへのリダイレクト処理 
RewriteRule ^wp-admin$ wp-admin/ [R=301,L] 
# ログイン状態でない場合にwp-adminへのアクセスを新しいログインURLにリダイレクト 
RewriteCond %{QUERY_STRING} !^action=logout 
RewriteCond %{HTTP_COOKIE} !wordpress_logged_in 
RewriteRule ^wp-admin/ /my-secret-login [R=302,L] 
</IfModule>

（注：実際の使用時は「my-secret-login」の部分を独自の複雑な文字列に変更してください。サンプルコードをそのまま使用しないでください。）

しかし、このやり方には注意点があります。既存の設定との競合や、サーバー環境によっては機能しないことがあります。私の場合も、このやり方では問題が解決しませんでした。そこで次の方法を試しました。

方法2: セキュリティプラグインを使用する（推奨）

「All In One WP Security」というプラグインには、管理画面URLを簡単に変更できる機能が備わっています。

管理画面から「All In One WP Security」→「WP Security」→「Brute Force」
ログインページの名前変更機能をクリック
「ログインページの名前変更機能を有効化」にチェック
「ログインページ URL」欄に独自の文字列を入力（非常に重要：ここには「xyz123abc」などの単純な例ではなく、必ず20文字以上の予測困難な独自の文字列を使用してください）
「変更を保存」ボタンをクリック

注意点: このプラグインの警告にもあるように、「この機能はサーバーの設定によっては正しく動作せず、管理者アカウントからロックアウトされる可能性があります」。でも心配しないでください！プラグイン経由なら多くの場合、設定を元に戻す方法も用意されています。私はこのプラグインの方法で成功しました。

重要な補足: カスタムURLの選び方

カスタムURLを選ぶときのポイント：

最低でも20文字以上の長さ（セキュリティを高めるため）
英数字を組み合わせたランダムな文字列
意味のある単語や名前を避ける
大文字・小文字・数字・特殊記号を混ぜるとさらに安全

設定後は必ずこのURLをパスワードマネージャーやセキュアなメモに保存しておきましょう。忘れるとサイトにログインできなくなります！

設定の確認方法

設定が正しく機能しているか確認するには、シークレットモード（プライベートブラウジング）を使うのがベストです。毎回キャッシュをクリアしたりリロードしたりする手間が省けます。通常のブラウジングモードだと、既にログイン済みのセッション情報やキャッシュが残っているため、正確なテストができないことがあります。

シークレットモードの開き方（基本的な教養として覚えておくと便利）

Google Chrome: Ctrl + Shift + N (Windows/Linux) または Command + Shift + N (Mac)
Firefox: Ctrl + Shift + P (Windows/Linux) または Command + Shift + P (Mac)
Edge: Ctrl + Shift + N (Windows) または Command + Shift + N (Mac)
Safari: Command + Shift + N

確認すべきポイント

新しいカスタムURL（例：https://あなたのサイト.com/あなたの複雑な文字列）にアクセスし、ログイン画面が表示されるか
標準のログインURL（https://あなたのサイト.com/wp-login.php）にアクセスし、404エラーが表示されるか
管理画面URL（https://あなたのサイト.com/wp-admin/）にアクセスし、404エラーが表示されるか、またはカスタムログインURLへリダイレクトされるか
投稿者アーカイブ（https://あなたのサイト.com/author/あなたのスラッグ/）へアクセスし、トップページにリダイレクトされるか

実際に確認してみると、1と2については想定通りでしたが、3の管理画面URLへのアクセスも404エラーになりました。All In One WP Securityプラグインの設定では、ログアウト状態での/wp-admin/へのアクセスも完全にブロックしているようです。これは攻撃者に対して「このサイトには管理画面が存在しない」と思わせることができるので、むしろセキュリティ面では良い結果です。

「でも、実際に設定してそれで終わり？その後どうなったの？」

これらの対策を実施した後でも、警告メールは来続けることがありました。しかし、メールをよく見ると、攻撃者はまだ「tbl-239」というユーザー名でログインを試みています。しかも、これはログイン試行が行われた証拠なので、攻撃者が何らかの方法でログインページにアクセスできている可能性があります。これは「セキュリティ対策が機能している証拠」ではなく、むしろ「カスタムURLが何らかの形で漏洩している可能性」を示唆しています。

モバイルテザリング環境での追加対策

私は自宅でもオフィスでもネット環境を100%スマホのテザリングで補っています。こういった環境だとIPアドレスが毎回変わるため、「特定のIPからのみアクセスを許可する」という一般的なセキュリティ対策は使えません。そんな特殊な環境でも実施できる追加対策をご紹介します。

2段階認証の導入（最重要）

注意：2段階認証の設定ミスによってもサイトからロックアウトされる可能性があります。必ずバックアップを取った上で、テストアカウントなどで動作を確認してから実施してください。

All In One WP Securityなどのプラグインを使って、2段階認証を設定できます。これにより、パスワードが漏洩しても、認証コードなしではログインできません。

設定方法：

All In One WP Security → WP Security → 2段階認証
「Two Factor Authentication」を有効化
スマートフォンに「Google Authenticator」アプリをインストール
QRコードをスキャンして連携

ユーザーエージェント制限（プロ向け）

特定のブラウザ（例：Chrome）からしかログインできないよう制限することも可能です。以下のコードを.htaccessに追加します：

# Chromeからのアクセスのみ管理画面へのアクセスを許可
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/あなたのカスタムURL [NC]
RewriteCond %{HTTP_USER_AGENT} !Chrome [NC]
RewriteRule .* - [F,L]
</IfModule>

「ユーザーエージェント」とは？ ウェブブラウザが自分自身を識別するための情報です。例えば「これはChromeブラウザです」「これはFirefoxブラウザです」といった情報を含みます。

より複雑なカスタムURL

もう一段階セキュリティを高めるなら、URLをさらに複雑にする方法があります：

20文字以上の長さ
大文字、小文字、数字、特殊記号を含める
例：jP4!mK8@cV7$dL9#eF2%（※実際の使用時はこの例をそのまま使わず、独自の文字列を作成してください）

第2部：セキュリティ設定の落とし穴と解決策

突然のアクセス拒否：問題の発生

セキュリティ対策を実施した後、ある日突然以下のようなエラーが表示されてサイトにアクセスできなくなりました：

このサイトにアクセスできません
127.0.0.1 で接続が拒否されました。

直前まで通常通りアクセスできていたサイトが突然表示されなくなる状況は、サイト管理者として非常に焦りを感じるものです。特にECサイトなど収益に直結するサイトであれば、一刻も早い復旧が求められます。

「127.0.0.1」の意味と原因の特定

「127.0.0.1」とは「ローカルホスト」と呼ばれる特殊なIPアドレスで、つまり「自分自身のコンピュータ」を指します。通常、外部サーバー上のWordPressサイトがこのアドレスを表示することはありえません。

原因を探っていく中で、以前に設定したセキュリティ対策が関係していることに気づきました。All in One WP Security & Firewallプラグインの設定で、不審なアクセスを127.0.0.1にリダイレクトする機能を有効にしていたのです。皮肉なことに、私自身が「不審なアクセス」と判定されてしまっていたのです。

問題解決への道：設定ファイルの直接編集

最大の問題は、管理画面にアクセスできないためプラグインの設定を変更できないことでした。しかし、同様の問題を経験した他のユーザーのフォーラム投稿を発見し、解決策を見つけました。

ConoHaのファイルマネージャーを使用して設定ファイルを直接編集する必要がありました。具体的な手順は以下の通りです：

ConoHaコントロールパネルにログイン
サーバー管理 → ファイルマネージャーを選択
サイトのルートディレクトリ（public_html）に移動
wp-content → uploads → aios → firewall-rules フォルダと進む
settings.php ファイルを見つけて編集モードで開く

ファイルの内容は次のようなJSON形式になっています：

<?php __halt_compiler();
/**
 * This file was created by All In One Security (AIOS) plugin.
 * The file is required for storing and retrieving your firewall's settings.
 */
{"aios_enable_rename_login_page":"1","aios_login_page_slug":"sd33ea17mym","aios_enable_brute_force_attack_prevention":"1","aios_brute_force_secret_word":"XeonFortress","aios_cookie_based_brute_force_redirect_url":"http:\/\/127.0.0.1","aios_brute_force_attack_prevention_pw_protected_exception":"1","aios_brute_force_attack_prevention_ajax_exception":"1",...}

この中から以下の部分を見つけ：

"aios_enable_brute_force_attack_prevention":"1"

この値を空（””）に変更します：

"aios_enable_brute_force_attack_prevention":""

変更を保存した後、再度サイトにアクセスするとリカバリーモードからログインできるようになりました。この操作は非常にデリケートなので、必ずバックアップを取ってから行うことをお勧めします。

根本原因：モバイルテザリングとIPベースのセキュリティの相性問題

この問題が発生した根本的な原因は以下の点にあります：

モバイルテザリングの使用：私は自宅でもオフィスでも固定回線を契約しておらず、いつもスマホのテザリングでネット環境を補っています。これにより、接続するたびにIPアドレスが変わる状況でした。
IPベースのセキュリティ設定：All in One WP Securityプラグインのブルートフォース防止機能は、不審なIPの変化を検出してブロックする仕組みです。
誤検知の発生：IPが頻繁に変わるテザリング環境で、正規ユーザー（私自身）が「攻撃者」と誤って判定されました。

適切な設定：モバイルテザリング環境での推奨対策

この経験から、特にIPが変わりやすい環境でのWordPressセキュリティ設定について重要な教訓を得ました。

1. IPベースのブロック機能を無効化

All in One WP Securityの以下の機能は、モバイルテザリング環境では無効にすることを推奨します：

Cookieベースの総当たりログイン防止機能：この設定がオンの場合、IPが変わるとブロックされる可能性があります。
404検出オプション：不審な404エラーを検出してブロックする機能も同様の問題を引き起こします。

2. 代替となるセキュリティ対策

IPベースの制限に頼らない以下のセキュリティ対策を組み合わせることで、安全性を維持できます：

ログインページのURL変更：標準の「wp-login.php」ではなく、カスタムURLを使用する
CAPTCHA設定：ログイン画面に認証を追加する
ハニーポット設定：CSSで隠された入力フィールドを設置する方法もあります：

// functions.php に追加
add_action('login_form', 'add_honeypot_to_login');
function add_honeypot_to_login() {
  echo '<style>.honeypot-field { display: none; }</style>';
  echo '<p class="honeypot-field"><label for="honeypot">Leave this empty</label><input type="text" name="honeypot" id="honeypot" value=""></p>';
}

add_filter('authenticate', 'check_honeypot_field', 10, 3);
function check_honeypot_field($user, $username, $password) {
  if (!empty($_POST['honeypot'])) {
    return new WP_Error('authentication_failed', __('<strong>ERROR</strong>: Bot detected.'));
  }
  return $user;
}

このコードは、人間には見えない入力フィールドを作成します。ボットはこのフィールドに入力してしまうため、入力があった場合はボットと判断してブロックします。

二段階認証の導入：Google Authenticatorなどのアプリを使用した追加認証を設定する

3. 必要な場合の慎重な設定

どうしてもIPベースの制限が必要な場合は、以下の設定を検討してください：

404ロックアウト転送URL：127.0.0.1ではなく外部サイト（Google.comなど）に設定ただし、127.0.0.1への転送にも利点があることを理解しておくべきです。この設定は攻撃者のサーバーに無駄な負荷をかけさせる効果があります。127.0.0.1に転送すると、攻撃者のリクエストは自分自身のコンピュータに向けられるため、攻撃効率が下がります。つまり、セキュリティの観点では理にかなった設定なのですが、モバイルユーザーには自分自身をロックアウトする危険性があるという矛盾が生じています。
ロックアウト時間：短時間（2〜5分程度）に設定して影響を最小限に抑える

もし侵入されてしまったら？

万が一、サイトに不正アクセスされた場合の対処法も知っておきましょう：

すぐにサイトをオフラインにする：一時的にメンテナンスモードにするか、サーバー側で一時停止します
ログを確認：不審なアクセスの痕跡を調査します
マルウェアスキャン：WordPressのセキュリティプラグインでスキャンを実行します
パスワードの変更：管理者アカウントを含む全てのパスワードを変更します
バックアップから復元：クリーンな状態のバックアップがあれば復元します
WordPressを最新版に更新：コアファイル、テーマ、プラグインを全て更新します
追加の対策を実施：本記事で紹介した対策を実施します

緊急時のアクセス回復方法のまとめ

セキュリティとアクセス性のバランスを考慮し、以下の情報を安全な場所に保存しておきましょう：

settings.phpファイルの場所（wp-content/uploads/aios/firewall-rules/settings.php）
aios_enable_brute_force_attack_preventionの修正方法
リカバリーモードのアクセス方法

結論：多層防御の重要性と注意点

本記事で説明した対策をまとめると、以下の「多層防御」が実現できます：

第一防御層: ログインページのURLを秘匿
第二防御層: ユーザー名（投稿者スラッグ）を予測困難なものに変更
第三防御層: 強力なパスワード
第四防御層: 2段階認証

ただし、モバイルテザリングなどIPが変わる環境では以下の点に注意が必要です：

All in One WP Securityプラグインのブルートフォース防止機能は慎重に使用する
「ブルートフォース防止」機能と「404検出オプション」の両方で127.0.0.1へのリダイレクト設定がある場合、自分自身がサイトから締め出される可能性がある
セキュリティを強化する際は、「自分が入れなくなる」リスクも考慮した多層防御が重要

思い返せば、私も最初は「なぜこんな手間をかけるんだろう」と思いました。でも、一度設定してしまえば、あとは普段のログイン時に少し違うURLを使うだけ。この小さな手間で、何倍ものセキュリティ向上が実現できるのです。同時に、緊急時のリカバリー方法も知っておくことで、万一の場合も冷静に対処できます。

「そもそもなぜブルートフォース攻撃を受けるのか？」という疑問をお持ちの方も多いでしょう。実は、攻撃者は特定のサイトを狙っているわけではなく、インターネット上の全WordPressサイトに対して自動化ツールで総当たり攻撃を仕掛けているのです。サイトの規模に関わらず、WordPressを使っていれば誰でも標的になり得ます。だからこそ、基本的なセキュリティ対策と、必要に応じてリカバリー方法も知っておくことが必須なのです。

最終的な統合推奨設定：すべてを組み合わせた完全ガイド

このシリーズの3部を通じて学んだすべての対策を統合した、最終的な推奨設定を以下にまとめます。この設定は、セキュリティヘッダー、CSP設定、ブルートフォース対策をバランス良く組み合わせたものです。特にモバイルテザリングなどIP変動環境でも問題が発生しにくいよう調整しています。

ステップ1: セキュリティヘッダーの設定（.htaccessファイル）

以下のコードをWordPressの.htaccessファイルの「# BEGIN WordPress」行の前に追加してください：

# BEGIN Security Headers
<IfModule mod_headers.c>
    # HSTS設定
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    
    # X-Frame-Options設定
    Header always set X-Frame-Options "SAMEORIGIN"
    
    # Content-Security-Policy設定（Google Analytics、AdSense、SNS対応）
    Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://*.google-analytics.com https://*.googletagmanager.com https://ajax.googleapis.com https://cdnjs.cloudflare.com https://platform.twitter.com https://*.googlesyndication.com https://*.doubleclick.net https://connect.facebook.net; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: https://*.google-analytics.com https://*.googletagmanager.com https://secure.gravatar.com https://*.googlesyndication.com https://*.doubleclick.net https://*.twimg.com https://*.fbcdn.net; font-src 'self' data: https://fonts.gstatic.com; connect-src 'self' https://*.google-analytics.com https://*.analytics.google.com https://*.googletagmanager.com https://*.googlesyndication.com https://*.doubleclick.net; frame-src 'self' https://platform.twitter.com https://syndication.twitter.com https://*.googlesyndication.com https://*.doubleclick.net googleads.g.doubleclick.net https://www.facebook.com https://www.youtube.com;"
    
    # Permissions-Policy設定
    Header always set Permissions-Policy "camera=(), geolocation=(), microphone=(), payment=()"
</IfModule>
# END Security Headers

ステップ2: ブルートフォース対策（All In One WP Security）

All In One WP Securityプラグインをインストールして以下を設定：

ログインページのURL変更：WP Security → Brute Force → 「ログインページの名前変更機能を有効化」にチェック → 独自の複雑な文字列（20文字以上）を設定
Two Factor Authentication：WP Security → Two Factor Authentication → 「Two Factor Authentication」を有効化
注意：モバイルテザリング環境では以下の機能を無効にしてください：
- 「Cookieベースの総当たりログイン防止機能」
- 「404検出オプション」のブロック機能

ステップ3: 投稿者スラッグ変更とアーカイブページの非表示化

WordPress管理画面 → ユーザー → プロフィール → 「投稿者スラッグ」を複雑な文字列に変更
Yoast SEO使用の場合：Yoast SEO → 検索画面 → コンテンツタイプ → アーカイブ → 「著者アーカイブを有効にする」のチェックを外す
または、functions.phpに以下を追加：

// 投稿者アーカイブへのアクセスをリダイレクト
function redirect_author_archive() {
    if (is_author()) {
        wp_redirect(home_url(), 301);
        exit;
    }
}
add_action('template_redirect', 'redirect_author_archive');

ステップ4: 緊急時のアクセス回復方法メモ（必ず安全な場所に保存）

下記の情報をパスワードマネージャーなどの安全な場所に保存しておくことで、万が一アクセスできなくなった際に復旧できます：

# 緊急アクセス回復情報

カスタムログインURL: [ここに自分のカスタムURLを記録]

settings.phpファイルの場所: 
wp-content/uploads/aios/firewall-rules/settings.php

ブルートフォース防止機能の無効化方法: 
"aios_enable_brute_force_attack_prevention":"1" を "aios_enable_brute_force_attack_prevention":"" に変更

ステップ5: テーマのカスタマイズ（functions.php）への追加（オプション）

さらにセキュリティを強化したい場合は、以下のコードをテーマのfunctions.phpに追加して、ログインページにボット対策用のハニーポット機能を導入できます：

// ログインフォームにハニーポット機能を追加
add_action('login_form', 'add_honeypot_to_login');
function add_honeypot_to_login() {
  echo '<style>.honeypot-field { display: none; }</style>';
  echo '<p class="honeypot-field"><label for="honeypot">Leave this empty</label><input type="text" name="honeypot" id="honeypot" value=""></p>';
}

add_filter('authenticate', 'check_honeypot_field', 10, 3);
function check_honeypot_field($user, $username, $password) {
  if (!empty($_POST['honeypot'])) {
    return new WP_Error('authentication_failed', __('<strong>ERROR</strong>: Bot detected.'));
  }
  return $user;
}

このセキュリティ設定は、セキュリティと利便性のバランスを考慮した総合的な推奨設定です。サイトの特性や要件に応じて適宜カスタマイズしてください。何よりも大切なのは、必ず事前にバックアップを取ってから設定を変更することです。

このシリーズを通じて、セキュリティ設定の難しさは「堅牢さ」と「使いやすさ」のバランスにあることを学びました。過剰なセキュリティは自分自身をロックアウトする危険性があり、緩すぎるセキュリティはサイトを危険にさらします。この記事で紹介した設定は、その最適なバランスを目指したものです。