8月27日 TCRF DDoS攻撃の事後分析

…しかし、まず、何が攻撃の引き金になったのかについて、簡単な脱線をさせてください。AIエージェントに対する私たちのスタンスは、それほど秘密ではありません。最近、The Cutting Room Floorに新しい機能を追加しました。もし「Claude-code」というユーザーエージェントでサイトにアクセスすると、Claudeユーザーの禁止リストに追加されます。その後、もし後でClaudeなしでサイトにアクセスしようとすると（おそらく「プロンプトインジェクション」ページを調査したかったため）、あなたは追い出すように書かれた特別なエラーページに迎えられ、ピクセル化されたClaudeのロゴが表示されます。 こんにちは、古い友人 Twitterの青いチェックマークを持つユーザーがこれに遭遇し、禁止を回避しましたが、禁止されたという事実に対してますます怒りを感じるようになりました。彼は「プロンプトインジェクション」の長らく非アクティブだったバージョンを掘り起こしただけでなく、それがVMをゼロにし、OSを消去したという話をすべて作り上げ、その作り話の悲痛な物語をホストに何度も送りつけ、その後、それについてTwitterの群衆を扇動しました。Kotakuさえもこのナンセンスの一部を報道しました。注目すべきは、彼らが私たち両方にコメントを求めたとき、私は応答しましたが、もう一人の男は…名誉毀損で訴えることについてGrokに法的アドバイスを求めました。 LLMはあなたの脳を腐らせます。一度たりとも。 この背景を mention するのは、禁止とTwitterでの大騒ぎが攻撃が始まる直前に起こったからです。タイミングは単なる偶然以上のもののように思えます。 DDoS攻撃そのもの TCRFに影響を与えるDDoSについて議論するとき、それらは通常、ボットまたはスクレイパーによって行われます。それらは何百ものページをリクエストし、誰も読まない応答を生成することでサーバーのCPU時間を使い果たそうとします。このような攻撃は、Anubisのような緩和ツールで対応できます。これは、ボットが数秒間計算をしない限り、ページのリクエストを停止します。この攻撃ではそうではありませんでした。ここの攻撃者は、文字通りのゴミトラフィックでサーバーのネットワーク接続を飽和させ、正当なトラフィックが何も通過できないほど圧倒することを目的としていました。それは十分に悪く、十分に長かったため、Linodeは私たちのサーバーの接続をnull-route（無効化）しなければなりませんでした。DDoSトラフィックはLinodeの他の顧客に影響を与え始めていました。彼らのインフラストラクチャは、私たちに送信されていた大量のゴミトラフィックを処理できませんでした。 Cloudflareのキャッシングが帯域幅に与える影響も確認できます。残念ながら、Anubisのようなアンチボットプロキシは、この種の問題には効果がありません。すべてのトラフィックを処理するには、十分な帯域幅が必要です。 以下は、何が起こったのか、そして私たちがそれに対して何をしたのかのタイムラインです。 攻撃前 ※（この投稿のすべての時間は、特に指定がない限り太平洋時間です） 何かがおかしいことに気づいた最初の点は、このスクリーンショットに日付を付けることができます。8月27日、午後12時11分に撮影されました。主な指標はCPUの紫色のセグメントです。これは、大量のゴミトラフィックの流入を処理しているシステムからのものです。実際にはビジーワーク（緑と赤のセクション）ではなく、単なるゴミです。その紫色の部分すべて？悪い兆候です。このグラフがMbpsで測定されているのを見たのは初めてです。私たちは大量の受信トラフィックを受けていました。サーバーは、このすべてをゴミ箱に捨てる以上のことはしていませんでしたが、あまりにも大量だったため、それしかできませんでした。この攻撃は約30分続きましたが、その間、ウェブサイトへのアクセスはほぼ不可能になりました。後から考えると、攻撃者自身が撤退したのではなく、Linodeの自動DDoS緩和策が一時的に機能した可能性があります。 メイン攻撃開始（8月27日） 私は紫が好きですが、ここではありません。 午後7時39分、攻撃の別の波が始まり、すべてをオフラインにしました。攻撃はポート80に大量のゴミを送信しており、そのほとんどが実際の資産に到達する前に（ufwまたはnginxルールのいずれかによって）フィルタリングされていたとしても、そのレベルのトラフィックはサーバーを圧倒するのに十分でした。しかし、すぐにトラフィックは停止しました。すべてのWebトラフィック。サーバーのファイアウォールで明示的に許可されていた、既知の安全なトラフィックさえもドロップされていました。 この攻撃の前、私は5回この通知を受け取っていました。これまでに。この攻撃は私に46回通知をもたらし、その一部は私がしきい値を40Mb/sに引き上げた後でした… 初期調査と対応 私たちはトラブルシューティングに時間を費やしました。Linodeのネットワークグラフにはトラフィックが表示されませんでした。さまざまなソースからの接続試行は、サーバー側のファイアウォールで明示的にホワイトリストに登録したものも含めて、機能しませんでした。すべてのオプションを使い果たした後、午後8時34分に、私たちはLinodeのカスタマーサポートに連絡しました。 午後10時44分、Linodeから返信を受け取りました。 こんにちは、 調査にご協力いただきありがとうございます。最近のIP（tcrf.net）に対するDDoS活動に応答して、ルーターレベルで着信TCPポート443トラフィックを対象とした自動緩和ブロックがトリガーされたことを確認しました。このブロックは当社の自動DDoS防御システムによって管理されているため、手動での解除の具体的なETAはありません。ただし、DDoSイベントが収まり、攻撃トラフィックがクリアされると、システムは自動的にブロックを解除し、通常のHTTPSトラフィックを復元します。トラフィック条件が安定したら、接続性が回復することを保証するために、当社側で状況を積極的に監視しています。それまでの間、ご不明な点がございましたら、お気軽にお知らせください。 要するに、「トラフィックが多すぎて、ハードウェアに干渉していたため、電源を切らなければなりませんでした。トラフィックが収まると、自動的にオンになります。あなたができることは何もありません。」理想的ではありませんが、まあ。到達不能だったので、私たちにできることはあまりありませんでした。 2日目（8月28日） DDoS攻撃は、12時間以上経過しても止まっていませんでした。私たちはLinodeに連絡し、午前8時56分にこの返信を受け取りました。 こんにちは、 フォローアップありがとうございます。遅延とサービスの中断が続いていることについて、心からお詫び申し上げます。以前に言及したルーターレベルの自動緩和は、ネットワークシステムがお客様のIPに対する継続的な攻撃トラフィックを処理しているため、まだアクティブです。当社側で状況を積極的に追跡しており、できるだけ早く更新情報をお知らせします。それまでの間、ご不明な点がございましたら、または何かお手伝いできることがございましたら、お気軽にお知らせください！ よろしくお願いいたします。 K この時点で、攻撃が進行中に「ステータスページ」をホストするための2番目のサーバーを準備し始めました。その唯一の目的は、非常に小さなHTMLページ（3KB未満）を提供することでした。DNSエントリを切り替え、完了！ステータスページ。 仕事完了。 私は起きて、朝食をとったり、シャワーを浴びたり、用事を済ませたりするような、もっと生産的なことをすることにしました。 興奮したホストの声：次に何が起こるか信じられないでしょう！ 私たちの「バックアップ」サーバーから。はい。 一時的なサイトがオンライン？それもダウンさせるべきだ。 そして彼らはそうしました。バックアップサーバーもダウンしました。 それだけでは不十分な場合、私たちの「友人」は、このブログ自体を含む、私が実行している補助サービスも標的にしていました。 それが起こった数時間後ですが、それが生成した通知の山を見ることができます。 この場合、私にできることは何もありません。これらのほとんどは単純な共有ホスティングであり、VPSでさえありません。そして、そのような場合、たとえ私が望んだとしても、Anubisのようなものを使用することさえできませんでした。それは完全に私の手の届かないところにありました。 幸いなことに、他のウェブサイトへの攻撃はしばらくするとほとんど止まりました。 これらすべてが起こっている間、私はLinodeに役立つものがあるかどうかを確認していました。彼らは「クラウドファイアウォール」を提供しているので、それについて（および一般的な状況について）問い合わせました。 午後8時36分、返信を受け取りました。強調は私が追加しました。 2026-08-28 こんにちは、 できるだけ早くオンラインに戻るための道筋を理解していることは完全に理解しています。残念ながら、ブロックはトラフィックがLinode自身のファイアウォールルールに到達する前に、さらに上流で発生しているため、Cloud Firewallはこの特定のケースでは役立ちません。最も信頼性の高い方法は、自動緩和がそのコースをたどるのを待つことです。これは、攻撃トラフィックが落ち着くとすぐに解除されるように特別に設計されており、それが私たちが待機することを推奨する解決策です。当社側で状況を積極的に監視しており、状況が安定したことが確認でき次第、すぐにお知らせします。 よろしくお願いいたします。 N 状況をできるだけ早く正常に戻すために、注意深く監視しています。ご遠慮なくお問い合わせください。