🔰ハッカーは「社内LANの案内係」をだます🔯ミカと教授のサイバーセキュリテイ🖥️第17回
【ARPスプーフィング――「社内LANで、なぜ他人の通信が自分のPCを通るのか」】
ミカ「教授、今日はARPスプーフィングですね」
教授「そうだ」
ミカ「前回のDNSキャッシュポイズニングは、インターネットの住所録を書き換える攻撃でした」
教授「今回はもっと近い。同じLANの中の住所案内をだます」
ミカ「社内LANの中？」
教授「そうだ。攻撃者が同じネットワークへ入っていることを前提に考える」
ミカ「では、インターネットの向こうから突然来る攻撃ではない？」
教授「一般的なARPスプーフィングは、同一LAN内など、ARPが届く範囲で問題になる」
ミカ「会社の中に攻撃者がいる？」
教授「不正に接続された端末、侵害されたPC、偽Wi-Fi経由など、いろいろな可能性がある」
ミカ「第17回にして、社内LANまで信用できなくなりました」
教授「セキュリティの勉強とは、信用の範囲を少しずつ狭くする旅でもある」
【まずARPとは何か】
ミカ「ARPって何の略ですか？」
教授「Address Resolution Protocolだ」
ミカ「住所を解決するプロトコル？」
教授「そうだ。同じLANの中で、IPアドレスからMACアドレスを調べるために使われる」
ミカ「IPアドレスとMACアドレスは何が違うのです？」
教授「簡単に言えば、IPアドレスはネットワーク上の住所、MACアドレスはLAN内で機器を識別するための番号だと考えればよい」
ミカ「では私のPCがルーターへ通信するとき？」
教授「まず『このIPアドレスを持っている機器のMACアドレスは何ですか』と尋ねる」
ミカ「相手が『私です』と答える」
教授「その対応関係をPCはしばらく覚えておく」
ミカ「それがARPキャッシュ？」
教授「そのとおりだ」
【正常な通信はこうなる】
教授「会社のLANに三台あるとしよう」
ミカ「私のPC、教授のPC、ルーターですね」
教授「ミカのPCがインターネットへ通信したい」
ミカ「まずルーターへ送る」
教授「ミカのPCは、ルーターのIPアドレスに対応するMACアドレスをARPで確認する」
ミカ「正しいルーターが答える」
教授「その結果をARPキャッシュへ保存する」
ミカ「そして以後は、そのMACアドレスへ通信を送る」
教授「ここまでは正常だ」
【では攻撃者が「私がルーターです」と言ったら？】
ミカ「ARPスプーフィングでは何が起きるのです？」
教授「攻撃者がLAN内で、本当のルーターではないのに『そのIPアドレスは私です』と偽る」
ミカ「そんなことをPCは信じるのですか？」
教授「ARPはもともと、同じLAN内の機器をかなり信用する前提で作られた古い仕組みだ」
ミカ「性善説ですね」
教授「インターネット黎明期のネットワークは、今ほど敵だらけではなかった」
ミカ「時代が変わったのに、住所係は昔のまま」
教授「そういう面がある」
【通信が攻撃者のPCを通る仕組み】
ミカ「偽物を信じるとどうなりますか？」
教授「ミカのPCが本来ルーターへ送るはずの通信を、攻撃者のMACアドレスへ送ってしまう」
ミカ「攻撃者のPCへ？」
教授「そうだ」
ミカ「でも、それではインターネットにつながらなくなります」
教授「そこで攻撃者が、その通信を本物のルーターへ転送する」
ミカ「えっ」
教授「するとミカから見ると、普通にインターネットが使えているように見える」
ミカ「実際には？」
教授「ミカ → 攻撃者 → ルーター」
ミカ「第12回の中間者攻撃になっていますね」
教授「そのとおり。ARPスプーフィングは、LAN内で中間者攻撃を成立させる手段の一つになり得る」
【身近な例――会社の郵便室】
ミカ「例え話をお願いします」
教授「会社の郵便室を考えよう」
ミカ「私は社長宛ての書類を郵便室へ持っていきます」
教授「通常なら受付係が『社長室行きはこちらです』と正しく案内する」
ミカ「はい」
教授「ところが怪しい人物が受付係の前へ立って、『社長室はこちらです。私に渡してください』と言う」
ミカ「私は信じて渡してしまう」
教授「怪しい人物は封筒を見る」
ミカ「そして？」
教授「その後、本物の社長室へ届ける」
ミカ「私は書類が届いたので異常に気付かない」
教授「それが怖い」
ミカ「盗むだけなら気付きます。でも転送されれば普通に動いて見える」
教授「通信を止めないことが、むしろ攻撃を見つけにくくする場合がある」
【ARPスプーフィングで何が狙われるのか】
ミカ「通信が途中を通ると、何ができますか？」
教授「通信内容を観察したり、条件によっては改ざんを狙ったりできる」
ミカ「パスワードも？」
教授「暗号化されていない通信なら、重要情報が見える危険が高まる」
ミカ「HTTPSなら？」
教授「TLSが正しく使われていれば、通信内容を簡単に読めないよう守る重要な防御になる」
ミカ「またHTTPSが助けてくれる」
教授「そうだ」
ミカ「ではARPスプーフィングされても問題なし？」
教授「そう単純ではない。通信先情報、接続状況、暗号化されていない古いプロトコルなど、環境によって漏れるものはある」
ミカ「つまりLAN内でも暗号化が重要」
教授「そのとおりだ」
【通信を止める攻撃にもなる】
ミカ「中身を盗み見なくても悪用できますか？」
教授「できる。偽のARP情報を流し、通信を正しく転送しなければ？」
ミカ「相手へ届かない」
教授「つまり通信妨害になる」
ミカ「社内ネットワークが突然つながらない」
教授「原因が単なるネットワーク障害に見える場合もある」
ミカ「DDoSほど大規模でなくても、LANの一部を止められる」
教授「そういう可能性も考えられる」
【どんな場所で問題になりやすいのか】
ミカ「会社のLAN以外にもありますか？」
教授「同じLANへ多数の知らない端末が接続する環境では注意が必要だ」
ミカ「公衆Wi-Fi？」
教授「代表例だ」
ミカ「ホテル、カフェ、空港」
教授「ただし最近はクライアント間通信を遮断する機能などで、利用者同士を直接見えにくくしているネットワークもある」
ミカ「Wi-Fiにつながった人同士を別々の部屋へ入れる」
教授「そういうイメージだ」
ミカ「会社でも来客Wi-Fiと社内Wi-Fiを分ける意味がありますね」
教授「非常に大きい」
【発見方法① ARPテーブルを見る】
ミカ「ARPスプーフィングはどうやって発見しますか？」
教授「端末が覚えているARP情報を確認する方法がある」
ミカ「Windowsなら？」
教授「例えば arp -a でARPキャッシュを確認できる」
ミカ「何を見るのですか？」
教授「本来別々のIPアドレスであるはずなのに、複数の重要なIPアドレスが不自然に同じMACアドレスを示していないかなどを見る」
ミカ「例えばルーターと別のサーバーが同じMACになっている？」
教授「調査材料になる」
ミカ「ただし仮想環境や冗長化では正当な理由もありますね」
教授「そのとおり。MACが同じ＝攻撃確定ではない。環境を理解した上で判断する」
【発見方法② 突然MACアドレスが変わっていないか】
ミカ「いつものルーターのMACアドレスを知っていれば？」
教授「監視しやすい」
ミカ「昨日までAだったのに、突然Bになった」
教授「機器交換やネットワーク構成変更がなければ確認したい」
ミカ「変更履歴と照合する」
教授「そうだ」
ミカ「セキュリティでは『変化』を見るのが大事ですね」
教授「正常状態を知らなければ異常は分からない」
【発見方法③ ARP情報が頻繁に変わる】
ミカ「ARPキャッシュがころころ変わる場合は？」
教授「それも調査材料になる」
ミカ「同じIPアドレスなのにMACアドレスが短時間で何度も変化」
教授「通常のネットワーク変更では説明できないなら、不審なARP応答などを疑う」
ミカ「ネットワーク監視ツールでも検知できますか？」
教授「可能だ。ARPの変化を監視し、異常な対応関係を検知する製品や仕組みもある」
【発見方法④ WiresharkでARP通信を見る】
ミカ「ネットワーク担当者ならWiresharkも使いますか？」
教授「調査には有用だ」
ミカ「何を見るのです？」
教授「ARPパケットの送受信状況や、特定IPに対するMACアドレスの変化などを確認する」
ミカ「大量の不自然なARP応答が出ていないか」
教授「そうした異常を調べる」
ミカ「ただし攻撃を再現する必要はない」
教授「そのとおり。監視と分析だけでも十分な学習になる」
【発見方法⑤ 通信が突然不安定になる】
ミカ「利用者側で気付く兆候は？」
教授「突然通信が不安定になる、特定サイトだけ遅くなる、社内サービスへの接続が切れるといった現象が出る場合はある」
ミカ「でも普通のネットワーク障害でも起こります」
教授「そうだ。症状だけでは判定できない」
ミカ「だからARPテーブル、スイッチのログ、DHCP情報などを組み合わせて調査する」
教授「良い」
【防御策① HTTPS・SSHなど暗号化通信を使う】
ミカ「では防御です」
教授「まず、ARPを完全に信用しない前提で通信内容そのものを暗号化する」
ミカ「HTTPS」
教授「SSH」
ミカ「TLSを使うメール通信」
教授「VPNなども状況に応じて使う」
ミカ「攻撃者のPCを通信が通っても、中身を読ませない」
教授「そうだ。ARPスプーフィング対策そのものというより、被害を抑える重要な多層防御だ」
【防御策② Dynamic ARP Inspection】
ミカ「ネットワーク機器側で止める方法は？」
教授「企業向けスイッチなどでは、Dynamic ARP Inspection、DAIという機能がある」
ミカ「何をするのです？」
教授「ARP応答が正当なIPアドレスとMACアドレスの対応か確認し、不正なARPパケットを遮断する」
ミカ「住所係に本人確認をさせる」
教授「そのイメージだ」
ミカ「何を基準に確認するのです？」
教授「DHCP Snoopingなどで作られた正当なIP・MAC・ポートの対応情報を利用する構成が一般的だ」
ミカ「ARPだけで完結しないのですね」
教授「ネットワーク防御も連携が重要だ」
【防御策③ DHCP Snooping】
ミカ「DHCP Snoopingとは？」
教授「正規のDHCPサーバーから割り当てられたIPアドレスとMACアドレスなどの情報をスイッチが記録し、不正なDHCP応答も抑止する仕組みだ」
ミカ「その記録をDAIが使う」
教授「そうだ」
ミカ「正規の入居者名簿を作って、ARPの申告と照合する」
教授「非常に分かりやすい」
【防御策④ ネットワークを分離する】
ミカ「小さな会社でもできることは？」
教授「社内ネットワークを必要に応じて分離する」
ミカ「来客Wi-Fiと社員Wi-Fiを分ける」
教授「重要サーバーのネットワークも分ける」
ミカ「経理、サーバー、一般PCを全部同じLANに置かない」
教授「必要に応じてVLANなどで分ける」
ミカ「一台侵害されても全社LANへ近づきにくくする」
教授「それが大切だ」
【防御策⑤ Wi-Fiの端末間通信を遮断する】
ミカ「来客Wi-Fiなら？」
教授「アクセスポイントのクライアント分離、AP Isolationなどと呼ばれる機能を利用できる場合がある」
ミカ「同じWi-Fiに接続している利用者同士を直接通信させない」
教授「そうだ」
ミカ「隣の席のPCが見えない」
教授「公衆・来客ネットワークでは有効な防御になる」
【防御策⑥ 静的ARPは万能なのか】
ミカ「ARPを手動固定してしまえば？」
教授「重要な少数機器で静的ARPを使う考え方はあるが、端末数が多い環境では運用が大変だ」
ミカ「全部手入力？」
教授「機器交換のたびに変更が必要になる」
ミカ「1000台あったら泣きますね」
教授「だから企業ネットワークではDAIなど、より管理しやすい仕組みを検討する」
ミカ「セキュリティは守れれば何でもよいのではなく、運用できることも重要」
教授「非常に重要だ」
【防御策⑦ 勝手な機器をLANへ接続させない】
ミカ「社内LANへ知らないPCを挿せなければ攻撃しにくい？」
教授「そうだ。ARPスプーフィングは同じLANへ到達する必要があることが多い」
ミカ「では、誰でも空いているLANポートへ挿せる会社は危ない」
教授「ネットワークアクセス制御、802.1X認証、未使用ポートの無効化などを検討できる」
ミカ「LANケーブルにも入場管理」
教授「そうだ」
ミカ「Wi-Fiも社員認証」
教授「ネットワークへ入る最初の段階を守ることが重要だ」
【防御策⑧ 侵害された端末を早く隔離する】
ミカ「でも正規社員のPCがマルウェア感染していたら？」
教授「そのPCは正規にLANへ接続できる」
ミカ「そこからARP攻撃を始められる可能性がある」
教授「だからEDRや端末管理、不審挙動の監視も重要になる」
ミカ「ARPだけ見ていればいいわけではない」
教授「ネットワーク攻撃でも、入口はフィッシングやマルウェアかもしれない」
ミカ「シリーズ全部がまたつながりました」
教授「攻撃者は復習が好きなのだ」
【安全な範囲で構造を確認する】
ミカ「攻撃手順ではなく、図だけで整理してください」
教授「三台書こう」
ミカ「A＝私のPC」
教授「B＝ルーター」
ミカ「C＝攻撃者のPC」
教授「正常ならAはBの正しいMACアドレスを覚える」
ミカ「A → B → インターネット」
教授「ARP情報が偽られると、AがBのIPアドレスに対応するMACとしてCを覚えてしまう」
ミカ「A → C」
教授「CがBへ転送すると？」
ミカ「A → C → B」
教授「これが中間者状態の基本イメージだ」
ミカ「通信が普通に続くほど気付きにくい」
教授「そのとおりだ」
【経営者が確認したいこと】
ミカ「経営者なら何を確認すればよいですか？」
教授「難しいARP設定を覚える必要はない。次のことを管理者へ確認すればよい」
社員用LANと来客用Wi-Fiは分離されているか
誰でも社内LANへ機器を接続できる状態になっていないか
ネットワーク機器のファームウェアは更新されているか
重要通信はHTTPSやSSHなどで暗号化されているか
スイッチにDAIやDHCP Snoopingなどの防御機能があるか
ネットワークの異常を監視しているか
感染端末を迅速に隔離できるか
ミカ「ARPという単語を知らなくても確認できますね」
教授「経営者の仕事はARPパケットを読むことではない」
ミカ「では？」
教授「守る仕組みが会社に存在するか確認することだ」
【利用者ができること】
ミカ「一般社員は？」
教授「知らないLANケーブルやWi-Fiへ安易に接続しない」
ミカ「公衆Wi-Fiでは重要業務を慎重にする」
教授「証明書警告を無視しない」
ミカ「HTTPSを確認する」
教授「PCへ異常があれば早く報告する」
ミカ「自分でARPキャッシュを毎朝点検しなくても？」
教授「それを全社員に義務付けたら、会社の業務が別の意味で止まる」
【ARPスプーフィングの本当の怖さ】
ミカ「今日の攻撃で一番怖いところは何ですか？」
教授「LANの内部だから安全、という前提を利用することだ」
ミカ「社内LANなら信用できる」
教授「攻撃者はその信用を逆手に取る」
ミカ「DNSキャッシュポイズニングも住所情報を信用した」
教授「そうだった」
ミカ「ARPも住所情報を信用する」
教授「そしてサプライチェーン攻撃では取引先を信用した」
ミカ「このシリーズ、結局『信用しすぎるな』ばかりですね」
教授「セキュリティとは、信用をなくすことではない」
ミカ「では？」
教授「信用する条件を技術的に確認することだ」
【ミカと教授の一言で締める】
ミカ「教授、ARPスプーフィングを一言で説明してください」
教授「同じLANの中で、IPアドレスとMACアドレスの対応を偽り、本来別の機器へ向かう通信を攻撃者側へ誘導する攻撃だ」
ミカ「何を狙う？」
教授「LAN内の住所案内だ」
ミカ「どう発見する？」
教授「ARP情報の不自然な変化、MACアドレスの重複、ネットワークログやパケットを確認する」
ミカ「どう防ぐ？」
教授「暗号化通信、DAI、DHCP Snooping、ネットワーク分離、端末認証などを重ねる」
ミカ「教授、私が『研究室のプリンは私のものです』と宣言したら？」
教授「それはARPスプーフィングではない」
ミカ「では？」
教授「単なる所有権の偽装だ」
ミカ「ネットワークより早く発見されましたね」
教授「冷蔵庫については監視が厳しい」
【次回予告】
【第18回 IPスプーフィング――「送信元の住所は、本当に信用できるのか」】
ミカ「次も住所を偽るのですか？」
教授「そうだ。ただし今度はMACアドレスではない」
ミカ「IPアドレス？」
教授「攻撃者が通信の送信元IPアドレスを本物とは違う値に見せる」
ミカ「封筒の差出人欄を書き換えるようなもの？」
教授「まさにそれだ」
ミカ「では次回は？」
教授「『このIPアドレスから来たから信用できる』という判断が、なぜ危険になるのかを考えよう」
