🔰GitHubを襲った1.35Tbps DDoS――ハッカーは「送信元の住所」を偽装する🔯ミカと教授のサイバーセキュリテイ🖥️第18回
【IPスプーフィング――「送信元の住所は、本当に信用できるのか」】
ミカ「教授、前回はARPスプーフィングでしたね」
教授「IPアドレスとMACアドレスの対応を偽る攻撃だった」
ミカ「今回はIPスプーフィング。何を偽るのですか？」
教授「通信パケットに書かれている送信元IPアドレスだ」
ミカ「手紙なら差出人住所？」
教授「そう考えると分かりやすい」
ミカ「では攻撃者が、自分の住所ではなく『○○銀行』と書く？」
教授「インターネット版の差出人偽装だ」
ミカ「そんな簡単に信用してよいのですか」
教授「そこが今日のテーマだ。IPアドレスは通信経路を決める重要情報だが、本人確認そのものではない」
【まずIPパケットを郵便物として考える】
ミカ「通信には送信元と宛先のIPアドレスがありますね」
教授「そうだ。例えばA社のサーバーからB社へ通信するとする」
ミカ「パケットには？」
送信元：A社のIPアドレス
宛先：B社のIPアドレス
教授「通常はこうなる」
ミカ「では攻撃者が送信元部分だけ別のIPアドレスにしたら？」
教授「受信側から見ると、別の機器から送られてきたように見える可能性がある」
ミカ「封筒の裏へ他人の住所を書くようなものですね」
教授「そのとおり」
【IPスプーフィングとは何か】
ミカ「では定義をお願いします」
教授「IPスプーフィングとは、IPパケットの送信元IPアドレスを本来とは異なるアドレスに偽装することだ」
ミカ「目的は？」
教授「攻撃元を分かりにくくする、別のコンピューターになりすます、DDoS攻撃で第三者へ大量の応答を送らせる、といった用途がある」
ミカ「一番よく使われるのは？」
教授「特に重要なのがDoS・DDoS攻撃やリフレクション攻撃だ」
ミカ「第13回のDDoSとつながりました」
教授「今回は、その大量通信を作る仕掛けの一つを見るわけだ」
【ただし「IPを偽れば何でもログインできる」わけではない】
ミカ「では銀行が『このIPアドレスから来た人だけ許可』としていたら、銀行のIPを偽れば入れますか？」
教授「そんなに単純ではない」
ミカ「なぜです？」
教授「通信には返事が必要だからだ」
ミカ「返事？」
教授「送信元を他人のIPアドレスに偽装すると、相手からの応答は基本的に偽装したIPアドレスの本当の持ち主へ返る」
ミカ「攻撃者のところへ戻ってこない」
教授「そうだ」
ミカ「ではWebサイトへ普通にログインするような双方向通信には使いにくい？」
教授「特にTCPでは接続確立のやり取りがあるため、単に送信元IPを書き換えただけで完全になりすますのは難しい」
ミカ「IPスプーフィング＝万能な変装ではない」
教授「重要な点だ」
【では、なぜ攻撃に使えるのか】
ミカ「返事が攻撃者に来ないなら、何の役に立つのです？」
教授「攻撃者が返事を受け取る必要がない攻撃なら使える」
ミカ「例えば？」
教授「DDoSだ」
ミカ「なるほど」
教授「攻撃者が、送信元IPアドレスを被害者のものに偽装して第三者のサーバーへ問い合わせる」
ミカ「第三者サーバーは？」
教授「『被害者から問い合わせが来た』と思って、被害者へ回答する」
ミカ「攻撃者ではなく被害者へ大量の返事が行く」
教授「これがリフレクション攻撃の基本構造だ」
【身近な例――勝手にピザを100軒注文する】
ミカ「いつもの例をお願いします」
教授「攻撃者が100軒のピザ屋へ電話する」
ミカ「大食いですね」
教授「自分の住所を言わず、ミカの住所を伝える」
ミカ「嫌な予感しかしません」
教授「『ピザを10枚届けてください。住所はミカさん宅です』」
ミカ「100軒全部？」
教授「100軒がミカの家へ届けに来る」
ミカ「玄関がピザ屋で埋まります」
教授「攻撃者自身は一度もミカの家へ来ていない」
ミカ「私になりすまして第三者へ注文した」
教授「それがリフレクションの発想だ」
ミカ「ピザなら夕食には困りませんが」
教授「ネットワークでは回線が詰まってサービスが止まる」
【さらに恐ろしい「増幅」】
ミカ「でも攻撃者が100送ったら、100返るだけでは？」
教授「そこでAmplification、増幅が加わる」
ミカ「どういうことです？」
教授「小さな問い合わせに対し、非常に大きな回答を返すサービスがある」
ミカ「1KBの質問に50KBの返事が来るような？」
教授「そういうイメージだ」
ミカ「攻撃者は少量しか送らない」
教授「しかし被害者には大量の通信が届く」
ミカ「攻撃者にとって効率が良い」
教授「残念ながらな」
【具体的な流れ――反射・増幅型DDoS】
ミカ「安全な範囲で流れを整理してください」
教授「四者を書こう」
① 攻撃者
② 多数の第三者サーバー
③ 被害企業のIPアドレス
④ 被害企業のWebサービス
ミカ「攻撃者は？」
教授「送信元を③の被害企業に見せかけた問い合わせを②へ送る」
ミカ「②は本物だと思って返事する」
教授「返答先は③だ」
ミカ「多数の②から一斉に③へ大量の返事」
教授「しかも応答が問い合わせより大きければ増幅される」
ミカ「そして④の通信回線が埋まる」
教授「サービスが使えなくなる」
ミカ「攻撃者はほとんど表に出ない」
教授「これがIPスプーフィングがDDoSで重要な理由だ」
【実例――GitHubを襲った1.35Tbps攻撃】
ミカ「実際の大規模事例はありますか？」
教授「有名なのが2018年2月28日のGitHubへのDDoS攻撃だ」
ミカ「GitHubが止まった事件ですね」
教授「GitHubの公式報告では、攻撃は最大1.35Tbps、1秒当たり約1億2,690万パケットに達した」
ミカ「1.35テラビット？」
教授「当時としては極めて大規模だった」
ミカ「どうやってそんな通信量を？」
教授「インターネットへ公開されていたmemcachedというサービスが悪用された」
ミカ「そしてIPスプーフィング？」
教授「そうだ。送信元IPをGitHub側に偽装した問い合わせを多数のmemcachedサーバーへ送り、その大きな応答をGitHubへ集中させた」
ミカ「小さな注文で巨大な荷物をGitHubへ届けさせた」
教授「GitHubの説明では、条件によっては非常に大きな増幅効果が得られる攻撃だった」
ミカ「攻撃者が全部の通信を直接送ったわけではない」
教授「インターネット上の第三者サーバーを増幅器として使ったわけだ」
【日本でも観測されている】
ミカ「日本ではどうですか？」
教授「JPCERT/CCも、日本国内のWebサイトなどから発生する反射パケットや、主要企業サイトを対象としたリフレクション攻撃とみられる活動を観測している」
ミカ「日本企業も無関係ではない」
教授「もちろんだ。またNICTも、DoS攻撃では送信元IPアドレスの詐称が利用されることがあり、攻撃元の特定を難しくすると説明している」
ミカ「ただし企業名まで公表されないケースも多い？」
教授「そうだ。だから『○○社がIPスプーフィングで被害』と根拠なく結び付けてはいけない」
【具体的方法① リフレクション攻撃】
ミカ「IPスプーフィングの代表的方法を整理してください」
教授「第一は今説明したリフレクション攻撃だ」
ミカ「被害者のIPになりすまして第三者へ問い合わせる」
教授「第三者が被害者へ回答する」
ミカ「大量の第三者を使えばDDoS」
教授「そうだ」
【具体的方法② 増幅攻撃】
ミカ「第二は？」
教授「増幅攻撃だ」
ミカ「小さな問い合わせ、大きな返事」
教授「DNS、NTPなど、過去にはさまざまなUDP系サービスが反射・増幅攻撃へ悪用されてきた」
ミカ「なぜUDPが多いのです？」
教授「UDPはTCPのような接続確立手順がなく、プロトコルや実装によっては送信元アドレスを厳格に確認せず応答するため、送信元偽装と組み合わせやすい」
ミカ「だからIPスプーフィングと相性が悪い意味で良い」
教授「そういうことだ」
【具体的方法③ SYN Floodなどで攻撃元を隠す】
ミカ「ほかには？」
教授「DoS攻撃で大量のパケットを送る際に送信元IPアドレスを偽装し、攻撃元を特定しにくくする場合がある」
ミカ「SYN Floodなどですね」
教授「そういうネットワーク層・トランスポート層の攻撃と組み合わされる」
ミカ「偽の差出人住所が大量に並ぶ」
教授「防御側は、本当の攻撃元を追いにくくなる」
【具体的方法④ IPアドレスだけを信用する仕組みを狙う】
ミカ「DDoS以外では？」
教授「古いシステムなどで、『このIPアドレスから来た通信だから信用する』という認証やアクセス制御があると危険だ」
ミカ「社内サーバーが『192.168.x.xなら社員です』みたいな？」
教授「IPアドレスだけを本人確認に使う考え方は弱い」
ミカ「ただIPを偽装しただけでは返事を受け取れない場合もある」
教授「その通り。ネットワーク構成や通信方式によるため、単純な話ではない。しかし原則として、IPアドレスだけを身元証明にしないことが重要だ」
【ARPスプーフィングとは何が違うのか】
ミカ「前回のARPスプーフィングとの違いを整理しましょう」
教授「ARPスプーフィングは？」
ミカ「同一LAN内で、IPとMACアドレスの対応を偽る」
教授「IPスプーフィングは？」
ミカ「IPパケットに書かれた送信元IPアドレスそのものを偽る」
教授「そうだ」
ミカ「ARPはLAN内の配送先案内」
教授「IPスプーフィングは差出人住所の偽装」
ミカ「似ているようで違いますね」
教授「スプーフィングとは、広く言えば『なりすまし・偽装』だ」
【メールの送信元偽装とも違う】
ミカ「メールで送信者を偽るのもIPスプーフィングですか？」
教授「別物だ」
ミカ「メールのFrom欄を偽装するのは？」
教授「メールの仕組み上の送信元情報を偽る話だ。IPスプーフィングとは層が違う」
ミカ「見た目はどちらも『差出人偽装』」
教授「そうだが、仕組みは別だ」
ミカ「セキュリティ用語は似た名前が多いですね」
教授「全部『偽装』で片付けると、教授の仕事がなくなる」
【どう発見するのか① あり得ない送信元IPを見る】
ミカ「防御側は、どうやってIPスプーフィングを見つけますか？」
教授「まず、そのネットワークから来るはずのない送信元IPアドレスを見る」
ミカ「例えば？」
教授「インターネット側の回線から届いたパケットなのに、送信元が社内専用アドレスになっている」
ミカ「外から来たのに『私は社内PCです』」
教授「明らかに疑わしい」
ミカ「ルーターやファイアウォールで落とせますね」
教授「そうだ」
【どう発見するのか② 入口と送信元の整合性を見る】
ミカ「ほかには？」
教授「パケットが入ってきたインターフェースと送信元IPアドレスが整合しているかを見る」
ミカ「この回線からこのIP帯が来るのはおかしい、という判断？」
教授「そうだ」
ミカ「ネットワーク機器なら自動化できますか？」
教授「uRPFなど、経路情報を利用して送信元を検証する仕組みがある」
ミカ「住所だけではなく、どの道から来たかまで確認する」
教授「良い理解だ」
【どう発見するのか③ NetFlowや通信ログを見る】
ミカ「大量攻撃なら？」
教授「NetFlowなどのフロー情報や、ファイアウォール、ルーター、DDoS対策装置のログを見る」
ミカ「何を探す？」
教授「突然増えた通信量、大量の同種パケット、不自然に多数の送信元、応答しても通信が成立しないパターンなどだ」
ミカ「DDoSの兆候ですね」
教授「そうだ。IPスプーフィングは単独で『私は偽物です』と名札を付けてくれない。通信全体の挙動から推測することが多い」
【どう発見するのか④ TCPなら片方向の異常を見る】
ミカ「TCPの場合は？」
教授「大量の接続開始要求が来るのに、その後の正常な接続処理が完了しない状態が増えるなら調査対象になる」
ミカ「最初だけ来て、その後返事がない」
教授「送信元が偽装されている場合を含め、SYN Floodなどさまざまな原因を考える」
ミカ「ただし、それだけでIPスプーフィング確定ではない」
教授「その通りだ」
【防御策① 入口で偽装パケットを落とす】
ミカ「では防止方法です」
教授「最も重要なのがSource Address Validation、送信元アドレス検証だ」
ミカ「何をするのです？」
教授「そのネットワークから出入りするパケットについて、送信元IPアドレスが妥当か確認する」
ミカ「顧客Aの回線から、顧客BのIPアドレスを名乗るパケットが出てきたら？」
教授「遮断する」
ミカ「これをインターネット全体でやれば？」
教授「IPスプーフィングはかなり難しくなる」
【防御策② BCP 38――偽の住所を外へ出さない】
ミカ「BCP 38という言葉を聞いたことがあります」
教授「IPスプーフィング対策で非常に重要な考え方だ」
ミカ「何をする？」
教授「ISPや組織のネットワーク境界で、自分のネットワークから出ていくはずのない送信元IPを持つパケットを外へ出さない」
ミカ「自社の社員が偽住所の手紙を郵便局へ持ち込んでも、受付で止める」
教授「そうだ」
ミカ「被害を受ける側だけではなく？」
教授「攻撃に加担しない側の対策でもある」
ミカ「インターネット全体で協力しないと効果が出にくい」
教授「そのとおりだ」
【防御策③ uRPF】
ミカ「さっき出たuRPFとは？」
教授「Unicast Reverse Path Forwardingだ」
ミカ「名前だけで難しそうです」
教授「簡単に言えば、『この送信元IPから来るなら、本当にこのインターフェースから来るのが自然か』をルーティング情報を使って確認する」
ミカ「帰り道を逆向きに調べる？」
教授「そういう発想だ」
ミカ「不自然なら？」
教授「設定に応じて破棄できる」
ミカ「ただし複数回線を使う複雑なネットワークでは？」
教授「通信経路が非対称になることがあるので、環境に合ったモードや設計が必要だ」
ミカ「何でもONにすればいいわけではない」
教授「ネットワーク技術者の仕事がまた増えたな」
【防御策④ ACLであり得ない送信元を拒否する】
ミカ「小さなネットワークなら？」
教授「ルーターやファイアウォールのACL、アクセス制御リストで、外部から来るはずのない送信元を拒否する方法がある」
ミカ「例えば社内専用アドレスを外部回線から受け取らない」
教授「そうだ」
ミカ「自社が所有しているIPアドレスが外部から送信元として来る場合も？」
教授「ネットワーク構成によるが、明らかにあり得ない経路なら遮断対象になる」
ミカ「『住所』だけでなく『入口』も見る」
教授「その考え方を覚えておけばよい」
【防御策⑤ IPアドレスを認証に使わない】
ミカ「アプリケーション側では？」
教授「IPアドレスだけを本人確認の根拠にしない」
ミカ「『会社のIPから来たから管理画面を開く』だけでは弱い」
教授「ユーザー認証、MFA、証明書、VPNなどを組み合わせる」
ミカ「ゼロトラストにつながりますね」
教授「そうだ。『どこから来たか』だけでなく、誰なのか、どの端末なのか、何をしようとしているのかを見る」
【防御策⑥ 反射器にならない】
ミカ「DDoSの被害者にならない方法だけではなく、自社サーバーが攻撃に利用されるのも防ぎたいですね」
教授「非常に重要だ」
ミカ「何をすれば？」
教授「不要なUDPサービスをインターネットへ公開しない。必要なサービスでもアクセス制御や適切な設定をする。古い機器やサービスを放置しない」
ミカ「自分のサーバーが他社を攻撃する『ピザ屋』にならない」
教授「そうだ」
ミカ「自社には被害がなくても？」
教授「攻撃の踏み台になれば、社会的な問題にもなる」
【防御策⑦ DDoS対策サービス】
ミカ「大量通信そのものへの対策は？」
教授「DDoS緩和サービス、CDN、上流ISPでのフィルタリングなどを利用する」
ミカ「自社サーバーへ届く前に落とす」
教授「大規模な攻撃は、会社の回線まで届いてから防ごうとしても回線自体が埋まってしまう」
ミカ「門の前で100万人を整理するのでは遅い」
教授「街へ入る前に分散させる必要がある」
【安全な範囲で仕組みを確認する】
ミカ「今回も攻撃プログラムなしで整理しましょう」
教授「三台書く」
A：攻撃者
B：第三者の応答サーバー
C：被害企業
ミカ「正常ならAからBへ問い合わせれば？」
教授「BはAへ返す」
ミカ「IPスプーフィングが使われると？」
教授「Aが送信元をCに見せかける」
ミカ「Bは？」
教授「Cへ返す」
ミカ「大量のBを使えば？」
教授「Cへ大量の通信が集中する」
ミカ「これなら仕組みが分かります」
教授「重要なのは理解であって、実際の第三者サーバーを使って試すことではない」
ミカ「実験するなら自分で管理する閉じた環境だけ」
教授「そのとおりだ」
【経営者が確認したい7項目】
ミカ「経営者には難しい話になりました」
教授「設定方法まで覚える必要はない。管理担当者へ次を確認すればよい」
インターネット境界で送信元IPアドレスの検証を行っているか
外部から来るはずのないIPアドレスをACLなどで遮断しているか
uRPFなどのアンチスプーフィング機能を検討しているか
IPアドレスだけで重要システムへのアクセスを許可していないか
不要なUDPサービスを外部公開していないか
DDoS発生時にISPや対策事業者へ連絡する手順があるか
大量通信や異常なフローを監視できるか
ミカ「『IPスプーフィング対策していますか』より具体的ですね」
教授「経営者はコマンドを打つ必要はないが、防御の有無を質問する必要はある」
【利用者ができることはあるのか】
ミカ「一般社員は何をすれば？」
教授「IPスプーフィングそのものを社員が防ぐ場面は少ない」
ミカ「ネットワーク側の問題ですね」
教授「ただし、ルーターやIoT機器を最新に保つ、不要なサービスを公開しない、提供元不明の機器を社内ネットワークへ接続しないことは重要だ」
ミカ「自分の機器を攻撃の踏み台にしない」
教授「そうだ」
ミカ「家庭のルーターでも？」
教授「同じ考え方だ」
【送信元IPをログに残せば犯人が分かるのか】
ミカ「教授、アクセスログに攻撃元IPが残っていれば、犯人が分かりますよね」
教授「それも危険な思い込みだ」
ミカ「なぜ？」
教授「今日一日何を勉強した？」
ミカ「IPアドレスは偽装できる」
教授「だからログの送信元IPは重要な手掛かりだが、それだけで犯人を断定してはいけない」
ミカ「VPNやプロキシ、踏み台もあります」
教授「ボットネットもある」
ミカ「偽装もある」
教授「実際の調査ではネットワーク事業者のログや通信経路、時刻など複数の情報を組み合わせる」
ミカ「IPアドレス＝犯人の住所ではない」
教授「非常に重要だ」
【IPスプーフィングの本当の怖さ】
ミカ「この攻撃の一番怖いところは？」
教授「インターネットの通信では、パケットに書いてある送信元住所を無条件に信用できないということだ」
ミカ「では何を信用する？」
教授「一つだけを信用しない」
ミカ「また多層防御？」
教授「そうだ。経路検証、暗号化、認証、MFA、証明書、ログ監視などを組み合わせる」
ミカ「ARPスプーフィングも、DNSキャッシュポイズニングも同じでした」
教授「すべて『表示されている住所が本物とは限らない』という問題でもある」
【ミカと教授の一言で締める】
ミカ「教授、IPスプーフィングを一言で説明してください」
教授「IPパケットの送信元アドレスを偽装し、別の機器から送られてきたように見せる手法だ」
ミカ「代表的な使われ方は？」
教授「DDoSのリフレクション・増幅攻撃や攻撃元の隠蔽だ」
ミカ「どう発見する？」
教授「送信元IPと入口・経路の矛盾、異常な通信量、フローログなどを見る」
ミカ「どう防ぐ？」
教授「BCP 38の考え方による送信元検証、uRPF、ACL、DDoS対策、そしてIPアドレスだけを本人確認に使わないことだ」
ミカ「教授、今日のレポートを送った人のIPアドレスは私ではありません」
教授「では誰なんだ」
ミカ「IPスプーフィングです」
教授「未提出をネットワーク攻撃のせいにする学生は初めてだ」
【次回予告】
【第19回 ポートスキャン――「ハッカーは侵入前に、なぜ会社のドアを一つずつノックするのか」】
ミカ「次は住所を偽らないのですね」
教授「次は住所へ着いた後だ」
ミカ「何をするのです？」
教授「建物に玄関、勝手口、搬入口があるように、サーバーにもさまざまな通信の入口がある」
ミカ「それがポート？」
教授「そうだ」
ミカ「ハッカーは一個ずつ確認する？」
教授「第19回では、攻撃者が侵入前に『どの入口が開いているか』を調べるポートスキャンと、それをどう発見・防御するかを見ていこう」
