ARPスプーフィングによる中間者攻撃の仕組みと多層の対策

ARPスプーフィング(ARPポイズニング)は、同じLANにつながった機器の対応表を書き換えて、他人あての通信を自分の手元へ引き込む手口です。特定の製品の欠陥を突くというより、1982年のRFC 826が定めた受信処理に送信元を確かめる段階が無いことを利用します。想定読者は、社内ネットワークの設計と運用、監視にあたる実務担当者です。記述はRFC、MITRE ATT&CK、スイッチベンダとOSの公式ドキュメントにもとづき、事実は執筆時点(2026年8月2日)に確認できた範囲に限ります。攻撃ツールの実行手順やコマンドは書きません。動作確認は、自組織が管理する、または管理者から明示の許可を得た検証環境だけで行ってください。許可のないネットワークで試す行為には複数の法令が関わりますが、成立の要件はそれぞれ異なります。不正アクセス行為の禁止等に関する法律が対象とするのは、他人の識別符号を使う行為や、アクセス制御機能の不備を使って本来制限されている利用を可能にする行為であり、ARPの偽装や通信の取得だけで直ちに当たるとは限りません。取得した認証情報を使って他人のアカウントへ入る段階になると、同法が想定する行為に近づきます。他人の通信内容を取得する行為については、電気通信事業法第4条が定める通信の秘密の保護が関わりますが、対象となる通信や行為主体を含めた個別の判断が要ります。実際にどの法令がどう適用されるかは事案ごとに変わるため、判断が必要な場面では法律の専門家へ確認してください。

ARPが宛先MACアドレスを決める手順#

同じセグメントの相手にIPパケットを届けるには、宛先のIPアドレスに対応する48ビットのイーサネットアドレスが要ります。RFC 826は、この変換をアドレス解決モジュールが保持する変換表で引き、見つからなければ問い合わせをブロードキャストする仕組みとして定めました。問い合わせパケットには、送信者のハードウェアアドレスと送信者のプロトコルアドレス、そして知りたい相手のプロトコルアドレスが入ります。該当する機器が応答を返し、送信側は得られた対応を表に記録します。

受信側の処理には、後の話につながる特徴があります。RFC 826の擬似コードは、送信者のプロトコルアドレスが既に変換表にあれば、そのエントリのハードウェアアドレスを新しい情報で更新すると書いています。自分が問い合わせの宛先だった場合には、まだエントリが無ければ組を追加します。opcodeを見るのは、この更新のあとです。RFC 826は、通信は双方向だろうという仮定からこの順序にしたと説明し、既にエントリがある場合は新しいハードウェアアドレスが古いものに取って代わると明記しています。

RFC 826は受信処理の擬似コードで、送信者の組が変換表にあれば更新してMerge_flagを立て、そのうえで「(NOW look at the opcode!!)」とopcodeの判定へ進むと記述しています。送信者が名乗ったアドレスの正当性を確かめる段階は、この手順に含まれていません。

認証を持たない設計がキャッシュ汚染を許す理由#

ARPには、名乗った送信者が本当にそのIPアドレスの持ち主かを確かめる手段がありません。MITRE ATT&CKのT1557.002も、ARPはステートレスで認証を必要としないため、機器がARPキャッシュのIPアドレスに対応するMACアドレスを誤って追加または更新してしまうと説明しています。

攻撃の入り方は2通りあります。1つは、誰かが出したARP要求を待ち受け、本来の持ち主より速く自分のMACアドレスで応答する形です。T1557.002は、キャッシュを汚染するには正規の持ち主の応答より速い必要があると書いています。もう1つは、要求を待たずに宣言や応答のパケットを送り、特定のIPアドレスの所有をセグメント全体へ伝える形です。RFC 5227は、送信者のプロトコルアドレスをすべて0にしたARP要求をARP Probeと呼び、使おうとしているアドレスが他で使われていないかを確かめる用途に充てています。ARP Announcementはこれとは別で、送信者と対象の両方に同じIPアドレスを入れたARP要求として、「これが今使っているアドレスです」という主張を伝えます。目的は、アドレスの使用開始を周知すること、以前そのアドレスを使っていたホストに残る古いARPキャッシュを更新させること、競合が起きたときに自分の使用を主張することです。一般にgratuitous ARP(GARP)と呼ばれる範囲には、この要求形式のほかに、要求されていないのに送られるARP応答も含まれます。T1557.002が挙げるのは後者のgratuitous ARP replyで、RFC 5227が定める要求形式のAnnouncementとはパケットの作りが異なります。

RFC 5227自身も、この仕組みがARPの脆弱性を引き継ぐと認めています。悪意あるホストが偽のARPパケットを送り、他のホストの正しい動作を妨げうると書いたうえで、この文書がその弱点を悪化させるものではないと断っています。裏を返せば、ARPの層に真正性の保証は用意されていないということです。

OS側の設定にも限界があります。Linuxカーネルのip-sysctl文書は、ARPテーブルにまだ存在しない機器からのGARPの扱いをarp_acceptで決めると説明し、既定値の0では新しいエントリを作らないとしています。ただし同じ項目に、GARPのIPアドレスが既にARPテーブルにある場合は、この設定の有無にかかわらずテーブルが更新されると書かれています。GARPをまとめて破棄するdrop_gratuitous_arpも用意されており、1にすればGARP自体を受け取らなくなりますが、既定値は0です。1にした場合は、冗長構成のフェイルオーバーや仮想IPアドレスの移動のようにGARPで対応の変化を伝えている動作を壊すことがあります。要求への応答を装う形の偽装はGARPではないため、この設定では防げません。

Linuxカーネルのip-sysctl文書は、arp_acceptが0のとき「don't create new entries in the ARP table」であり、一方で「If the ARP table already contains the IP address of the gratuitous arp frame, the arp table will be updated regardless if this setting is on or off」と記載しています。既存エントリの上書きは、この設定では止まりません。

攻撃者が同じブロードキャストドメインに居る必要#

ARPはL2で完結するため、ルータをまたいで届きません。CiscoのDynamic ARP Inspection(DAI)のドキュメントは、中間者攻撃が単一のL2ブロードキャストドメインに限られることを前提に、検査するドメインと検査しないドメインを分けるよう求めています。つまり攻撃者は、同じVLANに機器をつなぐか、同じ無線ネットワークに接続するか、そのセグメントにある端末をあらかじめ乗っ取るかのいずれかを済ませておく必要があります。ここで限られるのは、ARPパケットが届く範囲と、直接汚染できるARPキャッシュの範囲です。デフォルトゲートウェイの対応を汚染された場合は、被害端末と別ネットワークやインターネットとのやり取りも攻撃者を経由するため、中継や遮断、観測といった影響はL2の外へ及びます。

この性質は防御側にとって扱いやすい手がかりです。セグメントの広さが、そのまま1回の汚染で届く範囲の上限になります。来客用の回線や検証用の端末、管理者のいないIoT機器を業務セグメントと同居させているほど、足場を置かれたときの影響が広がります。

中間者の位置を取った攻撃者にできること#

CiscoのDAIドキュメントは、ホストCがホストAとホストBのIPアドレスを自分のMACアドレスに結び付けた状態を図で示しています。汚染されたホストは、AあてやBあての通信の宛先MACアドレスとしてホストCのMACアドレスを使います。ホストCは本来の対応を知っているため、受け取った通信を正しい相手へ転送できます。通信が続いたまま経路の途中に第三者が入るので、利用者の側からは変化が見えにくいという性質があります。

親のテクニックであるT1557は、この位置で行われる行為として、情報の収集、送信データの改ざん、リプレイ、正規のサイトからの誘導、アクセストークンやセッションクッキーを含む資格情報の窃取を挙げています。暗号化の水準を落とすダウングレードを狙う場合もあると記載しています。T1557.002の戦術区分はCredential AccessとCollectionで、対応プラットフォームはLinux、Windows、macOSです。実際の悪用例としてはCleaver(G0003)とLuminousMoth(G1014)が記録されており、後者はARPスプーフィングで侵害済みの端末を攻撃者の管理下のWebサイトへ誘導したとされています。

読み取られる度合いは、その通信が暗号化されているかで決まります。平文のままやり取りされるプロトコルは内容がそのまま見えます。T1557.002の緩和策M1041が、有線と無線のどちらの通信も適切に暗号化し、認証にはKerberosのような仕組みを使い、資格情報を含みうるWebトラフィックはTLSで保護するよう求めているのは、この差を埋めるためです。

TLSが守る範囲と、警告を無視させる誘導#

証明書の検証が正しく働いていれば、経路の途中に入っただけでは中身を読めません。攻撃者が用意した証明書は、ブラウザやOSが信頼する認証局の裏書きを持たないため、検証で弾かれます。そこで攻撃側は、利用者に警告を無視させる方向へ持ち込もうとします。T1557.002の緩和策M1017が、証明書エラーを疑うよう利用者を訓練することを挙げているのは、この誘導を想定しているからです。

技術側で警告への到達そのものを減らす仕組みもあります。RFC 6797が定めるHSTSは、既知のHSTSホストあてのhttpスキームのURIを読み込む前にhttpsへ置き換えるようUser Agentに求めます。さらに、そのホストとの安全な通信の確立で何らかのエラーが起きた場合は、警告レベルであっても致命的であっても接続を打ち切ることを求め、第12.1節では利用者に続行を選ばせるダイアログを出すべきではないと述べています。平文のHTTPで始まる遷移を残さないことが、ダウングレードの入口を狭めます。

証明書ピンニングは、あらかじめ決めた証明書や公開鍵とだけ結び付ける手法です。OWASPのPinning Cheat Sheetは、ピンニングをホストと期待されるX509証明書または公開鍵を関連付ける処理と定義し、信頼された認証局から不正な証明書を得る攻撃や、クライアントの信頼ストアへ攻撃者の認証局を差し込む攻撃への対抗策として位置づけています。同時に、ピン留めを検討すべき状況はほとんど無いとも書き、証明書の入れ替えに伴う障害の危険が利点を上回りやすいとして、主にネイティブモバイルアプリのように配布と更新を自分で握れる場面に限る判断を示しています。無条件に勧められる手段ではありません。

異常なARPを見つけるための監視#

MITRE ATT&CKは検知戦略DET0387として、Windows、Linux、macOSそれぞれでの分析を挙げています。3つの分析を通じて挙げられている兆候は、複数のIPアドレスが1つのMACアドレスに解決されている状態、要求していないのに届くARP応答、繰り返されるGARPです。観測の対象はOSごとに違うため、すべての環境で同じ項目を同じように取れるとは限りません。

端末側の兆候としては、OSが出すIPアドレス重複の警告があります。RFC 5227のアドレス競合検出が働いた結果で、汚染の副産物として現れることがあります。ただし攻撃者が競合を避けるように振る舞えば出ないため、これだけを頼りにはできません。IPアドレスとMACアドレスの対応の変化を継続して記録する専用の道具もあります。LBNLのネットワーク研究グループが公開するarpwatchは、イーサネットとIPアドレスの対応関係を追跡するモニタプログラムと説明されています。

スイッチ側のログも材料になります。CiscoのDAIは、破棄したパケットをログバッファへ入れ、レートを制御しながらシステムメッセージを生成します。各エントリには受信VLAN、ポート番号、送信元と宛先のIPアドレスとMACアドレスが含まれるため、どのポートに足場があるかを絞り込めます。

運用で難しいのは、正常な変化も同じ形をとる点です。冗長構成のフェイルオーバー、仮想IPアドレスの移動、NICの交換、無線のローミングは、いずれもIPアドレスとMACアドレスの対応を変えます。平常時の対応表を基準線として持たないと、通知が出ても切り分けられません。

スイッチでARPパケットを検証する仕組み#

CiscoのDAIは、untrustedに設定したインターフェースで受け取ったARP要求と応答を横取りし、IPアドレスとMACアドレスの対応が妥当かを確かめてから、ローカルのARPキャッシュを更新したり転送したりします。妥当性の判定に使う信頼できるデータベースが、DHCP Snoopingが構築するバインディングデータベースです。trustedなインターフェースで受け取ったパケットは検査を素通りします。DHCPを使わない環境や、固定IPアドレスのホストについては、管理者が定義するARP ACLで許可と拒否を決めます。追加の検査として、パケット内のIPアドレスの妥当性や、ARPパケット本体のMACアドレスとイーサネットヘッダのアドレスの一致を確かめるオプションも用意されています。

Ciscoのドキュメントは、DAIがARPパケットを横取りしてログに記録し、IPとMACの対応が不正なものを破棄する機能だと説明しています。既定ではすべてのVLANで無効、すべてのインターフェースがuntrustedで、untrustedインターフェースの受信ARPは毎秒15パケットに制限され、trustedインターフェースは無制限です。制限を超えたポートはerror-disabled状態になり、管理者が介入するかerrdisable recoveryで自動復旧させるまでその状態が続きます。

前提と限界も同じドキュメントに書かれています。DAIは入力方向の機能であり、出力方向の検査はしません。DAIに対応していない、あるいは有効化していないスイッチにつながるホストには効きません。DAIを動かすスイッチにつながるホストのキャッシュを、ネットワークの別の場所にいるホストが汚染することを防げるわけでもありません。優先順位にも注意が要ります。ARP ACLはDHCP Snoopingのバインディングより先に評価され、ACLが拒否すれば有効なバインディングがあっても破棄されます。

信頼状態の設定は、DHCP SnoopingとDAIで別々のものです。DHCP Snoopingのtrustedは、正規のDHCPサーバからの応答を通すために、サーバのあるポートやサーバへ向かうポートに指定します。ここを指定し忘れると正規の応答が破棄され、アドレスを取得できない端末が出ます。DAIのtrustedは、ARPパケットの検査を省くインターフェースの指定です。Ciscoは、DAIに対応していないスイッチや、DAIを有効にしていないスイッチとの接続をtrustedにすると検査を迂回する経路ができるとして、untrustedのままARP ACLを適用するか、L3で分けるよう求めています。上位リンクだから一律にtrustedにする、という決め方はできません。

端末とポート設計での補強#

静的ARPエントリは、設定した機器の上で、設定した対応についてはARPキャッシュ汚染を防げます。防げるのはそこまでで、設定していないエントリや、MACアドレス自体を偽る手口、スイッチのMACアドレステーブルを狙う攻撃には効きません。管理の手間も対象の数だけ増えます。T1557.002の緩和策M1035は、端末やゲートウェイなどの各機器に静的ARPエントリを作る方法を挙げつつ、大規模ネットワークでは現実的でない場合があると書いています。DHCPで動的にアドレスが変わる環境や、持ち出し端末が多い環境とは相性がよくありません。前述のとおり、arp_acceptを既定の0のままにしても、既存エントリの更新は止まりません。

ポートセキュリティは、ポートごとに許可するMACアドレスを限定し、定義した範囲外の送信元アドレスを持つパケットを転送しない機能です。物理ポートに勝手な機器をつなぐ経路を狭められますが、ARPパケットの中身までは見ません。攻撃者が自分のMACアドレスを正しく名乗ったうえでARPペイロードだけを偽る場合には効かないため、DAIの代わりにはなりません。IEEE 802.1x認証との併用については、同じCatalyst 9200のIOS XE 17.16.x向け資料の中でも記述が一致していません。Port Securityのガイドは802.1x authenticatorを設定したインターフェースでの併用を推奨しないと書き、802.1xのガイドはサポートしないと書いています。採用を検討する場合は、使う機種とバージョンのリリースノートや検証環境で実際の挙動を確かめてください。

IEEE 802.1xによるポート単位の認証は、公開された場所のポートから認証されていないクライアントがLANへ入ることを防ぐ仕組みです。会議室や執務スペースの空きポートを足場にする経路を塞げます。導入には、端末側のsupplicantと、AAAやRADIUSによる認証基盤といった前提の構成が要ります。supplicantを持たない機器のためにMABを併用する場合や、guest VLAN、認証サーバの障害時にバイパスする設定を入れる場合は、認証を通っていない端末にも限定的な通信、あるいは通常の通信を許すことになります。認証を通った正規の端末が乗っ取られた場合も、そこから先は同じセグメントの内側の話になります。

結局のところ、L2の対策は「足場を置きにくくする」「置かれても検査で弾く」「弾けなくても範囲を狭める」の3層で考えると整理できます。加えて上位層の暗号化が、読み取られる内容を減らします。

多層で並べる対策の順序#

社外ネットワークと公衆Wi-Fiでの前提#

自社で管理しないネットワークでは、DAIもポート認証も使えません。誰が同じセグメントにいるかを把握する手段もないため、L2の対策ではなく上位層の保護と設計思想で守ることになります。NIST SP 800-207は、ゼロトラストの原則としてネットワークの場所だけでは信頼が生まれないことを挙げ、社外の資産は接続先のローカルネットワークを敵対的なものとみなし、すべての通信が監視され改変されうる前提で振る舞うべきだとしています。

日本語の資料も同じ方向の注意を示しています。IPAのテクニカルウォッチは、暗号化が設定されていない場合や、不特定多数の利用者と同じ暗号化キーを共有する場合には、アクセスポイントとの通信内容が盗聴されるリスクは避けられないとしたうえで、重要な情報のやり取りはSSLに対応したサイトに限ることと、VPNの利用を挙げています。総務省もWi-Fi利用者向けと提供者向けのセキュリティ対策ガイドラインを公開しており、接続先のアクセスポイントの確認と通信のHTTPS化を求めています。

運用に落とすためのチェックリスト#

まとめ#

ARPスプーフィングは、送信者を確かめる段階がRFC 826の受信処理に無いことに由来するため、特定の製品へ修正プログラムを当てて塞ぐ種類の問題ではありません。受信したパケットの情報で既存エントリを更新する実装が残る限り、同じブロードキャストドメインからの汚染は成立しうる状態が続きます。そのうえで打てる手は、足場を置かれる範囲をセグメント分割で狭めること、DHCP SnoopingとDAIでARPパケットの内容を検査して弾くこと、対応関係の変化を記録して気づけるようにすること、そしてTLSとHSTSで読み取られる内容そのものを減らすことに分かれます。どれか1つで完結するものではなく、自組織の機器で使える範囲を確かめながら順に積み上げていく作業になります。検証は許可された環境だけで行い、関連法令の範囲を外れないよう気をつけてください。