私が遭遇したサイバーセキュリティ事件とその対処

最近、日本のスタートアッププロジェクトがネット攻撃に遭い、攻撃者はSMS認証APIを悪用して私のSMSサービスの請求書を膨らませました。現在、事態は収束しています。これまでの数年間に遭遇したネット攻撃事件と、そこから得た教訓を振り返りたいと思います。

国内のあるコンテンツプラットフォーム (2016 - 2018)

このコンテンツプラットフォームは、初めての起業の第二プロジェクトで、初めての起業だったため、特に防御を意識して行っていませんでした。また、当時の環境も、攻防の激しさは現在ほどではなかったため、普通のインターネットプロジェクトであれば、特に防御をしなくても、年間を通じてDDoS攻撃は数回程度でした。人は環境に適応できますが、大環境を超えることは難しいです。

2017年のDDoS攻撃

当時の対策は、クラウドプロバイダーの高防御を利用することでした。今振り返ると、これは非常に愚かな選択でした。各クラウドプロバイダーの高防御は、実際には知恵税であり、これらの高防御IPのコストは月に数百円程度なのに対し、価格は数万円に跳ね上がり、使用するにはドメインのDNS設定を変更する必要がありました。攻撃者がいつ攻撃するかわからないため、攻撃を受けたときに高防御に切り替えることが多く、今月の高防御が切れたら普通のIPに戻すという状況でした。

この防御方法の問題点は

高防御IPに切り替えた時点でサービスが既にダウンしている；
人手で操作が必要で、解析を変更した後、ユーザー側のDNSキャッシュが更新されるまでサービスが復旧しない；
高防御IPの価格が高く、クラウドプロバイダーは攻撃を受ける顧客を高価値顧客と見なし、供給と需要の観点から、あなたを騙しているだけで、技術的な価値はそれほど高くありません。

しかし、当時のプロジェクトは収益が良好で、私は単純なバカだったので、攻撃を受けるたびに1ヶ月の高防御を購入しても、特に問題があるとは思いませんでした。

前述のように、当時のネットセキュリティの大環境は比較的穏やかで、攻撃者は数回の攻撃の後、私がすぐに高防御に切り替えられることを知り、諦めて去っていきました。

2016年のDocker脆弱性侵入

同じくこのコンテンツプラットフォームで、当時Dockerのデーモンがパブリックポートをリッスンしており、ファイアウォールを設定してアクセスを許可すると、サーバーの権限が簡単に奪われることになります。ある時、サーバーの性能が特に理由もなく不足していることに気づき、調査したところ、サーバーがマイニングを行っていました 😅。マイニングプログラムの出所はダウンローダーであり、そのダウンローダーはDockerを通じて持ち込まれたものでした。実に恥ずかしく、少し笑える過去の出来事です。

2017年のXSS攻撃試行

その頃、コメント欄で <script>alert(‘test’)</script> や <script src="foo/xxx.js"></script> のようなものを見かけることがよくありました。彼が何をしようとしているのかはわかっていたので、foo/xxx.jsを辿って彼のXSSプラットフォームのドメインを見つけ、登録者の微博を調べて、直接メッセージを送り、無駄なことをしないようにお願いしました 🤣。彼は一連の省略号で返事をくれました。彼は当時若かったようで、高校生くらいの年齢だったと思います。私自身の若い頃を思い出しました。

Vueのようなフロントエンドフレームワークの {{ }} 構文がXSSの問題を処理しているため、特に何もする必要はなく、HTMLコードを挿入する際には、dompurifyのようなライブラリで sanitize するだけで済みました。

PixelCloud (2021 - 現在)

PixelCloudは私の第三の起業プロジェクトで、2021年に始まりました。この時点でネットセキュリティの環境は完全に異なり、自動化された攻撃ボットが横行していました。少しの不注意で、すぐに標的にされる可能性があります。最も典型的な証拠は、shodanのようなIPv4全感知プラットフォームの登場です。IPv4アドレスは4 x 8 = 32ビット（二進数）で、合計2^32 = 4294967296個のIPアドレスがあります。ムーアの法則がこの時点に達すると、普通の人がIPv4全体をスキャンすることも難しくなくなります。大手ネットセキュリティ企業が定期的にIPv4全体のポートをスキャンするのも当然のことです。shodanのようなサイトが登場しました。

ウェブサイトサーバーへの攻撃

ネット環境が悪化しているため、ほとんどのウェブサイトがCDNを使用しています。ウェブサイトのドメインはCDNに解析され、攻撃者はソースサーバーのIPアドレスを知ることができず、CDNのクラスターIPしか見ることができません。攻撃者はCDNを攻撃することしかできず、あなたのサーバーを攻撃することはできません。

しかし、私のサーバーは攻撃を受けました。なぜなら、nginxがHTTPSサイトのドメインエラーを処理する際に、証明書をクライアントに返すからです。これにより、shodanのようなプラットフォームがあなたのサーバーIPをスキャンした際に、エラーを通じてドメインを知ることができます。攻撃者はshodanのようなプラットフォームでドメインを検索することで、すぐにソースサーバーのアドレスを知り、CDNを回避して攻撃を行うことができます。

解決策は、新しいバージョンのnginxを使用することです。新しいバージョンのnginxは、ssl_handshake_reject文をサポートしており、アクセスするドメインが一致しない場合（例えばIP経由でアクセスされた場合）に接続を直接切断し、ドメインの漏洩を防ぎます。

数ヶ月前、三菱UFJ銀行がDDoS攻撃を受け、Twitterで誰かが「こんな大きな銀行がCDNを使わないのはなぜか」と疑問を呈していました。彼らはもちろんCDNを使用しており、akamaiを利用しています。彼らは私と同じ間違いを犯した可能性があり、ハッカーがCDNを回避して攻撃できるようにしてしまったのです。

shodanで mufg を検索すると、ソースサーバーのIPが直接表示されます。

ウェブサイトオブジェクトストレージへの攻撃

攻撃者は彼の下り帯域幅を使用して私のトラフィック請求書を膨らませ、私のオブジェクトストレージをクラウドプロバイダーに停止させ、関連するビジネスを停止させることを目的としました。

1Tのトラフィックが30分で消費されました。

解決策は、ダウンロードURLの署名APIで人間の検証を強制することです。具体的には、PixelCloudは国内プロジェクトであるため、geetestを使用しました。

CDNへの攻撃

攻撃者はCDNに対しても同様の攻撃手法を用い、特定の小さなファイルのURLを取得し、下り帯域幅を使用してCDNのトラフィック請求書を膨らませました。TクラウドプロバイダーのCDNで各IPのリクエスト数制限を設定することで解決しました。

ゲームサーバーへのDDoS攻撃

ゲームサーバーはCDNを通すことができません。なぜなら、ゲームのネットワークはL4であり、CDN（Content Delivery Network）のコンテンツは一般的にHTTPの意味を含んでいるため、L7です。国内にはCloudflare SpectrumのようなL4防御サービスは存在せず、最近のTencentのEdgeOneやCloudflare Spectrum自体も価格が高く、起業家にとっては現実的ではありません。

低コストでDDoSを防ぐために、私のパートナーが一つのアイデアを考え出しました。プログラムを書いて、クラウドプロバイダーのAPIに接続し、常駐のL4プロキシ仮想マシンを4つ生成します。もし特定の仮想マシンが攻撃されてダウンした場合、その仮想マシンに対応するEIPがダウンした場合、指数関数的により多くのEIPと仮想マシンを生成し、攻撃が停止するまで続けます。例えば、1つがダウンしたら2つ生成し、2つがダウンしたら4つ生成します。攻撃が停止した後は、これらの余分なEIPと仮想マシンを自動的に削除します。

この方法の利点は、クラウドサーバーとEIPが時間単位で課金されるため、攻撃が続いている数時間だけが課金されることです。

この方法は約1年間運用され、良好な結果を示しました。しかし、予期しない問題に直面しました。主にUクラウドプロバイダーが反対したのです。

私たちはクラウドプロバイダーの高防御を使用せず、「勝手に」弾力的な高防御ソリューションを構築したため、Uクラウドプロバイダーの担当者は非常に不満でした。顧客マネージャーの言葉は「あなたたちは攻撃を受けているのに高防御を購入していない唯一の存在です」とのことでした。彼らのビジネス担当者は、私がAからUに移転した際にこのソリューションについて詳細に説明し、彼らのビジネス担当者も認めていました。Aプロバイダーでは、どんなに大きな攻撃を受けても、誰も私に問題を持ちかけることはありませんでした。

2023年の春節に大きな攻撃を受け、1回で10以上のIPがダウンしました。Uクラウドプロバイダーは私たちのEIP申請権限を封鎖し、高防御を購入するよう強制しましたが、その時には攻撃は既に終了しており、なんとか耐えましたが、高防御を購入したくありませんでした。そこで、動的なDDoS防御システムを停止し、手元にあるEIPを利用して防御を行うことになりました。普段は2つのEIPを使用し、1つがダウンした場合は手動でUクラウドプロバイダーのバックエンドで新しいEIPを仮想マシンL4プロキシに再バインドし、その後手動でDNSPodの設定を変更し、24時間後に以前ダウンしたEIPが再び使用できるようになります。

こうして約半年が経過し、平均して2週間ごとに小さな攻撃があり、プレイヤーのゲームに少しのラグを引き起こしましたが、大きな問題はありませんでした。6月20日、再び大きな攻撃があり、手元のすべてのEIPが尽きてしまい、高防御を購入せざるを得ませんでした。その時、状況は緊急で、怒ったUプロバイダーの「バックエンド」からは私たちを退去させると脅されました。その時、私は選択肢がなく、Uプロバイダーの圧力の下で高防御を購入し、15kを支払いました。

PixelCloudは以前のコンテンツプラットフォームとは異なり、利益率が非常に薄く、15kは受け入れられませんでした。私は他の高防御ソリューションを探し始め、この時点で高防御ホストのレンタルコストが月に数百円しかないことを初めて知りました！

その後のことは簡単でした。L4プロキシを高防御ホストに配置するだけで、DDoSの問題は完全に解決しました。

日本のあるコンテンツプラットフォーム (2023 - 現在)

SMS悪用ラウンド1

このプロジェクトは私の第四の起業プロジェクトで、主にグローバル市場をターゲットにしており、L4防御の必要がなく、Cloudflareを無料で使用できるため、基本的にDDoS問題を考慮する必要はありません。

最近、再びネット攻撃を受け、攻撃者は自動化されたリクエストでSMS認証APIを悪用し、私のSMSサービスの請求書を膨らませました。この攻撃手法は、かつてのPixelCloudのオブジェクトストレージダウンロード攻撃と非常に似ているため、最初の反応は人間の検証を使用して解決することでした。しかし、ファイルを直接ダウンロードするのとは異なり、各SMS認証は私のAPIを経由する必要があるため、他の戦略を通じて人間の検証が転換率に与える影響をできるだけ避けることができるかどうかを考えました。

私は電話番号を制限することを試みました。特定の電話番号が認証コードを要求する回数が多すぎる場合、その電話番号をブラックリストに追加しました。この戦略は無効でした。攻撃者は特定の電話番号を所有する必要はなく、攻撃を行うために本当に認証コードを受け取る必要はありません。彼はSMSが送信されることを確認するだけで、私の請求書が引かれることになります。したがって、電話番号を禁止しても彼には何の損失もありません。

次に、IPを禁止することを試みました。特定のIPが過剰にリクエストを行った場合、そのIPをブラックリストに追加しました。この戦略も無効でした。攻撃者のIPは非常に多く、彼のIPは私のSMSよりも安価であるため、この防御戦略もコストに見合いませんでした。

結局、私は素直にhcaptchaを導入しました。その理由は、Google reCaptchaとCloudflare Turnstileは中国本土では機能しないからです。

ラウンド2

2日後、攻撃者は再び私のSMSサービスの請求書を膨らませました。つまり、彼は私を攻撃するために2日間かけてhcaptchaを回避する方法を研究したということです。彼の執念は素晴らしいです。

しかし、彼がそうすることで、攻撃コストが増加しました。なぜなら、以前はISO規則に合った電話番号を捏造するだけで、所有する必要はなく、APIを呼び出すだけで攻撃が完了していました。今では、hcaptchaを完了するためにpuppeteerのようなヘッドレスブラウザを使用する必要があります。AIエージェントのようなツールを使用する場合、攻撃を1回完了するために追加のトークン費用がかかります。

さらに、彼はhcaptchaのスキームを毎回成功させることができるとは限りません。

成功率は半分で、これはhcaptchaがまだ有効であることを示しています。

私の請求書を膨らませる効果を得るためには、攻撃者は並行処理を一定の程度まで引き上げる必要があります。ヘッドレスブラウザやAIエージェントを使用することで、攻撃者は自分のコンピュータ上でプロキシを使用して攻撃を完了することができず、クラウドプロバイダーの仮想マシンを大量に借りて大規模な並行処理を達成する必要があります。

攻撃者がクラウドプロバイダーのEIPを使用して攻撃を行う場合、彼のサーバーIPを禁止することが合理的になります。

自動禁止戦略で7、8個のIPが禁止された後、攻撃は停止しました。

この攻撃で私は非常に有用な戦略を発見しました。それは、クラウドプロバイダーからのすべてのIPを直接禁止することです。例えば、スクリーンショットにある 89.116.154.76 は、あるクラウドプロバイダーのものでした。攻撃ログを観察し、攻撃者がよく使用するクラウドプロバイダーを直接ブラックリストに追加することで、効果的に防御できました。普通のユーザーが公有クラウドのIPを通じてインターネットを利用することはほとんどありません。

ラウンド3

さらに2日後、攻撃者は再び私のSMS残高を使い果たしました。ログを確認すると、攻撃者は私の防御戦略を見抜いたようで、より多様なIPを使用して攻撃を行っていました。再度、クラウドプロバイダーを禁止した後、攻撃者は各IPが異なる組織から来ていることを実現しました。その中には民間ISPのIPも含まれていました。

どうやらこの攻撃者は悪意があり、利益が絡んでいる可能性が高いです。私は防御戦略を真剣に考えなければなりませんでした。そうでなければ、この問題は終わらないでしょう。

考えた結果、以下の防御戦略を実装しました：

hcaptchaを使用する；
特定のIPが過剰にリクエストしたり失敗した場合、そのIPを禁止する；
特定の組織のIPが3つ以上禁止された場合、その組織のすべての後続のIPを禁止する（手動で処理するのではなく）；
（ログイン済みユーザーのバインドされた電話番号インターフェースに対して）特定のIPが禁止された場合、リクエストにUser IDが含まれている場合、そのユーザーを禁止する；
特定の国際地域番号が過剰にリクエストされた場合、その地域番号を禁止する。ただし、すべてのハッカーの言うことを聞くわけにはいかないので、一般的な地域のホワイトリストを追加し、これらの地域番号は決して禁止しない；
認証コードの検証に成功したユーザーがいた場合、その地域番号とそのIPに対応する組織をすぐに解除する。

デプロイ後、地域番号を禁止する戦略は非常に効果的でした。なぜ攻撃者が+1のアメリカの番号を使用して私の請求書を膨らませないのかはわかりません。もしかしたら、私がアメリカの顧客を拒否すると思っているのでしょうか？

ラウンド4

一年と二ヶ月が経過し、上記の防御戦略は再び攻撃者によって突破されました。攻撃者は三つの国の番号プールを使用して、一斉に私にSMSリクエストを送信しました。その中にはGBの番号があり、イギリスの番号はホワイトリストに登録されているため、防御戦略ではブロックできませんでした。また、すべてのGB番号のリクエストは確認コードを完了し、防御戦略は設定に従ってそのIPを解除しました。同時に、攻撃者は攻撃の頻度を下げ、攻撃がスムーズに進行することを確保しました。

私は攻撃者がなぜこれほど執拗に攻撃を続けるのか、その動機が何であるのかに興味を持ち、SMS Pumpingについて調べました。攻撃者は特定の番号帯の運営者と提携しており、SMSの通信経路から利益を得ることができます。攻撃者にとって、私のウェブサイトは彼の印刷機のようなものです。

一年と二ヶ月後の今、llmはgpt 5.5に進化しており、私は具体的な攻撃戦略を自分で作成する必要がなくなりました。私はAIに防御戦略の調整方向と、その効果を検証する方法を伝えるだけで、他のことをすることができます。

調整の考え方は、「確認コードの完了」を信頼信号として扱わず、ウェブサイト内で実際に購入行動を完了した場合のみ解除するというものです。

最後の感想

実際、ネットワーク攻撃が来るたびに非常に困惑します。なぜなら、私はお金を失い、エネルギーを消耗し、サービスにも影響が出るからです。

例えば、今回のSMS API Abuseでは、攻撃者は私と時差があるようで、私の方では昼間は攻撃せず、深夜に攻撃を開始します。新しい防御戦略を展開した後、私は毎回10ドルを充てて、攻撃者の攻撃が依然として有効かどうかを確認しなければなりません。しかし、攻撃者は私の残高を使い果たした後、ゲームをしに行くようで、しばらくの間攻撃をしません。私はただ待つしかありません。この二日間は午前4時半まで寝られませんでした。

常に攻撃を受けている側として、小さな不満を言わせてもらうと、この攻防戦は本当に不平等です。私は最も早く対応し、攻撃が普通のユーザーに与える影響を最小限に抑えなければなりません。一方、攻撃者は暗闇に隠れ、準備を整え、機会をうかがうだけで済みます。

hcaptchaの導入は、実際にはすでにtodoリストに追加されていました。PixelCloudの経験から、こうした事態が発生することを予測していましたが、ずっと怠けていました。攻撃が発生するまで、実際には何も行動を起こしませんでした。暗闇の中をさまようハンターたちは、ある程度中立的であると言えます。彼らが攻撃しなくても、セキュリティの脆弱性はすでに存在しており、彼らは問題を早期に露呈させるだけなのです。

しかし一方で、2016年のプロジェクトと2021年のプロジェクトを比較すると、ネットワーク攻撃がより頻繁かつ一般的になったため、攻撃を受ける側の業者は、以前はあまり注意を払わなくても達成できた同じ効果を得るために、より多くの時間とお金をネットワークセキュリティに費やさざるを得なくなっています。例えば、オブジェクトストレージのダウンロード攻撃に関して、2016年のコンテンツプラットフォームプロジェクトでもオブジェクトストレージが大量に使用されていましたが、こんな奇妙な攻撃を受けたことはありませんでした。しかし2021年には、こうした攻撃に対処するために、すべてのユーザーがダウンロード機能を使用する前にスライドバーの確認コードを完了しなければならなくなりました。私の迅速な対応のおかげで、攻撃者は目的を達成できませんでした。攻防の両者がこの件に多くのエネルギーを費やしましたが、双方の戦線には何の変化もありません。軍拡競争は囚人のジレンマのようで、すべての人が自分の利益を最大化しようとする一方で、皆が損をする結果を招いています。泥棒の存在は、全社会にロックのコストをもたらします。

私が中二の年齢（中学二年から高校三年まで）にハッカーに非常に憧れていたこともあり、プログラミングを学ぶ前に多くのネットワークセキュリティの知識を独学しました。また、高校の公式ウェブサイトのサーバーに侵入し、3389を取得しました。いわば「スクリプトキッド」ですね。このような中二の経験があったため、プログラミングの仕事を始めた後は、さまざまなネットワークセキュリティの問題、例えばインジェクションやクロスサイトなどに非常に注意を払ってきました。そのため、私はコードが不十分であるためにハッカーがシステム権限を取得するような事態には遭遇したことがありません。

もちろん、もう一つの可能性もあります。職業的なネットワークセキュリティ攻撃の多くは、未公開の0day脆弱性を利用しています。つまり、「私は知らないことを知らない」ということです。彼らはすでに私のサーバーを完全に操られている可能性があり、rootkitの権限は私よりも高いため、私はずっと気づかずに、自分が良い状態だと思っているかもしれません。

@2025-04-22 22:30