住宅用プロキシがIP遮断を破る理由と有効な対策

住宅用プロキシの出口ノードのうち、主要プロバイダーが販売しているものの約4分の1は、持ち主が自分の機器がどこかのインフラの一部になっていることを知らないデバイス上で動いている。この推定は、これらのネットワークを数年にわたって測定してきた学術研究によるもので、多くのことを説明してくれる。たとえば、あるセキュリティ企業が、米国大統領府に割り当てられたIP空間の中に住宅用プロキシの出口が存在するのを見つけたことも含めてだ。研究者がそのトラフィックに気づいたとき、その半分が東部時間の午後5時から深夜0時の間に届いていたため、ネット上ではお約束の反応が起きた。ただ、ジョークの裏には、我々全員にとっての現実的な教訓がある。住宅用プロキシは、IPベースの防御を破る最も効果的な手段であり、今もなお「住宅IP」を信頼の根拠として扱っている脅威モデルは、一世代遅れているということだ。

私は中規模SaaS企業で4年間、不正検知を担当してきたが、その変化はダッシュボード上でリアルタイムに見えていた。クレデンシャルスタッフィングの攻撃グループがデータセンターのプロキシから住宅用の出口へ移行したころ、我々のIPブロックリストは攻撃トラフィックの80%を捕捉していたのが、ほぼ何も捕まえられなくなった。攻撃は同じ、ツールも同じで、違うのは最後のホップだけだ。この記事では、なぜそうなるのか、そしてIPの評判が機能しなくなったときに実際に効く対策は何かを解説する。

住宅用プロキシの実際の仕組み

住宅用プロキシとは、スマートフォン、スマートTV、セットトップボックス、ホームルーターといった一般消費者向けデバイス上で動く出口ノードにすぎない。プロキシネットワークの顧客は、これらのデバイスから出ていくトラフィックに対して料金を支払い、プロキシ事業者の仕事は、あらゆる地域に数百万台を用意しておくことだ。その供給源は、まっとうさの高い順に3つある。

1. オプトイン式SDK。 VPN、天気ウィジェット、モバイルゲーム、「帯域を共有して稼げます」系のアプリなど、無料アプリにプロキシSDKが同梱されている。同意は誰も読まない利用規約に埋もれているが、形式上は存在する。大手プロバイダーが倫理面を語るときに持ち出すのが、このモデルだ。
2. 改ざんされたファームウェアとマルウェア。 ボットネットは、長年にわたりプロキシの転売で収益を上げてきた。工場出荷時に怪しいファームウェアが書き込まれた安価なAndroidストリーミングボックスは、ネットに接続した瞬間にプロキシノードになる。持ち主はメディアプレーヤーを買ったつもりでいる。
3. ボットネットの直接レンタル。 市場の下層は、もはや取り繕ってもいない。もしプロバイダーが、調達元について何も明示せずに5000万個のローテーションIPを提供しているなら、あとは計算するだけだ。

重要なのは、防御側からこれがどう見えるかだ。トラフィックはComcastやBT、Deutsche Telekomの住宅向けASNから届く。IPは妥当な都市にジオロケートされる。逆引きDNSはpool-96-225-14-7.nycmny.fios.verizon.netのようなものを返す。2010年代に我々が作ったヒューリスティクスはすべて、これは家にいる人間だと判定する。しかし違う。これは1ギガバイトあたり3ドルの中継器であり、家の住人はそれが存在することすら知らない。

この最後の点は強調しておく価値がある。プロキシを買うことも、戦うこともしないあなたにも関係する部分だからだ。帯域を中継するのと同じSDKは、他人の遠隔操作下にあるソフトウェアであり、あなたのネットワーク境界の内側で動いている。今は帯域を売っているだけだが、運営者(あるいは運営者を乗っ取った者)が、そのノードにもっと悪質な仕事を割り当てることを妨げるアーキテクチャ上の仕組みは何もない。機密ネットワーク内のデバイスに載ったプロキシSDKは、帯域の問題ではない。課金部門付きの足がかりなのだ。

IPベースの防御はなぜ死んだのか

IPの評判管理が機能していたのは、悪用がいかにも悪用らしい場所から来ていたときだけだった。防弾ホスティング、乗っ取られたデータセンターのレンジ、忘れられたVPSのオープンプロキシなどだ。悪い地域を列挙しておけばよかった。住宅用プロキシは、悪いトラフィックを良い地域へ移すことで、その時代を終わらせた。1台ずつ、乗っ取られたリビングから。

経済性はさらに悪い。データセンターのIP空間は有限で、厳しく監視されている。/24を一つ使い潰せば、1日以内にあらゆるブロックリストに載る。一方、住宅の出口ノードは事実上無限で、自己修復的だ。1回のクレデンシャルスタッフィングで、数万の異なる家庭のIPを切り替えながら、それぞれ2、3リクエストだけ送れば、IPごとのレート制限に一度も引っかからない。WAFには何万もの別々の「ユーザー」が見える。個々のIPをブロックしても意味がなく、ASN全体をブロックすれば、実際の顧客まで締め出すことになる。

だから「そのトラフィックはホワイトハウスから来た」という話には注釈が必要で、この件を議論する懐疑派の指摘は正しい。IP空間を所有しているからといって、それがひとつの物理的な場所に対応するとは限らない。大きな組織は多数の拠点からレンジを広報し、ゲストネットワーク、研究室、キャリアNATのオーバーレイを運用している。組織のレンジに含まれる出口IPは、そのアドレス空間の登録先を教えてくれるだけで、パケットがどの机を経由したかまでは教えてくれない。自社ネットワークでこの分析をするときは(そうすべきだが)、帰属の判断を結論ではなく、社内のフローログで検証すべき仮説として扱ってほしい。

今も機能する検知シグナル

IPの評判はもはや死んでいるが、トラフィックが見えなくなったわけではない。プロキシの出口には指紋がある。どのシグナルも単独では不十分で、どれにも正当な説明があり得る。しかし組み合わせると驚くほど効く。これは現代の検知エンジニアリングの定石で、決定的な証拠を探すのをやめ、弱いシグナルからスコアを積み上げる。同じ考え方は難読化されたスクリプトの振る舞いフィンガープリンティングにも表れている。コードを読まなくても、振る舞いを特徴づけられればいいのだ。

ASNと接続形状の分析

まずはASNから見るが、「住宅向けかどうか」で止めてはいけない。有用な問いは、そのASNが主張しているクライアントに合っているかどうかだ。デスクトップ版Chromeのユーザーエージェントを名乗るリクエストが、携帯キャリアの一般向け5G帯から届いているなら怪しい。一般消費者向けISPのASNから、データセンターのような同時接続数でAPIを叩いてくるトラフィックも同様だ。個々のプロキシノードは実在の家庭であり、家庭には現実の制約がある。一般家庭向けのアップロード帯域、NATテーブル、キャリアグレードNATによるアドレス共有などだ。1時間に40人の異なるプロキシ顧客にサービスする出口IPは、どの家庭からも生まれない接続パターンを作る。

TLSとTCPのフィンガープリント

ここで雑なオペレーターを捕まえられる。ほとんどのプロキシ顧客は、プロバイダー提供のクライアントソフトウェアか、標準的なHTTPライブラリ(Pythonのrequests、Goのnet/http、Node)経由でトラフィックを流している。それぞれ固有のTLS ClientHelloを持つ。暗号スイートの順序、拡張の一覧、対応グループなどだ。JA3やJA4ハッシュを使えば、TLSハンドシェイクが示すクライアントの正体と、ユーザーエージェントの主張を突き合わせられる。「Windows上のChrome 126」を名乗りながらGoのTLSフィンガープリントを送ってくるなら、それは仮装したボットだ。高度なプロキシネットワークの中には、顧客のマシンからTLSをそのまま通す(パススルーする)ものもあり、その場合は嘘が保たれる。しかし多くはそうではなく、良質なものでもTCP層で情報が漏れる。Windowsを名乗るクライアントが、Linuxを示すTTLやウィンドウサイズの背後にあるなら、それもスコアに加算される。

遅延とタイミングのパターン

どの住宅用プロキシも、一般消費者のハードウェアと回線を経由するホップを追加する。そのホップにはコストがある。サービスがWebRTC、CDNのエッジ計測、あるいはセッション内のリクエストのタイミング分布などから、クライアントの真の遅延も観測できるなら、ネットワークのRTTと主張された地理情報を照合できる。バージニアのデータセンターに対して4msのRTTを示す「デンバーのユーザー」は、デンバーにはいない。セッション内のタイミングも重要だ。人間のブラウジングには、文章を読む間の停止、マウスの動き、不規則なリズムがある。自動化スクリプトからプロキシ経由で流れてくるトラフィックは、メトロノームのような性質を持つ。リクエスト間隔が一定で、アイドル時のずれがなく、フォーム送信は即座に行われる。攻撃者がジッターを加えたとしても、それは人間が決して生み出さない分布から引かれたジッターでしかない。

振る舞いヒューリスティクス

最も強力なシグナルは、クライアントが何者かではなく、何をするかだ。実在のユーザーは寄り道をする。ボットは計画を実行する。ログインし、UIのどの経路からも到達できないURLで設定ページに直接移動し、メールアドレスを変更し、90秒で支払い申請をPOSTするセッションは、IPが何と言おうと人間ではない。シーケンスのエントロピーを追跡しよう。セッションは、フロントエンドが実際に操作させる順序でアプリを回っているか。それとも、APIドキュメントを読み込んだ人間だけが選びそうな順序でエンドポイントを叩いているか。ここで決定打になるのは、セッションをまたいだ集約だ。住宅IPが1つで3リクエストを送るだけなら無害に見える。しかし、同一のTLSフィンガープリント、同一の画面解像度、同じエンドポイント順序を持つ300の住宅IPが、それぞれ3リクエストずつ送ってくるなら、それは300の仮面をかぶった1つの作戦だ。

自社ネットワーク内の住宅用プロキシSDKを探す脅威ハンティング

外向きの問題はよく注目されるが、今回の発端となった話は実は外向きの話だ。そうあるべきでないネットワーク上の機器が、他人のトラフィックを中継していたのだ。これは、あなたがネットワーク境界を管理しているので、実際に対処できるシナリオだ。いつかどこかのユーザーが、感染したストリーミングボックスを挿したり、業務用スマートフォンに「無料VPN」を入れたりすると想定しよう。あなたの仕事は、その出来事を大きな音で知らせる状態にしておくことだ。

検知ロジックは単純だ。プロキシSDKには特徴的な振る舞いがあるからだ。ノードは指示を受け取り、トラフィックを中継するために存在する。つまり次のようになる。

• 持続的な制御チャネル接続。 なじみのないドメインやIPへの長時間のTLSセッションで、多くの場合、小さな周期的ペイロードを伴う。宛先のベースラインを作ろう。ソフトウェアベンダーが拠点を置いていない国のホストに6時間つながっているクライアント機器は、確認に値する。
• クライアント機器からの高い接続ファンアウト。 1時間に数百の異なる外部IPへ外向き接続を張るワークステーションは、人間ではなくインフラのように振る舞っている。ラップトップはブラウジングをするが、中継器は中継をする。
• クライアントのサブネットへのインバウンド開始フロー。 多くのプロキシフレームワークは、インバウンドのトンネルを開けたり、STUN型のNAT越えを使ったりする。ゲストネットワークやIoT VLANのデバイスがインターネットから接続を受けているなら、セグメンテーションに深刻な問題がある。原因を突き止めよう。
• 非対称なアップロードパターン。 アップロード量がダウンロード量に近づくスマートフォンやTVボックスは、コンテンツを配信しているか、トラフィックを中継している。どちらも一般消費者向け機器としては正常ではない。
• 時間帯のベースライン。 政府系ネットワークの出口を見つけた研究者は、まさにこの点を手がかりにした。夜間に活動が集中しているのは、ゲストネットワークではなく個人のネットワーク上の機器を示唆していた。自社での方法はもっと単純でいい。量だけでなく、機器のトラフィックパターンの性質が変わったときにアラートを出そう。

これには深いパケット検査は不要だ。信頼されるネットワークを運用したいなら、ここは重要な点だ。フローのメタデータ(NetFlow、Zeekのconnログ、VPCフローログ)が、上記のシグナルをすべて運んでいる。まだ外向きのフローデータを保持してベースラインを取っていないなら、何かを買う前にそこを埋めるべきだ。ここでの死角は、クラウド認証ログの死角と似ている。データは存在するのに、インシデントが起きるまで誰も見ていない。

# Quick-and-dirty hunt: client devices acting like relays
# Feed this Zeek-style conn logs; flag RFC1918 sources with
# high distinct-destination fan-out and heavy upload ratios.
awk -F'\t' '
$3 ~ /^(10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01]))/ {
src=$3; dst=$5
up[src]+=$10; down[src]+=$12
seen[src SUBSEP dst]=1
}
END {
for (k in seen) { split(k,a,SUBSEP); fanout[a[1]]++ }
for (s in fanout)
if (fanout[s] > 200 && up[s] > down[s] * 0.5)
printf "%s dsts=%d up=%d down=%d\n", s, fanout[s], up[s], down[s]
}' conn.log | sort -t= -k2 -nr | head -20

ここまでは第一段階であって完成品ではない。ファンアウトの閾値は自社のベースラインに合わせて調整し、メディアサーバーやバックアップエージェントが誤検知を出すことも覚悟しておこう。大事なのは、このハンティングは安上がりだということだ。数時間のログ分析で、数十万ドル規模のアプライアンスが見つけるものを見つけられる。

セグメンテーションこそが本当の対策

私の強い意見は、痛い目に遭って形作られたものだが、こうだ。感染した一般消費者向け機器との検知の軍拡競争には、決して勝てない。供給があまりに大きく、安全でないファームウェアを出荷するベンダーは何の責任も問われないからだ。できるのは、侵害された機器を退屈なものにすることだ。適切にセグメント化されたIoT VLAN上の感染したストリーミングボックスは、その帯域をプロキシネットワークに売ることができる。迷惑で、IPレンジが機密なら恥ずかしいかもしれない。しかし、社内のファイルサーバー、内部APIや、恥を情報漏えいに変えるようなものには到達できない。

インシデントレビューでは、パターンはいつも同じだ。組織はフラットなネットワークを持っていた、あるいは、社内DNSや管理インターフェースに到達できる「ゲスト」ネットワークがあった、あるいは、ただのクリックスルー同意でしか強制されていないBYOD方針があった。そこへ安いAndroidボックスや、SDK同梱のスマートフォンが参加し、組織の出口IPがプロキシプロバイダーの在庫リストに現れ始める。事後の修正は、本来なら事前に行うべきだったことそのものだ。ゲストネットワークのクライアント隔離、出口のみのアクセスでRFC1918宛先を拒否したIoTデバイス用VLAN、本番の信頼ゾーンから十分に離した個人デバイス。多層防御は華やかではないが、多層防御と単一の強力な統制の比較で論じたように、どれか一つの統制が失敗したときに守ってくれるのは層であり、そして必ずどれかは失敗する。

社内で話し合う価値のある方針の問題もある。「無料」アプリこそ、これらのSDKが入ってくる経路だ。職員がネットワークに触れる機器に任意のソフトウェアを入れられるなら、あなたは自社の境界を、モバイル広告技術の企業に委任していることになる。MDMやアプリの許可リストで対応する組織もあるが、多くの組織にとっては、ネットワークのセグメンテーションでも同じ封じ込めが、政治的なコストを抑えて実現できる。

この件が本当に示していること

政治的な憶測を取り除けば、この話は2つの事実を明確に示している。第一に、住宅用プロキシの検知は一つの製品カテゴリーとして成熟した。研究者は出口ノードを大規模に列挙し、IP空間に対応づけられるようになった。これは実に有用なテレメトリーだ。第二に、そしてより不愉快なことに、どのネットワークも、不注意な機器の購入一つで、他人のインフラになり得る。世界で最も厳重に守られたネットワークにも人間がおり、人間は物を挿すのだ。

一つだけ持ち帰るなら、自組織の出口IPが住宅用プロキシの在庫リストに載っていないか確認してほしい。いくつかのサービスが教えてくれるし、脅威インテリジェンスのフィードにすでに含まれているかもしれない。レンジが載っていたとしても、それが侵害の証拠になるわけではない。キャリアグレードNATや共有アドレス空間が状況を曖昧にするからだ。しかし、ハンティングのための安価で信号の強い出発点にはなる。そのうえで、外向きのファンアウト、長時間の接続、VLANの設計を見てみよう。

攻撃者は何年も前から良い地域へ移り住んでいる。それに気づいた防御側は、アドレスをチェックするのをやめ、振る舞いを監視し始めた者たちだ。