代表社員 廣瀬高之
こんにちわ、クセの強い映像制作会社「トビガスマル」代表の廣瀬です。ある朝、うちのサイトが編集マンの気分転換みたいに別世界へワープ。調べてみると、犯人は——.htaccessが勝手に戻るという怪奇現象でした。
index.phpが何度でも転生し、サーバーの外側には「.htaccess／wp-blog-header.php（3KB）／wp-cron.php（3KB）」の三点セットが潜伏。極めつけは管理者欄に紛れ込んだAl1wpadmin（エルとイチの見分けクイズ）。映画なら笑えるけど、現実は笑えない。
そこで我々は、wp-admin／wp-includesを丸ごと入替→uploadsでPHP実行禁止→鍵（SALT）総入替の三段カットで反撃。この記事では「なぜ飛ぶのか」「どう止めるか」「二度と撮り直し（再感染）しないために」を、実録ベースでテンポよく解説します。準備よろしい？本番、よーい——セキュリティ！
目次
- 1 こうして事件は始まった：症状チェック（リダイレクト／ログイン不可）
- 2 改ざんのサイン：.htaccess・index.php・偽ファイルの見分け方
- 3 犯人は“三点セット”｜外側に潜む .htaccess／wp-blog-header.php／wp-cron.php
- 4 wp-adminの地下室で見つけたウェブシェルと偽管理者（Al1wpadmin）
- 5 復旧の全手順：最短でサイトを戻すチェックリスト
- 6 バックアップ復元のコツ：Web＋DB＋外側フォルダを同日に戻す
- 7 再発防止の実践：uploadsでPHP禁止／鍵の総入替／Xserver設定
- 8 入口はどこだった？ログ解析で分かったこと（アクセスログの読み方）
- 9 よくある質問（FAQ）：巻き戻り・復元時間・費用・プラグイン
- 10 まとめ：今日からできる3つの予防策
こうして事件は始まった：症状チェック（リダイレクト／ログイン不可）
まず疑うべきサイン（“それ、改ざんかも”リスト）
- トップや特定ページを開くと、見知らぬ外部サイトへ自動リダイレクトされる（時々・毎回・端末によって違う）。
/wp-login.phpが真っ白／404／別サイトに飛ぶ（管理画面に入れない）。.htaccessを直しても数十秒で元に戻る（いわゆる“巻き戻り”）。index.phpが異常に大きい、もしくは勝手に再生成される。- サイトのどこかで英語の“安全ではありません”“your site is hacked”的な文言や怪広告が出る。
一次切り分け（3分でできる“犯人は誰だ”テスト）
- シークレットウィンドウ＋別回線で確認（スマホの4G/5Gや別Wi-Fi）。ブラウザ拡張やキャッシュ要因を除外。
- URL直叩きで挙動を比較：
/（トップ）／/wp-login.php／/robots.txt／/sitemap.xml
→ ログインだけ飛ぶ？全部飛ぶ？で“.htaccess改ざん”か“アプリ側”かの見当がつきます。 - 更新日時で犯行時刻をあぶり出す：ファイルマネージャで並べ替え → 同じ時刻で一斉に変わっているフォルダをメモ。
- 外側フォルダ（
/mail、/xserver_php、アカウント直下など）に
.htaccess／wp-blog-header.php(約3KB)／wp-cron.php(約3KB)の“三点セット”がいないかチェック。 - Google Search Console があれば「セキュリティの問題」を確認（警告が出ることがあります）。
“現場保存”のために今すぐやること
- スクショ：リダイレクト先URL、エラーメッセージ、更新日時一覧を撮っておく。
- バックアップ確保：
/public_htmlをZIPでDL、DBをエクスポート（のちの比較に必須）。 - アクセス制限で封鎖（一時）：ベーシック認証を
/public_htmlに設定 or 一時的に.htaccessをRequire all deniedに。
やりがちなNG（被害拡大スイッチ）
- プラグイン大量インストールで“なんとなく”直そうとする（原因が増殖します）。
- .htaccessを何度も上書きだけして終了（書き戻しの発信源が外側に残ると無限ループ）。
- 管理者パスワードを後回し（復旧中にまた入られることがあります）。
プロっぽい確認メモ（必要なら）
- サイズで違和感：正しい
index.phpは数百バイト程度。巨大化していたら要注意。 - .htaccessの怪文書：
<FilesMatch>でphp/phtml/exe/suspectedを許可していたら改ざんパターン。 - ログイン不可の切り分け：
/wp-login.phpだけNG＝WAF/リダイレクト細工の可能性、全ページNG＝.htaccess or ルート改ざんの可能性高。
改ざんのサイン：.htaccess・index.php・偽ファイルの見分け方
危険な .htaccess の例（見たら即アウト）
<FilesMatch>でphp/phtml/exe/suspectedなど本来ブロックすべき拡張子を許可している。- 存在しないはずのファイル名をピンポイントで Allow（例：
wp-confiq.php、wp-crom.phpなど“q”“m”の置換）。 - やたら長い正規表現や大文字小文字混在の拡張子列（例：
Php|PHp|pHp…）。 - 権限が 444/555 固定で編集できない（ロックして書き戻しに使う典型）。
正常な .htaccess（WordPress 既定）は下記だけです：
<IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> index.php の判定（サイズと中身で即わかる）
- 正常：数百バイト。中身はほぼこれだけ。
<?php define('WP_USE_THEMES', true); require __DIR__ . '/wp-blog-header.php'; - 改ざん：数KB〜数百KB以上に巨大化／意味不明な難読（
base64_decode・eval・gzinflateなど）が並ぶ／勝手に再生成される。
“偽ファイル”の典型と居場所
wp-blog-header.php（約3KB）・wp-cron.php（約3KB）がpublic_html の外側（例：/mail/、/xserver_php/、アカウント直下）に出現。wp-admin配下のランダム名の大型PHP（1MB前後）＋同階層の.htaccess(555)。- テーマの
functions.php末尾にユーザー自動作成やリモート実行っぽいコード（wp_insert_user、eval等）。
チェックの進め方（3分クイック点検）
- ルート（
/public_html）の.htaccessを開き、上の「正常版」と一致するか確認。 - ルートの
index.phpのサイズと先頭数行を確認（巨大・難読ならアウト）。 - 外側フォルダ（
/mail/、/xserver_php/、アカウント直下 など）で
「.htaccess／wp-blog-header.php／wp-cron.php」の三点セットを検索。 wp-admin/直下〜下層に不審な大きいPHPと.htaccessが無いかを一覧ソートで確認。
見つけたらどうする？（ミニ初動）
- 権限を 644 に変更してから不審ファイルを削除（444/555 のままでは消せない）。
- ルートの
.htaccessは正常版に戻し、様子見後に444でロック。 - 併せて
wp-admin/wp-includesは公式パッケージで丸ごと入替を前提に。
犯人は“三点セット”｜外側に潜む .htaccess／wp-blog-header.php／wp-cron.php
三点セットとは？（正体と役割）
改ざん時にpublic_htmlの外側へばら撒かれる、下記の不審ファイル三兄弟です。
.htaccess… 実行許可やリダイレクトを仕込み、復旧を巻き戻す司令塔。wp-blog-header.php（約3KB） … 本物を装った偽ファイル。外側から読み込ませる踏み台。wp-cron.php（約3KB） … タイマー役。一定間隔で巻き戻し処理を起動。
この3つが外側に生きていると、ルートの .htaccess や index.php を直しても数十秒〜数分で再汚染されます。
どこに潜む？（よくある隠れ家）
- アカウント直下（例：
/xs123456.xsrv.jp/の直下） /mail/配下（Maildir、Maildir.1など各ユーザー箱）/xserver_php/、/xserver_php/session/、/autoreply//log/、/htpasswd/、/script/など管理系フォルダ
目印：更新日時が同一（例：19:01〜19:03に集中）、サイズが約3KB、.htaccess の権限が 444/555 固定。
なぜ巻き戻るのか（仕組みの超要約）
- 外側の
.htaccessが許可ルールを設定（危険拡張子の実行許可）。 wp-cron.phpが偽物のwp-blog-header.phpを通じて定期実行。- ルートの
.htaccessとindex.phpを上書き再生成 → 復旧が無効化。
安全な除去手順（順番厳守）
- フォルダ単位で巡回：上の「隠れ家」を一つずつ開く。
- 権限解除：各ファイルのパーミッションを 444/555 → 644 に。
- 削除：
.htaccess／wp-blog-header.php／wp-cron.phpをすべて削除。消せなければ.badへリネーム。 - ルート整備：
/public_html/.htaccessを正常版へ戻し、様子見の後に 444 でロック。
<IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> - 観察：30〜60秒待って、
.htaccessの自動改変が止まったことを確認。
消せない時の対処（最終手段）
- フォルダ隔離：親フォルダごと
*.badにリネーム → 新規フォルダをアップ。 - 復元の粒度を落とす：自動バックアップの「対象を指定して復元」で該当フォルダのみ感染前日に戻す。
- サポートに権限リセット依頼：所有者/権限不整合で削除不可な場合は運営に解除依頼。
削除後にやる最小セット（再発防止）
wp-admin／wp-includesを公式パッケージで丸ごと入替wp-content/uploads/.htaccessを作成しPHP実行禁止- 管理者パスワード総入替＋
wp-config.phpの AUTH_KEY/SALT 再生成
wp-adminの地下室で見つけたウェブシェルと偽管理者（Al1wpadmin）
ウェブシェルの特徴（ここを見れば怪しい）
- ファイル名がランダム（例：
WtXAhWdV.phpのような大文字小文字混在）。 - サイズが異常（1MB前後など巨大。通常のWP管理系PHPは数KB〜数十KB）。
- 同階層に
.htaccess(555/444)が置かれ編集不可になっている。 - 中身に
base64_decode/eval/gzinflate/str_rot13などの「難読化関数」が並ぶ。
安全な駆除手順（wp-admin 配下）
- 隔離：
/wp-adminをwp-admin.badにリネーム（フォルダごと隔離）。 - 正規品で置換：WordPress公式パッケージから新しい
wp-admin/を丸ごとアップ。 - 関連ロック解除：隔離先（
wp-admin.bad）内の怪しい.phpと.htaccessは 555→644 にしてから削除。 - コア補強：同時に
wp-includes/も公式で丸ごと入替、ルートのindex.php / wp-blog-header.php / wp-cron.php / wp-load.php / wp-settings.phpを上書き。
偽管理者「Al1wpadmin」の見抜き方と削除
- 見抜き方：
Al1wpadmin（エルとイチ混在）／見覚えのない管理者メール（例：al1wpadmin@gmail.com）。 - UIでの削除手順：ユーザー一覧→該当ユーザーを購読者に変更→更新→削除（投稿は正規管理者に譲渡）。
- SQLでの削除（消えない場合）：phpMyAdmin でIDを確認→
wp_usermeta→wp_usersの順に削除。
“鍵の総入替”で後始末
- 全管理者のパスワード変更（強力なランダムへ）。
- SALT再生成：
wp-config.phpの AUTH_KEY/SALT 8行を新規値で置換→全セッション強制ログアウト。 - アプリケーションパスワード（ユーザープロフィール最下部）を全消去。
- 管理用メール（設定→一般）が攻撃者アドレスに変わっていないか確認。
発見を早めるコツ（運用の型）
- 更新日時ソートで
wp-admin/とwp-includes/を定期巡回（同時刻に一斉更新は要注意）。 - テーマの
functions.phpやmu-pluginsにユーザー作成コード（wp_insert_user等）がないか検索。 - ログイン試行回数制限・ベーシック認証を /wp-login.php / /wp-admin に導入（Xサーバーのアクセス制限で可）。
復旧の全手順：最短でサイトを戻すチェックリスト
A. 初動（5分で封じ込め）
- アクセス遮断：一時的に
/public_html/.htaccessを以下で保存（復旧後に戻す）。
Require all denied - Cron停止：サーバーパネルの Cron を一旦「無効」に。
- バックアップ確保：現状の
/public_htmlと DB をエクスポート（比較用）。
B. “発信源”の除去（外側フォルダの三点セット）
- 以下の場所を一つずつ開き、
.htaccess／wp-blog-header.php(約3KB)／wp-cron.php(約3KB)を発見次第、権限 444/555 → 644 に変更して削除。
- アカウント直下（例：
/xsXXXXXX.xsrv.jp/） /mail/**（Maildir,Maildir.1など各ユーザー箱）/xserver_php/,/xserver_php/session/,/autoreply//log/,/htpasswd/,/script/等
- アカウント直下（例：
- 削除できなければ ファイル名を
*.badにリネーム → サポートへ「所有者/権限リセット」依頼。
C. コアの“正規入替”（手動で盤石に）
- wp-admin 交換：既存
/wp-adminをwp-admin.badにリネーム → 公式パッケージのwp-admin/を丸ごとアップ。 - wp-includes 交換：同様に公式の
wp-includes/を丸ごとアップ。 - ルートのコア上書き：
wp-blog-header.php/wp-cron.php/wp-load.php/wp-settings.phpを上書き。 - index.php 再作成（数百Bが正解）：
<?php define('WP_USE_THEMES', true); require __DIR__ . '/wp-blog-header.php'; - 権限の目安：ディレクトリ 755 ／ ファイル 644
D. .htaccess 整備（短く・堅く）
- ルート：下記だけにして保存 → 様子見して問題なければ 444 に固定。
<IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> - uploads 実行禁止：
/wp-content/uploads/.htaccessを新規作成（444）。
<FilesMatch "\.(?:php|phtml|php5|php7|php8|phps|pht|shtml|cgi|pl|py|exe|suspected)$"> Require all denied </FilesMatch>
E. ログイン後の“鍵の総入替”
- 全管理者のパスワード変更（強力なランダム）。
- SALT再生成：
wp-config.phpの AUTH_KEY/SALT 8行を新しい値に置換（全セッション強制ログアウト）。 - 見知らぬ管理者削除（例：
Al1wpadmin）。アプリケーションパスワードがあれば全削除。
F. 仕上げ（更新・再発防止）
- WP本体／テーマ／必要プラグインを最新に。不要は削除。
- WordPressセキュリティ設定（Xサーバー）：ログイン試行制限ON／XML-RPC制限ON（未使用なら）。
- /wp-login.php・/wp-admin にベーシック認証（アクセス制限機能で追加）。
- 1週間はときどき更新日時ソートで「外側フォルダ」を巡回し、再出現がないか確認。
G. 合格サイン（ここまで来たらOK）
/public_html/.htaccessが勝手に改変されない。- ルートの
index.phpが勝手に肥大化・再生成しない。 - トップページと
/wp-login.phpが正常表示。
バックアップ復元のコツ：Web＋DB＋外側フォルダを同日に戻す
なぜ「同日」復元が重要？
- 整合性の確保：ファイルとDBのズレ（URLやリダイレクト設定）が原因の不具合を防ぐ。
- 書き戻しの遮断：外側フォルダ（
/mail・/xserver_php等）に潜む不正ファイルも同日に戻し、再汚染を止める。 - 原因追跡の明瞭化：同じスナップショットに戻すと、ログとの突合が楽になる。
Xserverでの基本手順（対象を指定して復元）
- Web領域（/public_html）を改ざん前日付に復元。
- 同画面または続けて、外側フォルダも同日に復元：
/mail／/xserver_php／/xserver_php/session／/autoreply／（あれば）/log・/htpasswd・アカウント直下 など。 - MySQLデータベースを同じ日付で復元（別タブ）。
ポイント：「すべてを復元」はメールまで巻き戻すため、通常は“対象を指定”で必要箇所だけ戻す方が安全。
復元が重い／止まる時のコツ
- 粒度を落とす：
/public_html/wp-admin→/wp-includes→ 残り、と順に小さく復元。 - 空き容量の確保：
/wp-content/cacheなどを手動削除してから再実行。 - 同時実行しない：復元ジョブの多重実行はキュー渋滞の元。履歴タブで状態を確認。
復元“後”の必須仕上げ（再汚染防止）
- WordPressコアを公式で上書き：
wp-admin/とwp-includes/を丸ごと入替。ルートのindex.phpほかコアPHPも上書き。 - .htaccess整備：ルートは正常版にして
444固定、wp-content/uploads/.htaccessでPHP実行禁止。 - 鍵の総入替：全管理者のPW変更＋
wp-config.phpの AUTH_KEY/SALT を再生成。
差分データの取り扱い（注意点）
- 復元日以降の投稿・問い合わせ・受注は消える可能性。必要ならバックアップ前にエクスポート、復元後に再投入。
- 会員サイトの場合は、新規ユーザーや更新分の差分を確認して追補。
合格チェック（復元が効いているサイン）
- 30〜60秒待っても
/public_html/.htaccessが勝手に改変されない。 - ルートの
index.phpが勝手に再生成・肥大化しない。 - トップと
/wp-login.phpが正常表示。
再発防止の実践：uploadsでPHP禁止／鍵の総入替／Xserver設定
1) アップロード領域で「PHP実行禁止」
/wp-content/uploads/ はユーザーが書き込めるため、ここを守るだけで被害の大半を未然に防げます。
/wp-content/uploads/.htaccessを新規作成し、下記を保存（権限444）。
<FilesMatch "\.(?:php|phtml|php5|php7|php8|phps|pht|shtml|cgi|pl|py|exe|suspected)$"> Require all denied </FilesMatch> - 同様に、フォーム系プラグインの保存先（例：
/wp-content/uploads/forminator/等）にも配置推奨。
2) “鍵の総入替”でセッション一掃
- 全管理者のパスワード変更（長いランダム／使い回し厳禁）。
- SALT再生成：
wp-config.phpの AUTH_KEY/SALT 8行を新しい値で置換（全ユーザー強制ログアウト）。 - アプリケーションパスワード（ユーザープロフィール最下部）を全削除。
- 見知らぬ管理者の掃除（例：
Al1wpadmin）と、管理用メールの差し替え有無を確認。
3) Xserver側の防御設定（推奨値）
- WordPressセキュリティ設定：ログイン試行回数制限ON／XML-RPC制限ON（未使用なら）。
- ベーシック認証：
/wp-login.phpと/wp-adminに追加（アクセス制限機能）。 - WAF（Webアプリ防火壁）：必ず有効化。誤検知が出るプラグインは個別ルールで許可。
- 自動バックアップの確認：取得サイクルと復元手順を社内で共有。
4) プラグイン／テーマの“衛生管理”
- 不要は削除（停止のまま放置しない）。
- 更新を習慣化：週1回はダッシュボードで更新確認。
- セキュリティ系は1製品に統一（WAFの二重掛けは競合の元）。
5) ログと監視のミニ運用
- 更新日時ソートで「外側フォルダ」（
/mail・/xserver_php等）を週1巡回。 - アクセスログを月1で保存（改ざん時刻の特定に必須）。
- Search Console のセキュリティの問題を有効化し、通知を受け取る。
6) 仕上げチェック（通過点）
/public_html/.htaccessが勝手に改変されない（権限444のまま）。index.phpが肥大化・再生成しない。- 管理画面とフロントが安定表示し、エラーログに不審なPHP実行が出ない。
入口はどこだった？ログ解析で分かったこと（アクセスログの読み方）
何を見る？（改ざん直前1時間をズーム）
- 時間帯：発生推定の前後60分（例：18:30〜19:30）。
- 動詞：改ざんはたいてい
POSTで始まる。POSTの宛先と繰り返し回数を注視。 - 相手：同じIP/国からの連続アクセス（秒間〜分間で何十発）。怪しいUA（空/古いbot名）も手掛かり。
狙われやすいエンドポイント（痕跡の型）
/wp-login.php… 短時間の連続POST（総当たり）→ 成功後に管理画面系へ遷移。/wp-admin/admin-ajax.php… 脆弱なプラグイン経由のPOST。アップロードやオプション改変の入口になりやすい。/xmlrpc.php…system.multicallの大量連投（パスワード類推）。/wp-content/uploads/…… 画像拡張子に偽装したPOST/PUT→ 直後のGET … .php実行で“シェル投下→起動”。
ログの読み方（パターン別の見どころ）
- 同一IPの連続POST：秒間〜分間で数十回。成功後に
/wp-admin/内の色々へGETが伸びる。 - アップロード→実行：
POST /wp-admin/admin-ajax.php（またはフォーム系エンドポイント）直後に、GET /wp-content/uploads/xxx.phpなど実行痕。 - 巻き戻しのトリガ：一定間隔（1〜5分）で
GET /wp-cron.php（偽）や外側パスの.phpにアクセス。
Xserverでの実務（生ログを狙い撃ち）
- サーバーパネル → アクセスログ → 対象ドメイン → 生ログ をダウンロード。
- PC上でテキスト検索（エディタでOK）：「
POST」「admin-ajax.php」「xmlrpc.php」「wp-login.php」「/uploads/」「wp-cron.php」。 - 怪しいIPを見つけたら、そのIPで再検索し時系列を追う（最初の一手→投下→実行→巻き戻し）。
“犯人IP”の扱い（その後に活かす）
- .htaccessでブロック（一例／必要に応じて国やASNでの網羅も検討）
<RequireAll> Require all granted Require not ip 203.0.113.10 Require not ip 198.51.100.0/24 </RequireAll> - WAFのカスタムルールやセキュリティプラグインの拒否リストにも同IPを登録。
改ざんの断面を“確定”させるチェック
- 最初の異常（初回
POST）の時刻とIPを特定。 - 投下の痕（
/uploads/や/wp-admin/下にファイルを置く挙動）が続くか。 - 起動（置いた直後にそのファイルへ
GET … .php）。 - 恒久化（外側の三点セットや偽
wp-cron.phpの周期アクセス）。
ログが欠けている／判別が難しい時
- 復元前の生ログが無いと入口断定は難しい。取れる範囲で時系列とIPだけでも記録。
- FTP/コンパネのログが取得できれば、外側フォルダへの直接配置の有無が分かる。
- 不審プラグインのバージョン履歴と既知脆弱性を照合（古いアップロード系・フォーム系は要注意）。
結論の出し方（クライアント説明用の型）
「時刻（例：19:01）に IP A から POST /admin-ajax.php が集中→直後に /uploads/abc.php へ GET（実行）→以降、アカウント直下の偽 wp-cron.php に周期アクセス——この流れから、プラグイン経由のファイル投下→恒久化が主因と判断。対策はプラグイン更新・uploads実行禁止・管理系強化で再発を遮断。」
よくある質問（FAQ）：巻き戻り・復元時間・費用・プラグイン
Q. .htaccessがすぐ巻き戻るのはなぜ？
原因はpublic_htmlの外側に仕込まれた三点セット（.htaccess／wp-blog-header.php／wp-cron.php）が定期的に書き戻しているためです。外側から権限を644に→削除、その後にルートの.htaccessを正常版＋444で固定すると止まります。
Q. バックアップ復元だけで直る？
Web領域＋DB＋外側フォルダを同じ日付に戻せば基本は直ります。ただし復元“後”の穴塞ぎ（wp-admin/wp-includesを公式で入替、uploadsでPHP禁止、パスワード＆SALT総入替）が必須。ここを省くと再発率が高いです。
Q. 復元にどのくらい時間がかかる？
データ量・空き容量・同時実行状況で変動します。/wp-content/uploadsが大きいと長引きます。進まない場合は、粒度を落として「/wp-admin → /wp-includes → 残り」の順で復元し、同時に手動のコア入替を進めるのが実務的です。
Q. いきなり消して大丈夫？証拠は必要？
駆除前にスクショとバックアップ（現状の/public_htmlとDB）を取得してください。証拠保全後は、三点セットやウェブシェルは即削除でOKです。
Q. 費用の目安は？
ケース次第ですが、復旧＋基本対策でおおむね6.5〜9.5万円、原因分析レポート込みで9.5〜15.5万円が目安です。自社対応できる工程が多いほど圧縮可能です。
Q. セキュリティプラグインは何を使えば？
乗っ取り後はまず一度アンインストールし、.user.iniのauto_prepend_fileやルートのmalcare-waf.php等の残存フックを除去。そのうえで1製品に絞って再導入（二重WAFは非推奨）。
Q. もう入られないために最低限やることは？
- uploadsでPHP禁止（
/wp-content/uploads/.htaccess） - wp-admin / wp-includesを公式で入替＋コアPHPを上書き
- 管理者PW変更＆SALT再生成、不要プラグイン削除＆更新
- /wp-login.php と /wp-admin にベーシック認証、XML-RPC制限（未使用なら）
まとめ：今日からできる3つの予防策
1) 「書ける場所」を守る：uploadsでPHPを永久に禁止
/wp-content/uploads/.htaccessを配置してPHP実行をブロック（権限444）。- フォーム系プラグインの保存先にも同様のルールをコピー。
- 週1回は更新日時ソートでuploads配下にPHPがいないか点検。
2) “鍵”を回す習慣：パスワード＆SALTを定期更新
- 管理者パスワードは長いランダム＋使い回し厳禁、半年に一度は更新。
wp-config.phpの AUTH_KEY / SALT を再生成（全セッション強制ログアウト）。- 見知らぬ管理者／アプリケーションパスワードがないか月例点検。
3) 入口を狭める：Xserverの防御＋基本運用
- WordPressセキュリティ設定：ログイン試行回数制限ON／XML-RPC制限ON（未使用なら）。
- ベーシック認証を
/wp-login.phpと/wp-adminに追加。 - プラグイン／テーマは不要を削除・残りは常に最新に。WAFは一製品に統一。
- アクセスログは月1で保存（改ざん時刻の特定と原因追跡に必須）。
最後に：復旧は“短く正しく”
- .htaccessは短い正規版＋444、index.phpは数百Bの正しい中身。
- 巻き戻りを見たらまず外側（三点セット）を削除、次にwp-admin／wp-includesの正規入替。
- 復元後は鍵の総入替とuploads実行禁止で二度目の撮り直しを防止。
ここまでやれば、次に同じ“事件”が起きても早期検知→短時間復旧が可能です。この記事が、あなたのサイトの“守りの台本”になりますように。🎬
2025.06.22
本記事では、学割付きパッケージを提供する代表的な 3 校 アドバンスクールオンライン・たのまな・デジハリ ONLINE を 価格・講座内容・サポート体制の３視点で徹底比較。 「買うならどこが自分に合う？」「動画講座の質は？」「質問サポートの違いは？」 ──そんな疑問を、早見表...
こんにちわ、クセノツヨイ映像制作会社「トビガスマル」代表の廣瀬です。 このたびご縁がありまして、国際ロープレスキューの普及と発展を担う『GRIMP JAPAN』の公式ウェブサイト制作をお手伝いさせていただきました。 「ロープレスキュー？聞いたことはあるけど、実際どんな活動なの？」という方...
2025.09.19
そう、プロカメラマンの現場で意外と大切なのが 口臭対策。 最高のライティングも、最新のカメラも、口から“昨日の焼き肉フレーバー”が漏れた瞬間に全てが崩れ去ります。 （はい、私も一度やらかしました。シャッターより早く、現場の空気が凍りつくあの瞬間…二度と経験したくありません。） そこ...
コメント