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

最近、日本のスタートアッププロジェクトが再びネット攻撃を受け、攻撃者は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プラットフォームのドメインを見つけ、登録者のWeiboを調べて、直接メッセージを送り、無駄なことをしないように頼みました 🤣。彼は省略された一連の点を返してきました。彼は当時若かったようで、高校生くらいの年齢だったと思います。私自身の若い頃を思い出しました。

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）のContentは一般的にHTTPの意味を含んでいるため、L7です。国内にはCloudflare SpectrumのようなL4防御サービスは存在せず、最近のTencentのEdgeOneやCloudflare Spectrum自体も実際には高額で、起業家にとっては現実的ではありません。

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

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

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

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

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

こうして約半年が経過し、平均して2週間に1回小規模な攻撃があり、プレイヤーのゲームに若干の影響を与えましたが、大きな問題には至りませんでした。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規則に準拠した電話番号を偽造するだけでよかったのに対し、今は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のアメリカの番号を使用して私の請求を刷ることを選ばなかったのかは不明ですが、彼は私がアメリカの顧客を拒否すると思ったのでしょうか。

最後の感想

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

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

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

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

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

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

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

@2025-04-22 22:30