SiteGuard と CloudSecure を比べる：SiteGuard に統一し、ログインの URL の落とし穴も直した

セキュリティ対策, プラグイン関連

広告WordPress・PHP を学べる本

Amazonのアソシエイトとして、WordPress functions.phpは適格販売により収入を得ています。

セキュリティ用のプラグインとしてSiteGuard WP Plugin をよく使っているのですがエックスサーバーで WordPress を入れると、CloudSecure WP Security も一緒に入れられるようになりました。

どちらを使うのがよいのか、公式の情報で比べました。

結論から書くと、保守を行っているサイトは SiteGuard に統一しました。

また、調べている途中で、ログインの URL を変えたときに起きる問題が 2 つ見つかったので、直し方もまとめます。

数字は 2026-10-12 に公式のページで確かめたものです。

2 つのプラグイン

	SiteGuard WP Plugin	CloudSecure WP Security
作っているところ	JP-Secure	エックスサーバー（WordPress.org の作者もエックスサーバー）
料金	無料（WordPress.org から入れられる）	無料（WordPress.org から入れられる）
主な役目	ログインの守り・管理画面の守り	ログインの守り・管理画面の守り・通知

どちらも、有料の段階があるとは公式のページに書かれていません。

機能の比べ

機能	SiteGuard	CloudSecure
ログインの URL の変更	あり	あり
画像認証	あり	あり
ログインのロック（何度も失敗したら止める）	あり	あり
ログインの通知（メール）	あり	あり
2 段階認証	なし	あり（認証アプリかメール・予備のコード）
ログインのエラー文をまとめる	あり	あり
フェールワンス（最初の正しいログインをわざと失敗させる）	あり	なし
XML-RPC	ピンバックだけ止める／全部止める、を選べる	止める
REST API を止める	あり	あり
`?author=` でユーザー名を漏らさない	あり	あり
管理画面の制限	ログインできた IP だけ通す	24 時間ログインのない IP に 404
WAF	SiteGuard Server Edition の入ったサーバーで、誤検知の除外を書くだけ	プラグインの中の簡易 WAF（最初は切ってある）
設定ファイルへのアクセスを止める	なし	あり
500 エラーの通知	なし	あり
改ざんの検知	どちらも公式のページには書かれていない

いちばん大きな違いは、2 段階認証です。

CloudSecure にはあり、SiteGuard にはありません。

反対に、フェールワンスは SiteGuard だけの機能です。

フェールワンスは、正しい ID とパスワードを入れても、1 回目は必ず失敗にする機能です。

人なら「もう一度入れればよい」と知っていますが、パスワードを総当たりで試す仕組みは、正しいパスワードを試したときに失敗と受け取ってしまいます。

手入れの状況

WordPress.org のプラグインのページで見ました。

	SiteGuard	CloudSecure
今のバージョン	1.8.9	1.4.17
最終更新	2026-08-19	2026-09-29
有効なインストール	50 万以上	10 万以上
評価	4.3（15 件）	5.0（2 件）
フォーラムの未解決	30 件をこえる	0 件
試験済みの WordPress	7.1.3	7.1.3

使っている人の数は SiteGuard のほうがずっと多いです。

フォーラムの返事の早さは、CloudSecure のほうがよく見えます。

評価は、CloudSecure は 2 件しかないので、まだ比べにくいです。

プラグイン	中身	直ったバージョン
SiteGuard	CVE-2026-61982 など。ログインの URL を変えたときの、ログアウトの URL の XSS	1.8.7
CloudSecure	CVE-2026-42411 など。XML-RPC からのログインで、2 段階認証を飛ばせた	1.4.8

エックスサーバーとの関係

CloudSecure は、エックスサーバーのグループが作っています。

2025-03-25 から、エックスサーバーの「WordPress 簡単インストール」で、CloudSecure を一緒に入れられるようになりました
2025-11-12 から、XServer for WordPress で標準で使えるようになりました

簡単インストールの画面には、CloudSecure を一緒に入れる項目があります。

有効のまま進めると、CloudSecure が入った状態で WordPress ができます。

保守を行っているサイトは SiteGuard に統一した

フェールワンスや、管理画面の制限などの細かい設定も気に入っているので、SiteGuard に統一することにしました。

弱いところは、2 段階認証がないことです。

その分、ログインの URL の変更・画像認証・ログインのロック・フェールワンスを重ねて守ります。

2 つを同時に入れない

どちらも、ログインの URL を変えるときに、.htaccess とログインの処理を書き換えます。

2 つとも入れると、ログインの URL が 2 つ使えてしまったり、ログインの画面が出なくなったりします。

SiteGuard の WordPress.org のページにも、ほかのプラグインのログインの URL の変更と一緒に使わず、どちらか 1 つだけで有効にするように書かれています。

PageSpeed Insights パフォーマンスチューニング（表示の速さの改善）：お見積り

切り替えるなら、何が要るか

今回は切り替えていませんが、もし切り替えるなら、次のことが要ります。

ログインの URL が変わる。ブックマークや、ログインの URL を知っている人に知らせる
設定は引き継がれない。ロックの回数・通知・管理画面の制限などを、新しいプラグインで設定し直す
前のプラグインを止めたあと、.htaccess にルールが残っていないかを見る
切り替える前に、.htaccess とデータベースのバックアップを取る

見つかったこと 1：/wp-admin/ を開くと、変えたログインの URL へ転送されていた

比べている途中で、保守を行っているサイトの /wp-admin/ を、ログインしていない状態で開いてみました。

すると、多くのサイトで、変えたログインの URL へ 302 で転送されていました。

これでは、/wp-admin/ を開くだけで、変えたログインの URL が分かってしまいます。

ログインの URL を変えた意味が薄れます。

確かめ方

/wp-admin/ がどこへ転送されるかを見る

curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" https://example.com/wp-admin/

書き方	役目
`-s`	途中の表示を出さない
`-o /dev/null`	ページの中身は捨てる
`-w "%{http_code} %{redirect_url}"`	返ってきた番号と、転送先の URL だけを出す

転送先が、変えたログインの URL になっていたら、直す必要があります。

出た結果（URL は伏せています）

# 直す前
302 https://example.com/（変えたログインの URL）?redirect_to=...&reauth=1

# 直したあと
302 https://example.com/

なぜ転送されるのか

WordPress は、ログインしていない人が管理画面を開くと、ログインの画面へ転送します（auth_redirect()）。

SiteGuard でログインの URL を変えていると、この転送先も、変えたログインの URL になります。

SiteGuard には、この転送を止める設定があります。

「ログインページ変更」の画面にある「管理画面 (/wp-admin/) からログイン画面にリダイレクトしない。」です（設定の名前は redirect_enable）。

これらのサイトは、ここにチェックが入っていませんでした。

チェックを入れたときの処理

// SiteGuard（1.8.9）の classes/siteguard-rename-login.php から
add_filter( 'auth_redirect_scheme', array( $this, 'handler_stop_redirect' ), 9999 );

function handler_stop_redirect( $scheme ) {
	global $siteguard_config;
	$redirect_enable = $siteguard_config->get( 'redirect_enable' );
	if ( $redirect_enable == 1 ) {
		if ( $user_id = wp_validate_auth_cookie( '', $scheme ) ) {
			return $scheme;
		}
		wp_safe_redirect( home_url() );
		exit;
	}
}

書き方	役目
`auth_redirect_scheme`	WordPress が管理画面でログインを確かめる前に通るフィルター
`redirect_enable == 1`	「リダイレクトしない」にチェックが入っているとき
`wp_validate_auth_cookie()`	ログインしている人なら、ふつうに管理画面を出す
`wp_safe_redirect( home_url() )`	ログインしていない人は、ログインの画面ではなくトップへ送る

直した結果

チェックを入れたら、/wp-admin/ から変えたログインの URL へは転送されなくなりました。

どのサイトも、ログインしていない人は、上のコードのとおりトップへ 302 で送られるようになりました。

ほかのサイトは、もとから変えたログインの URL へは転送されていませんでした。

なお、SiteGuard の「管理ページアクセス制限」を有効にしていると、ログインしたことのない IP からの /wp-admin/ は 404 になると、公式のページに書かれています。

作業環境でも確かめた

作業環境の 2 サイトで、データベースの SiteGuard の設定（siteguard_config）の値をメモしてから、redirect_enable を 0 と 1 に変え、/wp-admin/ を 2 回ずつ開きました。

redirect_enable	サイト A	サイト B
0（チェックなし）	302・変えたログインの URL へ（2 回とも）	302・変えたログインの URL へ（2 回とも）
1（チェックあり）	302・トップへ（2 回とも）	302・トップへ（2 回とも）

試したあとは、メモした設定に戻し、戻した値がメモと同じことを確かめました。

見つかったこと 2：ログインの画面がキャッシュされて、認証画像が出なかった

あるサイトで、ログインの画面の画像認証の画像が出ず、ログインできなくなりました。

回り道：パーミッションを疑った

SiteGuard の画像認証は、wp-content/siteguard/ に画像を作ります。

最初は、このフォルダに書き込めないのだと思い、パーミッションを見ました。

でも、問題はなく、画像のファイルもちゃんと作られていました。

原因：キャッシュのプラグインが、ログインの画面を丸ごと保存していた

ログインの画面のソースを見ると、いちばん最後に次の 1 行がありました。

ページの最後にあった印

<!-- Cached by WP-Optimize - https://teamupdraft.com/wp-optimize/ - Last modified: （キャッシュを作った日時） -->

日時は前日のままでした。

キャッシュのプラグイン（WP-Optimize）が、変えたログインの URL のページを、ふつうのページと同じように保存していたのです。

SiteGuard の画像認証は、ページを開くたびに新しい画像を作り、使い終わった画像や古い画像は消します。

画像認証の画像の作り方

// SiteGuard（1.8.9）の画像認証の一部
// ページを開くたびに、新しい画像を作る
function put_captcha() {
	$this->word   = $this->captcha->generate_random_word();
	$this->prefix = siteguard_rand();
	$this->captcha->generate_image( $this->prefix, $this->word );
	echo $this->get_captcha();
}

// 画像の場所は wp-content/siteguard/（番号）.png
$result .= '<img src="' . WP_CONTENT_URL . '/siteguard/' . $this->prefix . '.png" alt="CAPTCHA">';

// 画像を作るときに、60 分より古い画像と答えのファイルを消す
public function cleanup( $minutes = 60 ) { ... }

保存されたページには、前日に作った画像の URL が書かれたままです。

その画像はもう消えているので、画像の URL は 404 になります（そのサイトでは、ない URL はトップへ転送していたので、画像の代わりにトップのページが返っていました）。

これで、画像が出ず、答えも合わないので、ログインできなくなっていました。

なぜ wp-login.php は大丈夫で、変えた URL はだめなのか

WP-Optimize は、最後が .php の URL はキャッシュしません。

WP-Optimize がキャッシュしない URL

// WP-Optimize（4.7.0）の cache/file-based-page-cache-functions.php から
$request_uri = isset($_SERVER['REQUEST_URI']) ? strval(parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH)) : '';
$file_extension = strtolower(pathinfo($request_uri, PATHINFO_EXTENSION));

// Don't cache disallowed extensions. Prevents wp-cron.php, xmlrpc.php, etc.
if (!preg_match('#index\.php$#i', $request_uri) && !wpo_is_cacheable_sitemap_request() && in_array($file_extension, array('php', 'xml', 'xsl'))) {
	$no_cache_because[] = 'The request extension is not suitable for caching';
}

書き方	役目
`pathinfo( ..., PATHINFO_EXTENSION )`	URL の最後の拡張子（php など）を取り出す
`array('php', 'xml', 'xsl')`	この拡張子の URL はキャッシュしない（index.php とサイトマップは別）
`$no_cache_because[]`	キャッシュしない理由を足す。理由が 1 つでもあれば保存しない

wp-login.php は最後が .php なので、最初からキャッシュされません。

でも、変えたログインの URL は、ふつうのページの URL と同じ形なので、WP-Optimize にはログインの画面だと分かりません。

そのため、自分で「キャッシュしない URL」に足す必要があります。

直し方

その場では、ログインの URL の最後に ?nc=1 を付けて開きました。WP-Optimize は、知らないクエリの付いた URL はキャッシュから出さないので、新しい画像のページが出て、ログインできました
ログインしてから、WP-Optimize の設定の「キャッシュしない URL」（設定の名前は cache_exception_urls）に、変えたログインの URL を足しました

もう 1 サイトでも、同じようにログインの画面がキャッシュされていたので、同じように足しました。

確かめ方

ログインの画面がキャッシュされているかを見る

curl -s "https://example.com/（変えたログインの URL）" | grep -c "Cached by WP-Optimize"

書き方	役目
`curl -s`	ログインしていない人として、ログインの画面を取ってくる
`grep -c "Cached by WP-Optimize"`	キャッシュの印が何行あるかを数える

1 が出たらキャッシュされています。

0 なら大丈夫です。

作業環境でも確かめた

作業環境の 2 サイト（どちらも、本番から複製したままの設定）で、ログインの画面を取ってきました。

開き方	キャッシュの印	認証画像の番号
そのまま（1 回目・2 回目）	2 サイトとも 1	2 回とも同じ番号
`?nc=乱数` を付ける（1 回目・2 回目）	2 サイトとも 0	毎回ちがう番号

そのまま開くと、保存されたページが返り、画像の番号が変わりません。

作業環境では、保存したばかりで画像がまだ残っていたので、画像は 200 で出ました。

画像が消えて 404 になるところ（60 分たったあと）は、作業環境では試していません。

気をつけること

この 2 つは、SiteGuard だけの話ではありません。

ログインの URL を変えるプラグインなら、どれでも起こりえます。

/wp-admin/ からの転送：ログインしていない状態で /wp-admin/ を開き、変えたログインの URL へ転送されないかを見る。転送されるなら、プラグインの「リダイレクトしない」設定を使う
ログインの画面のキャッシュ：キャッシュのプラグインは、変えたログインの URL を知らない。「キャッシュしない URL」に自分で足す
ログインの URL を変えたら、上の 2 つを curl で確かめる
ログインできなくなったら、ログインの URL に ?nc=1 のようなクエリを付けて開いてみる

まとめ

SiteGuard と CloudSecure は、ログインの守りの機能はほぼ同じ。どちらも無料
CloudSecure は 2 段階認証・設定ファイルの守り・500 エラーの通知がある。SiteGuard はフェールワンスがある
保守を行っているサイトは、設定がそろっている SiteGuard に統一した。2 段階認証がないのは弱いところ
簡単インストールで CloudSecure が一緒に入っても、あとからプラグインの画面で停止・削除できる（有効にするのは、どちらか 1 つだけ）
2 つを同時に入れない
/wp-admin/ から変えたログインの URL へ転送されていたので、「リダイレクトしない」にチェックを入れた
ログインの画面がキャッシュされて認証画像が出なかったので、変えたログインの URL を「キャッシュしない URL」に足した

参考

セキュリティ対策, プラグイン関連

エックスサーバーで PHP を 8.3 に上げる前に、サブドメインのサイトまでま…前の記事