DNSリバインディング攻撃とは？ブラウザを踏み台にする手口と企業ネットワークを守る対策ガイド

「社内のルーターや監視カメラの管理画面に、なぜか外部から操作された形跡がある」「ブラウザで普通のサイトを見ただけなのに、内部ネットワークの情報が外に漏れていた」

そんなインシデントの裏側にある攻撃手法が、DNSリバインディング攻撃です。この攻撃は、ファイアウォールや境界型セキュリティが整っていても、ブラウザを踏み台にして内部ネットワークに侵入できてしまう、非常に巧妙な仕組みになっています。

この記事では、DNSリバインディング攻撃の仕組みを攻撃者の視点で解説し、ルーター設定・内部サービス実装・ネットワーク設計の観点から今すぐできる防御策を具体的に紹介します。

DNSリバインディング攻撃とは？

DNSリバインディング攻撃（DNS Rebinding Attack）とは、DNSの名前解決タイミングを意図的に操作することで、ブラウザのセキュリティ機構である同一オリジンポリシー（SOP: Same-Origin Policy）を迂回する攻撃手法です。

まず、同一オリジンポリシーについて整理しておきます。これはブラウザに組み込まれたルールで、「あるドメインのJavaScriptは、別のドメインのデータを勝手に読み取れない」という制約です。たとえば `evil.example.com` のJavaScriptが `yourdomain.example` のAPIを呼び出してデータを盗む行為を防ぐ、Webセキュリティの根幹を支える仕組みです。

DNSリバインディング攻撃は、この制約を「ドメイン名は同じまま、紐付くIPアドレスだけをすり替える」という方法でこっそり破ります。

なぜ今この攻撃が重要か

近年、社内ネットワークにはWebインターフェース付きのデバイスが急増しています。管理画面を持つブロードバンドルーター、設定WebUIのあるNAS、映像確認ポータルのあるIPカメラ、ネットワーク機器のダッシュボードなどが代表例です。

これらは「内部ネットワークからしかアクセスできない」という前提で設計・運用されているため、認証が甘いままになっているケースが多く見られます。DNSリバインディング攻撃は、まさにその「内部からしかアクセスできない」という前提を崩します。

また、リモートワーク環境の普及により、自宅ルーターや個人用NASが業務端末と同じネットワークに接続されているケースも増えています。こうしたデバイスも攻撃の射程に入っています。

攻撃の仕組み（敵を知る）

DNSリバインディング攻撃がどのように同一オリジンポリシーを突破するか、ステップごとに説明します。

1. 攻撃者が悪意のあるドメインを用意する

攻撃者は `attack.example.com` のようなドメインを取得し、DNSのTTL（Time to Live: キャッシュ有効期間）を極端に短く設定します（30秒程度）。TTLが短いと、ブラウザはDNS解決結果をほとんどキャッシュしないため、頻繁に名前解決をやり直すことになります。

2. 被害者がサイトにアクセスし、JavaScriptが実行される

フィッシングメール、SNSのリンク、広告などを経由して、被害者のブラウザが `attack.example.com` を開きます。このとき、DNSは攻撃者が管理する外部のIPアドレス（例: 1.2.3.4）に解決されます。

攻撃者のサーバーから悪意のあるJavaScriptが配信され、ブラウザで実行が始まります。

3. TTL切れを待って、DNSレスポンスをすり替える

JavaScriptはバックグラウンドでタイマーを動かし、TTL（30秒）が切れる頃合いを見計らいます。攻撃者はそのタイミングでDNSサーバーを操作し、`attack.example.com` が解決するIPアドレスを内部ネットワークのIPアドレス（例: 192.168.1.1）に書き換えます。これが「リバインディング（再紐付け）」の瞬間です。

4. ブラウザが内部デバイスにリクエストを送信する

JavaScriptは `attack.example.com` に対して通常どおりHTTPリクエストを送ります。ブラウザは「同じドメイン名 = 同じオリジン」とみなすため、同一オリジンポリシーの制約なしにレスポンスを読み取れます。しかし実際には、そのドメインは今や `192.168.1.1`（内部ルーターなど）を指しており、リクエストは内部デバイスに届きます。

5. 内部情報を外部に送信する

JavaScriptは内部デバイスから取得した情報（管理者パスワード、設定内容、ネットワーク構成など）を、攻撃者のサーバーに送信します。管理画面への書き込みAPIにアクセスできれば、設定変更やファームウェア改ざん、マルウェアのインストールまで可能です。

攻撃の流れまとめ

具体的な防御手順

1. DNSサーバーにリバインディング保護を設定する

内部DNSサーバーやルーター内蔵DNSに「外部ドメインがプライベートIPアドレスに解決されたらレスポンスを破棄する」設定を入れることが、最も根本的な対策です。

Dnsmasqを内部DNSとして使用している場合:

# /etc/dnsmasq.conf に追加

# プライベートIPアドレス帯（RFC 1918）へのリバインディングを拒否
stop-dns-rebind

# ループバック（127.x.x.x）へのリバインディングも拒否
rebind-localhost-ok=false

# 自社内部ドメインは保護から除外（正当な内部解決を許可する場合）
# rebind-domain-ok=/internal.yourdomain.example/

`stop-dns-rebind` が有効になると、外部ドメイン名が 10.x.x.x、172.16.x.x～172.31.x.x、192.168.x.x に解決されるレスポンスを自動的に破棄します。

家庭用・中小企業向けルーター（バッファロー・ヤマハ・NEC Atermなど）でも「DNSリバインディング保護」または「プライベートIPアドレスへの名前解決を拒否」という名称で同等の機能が提供されているものがあります。管理画面のDNS設定を確認し、有効にしてください。

Linuxサーバー側でのDNS設定については、姉妹サイトLinuxMaster.JPでも関連するサーバー設定の基礎を解説しています。

2. 内部Webサービスに「Hostヘッダー検証」を実装する

内部ネットワークで動くWebサービス（ルーター管理画面・IoT機器のAPIなど）が、受信したHTTPリクエストの `Host` ヘッダーを厳格に検証することで、リバインディング攻撃を遮断できます。攻撃者のドメイン（`attack.example.com`）でアクセスが来ても、想定外のHostヘッダーには応答しない設計です。

Nginxで内部Webサービスを動かしている場合:

# /etc/nginx/sites-available/internal-app.conf

server {
    listen 80;

    # 許可するHostヘッダーを内部IPまたは内部ドメインに限定
    server_name 192.168.1.100 internal.yourdomain.example;

    # 上記以外のHostヘッダーは接続を即時切断（444 = no response）
    if ($host !~* ^(192\.168\.1\.100|internal\.yourdomain\.example)$) {
        return 444;
    }

    # 以下は通常のロケーション設定
    location / {
        proxy_pass http://127.0.0.1:8080;
    }
}

`return 444` はNginx独自の「接続を無応答で切断する」ステータスコードです。攻撃者のドメイン名でアクセスしてきた場合、レスポンス自体を返さないため、JavaScriptはエラーのみを受け取り内部情報を取得できません。

3. フォワードプロキシで内部IPへのブラウザアクセスをブロックする

企業環境では、フォワードプロキシを経由してすべてのHTTP/HTTPSトラフィックを管理する構成が有効です。プロキシサーバー側でプライベートIPアドレス帯向けのリクエストをブロックすることで、ブラウザからの内部デバイスへの直接アクセスを防げます。

Squidプロキシを使用している場合:

# /etc/squid/squid.conf に追加

# プライベートIPアドレス帯を定義
acl rfc1918 dst 10.0.0.0/8
acl rfc1918 dst 172.16.0.0/12
acl rfc1918 dst 192.168.0.0/16
acl rfc1918 dst 127.0.0.0/8

# ブラウザ経由でのプライベートIP直接アクセスを拒否
http_access deny rfc1918

# 通常の許可ルールはその後に続ける
http_access allow localnet
http_access deny all

フォワードプロキシの設計全般については、フォワードプロキシとネットワーク出口制御の解説記事も参照してください。

中小企業でも今日からできること

高度な設定変更が難しい環境でも、以下の対策は比較的すぐに着手できます。

・ルーターのDNSリバインディング保護をON: ルーター管理画面のDNS設定を確認し、「DNSリバインディング保護」「プライベートIPへの名前解決を拒否」などの項目を有効にする。ほとんどの市販ルーターに搭載されている機能です
・内部デバイスのデフォルトパスワードを必ず変更する: DNSリバインディングで管理画面に到達されても、強いパスワードとアカウントロック機能があれば操作は困難になる。これは最低限の前提条件です
・管理画面のポートを特定サブネット限定にする: ルーターや機器の管理画面（80/443/8080番ポートなど）は、特定の管理用PCのIPアドレスからのみアクセスできるよう制限する
・IoT機器・ルーターのファームウェアを最新に保つ: DNSリバインディングで到達された先の機器に既知の脆弱性があると、より深刻な侵害に発展する可能性がある。定期的なファームウェア更新が被害の抑制につながります
・DNSフィルタリングサービスの導入を検討する: クラウド型DNSフィルタリングサービスの中には、外部ドメインがプライベートIPを返すケースを自動で検知・遮断するものもある。DNSフィルタリングの全体像についてはDNSフィルタリングの実践ガイドも参照してください

よくある誤解と注意点

【誤解1】「外向きのファイアウォールがあれば安全」

境界型ファイアウォールは、外部から内部への直接アクセスを防ぐものです。しかしDNSリバインディング攻撃では、被害者のブラウザ（内部ホスト）が自発的に内部デバイスにリクエストを送ります。通信を開始しているのが「内側」であるため、外向きファイアウォールのルールに引っかかりません。

【誤解2】「HTTPSなら大丈夫」

内部の管理画面やIoT機器の多くはHTTPSに対応していません。対応していたとしても、攻撃者のドメインと内部デバイスのIPでは証明書が一致しないため、ブラウザは警告を出します。ただし、その警告を無視するユーザーがいると防御として機能しなくなります。また、ブラウザによっては特定条件下でHTTP接続の場合にこの攻撃がより成立しやすくなる側面もあります。

【誤解3】「自分のPCは会社のPCじゃないから関係ない」

リモートワーク中の自宅PCも対象です。自宅のルーター管理画面、NAS、スマートホームデバイスは全て同一ネットワークにあります。業務用端末からウェブを閲覧中に悪意のあるページを開いてしまえば、自宅ネットワーク内のデバイスが攻撃の踏み台になりえます。

【注意点】開発環境のlocalhostも標的になる

エンジニアがローカル環境（127.0.0.1）で動かしている開発中のWebアプリケーション、データベース管理ツール、内部APIなども、DNSリバインディングの標的になります。開発環境に認証を設けていない場合、悪意のあるサイトを閲覧するだけで開発中のデータやAPIが外部から操作されるリスクがあります。開発環境であっても、localhostサービスには最低限の認証を設けることをお勧めします。

なお、DNSを悪用した別の攻撃手法として、マルウェアのC2通信にDNSを使う「DNSトンネリング」があります。こちらも合わせて把握しておくと、DNS全体の脅威像が見えてきます。詳しくはDNSトンネリングの仕組みと検知・遮断ガイドを参照してください。

本記事のまとめ

DNSリバインディング攻撃は「外部からのアクセスを防いでいる」という一般的な前提を崩す点が厄介です。内部ブラウザを踏み台にするため、ネットワーク境界で見ると完全に正常な通信に見えてしまいます。

対策の本質は「DNSリバインディング保護（ルーター・DNSサーバーで設定）」と「内部サービスのHostヘッダー検証（サービス側の実装）」の2点です。どちらも大きなコストをかけずに実施できる対策ですので、まずルーターの設定確認から着手してみてください。