ロリポップとさくらのレンタルサーバは、WAFに弾かれた瞬間の見え方で決まる。制作中に慌てないための比較5選

ロリポップとさくらのレンタルサーバは、WAFに弾かれた瞬間の見え方で決まる。制作中に慌てないための比較5選

この記事の結論

WordPressで制作中に保存できない、403が表示される、インストールの途中で処理が進まない。このようなとき、サーバー側のWAFが通信を遮断している可能性があります。WAFは攻撃からサイトを守るためのセキュリティ機能であり、エラーが出たこと自体はサービスの不具合を意味しません。慌てないためには、どの画面で状態を確認し、どの情報がすぐ見えるかを契約前に知っておくことが役立ちます。

ナラビカはロリポップで運用しています。実際に、アフィリエイトタグを保存しようとして<script>を含むPOSTが403で弾かれました。この場合は、保存作業の間だけWAFを一時的に無効にし、保存後に有効へ戻す運用をしています。設定を変えた後、5〜10分程度は処理先のノードによって403が出たり出なかったりすることがあり、保存をリトライして通した経験があります。

さくらのレンタルサーバは、公式にSiteGuardというシグネチャ型WAFを案内しています。WAF設定はドメインごとに行い、検出ログは前日の結果を表示する仕様です。CGIやPHPプログラムの動作・インストールに影響する場合があることも、公式の注意事項に記載されています。ロリポップの一次体験と、さくらの公式仕様は性質の違う情報です。この記事では混ぜずに、制作中に確認する順番を整理します。

比べたもの

比べたのは、ロリポップとさくらのレンタルサーバです。比較する軸は次の5つです。

  1. 保存・投稿のときに確認する現象
  2. WAF設定を確認する場所
  3. 設定変更後に待つ・見直すポイント
  4. インストールや更新の前に確認すること
  5. サーバー側のWAFとWordPress側の設定を切り分けること

料金・速度・障害の多さは扱いません。ロリポップについて書く一人称の内容は、このサイトを運用して確認した事実だけに限定しています。さくらについては、公式の公表情報だけを扱います。

選び方の解説

WAFは「止める機能」なので、403を見たら原因候補に入れる

WAFは、Webアプリケーションへの攻撃を検知して遮断する機能です。さくらは、クロスサイトスクリプティングやSQLインジェクションなどを検知・ブロックする機能として説明しています。ロリポップでも、ナラビカの運用では<script>を含むPOSTが403で弾かれました。

ただし、<script>を含む通信がロリポップで止まることは、WAFが正しく通信を検査した結果です。正規の作業かどうかだけではなく、通信に含まれるパターンも検査対象になります。403が出たときに「WordPressのプラグインが壊れた」と決めつけず、WAFを原因候補に含めると、確認する場所を絞れます。

さくらについて、<script>を含むPOSTがどのように扱われるかは確認していません。ロリポップで確認した現象を、さくらにも当てはまる体験談として書くことはできません。サービスごとに、公式の設定画面やサポート情報を確認します。

保存できないときは、設定を変える前に作業内容を切り分ける

保存時の403は、WAFだけでなく、WordPressのプラグイン設定、権限、入力内容など複数の原因で起きます。最初に、どの画面で、どの操作をした瞬間に、どのエラーが出たかを記録します。たとえば、記事本文の保存なのか、プラグインの設定保存なのか、テーマの設定なのかで、確認する場所が異なります。

ロリポップでナラビカを運用している場合は、<script>を含むアフィリエイトタグの保存が対象でした。保存作業の間だけWAFを一時的に無効化し、作業が終われば有効に戻します。恒常的に無効化する手順ではありません。

さくらの公式サポート情報では、WAFを有効にするとソフトウェアの動作やインストールに影響が出る場合があり、CGIやPHPプログラムのインストールに影響する場合はインストール前にWAFを無効にするよう案内しています。作業の種類を切り分けてから公式手順を見ることで、必要のない設定変更を避けやすくなります。

WAFの設定場所と、ログを見るタイミングを知る

さくらでは、コントロールパネルの「WAF設定ドメイン」から対象ドメインを選び、「利用する」を選んで保存します。検出ログは前日の検出結果を表示する仕様で、即時表示ではありません。エラーが出た直後にログが見当たらなくても、その時点でWAFではないとは判断できません。

ロリポップのWAFについて、初期状態や設定変更の反映時間を示す公式の公表値は、この記事で確認した範囲では取得できませんでした。ナラビカの運用では、設定変更後に5〜10分程度、ノードによって403が混ざる状態を確認しました。これはこのサイトの運用で得た一次体験であり、ロリポップ全体の反映時間を示す公式値ではありません。

二つを比べるときに、「どちらが早く復旧するか」という結論は出せません。確認できる情報の見え方が異なる、と捉えるのが安全です。さくらではログの表示時点を意識し、ロリポップでは一次体験を一般化せず、自分の契約環境で確認します。

WAFはサーバー側、SiteGuardは名前が同じでも別の層がある

さくらがWAFとして案内している「SiteGuard」は、サーバーのWAF機能の名称です。一方、ナラビカのWordPressにはSiteGuardというセキュリティプラグインも導入されています。このプラグインでは、管理画面のログインURLを独自の文字列へ変更する設定がデータベースに保存されていることを確認しています。

これは、さくらのWAFの挙動を示す事実ではありません。WordPress側のプラグイン設定を別環境へインポートすると、設定も引き継がれ、通常のログイン画面にアクセスできなくなるおそれがある、という予防上の注意です。実際にログインできなくなった経験として扱うものではありません。

制作中に「ログインできない」「保存できない」と感じたときは、サーバーのWAFだけを疑うのではなく、サーバー設定とWordPressプラグイン設定を別の層として確認します。同じ名前が出てきても、どこで動く機能かを分けて見ることが重要です。

契約直後に確認しておきたいこと

契約後に一度、WAFの設定画面とサポート情報を開いておくと、実作業中の切り分けがしやすくなります。さくらでは対象ドメインのWAF設定と、検出ログが前日の結果であることを確認します。CGIやPHPのインストールを予定している場合は、公式の注意事項も先に見ます。

ロリポップを使う場合は、アフィリエイトタグや埋め込みコードを保存する予定があるなら、WAFが<script>を含むPOSTを403で弾く可能性を知っておくと、エラー時に原因候補へ入れやすくなります。ナラビカでは、一時的な無効化と作業後の再有効化、設定変更直後のリトライを行っています。

WAFを外したまま作業を続けることではなく、どの作業のどの通信が影響を受けたのかを確認し、必要な範囲だけ設定を扱うことが、制作を安全に進めるための前提になります。

1つずつ見る

1 ロリポップ!広告

項目 値
<script>を含むPOSTの扱い 403で弾かれることを運営者が実際に確認。セキュリティ機能として正常な挙動
保存時の対処 保存作業の間だけWAFを一時的に無効化し、保存後に有効へ戻す(運営者の運用)
設定変更後の状態 運営者の体験では、5〜10分程度ノードによって403が混ざることがある
WAF初期状態・公式反映時間 取得できず(この記事で確認した公式ページの範囲では記載を確認できず)
WordPress側の注意 SiteGuardプラグインのログインURL変更設定がDBに保存されている状態を確認

向いている人

アフィリエイトタグや埋め込みコードを保存する作業があり、WAFで403が出る可能性をあらかじめ知っておきたい人。設定変更直後の一時的な状態を、ナラビカの一次体験として参考にしつつ、自分の環境で確認できる人。

向かない人

WAFの初期状態や反映時間を、契約前に公式の固定値だけで確認しておきたい人。この記事で確認した範囲では、その値を取得できていません。

補足

ロリポップについての403と5〜10分の記述は、ナラビカ運営者の一次体験です。公式の仕様や、他の契約環境で再現することを示す値ではありません。WAFが通信を弾くことは、セキュリティ機能として正しい挙動です。

2 さくらのレンタルサーバ広告

項目 値
WAF SiteGuardを導入(公式明記)
設定場所 コントロールパネルの「WAF設定ドメイン」からドメインごとに設定
検出ログ 前日の検出結果を表示。即時表示ではない
制作への影響 CGI・PHPプログラムの動作やインストールに影響する場合がある(公式明記)
<script>を含むPOSTの扱い 取得できず

向いている人

WAFの設定場所と、検出ログを見るタイミングを公式情報で把握してから制作を始めたい人。CGIやPHPのインストール前にWAFの影響を確認する手順を、制作計画に含めたい人。

向かない人

<script>を含むPOSTがどのように扱われるかを、契約前に実体験として確認してから決めたい人。この記事では、その挙動を取得できていません。

補足

さくらについては公式の公表情報だけを扱っています。WAFの既定ON/OFF状態はこの記事で確認した公式情報では明記を確認できず、本文の結論には使っていません。さくらのWAFを、ナラビカのロリポップ運用で起きた403と同じ現象として扱っていません。

まとめ

ロリポップとさくらのレンタルサーバをWAFで比べるとき、見るべきなのは速度や設定の多さではなく、エラーが出た瞬間に何を確認できるかです。ロリポップでは、ナラビカの運用で<script>を含むPOSTが403で弾かれた一次体験があります。さくらでは、SiteGuardの設定画面、前日分を表示する検出ログ、CGIやPHPのインストールへの注意を公式が案内しています。

二つの情報を同じ種類の数値として比べることはできません。ロリポップの経験をさくらの実測として扱わず、さくらの公式仕様をロリポップの設定値として扱わないことが大切です。403や保存失敗に出会ったら、作業内容、サーバー側WAF、WordPress側のプラグイン設定を順に切り分けます。

契約前に、WAFの設定画面とログを見るタイミングを把握しておくこと。制作中は、必要な作業の範囲だけ設定を変更し、終わったら状態を戻すこと。この二つを守ることで、セキュリティ機能に慌てず作業を進めやすくなります。

近いカテゴリ