アドレス・ポイズニングとは？ 10分でわかりやすく解説

UnsplashのDenise Chanが撮影した写真      

アドレス・ポイズニングは、宛先の解決や対応付けに使う情報を偽り、通信先を攻撃者が用意した別の場所へ向ける攻撃の総称として使われる表現です。実際の手口は、DNSキャッシュポイズニング、ARPポイズニング、DHCPスプーフィングなどに分かれます。被害は偽サイトへの誘導、通信の盗聴や改ざん、業務停止まで広がるため、DNS管理、LAN保護、証明書確認、利用者教育を分けて考える必要があります。

アドレス・ポイズニングとは

ネットワークでは、名前から宛先を引く対応表や、IPアドレスとMACアドレスの対応表が通信の前提になります。アドレス・ポイズニングは、その対応情報を偽装して、本来とは異なる相手へ通信を流す攻撃を指します。

ただし、この言葉は単一の正式規格名ではありません。実務では、DNSのキャッシュ汚染、ARPキャッシュの汚染、偽のDHCP応答、IPv6の近隣探索の悪用など、別々の攻撃をまとめて説明する場面で使われます。記事を読むときは「何の対応表を偽るのか」を先に確認したほうが混乱しにくくなります。

何が書き換わるのか

代表的な手法

DNSキャッシュポイズニング

DNSキャッシュポイズニングは、リゾルバのキャッシュへ偽の応答を混ぜ、正しいドメイン名を不正なIPアドレスへ対応付ける攻撃です。古い実装や設定不備があると、攻撃者は問い合わせ中のタイミングを狙って偽の応答を先に送り込み、キャッシュを汚染しようとします。

防御では、ソフトウェア更新だけでは足りません。再帰問い合わせの公開範囲を絞る、問い合わせ元ポートやトランザクションIDの推測を難しくする、ログを監視する、DNSSECで署名検証を行う、といった複数の対策を重ねます。

ARPポイズニング

ARPポイズニングは、ローカルネットワークで偽のARP応答を送り、特定のIPアドレスに対するMACアドレスの対応を攻撃者の端末へ向ける手口です。同じセグメントに入り込めることが前提なので、社内LAN、共有Wi-Fi、検証環境などで成立しやすくなります。

成立すると通信が攻撃者を経由しやすくなり、中間者攻撃の足場になります。単に盗み見るだけでなく、平文通信の改ざんや認証情報の窃取に発展する場合があります。

DHCPスプーフィング

DHCPスプーフィングは、正規のDHCPサーバーより先に偽の応答を返し、クライアントへ不正なネットワーク設定を配る手口です。偽のDNSサーバーやデフォルトゲートウェイを渡されると、以後の通信全体が攻撃者の意図した経路へ流れやすくなります。

DNSリバインディング

DNSリバインディングは、DNSサーバーのキャッシュを汚す攻撃ではありません。攻撃者が管理するドメインに短いTTLを設定し、最初は外部サーバーのIPアドレス、次に社内向けやローカル向けのIPアドレスを返すことで、ブラウザに別の宛先へアクセスさせる手口です。

この手口は、管理画面やAPIを「社内IPからしか見えないから安全」と考えている環境で問題になりやすくなります。認証、HostヘッダーやOriginの検証、内部向け管理画面の公開範囲制限を併用しないと、防ぎ切れない場面があります。

被害の出方

アドレス・ポイズニングの被害は、偽サイトへの誘導だけではありません。宛先がすり替わると、その後の通信全体が影響を受けます。

• フィッシング詐欺用の偽サイトへ誘導され、IDや決済情報を入力してしまう
• 通信の盗聴や改ざんにより、ログイン情報や業務データが抜き取られる
• 正規サービスへ到達できず、業務アプリや社内システムが使えなくなる
• 偽サーバー経由でマルウェアを配布され、別のサイバー攻撃の起点にされる

利用者視点では「URLを間違えていないのに画面が違う」「急に証明書警告が出る」といった形で気付くことがあります。ただし、攻撃者が証明書や画面を巧妙に整えている場合、見た目だけで判別するのは難しくなります。

対策の進め方

DNS管理者が確認する項目

• DNSソフトウェアを更新し、既知の脆弱性を放置しない
• 不要な再帰問い合わせを外部へ公開しない
• 問い合わせ元ポートのランダム化や十分な乱数を使う
• 権威DNSとキャッシュDNSの役割を分ける
• DNSSEC検証を有効にし、署名付き応答を確認する
• 不審な問い合わせ量、失敗、キャッシュ汚染の兆候をログで追う

LANやWi-Fiで先に見る項目

• スイッチのDynamic ARP InspectionやDHCP snoopingの利用可否を確認する
• 重要機器を同一セグメントへ置き過ぎない
• 来訪者用ネットワークと業務ネットワークを分離する
• 共有Wi-Fiや検証環境で平文プロトコルを使わない
• IPv6を使っているなら、NDPやRAを保護できる機能の有無も確認する

Web運用側で見直す項目

HTTPSは通信の盗聴や改ざんを抑えるうえで役立ちますが、DNSレベルの誘導そのものを止める仕組みではありません。証明書警告を無視しない運用、HSTSの採用、管理画面やAPIへの認証、内部IPだけに依存しないアクセス制御を組み合わせる必要があります。

DNSリバインディングが気になる環境では、内部向け管理画面をブラウザで直接触らせない設計、HostやOriginの検証、内部アドレス帯への到達制限などを併用したほうが安全です。

利用者側で取れる対策

• URLの綴りと証明書警告を確認する
• ブラウザ、OS、ルーターのファームウェアを更新する
• 公共Wi-Fiでは機密情報の入力を避け、必要ならVPNを使う
• 見慣れたサイトでも、急に表示やログイン導線が変わったら入力を止める

まとめ

アドレス・ポイズニングは、名前解決やアドレス解決の対応情報を偽り、通信先をすり替える攻撃群です。DNSキャッシュポイズニング、ARPポイズニング、DHCPスプーフィングは狙う対象が違うため、対策箇所も同じではありません。

まず切り分けるべきなのは、どの対応表が狙われるのか、攻撃者が同一セグメントに入る必要があるのか、利用者を偽サイトへ誘導するのか、社内向け管理画面へ横から入ろうとしているのか、の4点です。この整理ができると、DNSSEC、LAN保護、HTTPS運用、利用者教育のどこを優先するかが見えやすくなります。

よくある質問（FAQ）