- 公開インターネットは大手クラウド事業者中心の分断されたエコシステムへと分かれていく可能性があり、AWS発のオンプレミス接続遮断はその流れを示す運用事例である
- 遮断対象は主にAWS内のクライアントがオンプレミスサービスに対して行うTCP接続の試行であり、ローカルクライアントがAWSホスティングのサービスへ出ていく接続は引き続き可能
- 運用中のオンプレミスサービスはWeb、Trualiasデモ、DNS、SMTPであり、DNSはUDPとTCP fallback、および限定的なセキュリティテレメトリの公開アクセスを提供している
- AWS遮断は過剰なpingトラフィックとabusive crawler/scannerへの対応から始まり、現在はabuse対象または発信元として観測されたAWSアドレス空間53個のCIDRを管理している
- 大手クラウド事業者がreverse DNS、whois、DNSネームスペース、abuseパターンのようなフォレンジック情報をより適切に公開しなければ、クラウド内部の利用者がほとんど不便を感じないまま分断が強化される可能性がある
大手クラウドが生む分断の可能性
- 大手クラウド事業者が“too big to fail”なbulletproof infrastructureになると、インターネットの分断を直接引き起こし得る
- まだ完全に現実化した現象ではないが、すでに始まっているか、まもなく現れる可能性がある状態と見ている
- クラウドネイティブのエコシステムは実際のインターネットと比べてカスタム化されたインフラを持ち、各クラウドサービスは共通アーキテクチャよりも差別化された機能を中心に構成されている
- 多くのサービスが特定クラウド内で自己完結的に動作し、一般のインターネットとの透過的な相互運用性には障壁がある
- クラウドネイティブコミュニティは一般のインターネットを外部リソースのように扱い、インターネットそのものより特定クラウド事業者のエコシステムとより多く相互作用している
公開インターネットの商業化の流れ
- 1989年以前のインターネットには一般公開アクセスがなく、政府・軍・研究・教育機関が使う私設的な性格のネットワークだった
- NSFがバックボーンの中核を管理しており、初期の公開アクセスは非商用トラフィックという条件の下で許可されていた
- 商用サービス自体が禁止されていたわけではないが、NSFNetバックボーンを通るトラフィックは広告や有料サービスのトラフィックであってはならなかった
- 商業事業者が別個の商用インターネットを構築し、1995年にNSFNetは公開アクセスを無効化した
- 2000年前後の大規模な淘汰の後には、ユーザー行動データに基づく広告と、ユーザー行動データ販売モデルが生き残った
- 現在のAIの流れでは、アクセス可能なコンテンツを大量収集してロンダリングし、モデル学習に使う点が際立っており、キュレーションと学習は主にクラウド上で、しかも次第にクラウド事業者自身によって行われている
オンプレミスサービスでのAWS接続遮断
- オンプレミスサーバーに入ってくるAWSからのアクセスの大半を無効化している
- 技術的には主にTCPトラフィックに注目しており、初期ハンドシェイクでクライアントとサーバーを区別できる
- AWS内のクライアントがオンプレミスサービスへ接続を試みることは遮断する
- ローカルネットワークのクライアントがAWSにホストされたサービスへ接続することは可能
- ローカルでインターネット公開の複数サービスを運用している
- 長年にわたりno crawlポリシーを維持しており、提供資産は主にインターネット上の個人利用者を対象としている
- DNSサーバーはUDPとTCP fallbackを用い、限定的な公開セキュリティテレメトリを提供している
- 例のクエリ:
dig @131.191.85.30 'fail2ban;*.keys.redis.athena.m3047' txt
- クラウドで動くサービスにも有用かもしれないが、運用に依存するのであればまず連絡してほしいと考えている
reverse DNSとSMTPの例外
- Webサービスだけが問題なら、reverse DNS参照のような別の緩和策を使うこともできる
- クラウド事業者はreverse DNSの運用が不十分なことが多く、これはクラウド内リソースが一時的であるという語りと整合している
- AWSは他の多くのクラウド事業者よりreverse DNSの扱いが良く、インスタンスのreverse DNSを設定できると聞いているが、自分では試していない
- SMTPには例外を設けている
- 特に問題が深刻でない限り、他サービスへの接続は遮断しても、メールサーバー接続は許可する
- 技術的には正確なreverse DNSがなくてもSMTPは運用できるが、実際には正確なreverse DNSがないと相手にメールを受けてもらえない
- reverse DNSを評価すれば、SYNが正当なメールサーバーから来たかどうかの初期判断ができる
- 評判サービスはreverse DNSをスコア化できる
- リース型・一時的リソースに特有のパターンが存在する
- reverse DNSの有無や形式だけでも、そのアドレスがクラウド事業者に属するかを合理的に推定できる
AWSアドレス遮断が始まった理由
- 一部のabusiveサービスについて識別可能なnetblockを遮断する作業から始まり、その後は小規模ホスティング事業者を選別して遮断する概念実証へとつながった
- AWSの場合、出発点は過剰なpingトラフィックだった
- pingはコネクションレスプロトコルなので送信元を偽装できる
- 偽装されたping要求への応答は攻撃者ではなく、偽装された実際の場所へ送られる
- 絶え間ないping応答を抑えるには一時的なファイアウォールルールを生成しなければならないが、Amazonは規模が大きすぎてルール数が多くなる
- AWSアドレス範囲の収集を始め、現在はabuse対象またはabuse発信元として観測されたAWSアドレス空間を代表する53個のCIDRを持っている
- ときにはその倍に達する一時的ファイアウォールルールも観測される
- “too big to fail”なクラウド事業者から借りられたabusive crawlerやscannerを止められるのは良い副次効果であり、Webログから消えても惜しくない
クラウド利用者が受ける影響
- 人気のあるリソースや、クラウド配備される可能性のあるリソースの大半はGitHubでホストされている
- 他のリソースをクラウドに配備する人は、ステージングに使う独自のリポジトリを維持しなければならない
- リポジトリがAWS上にあると、もはや更新確認ができなくなる
- デスクトップで確認する必要がある
- 私設ホスティングのリソースで確認する必要がある
- 別途arrangementを相談することは可能
- スマートフォン、S3バケット、EC2インスタンスだけを持っている状態を「インターネット上にいる」とは言い難いが、スマートフォンからはそうしたリソースにアクセスできる必要がある
データ盗用の緩和と意図しない利用
- オープンソース資料が許可なく意図しない目的に転用されるデータ盗用も、別の緩和が必要な脅威である
- AWS遮断はそのような緩和策の1つとしても機能する
- cats、bunnies、birdsに関する資料も緩和策の文脈で一緒に扱われる
- catsとbunniesは関連動画が非常に多く、一部は購入可能であることから登場する
- birdsはOSI第2層でより効果的であり、IP datagramの転送方法としてRFCに文書化されている
大手クラウド事業者に必要な公開情報
- 大手クラウド事業者は、今より優れたフォレンジック情報配布の仕組みを提供すべきである
- DNSとwhoisは、潜在的に有用な情報を配布する手段になり得る
- 大手事業者であれば、自前のreverse DNSを運用できるべきだ
- 個別アドレスに対するwhois、reverse DNSにエンコードされた追加情報、DNSネームスペースでの別個の公開情報が必要になるかもしれない
- 現在のabuseパターンと影響を受けているアドレスブロックを扱うstorm center blogも実現可能な方式である
- SMTPにはreverse DNSだけでなく、DNS TXTレコードで公開されるSPFもある
- たった1つのIPアドレスからでも、次の問いに答える情報を見つけられるべきだ
- そのアドレスの背後にあるリソースがpingを送るのか
- どれだけ多くのpingを送るのか
- outbound TCP接続を作るのか
- どのサービスへ接続するのか
- 誰がそのリソースを制御しているのか
- リソースが攻撃を受けているのか
- どの種類の攻撃なのか
- インターネット上の他のリソースがどのような緩和を望んでいるのか
- 適切な緩和は誰にとっても有益だが、的外れな緩和はそうではない
分断されたインターネットの帰結
- こうしたやり方が広がれば、balkanized internetにつながり得る
- 大手クラウド事業者のバブルの中でオンライン生活を送る人々は、不便の大半に気づかないかもしれない
- 気づく不便があっても、それを特定クラウド事業者を選んだ結果として受け止める可能性がある
1件のコメント
Hacker Newsの意見
主要なクラウドプロバイダーはいずれも、機械可読なIPレンジ一覧を公開している
例: https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-rang...
https://www.microsoft.com/en-us/download/details.aspx?id=565...
https://support.google.com/a/answer/10026322?product_name=Un... など
「Amazonの巨大なJSON一覧をブロックしてみよう」といったゲームをするつもりはなく、ルールは53個だけだ。ある程度の副作用は受け入れられるし、AWS上にあるサイトにも普通にアクセスできている
最近のインターネットでは、インフラを公開した途端に攻撃的なトラフィックが付いてくる速度が異常だ
最近、エニーキャスト構成のために /23サブネット を1つBGPで広告したところ、ルートが上がってルーターにトラフィックが流れ始めるや否や、tcpdumpがそのレンジ内の全IPに対するポートスキャンであふれ返った
もちろんルート自体が原因ではなく、多くの主体があらゆるIPレンジを無差別かつ常時スキャンしているようだ。このレンジは何年も広告されていなかったので、誰かの稼働中サーバー一覧に載っていたわけでもない
GitLabのような内部Webサービスをいまだにインターネットへそのまま露出しているのは衝撃的だ。少なくともVPNのような追加の保護レイヤーを置き、公開インターネットからサービスが見つからないようにすべきだと思う
公開アクセス可能なのは単一の踏み台ホストのSSHだけで、これも将来的にはVPNレイヤーをかぶせてなくしたい
宇宙に行けば背景放射があるように、インターネットに行けばインターネットの背景放射がある。脆弱なサービスを動かしていないなら、こうしたポートスキャンのリスクは、月にバナナを1本余計に食べる程度のものに近い
コンソールで直接見ているから気になるだけだ。飛行機に感度の高すぎるガイガーカウンターを持ち込むと驚くかもしれないが、知らなければ害はないのと同じだ
内部サービスをインターネットに露出することには自分も驚くが、理由は2つある。たいていのプログラムの認証システムを信用していないことと、どんな内部サービスを使っているのかを外部に知らせたくないことだ。純粋な技術的セキュリティというより、プライバシーに近い理由もある
逆に、インターネット上にあるべきもので、強固な玄関口を備えている、あるいは十分にサンドボックス化されていると信じられるものは、一日中インターネット上にあってもよい
ポートスキャンは、街を歩き回ってどの家の明かりがついているかを書き留める行為のインターネット版だ。多少ストーカーっぽくはあるが、公開情報である
ちなみに
ssh -wはVPNトンネルインターフェースを作るが、実際のVPN製品のように残りの設定を自動構成してくれるわけではないインターネットはますます、Cyberpunkのblackwallの向こう側で起きていることのように感じられる
ファイアウォールの拒否アクセスログを有効にすると、既知のポートにも未知のポートにも試行が絶え間なく流れ込んできた
何かを公開するなら、たとえ奥深くに隠したWebコンポーネントであっても、それがデータやインフラへの入口にならないようにしなければならない
当時と少し違うのは、トラフィックの発生元と、受け入れるべきか遮断すべきかを判断する基準だ。正規のサーバーやサービス、エンドユーザー側のプロキシ、クラウドプロバイダー、クローラーの数が大きく増えた
本当に残念なこと。そうすると自分のコンテンツが検索エンジンにまったく出てこず、Marginaliaにも拾われず、Wayback Machineにも保存されない危険がある。
もともとそれを望んでいるなら、すべてのクラウドとデータセンターをブロックするのが正しいのかもしれない。小規模ISPがCGNATゲートウェイをどこで動かしているかによっては、そのISPの利用者までブロックしてしまうこともあり得る。可能性は低いが、不可能ではない。
記事で実際の悪用として挙げられているのは、送信元アドレスを偽装したpingだけのように見える。偽装されたpingパケットがAWSから来たかどうかは分からない。送信元アドレスは、スプーファーが応答を送らせたい先のアドレスであって、スプーファー自身のアドレスではないからだ。
はるかに侵襲性の低い緩和策は、pingを毎秒10個程度にレート制限すること。
インターネットがバルカン化しているのは確かだが、主因はIPレンジのブロックというより、広告・データ収益のためにソーシャルメディアがサイロ化し、AI学習データから収益を引き出そうとする流れにある。Reddit/Googleの独占契約のような事例がそれに近い。
数回のpingを理由に特定プロバイダーをブロックしながら、IP接続性がバルカン化していると不満を言う考え方は理解しがたい。バルカン化を生んでいるのは、ブロックしている側だ。
個人ブログや小さな趣味サイトが検索結果に見えなくなって、かなり時間がたった。
WikipediaやStack Overflowが必要なら、そのサイトで直接検索すればいい。「いつも出てくる候補」を除外して、もっとロングテールのコンテンツを見られるオプションがあればと思う。
ただ全体のトーンは、蚊に刺された出来事を壮大な歴史叙事詩に仕立てている感じに近い。
クラウド上でCGNATゲートウェイを運用すると問題が多そうだ。加入者が住宅用IPではなくなるため、Netflixのようなサービスを見られないかもしれないし、CloudflareやGoogleでボット対策CAPTCHAに遭遇する頻度も高くなる可能性が大きい。
実際に知られている事例があるのか気になる。
Hetzner、DigitalOcean、Linode、OVH、Contaboはしばらく前からブロックしている。
pfBlocker NGでASNブロックとしてもできるし、UFWルールでも可能: https://blog.abctaylor.com/ufw-and-firewalld-rules-to-block-...
たとえば、ある組織がクラウドプロバイダー上でWireGuardや別のVPNソリューションを自前運用していて、人々がそこ経由で接続すると、出口IPがクラウドプロバイダーのIPに見える。
自動化を付けることもできる。そうすれば公平で、各当事者が何が起きているか分かる。そうでなければ、こんな砂場遊びのようなことの代わりに本物の銃を使うかだ。
最初に思ったのは、AWSで動いている実際のデスクトップ、特にAmazon Workspacesのようなサービスがブロックされ得るという点だった。
ただし、そうしたサービスのIP空間も公開文書化されているようなので、必要なら該当IPを別途許可できる。
とはいえ、プロキシやVPNを使えば、こうしたブロックを回避するのは非常に簡単だ。
ずっと前に、Amazonのサーバー数十台がこちらのオンプレミスサーバーを遅くし始めたので、こうした。
何らかのSSO試行のようなものだったのかもしれないが、結局完全には追跡できなかった。ただ定期的にAmazonのIPレンジ一覧をダウンロードして、すべてブロックするスクリプトを書いて済ませた。
理解はできる。自分が作ったものからインターネットの大きな領域を壁で遮断したいなら、自分も同じことをしただろう。国全体をブロックするのと大きくは違わない。
ノイズを減らして「小さな友人グループ」だけを許可したい欲求も理解できる。
ただし自分はドメイン全体ではなく、特定のサービスにだけそうしている。Mumbleサーバーは友人がいる3〜4か国にだけ開き、クラウドプロバイダーは除外している。技術ブログは世界中の誰でも見られるようにしている。
自分は共有知識がすべての人に利益をもたらすという立場に固く立っている。300ボーのC64モデムのモデム初期化文字列に関する自分のメモが、たった一人にでも役立つなら、その人は自分が味わった苦労を繰り返さずに済み、世界は少しだけ良くなる。
いろいろな理由でそういう欲求が生まれるのは理解できる。構わない。各自が好きにすればいい。
Amazonは無視するには大きすぎる。ICMPとSYNトラフィックの多くがゴミだというのは理解している。自分もブロックを手助けしたいし、実際に緩和策も基本的には用意している。
問題は、Amazonが「大規模に」自分の緩和策に触れてくるため厄介だという点だ。Amazonは籾殻と穀粒をより分ける助けをしてくれない。「ping問題についてPCAPを送れ」という感じだ。
Amazonに資料を送って何の返事ももらえなければ、学べることはない。良いトラフィックも悪いトラフィックも、彼らを攻撃する偽装トラフィックも、あえて必要ではない。
彼らが、自分が彼らを助けられるように手助けするつもりがないなら、すべて不要だ。ただ自分の生活を単純に保っているだけだ。
こういうのを見ると、昔のインターネットが恋しくなる。商業化される前のインターネットがどれほど素晴らしかったかを説明するのは本当に難しい。
その結果がこうなると正確に言い当てていたという苦い喜びは、失ったものへの埋め合わせとしてはまったく十分ではない。
AWSはDigitalOcean、OVHcloud、ColoCrossing、Scaleway、Tencent、さらにはGoogleのようなところに比べればボーイスカウト並みだ。
特にDigitalOceanは、「サイバーセキュリティ」コミュニティにマーケティングしたのがひどい失敗だったと思う。
利害関係の開示：AWSは現在の私の雇用主だ。
何か明らかな点を見落としているのかもしれないが、投稿者がpingトラフィックはスプーフィングされたものだと考えているなら、どうやってAWSが送信元だと分かるのだろう？
経験上、AWSから圧倒的なトラフィックが来たケースをあまりにも多く見てきたし、場合によっては同じ解決策、つまりAWS全体をブロックするところまで行った。
AWSが気にしていないのか、対応が遅いのかは分からない。通報が難しすぎるのかもしれない。
見落としている明らかな点はこれだ。AWSは「悪い」トラフィックの巨大な発信元であり、誤動作している顧客を停止させるのは難しすぎる一方で、悪意ある行為者がばかげた容量を借りるのは簡単すぎる。
GCPやAzureが同じレベルの狂ったトラフィックの発信元になるのは、ほとんど見たことがない。