はじめに
みなさん、Cloudflareを使っていますか？まぁ別に使わなくても運用できてしまうと言えばできてしまうのですが... セキュリティを考慮すると、圧倒的にCloudflareの方が優位なのです。そこで今回は、VPS公開時のCloudflareのメリットに焦点を当てます。
さて、VPSでWebサイトを公開する方法として以下のような方法があります。
- VPSのIPアドレスをDNSに登録し、利用者から直接アクセスさせる
- DNSをCloudflareのプロキシ（オレンジの雲）にし、Cloudflare経由でVPSへアクセスさせる
どちらでもWebサイトは公開できますが、攻撃への耐性、オリジンIPの見え方、キャッシュ、アクセス制御、運用のしやすさは大きく異なります。
なお、Cloudflareを有効にしただけでVPSへの直接アクセスが自動的に消えるわけではありません。Cloudflareのメリットを活かすには、オリジン側のファイアウォール設定も重要です。
この記事で比較する構成
この記事では、同じVPS上でWebサービスを公開する場合について、次の2つを比較します。
- 直接公開：DNSにVPSのIPアドレスを登録し、利用者からVPSへ直接アクセスさせる
- Cloudflareプロキシ保護：DNSレコードを Proxied（オレンジの雲） にし、HTTP/HTTPS通信をCloudflare経由でVPSへ届ける
Cloudflareプロキシは、単なるDNSサービスとしてではなく、Cloudflareをリバースプロキシとして通信経路に入れる構成です。
プロキシ設定後も、オリジンVPSがインターネットから直接到達できる状態なら、攻撃者はCloudflareを経由せずVPSへアクセスできます。この記事のポイントは、右下の直接経路をどう扱うかです。
DNSのみとプロキシの違い
Cloudflareでは、DNSレコードごとにプロキシの有無を設定できます。
| 項目 | DNSのみ（グレーの雲） | プロキシ（オレンジの雲） |
|---|---|---|
| DNSの応答 | VPSの実IPアドレス | CloudflareのIPアドレス |
| HTTP/HTTPS通信 | 利用者からVPSへ直接 | 利用者 → Cloudflare → VPS |
| オリジンIPの露出 | 原則として露出 | DNS上は隠せる |
| Cloudflare WAF | 利用できない | 適用できる |
| Cloudflare CDN/キャッシュ | 利用できない | 利用できる |
| CloudflareのHTTP分析 | 対象外 | 利用できる |
| 非HTTPサービス | そのまま利用 | 通常のプロキシ対象外 |
Cloudflare公式ドキュメントでも、DNSのみのレコードは実際のオリジンIPを返すため、Webトラフィックに対する保護が得られないと説明されています。一方、プロキシ設定ではCloudflareのAnycast IPが返され、HTTP/HTTPS通信がCloudflareを経由します。
Cloudflareプロキシにする主なメリット
1. 利用者から見えるIPをCloudflareのIPにできる
直接公開では、DNSを引くだけでVPSの実IPアドレスが分かります。プロキシを有効にすると、通常のDNS問い合わせにはCloudflareのAnycast IPが返され、利用者から見えるWebの入口をCloudflare側にできます。
その結果、VPSのIPアドレスをWebアクセスのために広く公開せずに済みます。
2. 通常のWeb攻撃をCloudflare側で処理できる
プロキシを経由するWebリクエストには、Cloudflareの機能を適用できます。
- DDoS攻撃に対する防御
- WAFルールによる不正なHTTPリクエストの検査
- レート制限
- Bot対策
- キャッシュによるオリジン負荷の軽減
- TLS終端と証明書管理
- HTTP/HTTPSアクセスの可視化
ただし、これはCloudflareを経由したリクエストに対しての効果です。攻撃者が既知のVPS IPへ直接アクセスできるなら、その通信はCloudflareのWAFやレート制限を通りません。
3. キャッシュ可能なコンテンツの負荷をVPSから逃がせる
静的ファイルやキャッシュ可能なレスポンスは、Cloudflareのエッジから返せます。
オリジンIPが知られているかどうかに関係なく、次のような負荷軽減が期待できます。
- 画像やCSS、JavaScriptの配信
- キャッシュ可能なHTML
- 大量の同一コンテンツへのアクセス
- 地理的に離れた利用者への配信
ただし、ログイン後の動的ページや、常に最新データが必要なAPIは、キャッシュ設定を誤ると情報漏えいにつながるため注意が必要です。
4. 直接アクセスを遮断する構成へ移行するきっかけになる
プロキシ化の本当の価値は、CloudflareのIPを隠すことだけではありません。
オリジン側で次のようなルールを設定することで、Webの入口をCloudflareに限定する構成にできます。
インターネット
│
├─ Cloudflare経由 ─────→ 許可
│
└─ VPS IPへ直接 ───────→ 拒否
この構成にすれば、攻撃者が過去にVPSのIPを知っていたとしても、Webアプリケーションへ直接到達しにくくなります。
Cloudflareプロキシのメリットを活かすための設定
1. 先にCloudflareのプロキシを有効にする
対象のWeb用 A / AAAA レコードをProxiedに変更します。
example.com A <VPSのIP> Proxied
www.example.com CNAME example.com Proxied
Cloudflareのプロキシ対象は主にWeb用のA、AAAA、CNAMEレコードです。MXやTXTなど、メールやドメイン検証に使うレコードまで無理にプロキシするものではありません。
2. オリジン側でCloudflareのIPレンジだけを許可する
Web用の80番・443番ポートについて、VPSのファイアウォールでCloudflareのIPレンジだけを許可し、それ以外を拒否します。
概念的には次のようなルールです。
TCP/80,443
├─ Cloudflare公式IPレンジからの通信 → 許可
└─ その他 → 拒否
CloudflareのIPレンジは固定の一覧を手作業で写経するのではなく、公式のIP一覧を参照して管理します。CloudflareのIPレンジが更新されたときに、VPS側の許可リストも更新できる運用にしておくと安全です。
例えばLinuxのファイアウォールで考える場合も、次のような順序が重要です。
- 自分のSSH接続元を許可する
- CloudflareのIPレンジから80/443番を許可する
- 80/443番のその他の通信を拒否する
- SSHは必要な送信元だけに制限する
- 設定反映後、別端末からCloudflare経由のアクセスを確認する
SSHまでCloudflareのIPだけに制限すると、自分自身がログインできなくなる可能性があります。Webの入口と管理用SSHの入口は分けて考えるのがポイントです。
3. Cloudflare経由のアクセスログを正しく記録する
プロキシ配下では、VPSから見る接続元IPがCloudflareのIPになることがあります。そのため、アプリケーションやWebサーバーのログで、Cloudflareが付与する実クライアントIP用ヘッダーを正しく扱う必要があります。
ただし、任意のクライアントが直接VPSへ到達できる状態でそのヘッダーを信頼すると、IP偽装につながります。先にファイアウォールでCloudflare経由に限定し、信頼するプロキシをCloudflareのIPレンジに限定するのが安全です。
IPを変更したほうがよいケース
次のような場合は、プロキシ化だけでなくVPSのIPローテーションも検討します。
- すでに継続的な攻撃や大量のスキャンを受けている
- 攻撃者がIPを直接指定して大容量通信を送っている
- 過去にDNS、メール、FTP、SSHなど複数の経路からIPが漏れている
- IPアドレスが攻撃対象としてブラックリスト化されている
- プロバイダー側のDDoS対策や通信制限に抵触している
Cloudflare公式も、過去のDNSレコードには以前のIPアドレスが残り得るため、必要に応じてオリジンIPをローテーションすることを案内しています。
実施の流れは概ね次のとおりです。
- 新しいVPSまたは新しいIPを用意する
- Webサーバー、アプリ、データベース接続を移行する
- Cloudflareのオリジン先を新IPへ変更する
- 新IP側でCloudflareのIPだけを許可する
- 旧IPを停止・解放する
- DNS、メール、監視、バックアップ設定に旧IPが残っていないか確認する
ただし、IPを変更しても、オリジン側のファイアウォールが開いたままだと、再び同じ問題が起きます。IP変更はリセット、ファイアウォール制限は再発防止と考えると分かりやすいです。
Cloudflareプロキシだけでは隠し切れない経路
プロキシ設定は、設定対象のホスト名に対するHTTP/HTTPS通信を保護するものです。次のような経路からオリジンIPが漏れることがあります。
DNS-onlyレコード
次のようなレコードをDNS-onlyで公開していると、同じVPSのIPを推測される可能性があります。
ftp.example.com
ssh.example.com
origin.example.com
old.example.com
Webに不要なレコードは削除し、必要なDNS-onlyレコードにはオリジンIPを載せない構成を検討します。
メールサーバー
Webとメールを同じサーバーで運用すると、メール関連の情報からIPが分かることがあります。可能なら、Web用オリジンとメール基盤は分離します。
証明書・過去のDNS情報
過去のDNSレコードや証明書の透明性ログなど、すでに公開された情報をCloudflareが消してくれるわけではありません。履歴から判明したIPが現在も使われているなら、IP変更が有効です。
アプリケーションのレスポンス
エラーメッセージ、デバッグ情報、Server ヘッダー、管理画面などから、ホスト名や構成情報が漏れることがあります。プロキシ設定後もアプリケーション側の情報露出を確認します。
さらに強くするならAuthenticated Origin Pulls
Cloudflareには Authenticated Origin Pulls（AOP） という、Cloudflareからオリジンへのリクエストにクライアント証明書を要求する仕組みがあります。
通常の「Cloudflare IPレンジだけを許可する」方法は、送信元IPによる制御です。AOPでは、TLSクライアント証明書も検証するため、オリジン側で「Cloudflare経由の通信であること」をさらに厳密に確認できます。
Cloudflare公式の説明では、AOPを使わない場合、オリジンIPを知っている相手はCloudflareを迂回して直接リクエストを送れるとされています。WAFと組み合わせることで、Cloudflareで評価されたリクエストだけをオリジンが受け付ける構成にできます。
ただし、AOPはオリジン側のWebサーバー設定が必要です。まずは次の順序で導入するのが現実的です。
- Cloudflareプロキシを有効化
- CloudflareのIPレンジを許可
- 直接アクセスを拒否
- 動作確認とログ確認
- 必要に応じてAOPやCloudflare Tunnelを導入
Cloudflare Tunnelを使うと、オリジンからCloudflareへのアウトバウンド接続を利用し、公開到達可能なオリジンIPを持たない構成も検討できます。
注意点・デメリット
すべての通信がプロキシできるわけではない
Cloudflareの通常のDNSプロキシは、主にHTTP/HTTPS向けです。SSH、SMTP、任意のTCP/UDPサービスを同じ感覚でプロキシできるわけではありません。
メール用のMXレコードや、CloudflareのHTTPプロキシに対応しないサービスはDNS-onlyにする必要があります。その場合は、サービス分離、VPN、Cloudflare Tunnel、Cloudflare Spectrumなど別の方法を検討します。
Cloudflare障害時の影響が増える
Cloudflareを経路に追加するため、Cloudflare側の障害や設定ミスがWebアクセスに影響します。管理用に、Cloudflareを経由しない安全な緊急アクセス経路を用意しておくと安心です。
オリジン証明書とSSL/TLSモードに注意する
CloudflareからVPSまでの通信も暗号化し、適切なSSL/TLSモードを選びます。特に本番環境では、オリジン証明書の検証を行う設定を検討してください。
長時間処理・大容量アップロードには制限がある
Cloudflareプロキシには、プランに応じたリクエストサイズ、タイムアウト、接続時間などの制限があります。長時間のレスポンス、大容量ファイル、WebSocket、gRPCなどを利用する場合は、公式ドキュメントの制限を確認してから移行します。
実施前後のチェックリスト
Cloudflare側
- Web用のA/AAAA/CNAMEレコードをProxiedにした
- 不要なDNSレコードを削除した
- DNS-onlyレコードにオリジンIPが含まれていない
- SSL/TLSモードを確認した
- WAFやレート制限を必要に応じて設定した
- キャッシュ対象と非対象を確認した
VPS側
- Cloudflare公式IPレンジからの80/443番だけを許可した
- その他の80/443番通信を拒否した
- SSHの送信元を制限した
- Cloudflareの実クライアントIPヘッダーを安全に処理している
- Webサーバーのエラーページやレスポンスヘッダーを確認した
- 旧IPや別ホスト名から直接アクセスできないことを確認した
運用面
- Cloudflare IPレンジの変更を追跡できる
- Cloudflare経由と直接アクセスの両方を監視している
- 新しいオリジンIPを不用意にDNS、メール、監視設定へ公開していない
- 障害時のSSH・コンソール・バックアップ経路を確保している
まとめ
VPSのWebフロントを直接公開する構成と比べると、Cloudflareプロキシには次のメリットがあります。
- 今後のDNS問い合わせにVPSのIPを返さずに済む
- CloudflareのDDoS対策、WAF、レート制限をWeb通信へ適用できる
- キャッシュによってオリジンの負荷を減らせる
- Webの入口をCloudflareへ集約できる
- 直接アクセスを拒否する構成へ移行できる
一方で、プロキシを有効にするだけでは、VPSへの直接アクセスは止まりません。
実際の対策は、次のように考えるとよいでしょう。
プロキシ化
+ オリジンIPの露出経路を整理
+ Cloudflare IPだけを許可
+ 直接アクセスを拒否
+ 必要ならIP変更
+ 必要ならAOP / Tunnel
したがって、Cloudflareプロキシは「DNSをCloudflareに向けるだけ」ではなく、Webの入口をCloudflareに集約し、オリジンへの直接アクセスを制限する構成として考えるのが適切です。