ホームページにWAFは必要？Cloudflareへの移行手順と、防げる攻撃・防げない攻撃

「レンタルサーバーにファイアウォールが付いているから、うちはもう守られている。」

「ホームページを作り直すお金はないし、今のままで何とかなる。」

ホームページは、一度作ったら数年はそのまま使うものだと思います。作り直すにはお金も時間もかかるので、「今は触らずにおこう」と考えるのは自然なことです。

その一方で、セキュリティのニュースを見るたびに、どこか不安が残っている。そんな経営者の方も多いと思います。

結論から言うと、今のホームページを作り直さなくても、Cloudflare（クラウドフレア）のWAFを手前に置くことで「最初の盾」は作れます。基本の機能なら、無料から始められます。

ただし、移し方を間違えるとメールが止まります。

ただ、移しただけで守りが完成するわけではありません。

この記事では、WAFの考え方、メールもサイトも止めずに移す手順、移したあとに必ずやる設定、そしてWAFでは防げない攻撃まで、順番にお伝えします。
ホームページを「ビルの入口」にたとえながら読んでみてください。

途中で、我々自身がやってしまった失敗もひとつお話しします。

WAFとは何か。ファイアウォールとの違い

ファイアウォールは「ビルの門」、WAFは「受付で用件を確かめる人」です。

	ファイアウォール	WAF
見ているもの	どこから、どの扉に来たか	来た人が、何をしようとしているか
止められるもの	開けていない扉への通信	ホームページへの不正な命令や探り
置き場所	社内ネットワークやサーバーの入口	ホームページの手前

ホームページは、誰でも見に来られるように扉を開けておく必要があります。だから、扉を閉じる役目のファイアウォールだけでは守れません。

WAF（Webアプリケーションファイアウォール）は、開いた扉から入ってくる通信の「中身」を見て、怪しいものを止めます。

たとえば、データベースを不正に操作しようとする命令、管理画面への総当たりのログイン、設定ファイルを探すアクセスなどです。

ファイアウォールは、とても大切な守りです。ただ、それだけだと、受付のいないビルに門だけが付いている状態。

門の中に入ってから何をされるかは、門では止められません。

小さな会社のホームページにも、毎日届いている自動の探り

ホームページには、人が見に来るよりずっと多くの「機械による探り」が届いています。

社員10人の会社のサイトでも、サーバーの記録を開けば、次のようなアクセスが日常的に並んでいるのが普通です。

• /.env や /.git/ など、設定ファイルやパスワードが置かれていそうな場所を探す
• /wp-login.php や /xmlrpc.php など、WordPressの入口を探して、パスワードを試す
• 古いプラグインの名前を順に打ち込み、弱点のあるものを探す
• /phpmyadmin/ や /backup.zip など、置き忘れがありそうな名前を片っ端から試す

.env は、データベースのパスワードなど、大事な設定を書いておくファイルです。

これが外から見える場所にあると、一度のアクセスで中身を持っていかれます。

「うちみたいな小さい会社を、誰が狙うの？」

そう思いたくなる気持ちは、凄くわかります。でも、攻撃する側は、あなたの会社を選んで狙っているわけではありません。

インターネット上のすべてのホームページに、同じ探りを機械で送り続けています。そして、引っかかったところから本格的な攻撃が始まります。

ビルでいえば、すべての部屋のドアノブを、片っ端から回して歩いているようなものです。

だから、知名度も規模も関係ありません。

古いプラグインが1つ残っている、置き忘れたファイルが1つある。それだけで、入口になってしまいます。

Cloudflareで何ができるのか

Cloudflareは、ホームページの「手前」に立って、通信をいったん受け止めてくれるサービスです。

訪問者の通信は、まずCloudflareを通り、そこから自社のサーバーに届きます。
その途中で、次のような守りをかけられます。

機能	何をしてくれるか	無料プランでの扱い
WAF（管理ルール）	不正な命令や既知の攻撃パターンを止める	基本のルールセットが最初から有効
DDoS対策	大量の通信でサーバーを落とす攻撃を受け止める	使える
SSL/TLS	通信を暗号化し、証明書の期限を管理する	使える
ボット対策	機械による大量アクセスを見分ける	基本の機能が使える
レート制限	短時間に同じ場所へ来すぎた通信を止める	1つだけ、決まった条件で使える
アクセス制限	管理画面に入れる人をメールアドレスで絞る	少人数なら使える

プランごとの内容は変わることがあるので、導入するときにCloudflareの公式の案内で確かめてください。

会社案内と問い合わせフォーム程度のサイトなら、まずは無料の範囲で「最初の盾」を作れます。

ドメインの移管と、DNSの移行は別のもの

Cloudflareを使うために、ドメインの契約先を変える必要はありません。

ここは、本当によく質問されます。

	ドメインの移管	DNSの移行
変わるもの	ドメインの契約・支払い先	ドメインの「住所録」の管理場所
手続き	認証コード（AuthCode）を使った移管	ネームサーバーの書き換え
Cloudflare導入に必要か	必須ではない	必要

DNSは、「このドメインのホームページはこのサーバー、メールはこのサーバー」と案内する住所録のようなものです。

Cloudflareを使うときは、この住所録の管理場所をCloudflareに移します。ドメインの契約そのものは、今の会社のままで大丈夫です。

ドメインの名義や管理画面が制作会社側にあって、自社では触れない。

そういう場合は、先にその整理が必要です。

移行前に確認する、メール・DNSSEC・サブドメイン

移行で事故が起きるのは、ホームページではなく「メール」と「忘れていた設定」です。

Cloudflareは、今の住所録を自動で読み込んでくれます。

ただし、すべてを読み込めるとは限りません。

特に、メール関係の細かい設定や、昔の担当者が足したサブドメインは漏れがちです。

だから移行前に、今の住所録を自分たちでも書き出しておきます。

ドメインの管理画面に「DNS設定」「ゾーン編集」といった項目があるので、そこに並んでいる行をすべて控えます。
画面をそのまま撮影しておくだけでも、あとで必ず助かります。

特に注意してほしいのが2つです。

1つ目は、メールの設定です。

メールの受信設定が新しい住所録に入っていないと、切り替わったところからメールが届かなくなります。
しかも、自社では気づきにくい。

届かなかったメールは、送り主のサーバーが数時間〜数日かけて再送を続け、そのあいだ送り主には「遅れています」という通知が届くだけだからです。

数日たってようやくエラーで返り、取引先から「メールが返ってくる」と連絡が来て初めて分かる。そういう流れになります。

また、メールのサーバーはプロキシにできません。
mail.〜 の行は「DNSのみ」にしておく必要があります。

ここで、もうひとつ気をつけたいことがあります。

レンタルサーバーでは、ホームページとメールが同じサーバーに同居していることがよくあります。

その場合、「DNSのみ」にした mail.〜 の行から、サーバーの本当の住所（IPアドレス）が誰にでも見えてしまいます。
この「本当の住所」が、あとで出てくる裏口の話につながります。

2つ目は、DNSSECです。

今の管理会社でDNSSECが有効になっている場合、そのままネームサーバーを書き換えると、ドメイン全体がつながらなくなることがあります。

移行前にいったん無効にし、古い設定が消えるまで1〜2日ほど待ってからネームサーバーを書き換えます。
移行が終わったら、Cloudflare側で有効にし直します。

サイトやメールを止めないための移行手順

手順は「住所録を整える → 守りの設定 → ネームサーバーの書き換え → 確認」の順です。

1. Cloudflareにサイトを登録し、自動で読み込まれた住所録を、控えておいた設定と1行ずつ見比べる
2. 足りない設定を追加し、メール関係を「DNSのみ」、ホームページを「プロキシ」にする
3. サーバー側に証明書が入っていることを確かめてから、SSL/TLSの暗号化モードを「フル（厳密）」にする
4. ドメインの管理会社の画面で、ネームサーバーをCloudflareのものに書き換える
5. ホームページの表示と、メールの送受信を確かめる（社外のアドレスとの往復で試す）
6. 必要に応じて、DNSSECをCloudflare側で有効にする

3のSSL/TLSは、見落とすと危ない設定です。

「フレキシブル」は選ばない。「フル（厳密）」にする。 経営者の方が覚えておくのは、この一行で十分です。

サーバーの証明書は、ネームサーバーを書き換える前に入れておきます。レンタルサーバーの無料の証明書の中には、切り替えたあとだと発行しにくいものがあるからです。

ネームサーバーの切り替えは、すぐに全員に反映されるわけではありません。

数時間から、長いと2日程度かかります。

問い合わせの少ない時間帯を選び、翌朝にメールの往復を確かめるところまでを1セットにしてください。

そして、切り替わるまでのあいだは、古い住所録もまだ使われています。今の管理会社にある住所録の設定は、消したり解約したりせず、移行が落ち着くまでそのまま残してください。

切り替えた日の夜に「サイトは見えるのにメールが来ない」と気づいても、慌てなくて大丈夫です。

たいていは、MXレコードの入れ忘れか、mail.〜 がプロキシになっているかのどちらかです。

控えておいた設定と見比べれば、直す作業そのものは数分です。

直した設定が行き渡るまで少し待つ必要はありますが、そのあいだも送り主のサーバーは再送を続けているので、早く
直せば、届くはずだったメールの多くはあとから届きます。

Cloudflare導入後に必ずやる4つの設定

移しただけでは、守りは半分です。移したあとに、次の4つを必ず行ってください。

1. WAFの管理ルールを有効にする

無料プランの基本のルールは、登録した時点で有効になっています。
注意したいのは、有料プランに上げたときです。追加で使えるようになるルールは、自分で「有効」にしないと働きません。
どのプランでも、セキュリティの設定画面で、管理ルール（マネージドルール）が「有効」になっているかを一度確かめてください。

2. 管理画面に入れる人を絞る

/wp-admin のような管理画面は、お客さまが見る必要のない場所です。
ビルでいえば、社員しか入らないバックヤード。
Cloudflareのアクセス制限の機能で、許可したメールアドレスの人しか通さない関所を置きます。
固定のIPアドレスを持っている会社なら、会社のIPアドレスだけに絞る方法もあります。

ただし、WordPressの場合は注意が1つあります。
/wp-admin の中には、お客さまが見る画面（フォームなど）が裏で使っている部分もあります。
丸ごと閉じるとフォームが動かなくなることがあるので、絞る範囲は制作会社と確かめてから決めてください。

我々が運用をお手伝いしているWebサービスでは、管理画面の入口を別のドメインに付け替え、サーバーから外へ向けてだけつなぐトンネルで結びました。
サーバー側に、新しく穴を開けずに済む形です。
詳しい流れは、情シスのいない会社向けチェックリストの「我々の実話。」に書いています。

3. ログイン画面への回数制限をかける

同じ場所から短時間に何十回もログインを試す通信は、ほぼ総当たりです。
レート制限の機能で、ログイン画面に「短時間に何回まで」という上限をかけます。
無料プランでは数える時間が10秒に決まっているので、「10秒に5回を超えたら止める」のような形になります。
1分単位など細かく決めたい場合は、有料プランが必要です。

4. サーバーが、Cloudflareを通った通信だけを受け付けるようにする

ここがいちばん大事で、いちばん忘れられるところです。

Cloudflareを使っていても、サーバーの本当の住所（IPアドレス）が知られていると、攻撃者はCloudflareを避けて、直接サーバーに来られます。

受付を通らずに、裏口から入ってくるのと同じです。

そして、本当の住所は思ったより簡単に知られます。

昔の住所録の記録を保存しているサービスがあります。

サーバーから送ったメールのヘッダーに、住所が書かれていることもあります。
先ほどの mail.〜 の行から見えてしまうこともあります。

Cloudflareに移す前から使っていた住所は、すでに知られている前提で考えてください。

だから、サーバー側で、Cloudflare以外からの通信を断ります。ここは、サーバーの種類によってやり方が分かれます。

VPSや専用サーバーの場合。

サーバーのファイアウォールで、Cloudflare以外からの通信を閉じられます。

CloudflareのIPアドレスの一覧は公開されているので、その一覧以外を閉じ、さらにCloudflareからの通信に証明書を持たせる仕組みを足します。

レンタルサーバー（共用サーバー）の場合。

多くのレンタルサーバーでは、通信元で閉じる設定や、証明書を確かめる設定を、利用者側ではできません。
その場合は、次のどれかになります。

• サーバー会社に「Cloudflare以外からの通信を断る設定ができるか」を問い合わせる
• サーバーの住所（IPアドレス）を変えてもらい、新しい住所をどこにも出さないようにする（メールを別のサービスに分けるのが前提）
• 外へ向けてだけつなぐトンネル型の構成にできるサーバーへ移る

どれが合うかは、サイトの大きさと予算で変わります。

「うちのサーバーではどこまでできるのか」を確かめるところから始めてください。

ここまでやって、ようやく盾が正しく働きます。

我々がやってしまった話。正しい利用者を止めてしまう

守りを強くすると、今度は「味方を止めてしまう」事故が起きます。これは、我々自身もやりました。

ワンシックスでは、自社やお客さまのサイトを公開したあと、ページが正しく表示されるかを機械で確かめることがあります。

あるとき、その確認を短時間に集中させすぎて、配信サービスの自動防御に、自社の接続ごと弾かれました。

画面には「403」というエラーが返ってきます。その瞬間は「サイトが落ちた」と見間違えました。

実際には、一般の訪問者は無傷で、時間が経てば自然に解除される種類のものでした。

守りがきちんと働いていた、ということでもあります。

ここから学んだことは2つ。

• 守りの設定を入れたら、いきなり遮断する前に、正常な利用者への影響を確認する
• 403が出ても、すぐに「障害」と決めつけず、別の回線やスマートフォンから普通に見えるかを先に確かめる

WAFは、ルールを足すほど守りが強くなります。

でも同時に、「正しいお客さまのフォーム送信を止めていた」という事故も起きます。

特に、お問い合わせフォームに長文や記号を入れると止まる、という誤検知は多いです。

導入後しばらくは、セキュリティのイベント一覧を週に一度は眺めて、止められた通信の中にお客さまが混ざっていないかを見てください。

WAFだけでは防げない攻撃

WAFは強い盾ですが、万能ではありません。防げないものを知っておくことが、次の守りを決める材料になります。

WAFだけでは防げないもの	なぜ防げないか	代わりに効く守り
正しいIDとパスワードでのログイン	本人と区別がつかない	二段階認証、パスワードの使い回し禁止
ホームページの仕組みそのものの欠陥	「正しい操作」に見える	プログラムの修正、脆弱性の点検
社員のパソコンやメールからの侵入	ホームページの手前ではなく、社内から入る	パソコンの更新、迷惑メール対策、見張りの仕組み
すでにサーバーに置かれた不正なファイル	中からの動きはWAFの外	サーバー内の点検、ファイルの変更監視
外部サービスやプラグインの更新に仕込まれた細工	正規の更新として入ってくる	更新元の確認、使っていないものの削除

正しい鍵を持って受付に来た人は、受付では止められません。

2026年秋に相次いだサイバー攻撃を受けて、JPCERT/CCなどが注意を呼びかけている傾向のひとつも、「盗まれたAPIキーや認証情報を悪用する攻撃」です。

これはWAFの得意分野ではありません。

また、WAFは設定したら終わりではありません。
正しいお客さまの通信を、誤って止めていないか。
新しい攻撃に合わせて、ルールを足す必要はないか。
見張りながら、調整し続ける。 WAFは、運用して初めて効果が続く仕組みです。

だからこそ、WAFに加えて、本体やプラグインの更新、二段階認証、別の場所へのバックアップを重ねていきます。

よくある質問

Q1. 今のサーバー会社のままで使えますか？

使えます。

Cloudflareはサーバーの手前に立つだけなので、サーバーもドメインの契約も、今のままで構いません。

ただし、サーバー会社が独自の「CDN」や「WAF」を提供している場合は、二重になって設定がぶつかることがあります。先にサーバー会社の設定を確かめてください。

特に気をつけたいのが、ログインの回数制限です。

Cloudflareを通すと、サーバーからは、訪問者全員が「CloudflareのIPアドレス」から来ているように見えます。
サーバー会社のWAFや、WordPressのセキュリティプラグインがそのIPアドレスを弾くと、全員がサイトを見られなくなります。

訪問者の本当のIPアドレスをサーバーに伝える設定が必要なので、制作会社かサーバー会社に確かめてください。

Q2. 無料プランで足りますか？

会社案内と問い合わせフォーム程度のサイトなら、無料プランで「最初の盾」は作れます。

細かいルールの調整、ボット対策の強化、ログの長期保存などが必要になったら、有料プランを検討します。

先に無料で入れて、止められた通信の中身を見てから判断するのが現実的です。

Q3. 制作会社に「Cloudflareは対応していない」と言われました。

Cloudflareの設定は、制作会社がサーバーを触らなくても、ドメインの管理画面を持っている人ができます。

ただし、SSLの設定と、Cloudflare以外からの通信を断る設定は、サーバー側の作業が必要です。

そこだけ制作会社に相談するか、別の会社に頼む形でも進められます。

この記事の「制作会社に渡すメモ」を、そのまま見せてください。

Q4. 移したあと、何を見ていればいいですか？

セキュリティのイベント一覧（止めた通信の記録）を週に一度、そしてメールの往復を月に一度。これだけでも、誤検知と設定漏れの多くに早めに気づけます。

まとめ

我々は、攻撃する側がどこから入ろうとするのかを見ながら、経営者の方と一緒に守りを組み立てています。

今回は、今のホームページを作り直さなくても、CloudflareのWAFで守りを足せる、というお話でした。

「DNSのみ」では守られない。プロキシにする必要がある。

移行前にはメールの設定とDNSSECを確かめる。

移行後はSSL/TLSを「フル（厳密）」にして、サーバーがCloudflare経由の通信だけを受け付けるようにする。レンタルサーバーなら、どこまでできるかを先に確かめる。

そして、いきなりブロックせず「チャレンジ」で始め、正しいお客さまを弾いていないかを見てから締めていく。

WAFでは防げない攻撃があることを前提に、二段階認証と更新とバックアップを重ねていけば、小さな会社のホームページでも、守りの形は作れます。

もし、「今のホームページを変えずに、守りを固めたい」「移行のときにメールが止まらないか心配」
そう思ったら、ご相談ください。

移行前の確認表づくりから、移行後の設定と見張りまで、一緒に進めます。

Cloudflareの導入・設定について相談する

門を付けて、受付を置いて、裏口を閉める。ホームページの守りも、ビルの守りと同じ順番で考えれば、難しいものではありません。

出典・参考資料

記載に間違いがないように、下記の出典・資料を参考にしています。

• Cloudflare Docs「Proxy status」
• Cloudflare Docs「DNSSEC」
• Cloudflare Docs「Encryption modes（SSL/TLS）」
• Cloudflare Docs「Managed Rules（WAF）」
• Cloudflare Docs「Rate limiting rules」
• Cloudflare Docs「Authenticated Origin Pulls」
• Cloudflare「IP Ranges」