Cloudflare を入れたのに攻撃される？オリジン IP 漏洩の 7 つの見落とし経路と対策ガイド

ブログが攻撃を受け、サーバーが応答不能になり、転送量が 1 日 20 GB に達して強制停止——Cloudflare を入れているのに、なぜ直撃されるのでしょうか。ログを見ると、攻撃トラフィックは Cloudflare を経由せず、オリジンサーバーの IP に直接届いています。攻撃者が CDN を迂回して本物のサーバーを叩く、これがオリジン IP 漏洩の問題です。

よくある話です。「Cloudflare を設定すれば安心」と思っていても、DNS 履歴・メールヘッダー・サブドメインなどから IP は既に漏れていることがあります。本記事では、漏洩経路、検出方法、そして完全な防御策を解説します。

なぜオリジン IP が漏れるのか

オリジン IP 漏洩とは、どんな被害があるか

Cloudflare などの CDN では、ユーザーは Cloudflare のエッジにアクセスし、Cloudflare がオリジンサーバーへ転送します。攻撃者から見えるのは Cloudflare の IP だけで、本物のサーバー IP は見えません。

しかし何らかの経路でオリジン IP を突き止められると、CDN の意味がなくなります。攻撃者は Cloudflare の防御をすべて迂回して、直接オリジンを叩けます。

被害は深刻です。

• サーバー停止：DDoS がオリジンに直撃し、耐えきれずダウン
• 転送量課金の急増：従量課金 VPS では請求が跳ね上がる
• データ窃取リスク：脆弱性があれば WAF を迂回して侵入される

Cloudflare 2024 年 Q4 レポートでは、観測史上最大の 5.6 Tbps DDoS 攻撃が記録されました。

一般サイトには稀ですが、数 Gbps でも小規模サーバーは耐えられません。

[画像：CDN 動作の概略図]

プロンプト：server behind CDN shield, user traffic flow through cloudflare nodes, simplified diagram, tech blue color scheme, professional illustration

オリジン IP 漏洩の 7 つの経路

では、IP はどう漏れるのでしょうか。よくある 7 つの経路を、リスクの高い順にまとめます。

経路 1：DNS 履歴（リスク：高）

最も多く、見落とされがちな経路です。

問題は、本番 IP に直接 A レコードを向けて運用し、後から Cloudflare を入れるパターン。DNS レコードは SecurityTrails や DNSdumpster などに永久保存されます。

私もサイト公開時に生 IP で運用し、半年後に Cloudflare を入れたことがあります。SecurityTrails で確認すると、数ヶ月前の DNS 記録がそのまま残っていました。

経路 2：メールサーバーヘッダー（リスク：高）

非常に見落とされがちです。

登録確認メール、パスワードリセット、RSS 通知……Email Header には送信サーバーの IP が含まれます。自前メールサーバーや、Web サーバーから直接送信していると IP が漏れます。

攻撃者はテスト登録で確認メールを受け取り、メール原文で Received フィールドを探せば、送信サーバーの IP が分かります。

初めて知ったときは驚きました。メールから IP が漏れるとは思いませんでした。

経路 3：サブドメインスキャン（リスク：中〜高）

こちらもよくあるパターンです。

example.com だけ Cloudflare 経由でも、mail.example.com（メール）、admin.example.com（管理画面）、dev.example.com（開発環境）などは生 IP のことが多い。sublist3r や OneForAll で全サブドメインを列挙し、1 つでも生 IP が返れば位置が特定されます。

主ドメインとサブドメインが別サーバーでも、同じ C セグメント（例：192.168.1.x）なら IP 帯は推測できます。

経路 4：サイトソースコード漏洩（リスク：中）

開発時に残したテストページやデバッグ情報からも IP が漏れます。

よくある例：

• phpinfo() ページを削除し忘れ、サーバー IP と設定が丸見え
• .git ディレクトリが外部公開され、設定ファイルに IP が記載
• デバッグモードのエラーログにサーバーパスと IP が出力
• ソースコードに API エンドポイントを IP でハードコード

テスト用 info.php を残したまま検索エンジンにインデックスされ、サーバー情報が丸見え——こうした初歩的ミスは意外と多いです。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

経路 5：SSL 証明書照会（リスク：中）

SSL 証明書も漏洩源になり得ます。

Certificate Transparency により、発行された SSL 証明書はすべて記録されます。crt.sh や Censys でドメインの証明書履歴を調べ、過去にバインドされていた IP を追跡できます。

Cloudflare 導入前に証明書を生 IP に直接設定していた場合、その記録が残ります。毎回 IP が分かるわけではありませんが、有効な経路の 1 つです。

経路 6：海外 DNS 解決の差異（リスク：中〜低）

国内 CDN のみで海外ノードがない場合、海外 DNS からはオリジン IP が返ることがあります。Cloudflare はグローバル CDN なので問題は少ないですが、国内小規模 CDN では注意が必要です。

Google DNS（8.8.8.8）や Cloudflare DNS（1.1.1.1）で解決し、返る IP が CDN ノードかどうか確認しましょう。

経路 7：C セグメントスキャンと同居サイト（リスク：低）

1 台のサーバーで複数サイトを運用している場合、1 つでも防御が甘いと他サイトの IP 帯が特定されることがあります。

Bing や Google の ip:xxx.xxx.xxx.xxx 構文で IP 上のサイトを逆引きしたり、C セグメント全体をスキャンしたりできます。リスクは相対的に低いですが、同居サイトが多い場合は注意してください。

[画像：オリジン IP 漏洩経路の一覧図]

プロンプト：7 ways of IP leak infographic, DNS history, email headers, subdomain scan, source code leak, SSL certificate, colorful icons, flat design

オリジン IP 漏洩を検出する方法

ここまで漏洩経路を見てきました。では、自分のサイトが該当しないか確認しましょう。以下のチェックリストを順に実行すれば、ほとんどの問題を見つけられます。

検出ツール一覧

詳細な検出手順

チェック 1：DNS 履歴

次のサイトでドメインを検索してください。

• SecurityTrails（securitytrails.com）——ドメインの過去 DNS 解決記録
• DNSdumpster（dnsdumpster.com）——DNS 列挙、サブドメインと履歴
• Netcraft（sitereport.netcraft.com）——サイトの過去 IP も記録

Cloudflare 導入前の生 IP が残っていれば、漏洩はほぼ確定です。

チェック 2：メールヘッダー

実用的な方法です。

1. サイトに登録機能があれば、テストアカウントを作成して確認メールを受信
2. またはパスワードリセットでメールを受信
3. 「メール原文を表示」でヘッダーを開く（クライアントによって名称は異なります）
4. Received や X-Originating-IP を検索
5. 記載 IP がオリジン IP かどうか確認

SendGrid や Amazon SES 経由なら第三者 IP が表示され、問題ありません。

チェック 3：サブドメインスキャン

全サブドメインの DNS 解決を手動確認し、生 IP へ向いていないか調べます。

# dig でサブドメインを確認
dig mail.yourdomain.com
dig admin.yourdomain.com
dig api.yourdomain.com

またはオンラインツールで自動スキャン：

• Sublist3r——Python 製、多数のサブドメインを列挙
• OneForAll——国内開発のサブドメイン収集ツール

列挙したサブドメインを ping し、返る IP が Cloudflare かどうか確認します。

チェック 4：グローバル ping

各地からドメインを ping し、返る IP が一致するか確認します。

• ping.pe——世界各地のノードから同時 ping
• 17ce.com——国内の多地 ping ツール

国内と海外で IP が異なれば、設定ミスの可能性があります。Cloudflare はグローバル CDN なので、通常は各地で最寄り CF ノード IP が返ります。

チェック 5：SSL 証明書の関連照会

crt.sh でドメインを検索し、証明書履歴を確認します。

https://crt.sh/?q=yourdomain.com

証明書がオリジン IP にバインドされていた記録があれば、IP は半公開状態と言えます。

チェック 6：ネットワーク空間検索エンジン

やや上級ですが有効です。Shodan や Censys でドメインやサイト特徴を直接検索します。

• Shodan（shodan.io）——インターネットデバイス検索
• Censys（censys.io）——ネットワーク空間スキャン
• Fofa（fofa.so）——国内のネットワーク空間測量

オリジンで 80 ポートなどが公開されていれば、インデックスされ IP が露出する可能性があります。

チェック 7：サーバーログ

最も直接的な方法です。アクセスログを確認します。

# Nginx ログの一般的な場所
tail -f /var/log/nginx/access.log
# Apache ログ
tail -f /var/log/apache2/access.log

Cloudflare IP 帯以外からの直 IP アクセスがあれば、誰かがオリジン IP を知って直撃を試みているサインです。Cloudflare の IP 帯は公式ドキュメントで確認でき、正常時はすべてのリクエストがこれらの帯域から来るはずです。

完全な防御策

設定前の準備

Cloudflare 未導入、または IP 漏洩が判明して再設定する場合、先に以下を済ませると後が楽です。

準備 1：サーバー IP の変更、または新規サーバーの利用

最も徹底的な方法です。IP が漏れているなら、新 IP でやり直すのがベスト。

クラウド VPS では次の選択肢があります。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

• 新サーバーを購入：データ移行後、旧サーバーを破棄
• パブリック IP の変更：Alibaba Cloud・Tencent Cloud などで Elastic IP を付け替え（無料〜少額のことが多い）
• 新ドメインへの切り替え：ドメインと IP の結びつきが強い場合（コスト高、最終手段）

サイトが立ち上がったばかりなら、新サーバーへの移行が最も手軽です。データが少なければ数分で済みます。

準備 2：IP 漏洩の痕跡をできる限り削除

DNS 履歴は第三者に永久保存されているため消せませんが、管理下のものは整理しましょう。

• テストページ（phpinfo.php、info.php など）を削除
• デバッグモードとエラーログ出力を無効化
• .git ディレクトリへの外部アクセスを拒否（nginx 設定）
• ソースコードに IP がハードコードされていないか確認

準備 3：DNS 解決方針の設計

どのドメインを Cloudflare 経由にするか、事前に決めておきます。

• メインドメインと www：必ず Cloudflare 経由
• 外部公開サブドメイン：blog、api、img なども Cloudflare 経由
• メールサーバー：自前なら第三者メールサービスへの移行を検討
• 内部サービス：管理画面や DB はパブリック DNS を設定せず、内部ネットワーク IP でアクセス

Cloudflare 設定のベストプラクティス

準備ができたら、オリジン IP をしっかり隠す Cloudflare 設定に入ります。

実践 1：全サイト CDN、全サブドメインを Cloudflare 経由

最重要項目です。Cloudflare の DNS 設定では、各レコード横に雲アイコンがあります。

• オレンジ雲：Cloudflare プロキシ経由、オリジン IP を隠す
• グレー雲：プロキシなし、生 IP に直接解決

外部公開するドメインはすべてオレンジに。メインドメインだけオレンジ、サブドメインはすべてグレー——よくあるパターンですが、意味がありません。

グレーにできるのは、Cloudflare がプロキシできない MX や TXT などのレコードだけです。

[画像：Cloudflare DNS 設定画面]

プロンプト：cloudflare DNS settings screenshot, orange cloud vs gray cloud comparison, highlight the proxy status toggle, clean interface, 16:9

実践 2：メールは第三者サービスを使い、自前サーバーで送らない

メールヘッダーは送信サーバー IP を漏らします。自前サーバーから送るのをやめ、第三者サービスに切り替えましょう。

• SendGrid：無料枠 1 日 100 通、小規模サイトに十分
• Amazon SES：従量課金、月 62,000 通まで無料（AWS アカウント必要）
• Mailgun：無料枠あり、API が使いやすい

いずれも API と SMTP を提供し、移行も容易。到達率も自前より高いことが多いです。

実践 3：ファイアウォールのホワイトリスト、Cloudflare IP のみ許可

核心の防御です。オリジン IP が知られていても、ファイアウォールが Cloudflare IP 帯のみ許可していれば、攻撃トラフィックは届きません。

Cloudflare 公式 IP 帯リスト：

https://www.cloudflare.com/ips/

ダウンロード後、サーバーファイアウォールを設定します。iptables の例：

# ⚠️ 重要：SSH ポートに影響しないよう先に確認
# テスト環境で検証してから本番に適用
# 既存ルールをクリア
iptables -F
# ローカルループバックを許可
iptables -A INPUT -i lo -j ACCEPT
# 確立済み接続を許可
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# SSH を許可（自分の SSH ポートに変更）
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Cloudflare IP 帯のみ 80/443 を許可
# 以下は IPv4 の一部。完全リストは公式サイトから取得
iptables -A INPUT -p tcp -m multiport --dports 80,443 -s 173.245.48.0/20 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 80,443 -s 103.21.244.0/22 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 80,443 -s 103.22.200.0/22 -j ACCEPT
# ... すべての CF IP 帯を追加 ...
# その他の 80/443 は拒否
iptables -A INPUT -p tcp -m multiport --dports 80,443 -j DROP
# ルールを保存
iptables-save > /etc/iptables/rules.v4

設定時の注意：

1. テスト環境で先に試す
2. SSH ポート（22）のアクセスは必ず残す
3. 設定後、別デバイス（スマホなど）で動作確認
4. クラウド VPS ならコンソールのセキュリティグループが安全で便利

クラウド VPS なら、コンソールのセキュリティグループ設定の方が誤操作で SSH が遮断されるリスクが低いです。

設定後、スマホのモバイル回線からオリジン IP に直接アクセスしてみてください。接続できなければ成功です。

[画像：ファイアウォール設定の概略図]

プロンプト：firewall protection layers diagram, cloudflare IP whitelist, block non-cloudflare traffic, security shield icon, professional tech illustration

実践 4：サーバーの ping 応答を無効化

IP 帯スキャンでサーバーを特定されないよう、ping 応答を止めます。

# ping を禁止
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
# 永続化：/etc/sysctl.conf を編集
net.ipv4.icmp_echo_ignore_all = 1
# 反映
sysctl -p

これで IP 帯スキャン時にサーバーは応答せず、無効 IP のように見えます。

高度な防御策

サイトの重要度が高い、または既に攻撃を受けた場合は、さらに高度な対策を検討します。

対策 1：Cloudflare Tunnel（旧 Argo Tunnel）

オリジン IP を一切公開しない Cloudflare の機能です。

サーバー上で cloudflared を実行し、Cloudflare ネットワークへ outbound トンネルを張ります。

• 80/443 を開ける必要がない
• インターネットからオリジン IP に到達できない
• すべてのトラフィックが Cloudflare 経由のトンネルで転送される

設定手順（簡略版）：

# cloudflared をインストール
wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
dpkg -i cloudflared-linux-amd64.deb
# Cloudflare にログイン
cloudflared tunnel login
# トンネルを作成
cloudflared tunnel create mytunnel
# ルートを設定
cloudflared tunnel route dns mytunnel yourdomain.com
# トンネルを実行
cloudflared tunnel run mytunnel

ほぼ完璧な IP 隠蔽ですが、設定はやや複雑で、一部高度機能は有料版が必要です。

対策 2：定期的なオリジン IP の変更

高リスクサイトでは、3〜6 ヶ月ごとに IP をローテーションする習慣も有効です。過去 IP が漏れていても、攻撃は空振りになります。コストは高めなので、サイトの重要度に応じて判断してください。

対策 3：異常トラフィックの監視

Cloudflare 以外の IP からのアクセスを検知したら即座にアラート：

# 簡易監視スクリプトの例
tail -f /var/log/nginx/access.log | grep -v -E "(173\.245\.|103\.21\.|103\.22\.)" | while read line
do
    echo "Alert: Non-CF IP access! $line"
    # メールや SMS 通知と連携可能
done

直 IP アクセスの試行をすぐに把握できます。

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

対策 4：ソースコードに IP をハードコードしない

基本中の基本ですが、念のため。API 呼び出しやリソース読み込みはすべてドメインを使いましょう。

// 悪い例
fetch('http://123.456.78.90/api/data')
// 良い例
fetch('https://api.yourdomain.com/data')

フロントエンドコードを見られても、オリジン IP は見つかりません。

漏洩が判明したら

IP が漏れていると分かっても、慌てる必要はありません。履歴データは消せませんが、リスクは下げられます。

対処 1：即座にサーバー IP を変更

最も効果的です。新サーバーの申し込み、またはパブリック IP の付け替えでデータを移行します。

コスト目安：

• クラウド VPS の IP 変更：無料〜数十元が多い
• 新サーバー購入：1 コア 2 GB なら月 30〜50 元程度
• データ移行：小サイトなら 30 分程度

IP 変更後、旧サーバーはすぐ破棄せず、数日様子を見てから停止しましょう。

対処 2：ファイアウォールのホワイトリスト

IP が知られていても、ファイアウォール設定が正しければ攻撃は届きません。前述の iptables 設定やクラウドセキュリティグループで、Cloudflare IP 帯のみ 80/443 を許可してください。

注意：設定ミスで SSH が遮断されないよう、テスト環境で先に確認し、SSH ポート（22）を残し、別デバイスでテスト。私も一度設定ミスで締め出され、VNC 経由で復旧したことがあります。

対処 3：Cloudflare Rate Limiting

Cloudflare の Rate Limiting で、単一 IP のアクセス頻度を制限できます。

無料版には制限がありますが、Pro 版（月 20 ドル）なら細かいルールが設定可能です。

• 1 IP あたり 10 秒間に最大 10 リクエスト
• 閾値超過で自動ブロックまたは Challenge（CAPTCHA）
• 特定パスへの保護

小規模攻撃の抑止に有効です。

対処 4：高防御 IP サービスの検討

頻繁に攻撃を受ける、またはビジネスクリティカルなサイトなら、DDoS 高防 IP を検討します。

Alibaba Cloud、Tencent Cloud、Baidu Cloud など中国系クラウドには DDoS 高防御サービスがあります。

• 帯域課金：固定料金で一定帯域（例：20 G）を防御
• 攻撃量課金：平時は低コスト、攻撃時のみ課金
• コスト：防御レベルにより月数百〜数万

個人サイトや小規模企業には高コストですが、EC サイトやゲームサーバーには投資価値があります。

対処 5：監視と即時対応

異常トラフィックや直 IP アクセスを検知したら、すぐ対応します。

• Cloudflare の通知機能で流量異常時にメールアラート
• zabbix や prometheus などの監視ツールを導入
• 攻撃時は DNS を一時変更してバックアップサーバーへ切り替え

反応速度が重要です。数時間気づかず、転送量課金が膨らんだ事例もあります。

まとめ

オリジン IP 漏洩は、Cloudflare を入れただけでは防げない体系的な問題です。DNS 履歴からメールヘッダー、サブドメイン、SSL 証明書まで、漏洩経路は意外と多い。

最も重要な防御：

1. 全サイト CDN — 外部公開ドメインはすべて Cloudflare 経由、オレンジ雲をオン
2. ファイアウォールのホワイトリスト — Cloudflare IP 帯のみ許可、最後の防壁
3. メールの外部委託 — SendGrid、SES などを使い、自前サーバーから送らない
4. 定期セルフチェック — 本記事のツールで確認、未然に防ぐ

Cloudflare 未導入なら、最初から正しい手順で設定すれば後の手間が省けます。既に導入済みでも、10 分のセルフチェックで安心できます。

万が一 IP が漏れていても、新 IP への変更とファイアウォール設定で、大きな問題にはなりにくい。

最後にもう一度：オリジン IP の防御は継続的な作業です。サブドメイン追加時は CDN 経由を忘れず、設定変更で IP を晒さないよう注意し、定期的に防御が有効か確認しましょう。

まず SecurityTrails で DNS 履歴を調べ、問題があれば本記事の手順で段階的に強化してください。手間はかかりますが、サーバーダウンよりはるかにマシです。