世界中に友人への不正利用通報を送らせるIPスプーフィング攻撃
(delroth.net)- Hetznerは
195.201.9.37でSSHポートスキャンが発生したという 不正利用通報 を転送したが、サーバー内部では悪性プロセス・ファイル改変・異常トラフィックの証拠は見つからなかった tcpdumpで確認した実際の流れは、サーバーが外部の22/tcpに接続したのではなく、複数のインターネットホストがサーバーへ TCP RST を返してくる、いわゆるバックscatterに近いものだった- 中核となる原因は、BCP38 フィルタリングを行っていないネットワーク経由で任意の送信元IPを付けたパケットを送れる点にあり、往復応答が必要なTCP・QUIC・TLSでは攻撃者は応答を直接見ることができない
- 同じパターンは筆者の別の Tor relay 2台でも現れ、
tor-relaysメーリングリストやTor Projectのissueには数日前から類似現象が報告され、一部ノードが一時的に停止した事例もあった - 攻撃者は被害者IPを送信元に偽装して複数のSSH対象へ接続試行を送り、自動不正利用通報・ブロックリスト・ホスティング事業者の措置を誘発できる
Hetznerの不正利用通報とサーバー点検
- Hetznerは
195.201.9.37IPに関する AbuseInfo メールを送ってきた- 通報者は
abuse@watchdogcyberdefense.com - ログには複数の
202.91.16x.x宛て22/tcpのDENIED項目が含まれていた
- 通報者は
- 見た目にはサーバーがインターネット上へSSH接続を送り始めたように見え、通常なら マルウェア感染 を疑うような状況だった
- 1〜2時間点検したが、サーバー状態はほぼ正常だった
- 異常プロセスなし
- ファイルシステム改変なし
- ハイパーバイザー視点での異常なネットワークトラフィックなし
- そのサーバーでは複数の分散・連合型サービスが稼働していた
- Syncthing relay
- Mastodon instance
- Tor relay
- Matrix homeserver
- Tor relayは一部の
22/tcpリレーへ接続するが通報ネットワークとは一致せず、Matrix・MastodonのログやMastodon Sidekiqキューにも任意IP・ポートへの要求痕跡は見当たらなかった
tcpdump が示した実際のパケットの流れ
- 当初は
dst port 22フィルタで、サーバーから外部22/tcpへ出ていくトラフィックを確認しようとした - フィルタを
not src host 195.201.9.37に変えると、複数の外部IPの22/tcpから筆者サーバーの一時ポートへ入ってくる TCP RST パケットが見えた - 実際にはサーバーが任意ホストの
22/tcpに接続を送ったのではなく、任意のインターネットホストがサーバーへresetパケットを送っている形だった - このパターンは 送信元IP偽装 により応答パケットが偽装されたIPへ返るバックscatterと一致する
送信元IP偽装とBCP38の穴
- インターネットでは宛先IPは正確である必要があるが、送信元IPを偽装したパケットを複数の宛先へ送ることは可能だ
- BCP38 は、ピアネットワークが想定されるIPアドレスだけを送信元として使えるようにすべきだという現行のベストプラクティスである
- このフィルタリングはパケット経路の初期段階で適用されてこそ効果がある
- 大規模transit providerの段階では、ピアがそのproviderにインターネット全体のトラフィック転送を期待するため、有意義なフィルタリングは難しい
- BCP38未適用のtransit provider を1つ見つけるだけで、任意の送信元IPを付けたパケット送信が可能になる
- APNICは2023年に、送信元アドレス検証が依然として問題である理由を扱った記事を公開した
- TCP、QUIC、TLS系は往復通信を必要とするため、送信元IPを偽装すると攻撃者は応答を見られない
- 一般的なポートスキャン結果の確認には向かない
- 反射DDoSのような既知の悪用手法は存在する
なぜこのスプーフィングが被害を生むのか
- 最ももっともらしい流れは、誰かが筆者のIPを送信元として複数のインターネットホストの
22/tcpに接続試行を送っているというものだ - 通常のオープンポート探索が目的なら、偽装側は応答を見られないため論理的に合わない
- 過去には Idle Scanning という手法があったが、より暇なサーバーと予測可能なネットワークスタックのカウンタに依存しており、数十年前から実用性は失われている
- トラフィック規模が小さすぎ、継続時間が長すぎるため、スキャナ設定で送信元IPを誤入力した状況も説得力に欠ける
- 実際の被害は 不正利用通報の自動化 で発生する
- 偽装された接続試行がhoneypotや侵入検知システムのあるネットワークに届く
- 一部のシステムは自動で不正利用通報を送る
- ホスティング事業者は被害サーバーが侵害された、または悪性だと誤解する可能性がある
他のTor relayでも繰り返されたパターン
- 筆者は自分のサーバーが Tor relay として動作している点を改めて確認した
- Tor relayはTorネットワーク内部ノードであり、exit nodeでない限り公開インターネットと直接通信しない
- relayはTorネットワーク参加ノード間で暗号化された匿名トラフィックを中継する
- 一部のrelayはGuard Nodeとして動作し、Torネットワークの入口になることがある
- 異なる国とISPにある追加のrelay 2台でも
tcpdumpを実行した- 家庭用回線のrelay
- 日本のLinode VPS上のrelay
- 2台のrelayでも、外部
22/tcpからrelay IPへ向かう同じ 偽装されたTCP応答パターン が現れた - 筆者は
tor-relaysメーリングリスト にメールを送り、数日前から同じ現象を診断していた Tor Project issue がすでに存在していた - このスプーフィング攻撃はrelay以前に別タイプのノードで始まっており、より大規模な偽装接続によって一部ノードが一時停止した事例もあった
誰でも標的になり得る攻撃の流れ
- あり得る攻撃の流れは次の通り
- 攻撃者が BCP38フィルタリングのないネットワーク にアクセスする
- 複数の任意インターネットホストの
22/tcpにTCP接続要求を送る - 送信元IPは被害者のIPに偽装する
- 対象ホストやセキュリティシステムは被害者が接続を試みたと見なし、不正利用通報を送る
- 十分な規模になると、被害IPが複数のブロックリストに載り、ホスティング事業者がサーバーを停止する可能性がある
- この攻撃にTor特有の要素はない
- 単独の動機ある攻撃者が実行するのに特別難しい方法には見えない
- 被害者は実際の攻撃者ではなく、偽装された送信元IPの所有者だが、自動化された不正利用通報とホスティング事業者の対応によって運用上の被害を受け得る
2024年にも残るインターネット運用の問題
- 偽装送信元IP が2024年になっても問題である状況は、インターネット運用上の失敗に近い
- BCP38だけでなくRPKIも展開面で似た問題を抱えており、大手インターネット企業が直接ピアに要件を強制し始めて初めて普及が進み始めた
- この攻撃に対する次のステップは明確ではない
- すでに現実に発生している
- 既存に文書化された攻撃なのか、筆者には分からない
- 偽装IPパケットの実際の発信元を事後に追跡する方法を筆者は知らない
- 同様の不正利用通報を受けた運用者は、サーバーが加害者ではなく被害者である可能性を確認し、ホスティング事業者に説明する根拠を確保する必要がある
1件のコメント
Hacker Newsのコメント
こういう種類の問題は本当に対処が厄介だ。悪用報告に対する正当な返答である「誰かが私の IP をスプーフィングしており、私はやっていないし、機器も侵害されていない」は、悪意ある行為者が並べる言い訳と まったく同じだからだ
結局、記事にあるように、こちらにほとんど関心のない相手に対して 不存在の証明 をしなければならないが、実際にはほぼ不可能に近い
簡単にスプーフィングできるものに対する自動の悪用報告は、その報告自体を正当化するものではないが、自分のサーバーが正常に動作していて侵害されていないかを素早く確認する理由にはなる
少なくとも身元と管轄権の根拠、場合によってはビデオ通話のようなものも必要かもしれない。インターネット上で匿名のまま「自分は善良な人間だ」と主張して信じてくれと言うだけでは不十分だ
スプーフィングされた MAC アドレス、メールアドレス、ARP メッセージ、Neighbor Discovery、中間者 TLS 証明書も同じだ
それでもなお、まだいろいろ動いていることの方が驚きなくらいだ
完璧に設計され運用されるよう作っていたら、むしろかなり頻繁に大きく壊れていた可能性が高い。多少の不完全さに耐える性質が、インターネットの堅牢さと有用性に大きく寄与してきた
だからといって改善するなという意味ではなく、完全主義 を追い求めると、すべてを台無しにする大きな失敗をしがちだという警告に近い
以前は似たやり方で DrDoS リフレクションサーバー をスキャンしていた。ポートスキャン報告を受け取りたがるホスティング事業者はいないので、スキャンの送信元アドレスを評判の良い無実のクラウド事業者の IP にしておけば、リフレクションサーバーは UDP 応答をそちらへきちんと送ってくれた
クラウド事業者は当然ものすごい数の報告を受けるが、自分のサーバーではスキャンしていないと言えば事業者が確認してサービスを止めなかった。スプーフィングされたスキャンパケットを送るサーバーは検知されないので、通常の悪用報告の問題なしにインターネット全体を繰り返しスキャンできた
実際にどれほど頻繁に起きているかは分からないが、トランジット事業者と協力してホップをさかのぼれば、スプーフィングパケットの発信元追跡は可能だ。一度、JPMorgan が Cogent と協力して、自分たちの IP アドレス宛てにパケットを送らないでくれと知らせてきたことがある。ちなみに Cogent はインターネットの Tier 1 事業者の中でもスプーフィングにかなり寛容な方だ
このやり方が Tor を狙って使われたというのは初めて聞いたし、直感にはやや反する。スプーフィングパケットを送る側なら Tor 支持者っぽいからだ。単なる荒らしである可能性が高く、幸い Tor をホスティングしている事業者はこうしたことをあまり気にしないだろう
単なる荒らしかもしれないが、Tor が監視活動の邪魔になるので 放射性廃棄物 扱いされるよう仕向けたい側なのかもしれない
これは新しい話ではない。何年か前、ごく基本的なファイアウォール規則を作り、宛先ポート 22 に入ってくる TCP パケットのうち SYN=1、ACK=0 のものについて、送信元 IP を 1 日ブロックしていた
ところが、特定のサイトやサービスが使えないという苦情が出てきて、調べると数日おきに 8.8.8.8、1.1.1.1、Steam、Roblox、Microsoft、Facebook、Instagram、各種チャットサービスなどの人気サーバー IP からそうしたパケットが入ってきていた。もちろん全部 スプーフィングパケット で、結局ファイアウォール規則にもう少し検証を入れることになった
だから、これはかなりありふれたことだと確信している。個人的には複数の IP アドレスを運用する例外的なケースだと分かっているが、自分の送信元アドレスのどれでも使って、どの ISP に対してもパケットを送れる柔軟性が必要だ。自分には重要で、ISP が送信元基準でフィルタリングするなら契約を打ち切る理由になるので、別の ISP に移るだろう
後者は「スペースバー暖房を再びオンにする」みたいな類に近く、ISP には壊れたネットワークを直してほしい
ある会社では支社のオンプレミスに一部の Web 資産をホスティングしており、そこには 1Gbps 回線があった。本社には複数の 10G 回線とかなりまともなデータセンターがあったため、Web VM を本社へ移しつつ、割り当て済みの IP アドレス、つまり ISP-A の固定グローバル IP は維持した。VPN で本社までルーティングし、サーバーはデフォルトゲートウェイを使って ISP-B の 10G 回線から ISP-A 送信元 IP の応答を返していた
こうして受信は 1G に制限されても送信は 10G を活用できた。どうせ GET リクエストだけだった。最適な構成ではなく、最終的には IP を変更したが、有効なユースケースには見える
2 つ目として、異なる 2 本の ISP 回線と自前の ASN、自前の /23 アドレスを持っていた。トラフィックの一部を負荷分散するために、IP の半分を ISP-A、残り半分を ISP-B に流していた。うまく動いていたが、バランスを少し混ぜようとすると興味深い問題が見つかった。最初の /24 は ISP-A に、2 つ目の /24 は ISP-B にアナウンスしていたが、ISP-A に RP フィルタリング があった。そのため、すべての IP をそちらにもアナウンスしなければならなかった
RP フィルタの動作上、プリペンドのようなことはできず、すべてのトラフィックが彼ら経由で入ってこなければならない。対象プレフィックスにより良い経路が見えるとフィルタリングしてしまう。数か月にわたり、セキュリティを理由に修正を拒否された。セキュリティのベストプラクティスだという名目なのだから、ISP 名を出してもいいだろう。Virgin Media だった
ちなみに rp_filter があるインターネット回線は月 20 ドルのものではなく、月 5,000 ドル超のものだった。その地域に代替手段がなかったので変えられなかったが、代替があったなら誰が契約を失っていたかは明らかだ
「誰かがTorリレーを嫌っている」という仮説は、かけた労力の割にあまり説得力がないように見える
悪意あるリレーを運営する主体が、正当なリレーを非倫理的に引きずり下ろし、自分たちが制御するネットワーク比率を高めようとしているのかもしれない
BitTorrentのダウンロードをいくつか回すだけでも十分かもしれない
スプーフィングがもはや不可能になるよう、BCP38を実装していないすべてのASのトラフィックを十分な数のネットワーク事業者が拒否するには、何が必要だろうか？
すでに十分なインバウンドトラフィックを握っているので、「接続の安全性を確認中」が実際に意味を持ちうる
ただし、反射増幅係数を下げるほうがはるかに簡単だ。IPv4では反射ベクターをスキャンでき、入力バイトの10倍で応答する相手に抗議できるからだ
スワッティングに似た問題だ。未検証の問題報告を根拠に、権限ある主体が強い措置を取ることに依存している
違いがあるとすれば、権限者に直接連絡する代わりに、無関係な第三者を使って通報を送らせる点だろう
単一パケットで往復もない要求については、サービス拒否レベルのトラフィックでもない限り、システムが悪用通報を自動送信すべきではないと思う
特にSSHなら、どの種類のハンドシェイクも始まる前では有効な接続試行と見なす方法がない
私のメインサーバーも偽の悪用通報のせいで停止されたことがある。私のIPから1Gbpsを超えるDoS攻撃を受けたと主張していたが、私のサーバー回線は400Mbpsに制限されていた。人が通報を読むだけでも不可能だと分かったはずで、休暇中に電話サポートと2日間も争う必要はなかっただろう
これはIP版のスワッティング、特許トロール、無実の人への濡れ衣、競合相手を排除しようとするDMCA削除要請のようなものだ
本質的には、悪用防止メカニズムを武器化して気に入らない対象を攻撃するやり方だ。権限ある主体が弱い環となり、不道徳な行為者の目的達成のために積極的に利用されうるという点が興味深いが、まったく新しい現象ではない
metrics.torproject.orgのリレー数と「advertised bandwidth」のグラフを見ると、大きな差を生んだようには見えないが、それでも興味深い
最悪なのは、「Watchdog Cyber Defense」、Spamhaus、Shadowserver、あるいはUCEPROTECTのような脅し屋まがいの連中が自動通報を何百万件も送りつけられ、ホスト側はIP帯域がブロックリストに載るのを避けるために、事実上それに従わざるを得ないことだ
この問題に対するインバンドの解決策はないが、アウトオブバンドの解決策はありうる
たとえば、(1) 逆方向のトラフィックを受けていると宛先ISPに通知し、(2) そのISPがパケットの発信元を確認して当該ISPに通知し、(3) 発信元が見つかるまで2の手順を繰り返し、(4) そのネットワークの一部が正しく動作するまで隔離する、といった具合だ
結局のところ、インターネットは人間でできている