CDNを使っている場合のオリジンサーバの見つけ方 ― メカニズムと対策

解析

サイバーセキュリティ 攻撃手法 防御対策  📖 読了時間の目安：約20〜25分

🎯 この記事でわかること
  • CDNとオリジンサーバの仕組みをゼロから理解できる
  • 攻撃者がオリジンIPを突き止める7つの手法を具体的に知れる
  • 自分のサーバを守るための実践的な対策がわかる
  • 実際に使われているツール・コマンドが確認できる
📋 目次
  1. CDNとは何か？―まず仕組みをゼロから理解しよう
  2. オリジンサーバとは？―CDNの「本体」を知る
  3. なぜオリジンIPを隠す必要があるのか？―脅威の全体像
  4. 攻撃者がオリジンIPを探す7つの手法（技術詳細）
    1. DNSの過去の履歴から探す
    2. SSL/TLS証明書の情報から探す
    3. サブドメインのスキャンから探す
    4. メールヘッダーから探す
    5. HTTPレスポンスヘッダーから探す
    6. Shodanなどの検索エンジンで探す
    7. Faviconハッシュから探す
  5. 実際の攻撃シナリオ―発見からDDoSまで
  6. 完全防御のための10の対策
  7. 主要CDNサービスでの設定ポイント
  8. まとめ―チェックリスト付き

1. CDNとは何か？―まず仕組みをゼロから理解しよう

1-1. CDNの基本概念

CDN（Content Delivery Network＝コンテンツ配信ネットワーク）とは、世界中に分散配置されたサーバ群を使って、Webサイトのコンテンツを高速・安定的に配信するための仕組みです。

たとえば、あなたが東京にある1台のサーバでWebサイトを運営しているとします。アメリカのユーザーがそのサイトを開こうとすると、データが太平洋を往復しなければならず、表示に時間がかかります。しかしCDNを使うと、アメリカのユーザーには近くのアメリカのCDNサーバからコンテンツが届きます。これが「エッジサーバ」です。

CDNはもともとパフォーマンス向上のために生まれましたが、現在ではセキュリティ機能も強力で、特に以下の2点が重視されています：

  • DDoS攻撃の緩和：大量のリクエストをCDNが吸収してオリジンを守る
  • WAF（Webアプリケーションファイアウォール）：SQLインジェクションやXSSなどをCDN側でブロックする

1-2. CDNの主要プレイヤー（シェアと事実）

CDNサービス 特徴 代表的な利用例
Cloudflare 世界最大規模。無料プランあり。320都市以上にPoP（拠点）を持つ 中小企業〜大企業まで幅広い
AWS CloudFront Amazon傘下。AWSサービスとの連携が強力 AWSを使う企業全般
Akamai 老舗。金融・官公庁など高信頼性が求められる領域に強い 銀行、政府機関など
Fastly リアルタイム設定変更が特徴。エッジコンピューティングに強い メディア、EC
Google Cloud CDN Google Cloud Platformと統合。Googleのグローバルネットワークを活用 GCPユーザー
📊 実際の数字（FACT）
W3Techsの調査によると、2024年時点でCloudflareはCDN市場においてWebサイト全体の約35%以上のシェアを持ちます。Akamaiは約10%、AWS CloudFrontは約9%です。Cloudflareは1日に約5兆件のDNSクエリを処理しているとされます（Cloudflare公式発表）。

1-3. CDNの動作フロー（図解で理解）

以下はCDNを使ったアクセスの流れです：

【CDNなしの場合】 ユーザー (東京) ──────────────────→ オリジンサーバ (東京) ↑ 直接アクセス。DDosを受けたら即ダウン 【CDNありの場合】 ユーザー (東京) → CDNエッジサーバ (東京) ─キャッシュあり→ レスポンス ─キャッシュなし→ オリジンサーバ (東京) ユーザー (NY) → CDNエッジサーバ (NY) ─キャッシュあり→ レスポンス ─キャッシュなし→ オリジンサーバ (東京)

ポイントは、ユーザーから見えるIPアドレスはCDNのIPアドレスであり、オリジンサーバのIPアドレスは（理想的には）見えない点です。しかし、このIPアドレスが漏れてしまうと大問題になります。

2. オリジンサーバとは？―CDNの「本体」を知る

オリジンサーバ（Origin Server）とは、Webサイトの実際のコンテンツやアプリケーションが動作している本体のサーバです。CDNはオリジンサーバから受け取ったコンテンツをキャッシュして配信しますが、オリジンサーバ自体は一箇所（または少数の場所）にしかありません。

たとえばWordPressサイトの場合、以下がオリジンサーバ上に存在します：

  • WordPressのPHPファイル・プラグイン・テーマ
  • MySQLデータベース（記事・ユーザー情報など）
  • アップロードしたメディアファイル
  • wp-config.php（データベースパスワードが入った設定ファイル）
⚠️ なぜオリジンサーバのIPが危険なのか？
CDNは「防波堤」です。オリジンサーバのIPアドレスがバレてしまうと、攻撃者はCDNを完全にスキップしてオリジンに直接攻撃を仕掛けることができます。DDoS攻撃、ブルートフォース、SQLインジェクション、すべてがCDNの防御をすり抜けてしまいます。

現実のインフラでは、Webサーバ（Apache/Nginx）とデータベースサーバが同一マシンのこともあれば、VPS・クラウドVM（AWS EC2、さくらのVPS、ConoHaなど）や、物理サーバであることもあります。WordPressの場合は特に、格安レンタルサーバをオリジンにしているケースが多く、それらはDDoSに極めて弱いです。

3. なぜオリジンIPを隠す必要があるのか？―脅威の全体像

3-1. CDNを「バイパス」された場合の脅威

オリジンIPが判明した場合、攻撃者がとれる行動は多岐にわたります：

攻撃手法 内容 影響
DDoS攻撃（直接） CDNを迂回してオリジンIPに大量トラフィックを送る サービス停止・サーバダウン
ポートスキャン オリジンIPのポートを調べ、開いているサービスを特定 SSH・RDP・DBへの侵入口発見
脆弱性スキャン Nikto・Nucleiなどで既知の脆弱性を自動スキャン CVEの発見と悪用
WAFバイパス SQLインジェクション・XSSをCDNのWAFなしで直接送信 データ漏洩・改ざん
ブルートフォース WordPressのwp-login.phpなどに直接総当たり 不正ログイン・乗っ取り
地理的位置の特定 IPからデータセンターの場所を特定 物理的攻撃・法的手段の悪用

3-2. 実際の被害事例（FACT）

📌 実際に起きたCDNバイパス攻撃の事例

① GitHubへのDDoS（2018年）
2018年2月28日、GitHubはMemcachedを悪用した増幅型DDoS攻撃を受け、ピーク時1.35Tbpsのトラフィックが記録されました。これはCDNを完全にバイパスするものではありませんでしたが、特定のサービスエンドポイントへの直接攻撃であり、CDNだけでは完全に防げないことを示しました。

② Cloudflare利用サイトへのバイパス攻撃（継続的な事例）
セキュリティリサーチャーのCraig Pearce氏らの調査では、Cloudflareを使っているWebサイトの相当数で、過去のDNSレコードやサブドメインからオリジンIPが特定できることが報告されています。特にCloudflareへ移行前のIPアドレスが公開DNS履歴に残っているケースが多く見られました。

③ 2023年〜2024年：AI企業・フィンテック企業を標的にしたL7 DDoS
Cloudflareの2024年DDoSレポートによると、2023年Q4に記録された最大のHTTP DDoS攻撃は毎秒2,010万リクエスト（20.1Mrps）に達しました。多くはオリジンIPを直接狙ったものでした。

4. 攻撃者がオリジンIPを探す7つの手法（技術詳細）

⚠️ 免責事項
以下の手法はすべて、自分が管理するサーバへのセキュリティテスト、または許可を得たペネトレーションテストに限り使用されるべきです。他者のサーバに無断で実行することは不正アクセス禁止法（日本）などの法律に違反します。この記事の目的は防御の理解にあります。

手法① DNSの過去の履歴から探す

最もよく使われる手法です。CDNを導入する前、多くのサイトは自分のオリジンIPアドレスをDNSのAレコードに直接登録していました。CDNに移行した後も、過去のDNSレコードはさまざまなサービスに記録が残っています。

使われるツール・サービス：

  • SecurityTrails（https://securitytrails.com）：過去のDNSレコードの履歴を無料で検索できる
  • ViewDNS.info（https://viewdns.info/iphistory/）：IPヒストリー機能
  • DNSdumpster（https://dnsdumpster.com）：DNSレコードの可視化ツール
  • RiskIQ（Microsoft Defender Threat Intelligence）：DNS履歴の高度な分析
# SecurityTrailsでの調査例（APIを使った場合） curl -s “https://api.securitytrails.com/v1/history/example.com/dns/a” \ -H “APIKEY: YOUR_API_KEY” | python3 -m json.tool # 出力例（簡略化） { “records”: [ { “values”: [{“ip”: “203.0.113.50”}], ← これがCDN移行前のオリジンIP “first_seen”: “2019-03-01”, “last_seen”: “2021-08-15” }, { “values”: [{“ip”: “104.21.14.5”}], ← CloudflareのIP（現在） “first_seen”: “2021-08-16” } ] }

上の例では、2021年8月16日以前のIPアドレス（203.0.113.50）がオリジンIPである可能性が高いです。攻撃者はこのIPに直接DDoSをかけたり、ポートスキャンをしたりします。

🔍 なぜDNS履歴が残るのか？
インターネット上のDNSリゾルバやパッシブDNSサービスは、DNSクエリの結果を記録し続けています。これは障害解析やセキュリティ調査のためですが、攻撃者にも悪用されます。「一度インターネットに公開されたIPは消えない」と思っておくべきです。

手法② SSL/TLS証明書の情報から探す

HTTPS通信に使われるSSL/TLS証明書には、ドメイン名の情報が含まれています。そしてこの証明書の発行履歴は、証明書の透明性（Certificate Transparency, CT）ログと呼ばれる公開ログに記録されます。

攻撃者はこのCTログを検索し、CDNに隠れているオリジンサーバのサブドメインや、そのIPアドレスを割り出します。

使われるツール・サービス：

  • crt.sh（https://crt.sh）：CTログを無料で検索できる。最もよく使われる
  • Censys（https://search.censys.io）：IPアドレスやドメインでSSL証明書を横断検索
  • Facebook CT Monitor：Facebookが提供するCTログ監視サービス
# crt.shで証明書を検索（例：example.comの全サブドメインの証明書） curl -s “https://crt.sh/?q=%25.example.com&output=json” | \ python3 -c “import sys, json; [print(r[‘name_value’]) for r in json.load(sys.stdin)]” | \ sort -u # 典型的な出力例 *.example.com example.com mail.example.com origin.example.com ← “origin”という名前が怪しい！ staging.example.com ← ステージング環境がオリジンを指している場合も api-internal.example.com # 次のステップ：見つかったサブドメインをdigで調べる dig +short origin.example.com # → 203.0.113.50 ← CloudflareのIPではなくオリジンIPが直接返ってくることがある
💡 CTログとは何か？
CTログ（Certificate Transparency Log）は、CAブラウザフォーラムが定めた標準で、すべての公的CA（認証局）が発行したSSL証明書を公開ログに記録することを義務付けた仕組みです（2018年よりChrome必須）。フィッシングサイトの証明書を見つける目的で作られましたが、攻撃者にも使われるという「諸刃の剣」です。

手法③ サブドメインのスキャンから探す

多くの組織では、CDNを使っているメインドメイン（www.example.com）の裏に、CDNを通っていないサブドメインが存在します。たとえば以下のようなケースです：

  • mail.example.com：メールサーバ（CDNを通さないことが多い）
  • ftp.example.com：FTPサーバ
  • staging.example.com：開発・テスト環境
  • direct.example.com、origin.example.com：CDN設定用に残した直接アクセス用ドメイン
  • cpanel.example.com：cPanel（レンタルサーバ管理画面）

これらがCDNを通していなければ、そのIPがオリジンIPです。

# サブドメイン列挙ツール例：subfinder（有名なOSSツール） subfinder -d example.com -silent | anew subdomains.txt # massdnsで大量のサブドメインを高速解決 massdns -r resolvers.txt -t A -o S subdomains.txt | \ awk ‘{print $1, $3}’ | sort -u # amassによる包括的な列挙 amass enum -d example.com -o amass_output.txt # dnsx でCloudflareのIPを除外してオリジンを絞り込む cat subdomains.txt | dnsx -resp-only | \ grep -v -f cloudflare_ip_ranges.txt

特にメールサーバ（MXレコード）とWebサーバが同じオリジンにある場合、メールに関連するサブドメインを調べることでオリジンIPが判明するケースが非常に多いです。

手法④ メールヘッダーから探す

これは見落とされがちな手法です。Webサイトの問い合わせフォームやニュースレター登録で届くメールには、送信サーバのIPアドレスがヘッダーに記録されます。

# メールのヘッダー例（GmailやThunderbirdで「ヘッダーを表示」から確認） Received: from mail.example.com (mail.example.com [203.0.113.50]) by mx.google.com with ESMTP id abc123 for <you@gmail.com>; Mon, 1 Jan 2024 10:00:00 -0800 # “203.0.113.50” がオリジンサーバのIPアドレスであることが多い # このIPがCDNのIPでなければ、オリジンIPとして特定できる

攻撃者は以下の手順を踏みます：

  1. 標的サイトの問い合わせフォームでダミーの問い合わせを送信
  2. 自動返信メールを受け取る
  3. メールのヘッダーを確認し、Received:フィールドからIPを取得
  4. そのIPがCloudflare等のCDN IPでなければ、オリジンIPを特定完了
⚠️ WordPressサイトは特に危険
WordPressは標準でPHPのmail()関数やSMTPプラグインを使ってメールを送りますが、多くの場合オリジンサーバから直接送信します。その結果、メールヘッダーにオリジンIPが記録されます。Contact Form 7、WPForms、Gravity Formsなどの定番プラグインを使っている場合も同様です。

手法⑤ HTTPレスポンスヘッダーから探す

WebサーバやCDNの設定ミスにより、HTTPレスポンスヘッダーにオリジンの情報が漏れることがあります。

# curlでヘッダーを確認 curl -sI https://www.example.com # 漏れが起きるヘッダーの例： HTTP/2 200 server: nginx/1.18.0 ← Webサーバのソフトウェアとバージョンが露出 x-powered-by: PHP/8.1.12 ← PHPのバージョン露出（脆弱性チェックに悪用） x-origin-server: 203.0.113.50← 設定ミスでオリジンIPが丸見え（実際にあるミス！） x-real-ip: 203.0.113.50 ← 本来クライアントIPを入れるヘッダーが誤設定された例 x-backend: origin-prod-01 ← サーバ名が漏れる via: 1.1 origin.example.com ← CDNのviaヘッダーにオリジン名が入ることも # CloudflareのCF-Connecting-IPをバックエンドがそのまま返してしまうケースも

また、/wp-cron.phpや/xmlrpc.phpなど、WordPressの特定のエンドポイントが返すエラーページにサーバ情報が含まれることもあります。

手法⑥ Shodanなどの検索エンジンで探す

Shodan（https://www.shodan.io）は「IoTやサーバを対象にしたインターネット全体の検索エンジン」です。通常の検索エンジン（GoogleやBing）はWebページの内容を検索しますが、ShodanはIPアドレスごとにポートやバナー情報、HTTPヘッダー、SSL証明書などを収集しています。

# Shodanで特定のWebサイトに関連するサーバを探す例 # SSL証明書のCNでドメインを検索（有料機能） ssl.cert.subject.cn:”example.com” # HTTPのタイトルで検索 http.title:”Example Corp – Dashboard” # HTTPヘッダーのServerフィールドで検索 http.headers.server:”nginx” http.title:”Example” # Cloudflareを除外して検索（Cloudflare ASN: AS13335） ssl.cert.subject.cn:”example.com” -asn:AS13335 # 結果として返ってくるIPがオリジンサーバの候補

Censys（https://search.censys.io）も同様の機能を持ち、特にSSL証明書の検索に優れています。攻撃者はShodanとCensysを組み合わせて、CDNを使っているサイトのオリジンIPを効率的に割り出します。

📊 FACT：Shodanのスキャン規模
Shodanは毎日数百万のIPアドレスをスキャンしており、インターネット上に公開されているあらゆるポート・バナー・証明書の情報を収集しています。あなたのオリジンサーバが直接インターネットに面している場合、Shodanにはすでにデータが存在する可能性が高いです。

手法⑦ Faviconハッシュから探す

これは比較的新しい、巧妙な手法です。Webサイトのfavicon（ブラウザのタブに表示される小さなアイコン）をハッシュ化し、そのハッシュ値でShodanやCensysを検索することで、同じfaviconを使っている別のIPアドレス（＝オリジンサーバ）を見つけることができます。

# PythonでFaviconのMMH3ハッシュを計算する import mmh3 import requests import base64 # Faviconを取得 response = requests.get(‘https://www.example.com/favicon.ico’) favicon_data = response.content # Shodanと同じ方式でハッシュ化 favicon_b64 = base64.encodebytes(favicon_data) favicon_hash = mmh3.hash(favicon_b64) print(f”Favicon Hash: {favicon_hash}”) # 例: -1234567890 # Shodanでそのハッシュのサーバを検索 # http.favicon.hash:-1234567890 # ヒットしたIPがCDN以外なら、オリジンサーバの可能性がある

この手法が有効な理由は、多くのWebサイトがCDN経由のURLと、オリジンサーバの直接URLの両方で同じfaviconを返すからです。Shodanはインターネット全体をスキャンしているため、同じfaviconを持つIPを横断的に検索できます。

🔍 このハッシュ手法はバグバウンティ（脆弱性報奨金制度）でもよく使われる
HackerOneやBugcrowdなどのバグバウンティプラットフォームでは、この手法でオリジンIPを特定し、重大な脆弱性として報告されたケースが多数あります。「favicon hash search」で検索すると、実際のバグバウンティ報告書（writeup）が多数見つかります。

5. 実際の攻撃シナリオ―発見からDDoSまで

攻撃者がオリジンIPを発見してから実際に攻撃するまでの流れを、ステップごとに見てみましょう。

1ターゲットの選定とCDN確認

# まずCDNを使っているか確認 dig +short www.target-example.com # → 104.21.0.1 (CloudflareのIP) # → nslookupなどでCloudflare ASNに属するIPかを確認 # Cloudflareを使っているかどうかはHTTPヘッダーでも判断できる curl -sI https://www.target-example.com | grep -i “cf-ray\|server: cloudflare” # CF-Ray: 1234567890abcdef-NRT というヘッダーがあればCloudflare確定

2DNS履歴の調査

# SecurityTrailsのWeb UIまたはAPIで過去のAレコードを取得 # 例：2年前のDNSレコードに 203.0.113.50 が残っていることを発見

3サブドメイン列挙でオリジンIPを確認

subfinder -d target-example.com -silent | dnsx -resp-only # → origin.target-example.com → 203.0.113.50 (CDNのIPではない！) # → mail.target-example.com → 203.0.113.50 (同じIP) # → www.target-example.com → 104.21.0.1 (Cloudflare)

4オリジンIPへの直接アクセステスト

# HostヘッダーをwwwのドメインにしてオリジンIPに直接アクセス curl -sI http://203.0.113.50 -H “Host: www.target-example.com” # → HTTP/1.1 200 OK が返ってきた！CDNを完全にバイパスできた

5脆弱性スキャンとDDoS攻撃

# ポートスキャン nmap -sV -p 22,80,443,3306,8080 203.0.113.50 # → 22/tcp open ssh OpenSSH 7.4 # → 80/tcp open http Apache httpd 2.4.6 # → 3306/tcp open mysql (DBが外部公開されている！) # この段階でDDoS攻撃・ブルートフォース・SQLインジェクションが可能になる

6攻撃の実行（CDNをバイパスしてWAFを回避）

攻撃者はここで、CDNのWAFに検知されることなくSQLインジェクションやXSSを試みます。また、大量のボットネットをオリジンIPに向けてDDoSを開始します。CDNがないため、格安レンタルサーバやVPSはすぐにダウンします。

6. 完全防御のための10の対策

🛡️ 防御の基本原則
オリジンサーバのIPは「一度も漏らさない」か「漏れたら即座にIPを変える」の二択です。以下の対策を重ねることで、多層防御（Defense in Depth）を実現できます。

対策① CDNの「プロキシ設定」を必ず有効にする

Cloudflareの場合、ドメインの横にあるオレンジ色の雲マーク（🟠）がプロキシ有効を意味します。灰色の雲（⚫）はDNSオンリーで、オリジンIPがそのまま公開されます。必ずオレンジ色にしてください。

# Cloudflare APIでプロキシステータスを確認・変更 # プロキシが有効かどうか確認 curl -X GET “https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records” \ -H “Authorization: Bearer {api_token}” # レスポンスの “proxied”: false になっているレコードが危険！ # “proxied”: true にすること

特に注意が必要なレコードタイプ：

  • Aレコード（IPv4）：プロキシを有効に
  • AAAAレコード（IPv6）：IPv6でオリジンIPが漏れることも多い。要注意
  • MXレコード：メールサーバ用。プロキシは使えないが、別IPを使うべき
  • サブドメイン：すべてを確認し、不要なものは削除

対策② オリジンファイアウォールでCDNのIPのみ許可する

これが最も重要かつ効果的な対策です。オリジンサーバのファイアウォール（iptables、ufw、セキュリティグループ）で、CDNのIPアドレスレンジからのトラフィックのみ許可し、それ以外はすべてブロックします。

# Cloudflareの公式IPリストを取得 curl -s https://www.cloudflare.com/ips-v4 > cloudflare_ips_v4.txt curl -s https://www.cloudflare.com/ips-v6 > cloudflare_ips_v6.txt # UFW（Ubuntu Firewall）での設定例 # まずHTTP/HTTPSへのアクセスをすべてブロック sudo ufw deny 80 sudo ufw deny 443 # CloudflareのIPレンジのみ許可（自動化スクリプト） while read -r cidr; do sudo ufw allow from “$cidr” to any port 80 sudo ufw allow from “$cidr” to any port 443 done < cloudflare_ips_v4.txt while read -r cidr; do sudo ufw allow from “$cidr” to any port 80 sudo ufw allow from “$cidr” to any port 443 done < cloudflare_ips_v6.txt # 設定を適用 sudo ufw reload sudo ufw status verbose # Nginx での設定例（/etc/nginx/conf.d/cloudflare.conf） # real_ip_header CF-Connecting-IP; # set_real_ip_from 103.21.244.0/22; # … （CloudflareのIPリストを全部記載）

AWSを使っている場合：セキュリティグループのインバウンドルールで、HTTP/HTTPSをCloudflareのIPレンジのみに制限します。AWS Managed Prefixリストでは「com.amazonaws.global.cloudfront.origin-facing」が利用できます。

対策③ Cloudflare Tunnelを使う（最強の隠蔽方法）

Cloudflare Tunnel（旧Argo Tunnel）は、オリジンサーバ側からCloudflareへの接続を確立するトンネル型の仕組みです。オリジンサーバはインバウンドポートを一切開かなくてよいため、オリジンIPが完全に隠蔽されます。

# Cloudflare Tunnelのセットアップ（無料で使える） # 1. cloudflaredをインストール curl -L –output cloudflared.deb \ https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb sudo dpkg -i cloudflared.deb # 2. Cloudflareにログイン cloudflared tunnel login # 3. トンネルを作成 cloudflared tunnel create my-tunnel # 4. 設定ファイルを作成（~/.cloudflared/config.yml） # tunnel: your-tunnel-id # credentials-file: /home/user/.cloudflared/your-tunnel-id.json # ingress: # – hostname: www.example.com # service: http://localhost:80 # – service: http_status:404 # 5. DNSレコードをトンネルに向ける cloudflared tunnel route dns my-tunnel www.example.com # 6. トンネルを起動 cloudflared tunnel run my-tunnel

Cloudflare Tunnelを使うとオリジンのポート80/443を閉じることができ、ファイアウォールルールも不要になります。無料プランでも利用可能です。

対策④ IPv6を無効化または管理する

IPv6アドレスは見落とされがちです。オリジンサーバにIPv6アドレスが割り当てられており、それがDNSのAAAAレコードに登録されていると、CloudflareがIPv4をプロキシしていてもIPv6から直接アクセスできてしまうことがあります。

# IPv6のDNSレコードを確認 dig AAAA example.com dig AAAA www.example.com # もしAAAAレコードがオリジンのIPv6を返しているなら即削除 # Cloudflareでは「IPv6互換性」設定でIPv6をCloudflare側で管理できる # サーバ側でIPv6を無効化（Ubuntu/Debian） echo “net.ipv6.conf.all.disable_ipv6 = 1” | sudo tee -a /etc/sysctl.conf echo “net.ipv6.conf.default.disable_ipv6 = 1” | sudo tee -a /etc/sysctl.conf sudo sysctl -p

対策⑤ メールの送信経路を分離する

オリジンサーバからメールを送るのをやめ、外部のメール送信サービス（SendGrid、Amazon SES、Mailgun、Postmarkなど）を使います。これにより、メールヘッダーにオリジンIPが記録されなくなります。

# WordPressの場合：WP Mail SMTPプラグインを使う # 設定例（SendGridを使う場合） # wp-config.phpに追記（直接設定する場合） define(‘WPMS_ON’, true); define(‘WPMS_MAILER’, ‘sendgrid’); define(‘WPMS_SENDGRID_API_KEY’, ‘SG.xxxxxxxxxxxxxxxxxxxx’); # これにより、すべてのメールがSendGridのサーバから送信される # メールヘッダーに記録されるIPはSendGridのIPになり、オリジンIPは漏れない

対策⑥ HTTPヘッダーの情報漏洩を防ぐ

Webサーバのレスポンスヘッダーからサーバソフトウェア・バージョン情報を削除します。

# Nginx の場合（/etc/nginx/nginx.conf） http { server_tokens off; # nginx/x.x.x のバージョン情報を隠す # … } # Apacheの場合（/etc/apache2/conf-available/security.conf） ServerTokens Prod # “Apache”のみ表示（バージョン非表示） ServerSignature Off # エラーページにバージョン情報を表示しない # PHP のバージョン情報を隠す（php.ini） expose_php = Off # WordPressのwp-config.phpに追記 @header_remove(‘X-Powered-By’); # カスタムヘッダーの追加（誤った情報でミスリード） # ※ これは高度な対策。空のヘッダーを返すだけでも効果がある

対策⑦ 新しいIPアドレスでオリジンを再構築する

過去のDNS履歴にIPアドレスが残ってしまっている場合、そのIPを使い続ける限り危険です。根本的な解決策はオリジンサーバのIPアドレスを変更することです。

  • VPSを使っている場合：サービスによっては追加料金でIPを変更できる
  • AWS EC2の場合：Elastic IPを新しいものに付け替える
  • 新しいVPSインスタンスを立てて移行する：最も確実

新しいIPに移行したら、最初からCDNのプロキシを有効にした状態でのみ公開し、オリジンIPが新たに漏れないよう徹底します。

対策⑧ WordPressのXML-RPC・REST APIを制限する

# .htaccessでXML-RPCへの直接アクセスをブロック（Apache） <Files xmlrpc.php> Order Deny,Allow Deny from all </Files> # wp-login.phpへのブルートフォースをブロック <Files wp-login.php> Order Deny,Allow Deny from all Allow from 203.0.113.1 # 自分のIPのみ許可 </Files> # Nginx の場合 location = /xmlrpc.php { deny all; return 404; } location = /wp-login.php { allow 203.0.113.1; # 自分のIPのみ deny all; }

対策⑨ Faviconを動的または個別に生成する

Faviconハッシュによる追跡を防ぐには、サイトごとにユニークなfaviconを使います。ただし、これは相対的な対策です。より重要なのは対策①②③です。

対策⑩ 定期的な自己チェック（Exposure Management）

# 自分のサイトのオリジンIPが漏れていないかチェックするコマンド集 # 1. crt.shでサブドメインを確認 curl -s “https://crt.sh/?q=%25.your-domain.com&output=json” | \ python3 -c “import sys,json; [print(r[‘name_value’]) for r in json.load(sys.stdin)]” | sort -u # 2. すべてのサブドメインのIPを確認し、CloudflareのIPか確認 # CloudflareのIPレンジ（2024年時点の主要なもの）： # 103.21.244.0/22, 103.22.200.0/22, 103.31.4.0/22 # 104.16.0.0/13, 104.24.0.0/14, 108.162.192.0/18 # 131.0.72.0/22, 141.101.64.0/18, 162.158.0.0/15 # 172.64.0.0/13, 173.245.48.0/20, 188.114.96.0/20 # 190.93.240.0/20, 197.234.240.0/22, 198.41.128.0/17 # 3. SecurityTrailsでDNS履歴を確認（定期的に） # 4. Shodanで自分のIPを検索してどんな情報が公開されているか確認 shodan host your-origin-ip

7. 主要CDNサービスでの設定ポイント

Cloudflare（最もよく使われるCDN）

設定項目 推奨値 理由
プロキシステータス 🟠 オレンジ色（プロキシ有効） 全DNSレコードで有効にする
SSL/TLS暗号化モード 完全（Strict） オリジン〜CDN間も暗号化。「フレキシブル」は危険
ボット管理 有効（有料プラン） ボットからのスキャンを自動検知
Cloudflare Tunnel 可能なら採用 オリジンのポート開放が不要になる
認証済みオリジンプル 有効 CloudflareからのリクエストのみオリジンがSSL接続を受け入れる
IPアクセスルール 悪意あるIPをブロック 既知の攻撃元IPを事前にブロック

AWS CloudFront

# CloudFrontを使う場合のオリジンアクセス制御 # 1. Origin Access Control (OAC) を使う（S3の場合） # 2. Custom Origin（EC2/ALB）の場合はCustom Headerで認証 # ALBにカスタムヘッダーを設定（CloudFrontからのリクエストのみ許可） # CloudFrontディストリビューションにカスタムヘッダーを追加 X-Custom-Header: your-secret-value-here # ALBのリスナールールでこのヘッダーがない場合は403を返す設定 # AWS WAFでCloudFrontのマネージドIPセット以外をブロック # AWS WAFでCloudFrontのIPセットを使ったルールを追加 # マネージドルール “Amazon IP Reputation List” を有効化

さくらのVPS・ConoHa・Xserver など国内レンタルサーバ

国内サーバでよくある落とし穴
  • コントロールパネル（cPanel/Plesk）のポート（2083、8443など）がそのまま公開されている
  • FTPサーバ（ポート21）が公開されていてオリジンIPを特定される
  • phpMyAdminのURLがデフォルトパスのまま（/phpmyadmin）
  • メールサーバとWebサーバが同じIPに共存している
対策：コントロールパネルへのアクセスを自分のIPのみに制限し、FTPを無効化してSFTPに切り替え、phpMyAdminのURLをランダムな文字列に変更する。

8. まとめ―セキュリティチェックリスト

CDNを使っているからといって安心してはいけません。CDNはあくまで「防波堤」であり、オリジンサーバのIPが漏れれば防波堤を迂回されてしまいます。以下のチェックリストで自分のサーバの状態を確認しましょう。

🔴 今すぐ確認すべき重要チェックリスト
チェック項目 確認方法 重要度
すべてのDNSレコードでCDNプロキシが有効か DNSコントロールパネルで確認 最高
ファイアウォールでCDNのIPのみ許可しているか ufw/iptables/セキュリティグループを確認 最高
IPv6アドレスがDNSに直接登録されていないか dig AAAA example.com で確認 最高
過去のDNS履歴にオリジンIPが残っていないか SecurityTrails / ViewDNSで確認 高
crt.shでサブドメインを調べてオリジンIPが露出していないか crt.shで検索→DIGで名前解決 高
メール送信がオリジンサーバから行われていないか テストメール送信→ヘッダーを確認 高
HTTPレスポンスヘッダーにサーバ情報が漏れていないか curl -sI https://your-site.com 高
wp-login.phpへのアクセスが制限されているか .htaccess / Nginx設定を確認 中
Shodanで自分のオリジンIPを検索した結果を確認しているか shodan.ioで検索 中
CloudflareTunnel導入またはIP変更を検討しているか 履歴が汚染されている場合 推奨
🎯 最後に：攻撃者の視点を持つことがセキュリティの第一歩

セキュリティの世界では「自分のサーバを攻撃者と同じ目線で見る」ことが重要です。「攻撃者ならどうやってオリジンIPを探すか？」を知ることで、自分の弱点が見えてきます。

本記事で紹介した手法はすべて、セキュリティ研究者がペネトレーションテストや脆弱性調査で合法的に使うツールと同じです。自分のサーバに対して定期的に「擬似攻撃（セルフペネトレーションテスト）」を実施し、問題を先回りして対処することが、本当の意味でのセキュリティ強化につながります。

参考リソース

⚠️ 免責事項：本記事の情報は教育・防御目的のためのものです。第三者のシステムへの無断スキャンや攻撃は、不正アクセス禁止法（日本）、Computer Fraud and Abuse Act（米国）など各国の法律で厳しく罰せられます。本記事の情報を悪用した場合の責任は一切負いかねます。

コメント