The Cutting Room Floor への DDoS アタック：経過報告と教訓

本記事では、TCRF（The Cutting Room Floor） に対する長期にわたる DDoS アタック の背景、経過、対応策、および結果について詳しく報告します。また、今回の教訓やインフラの改善についても触れています。

事件のきっかけ：Twitter 上の炎上とバナー

アタック発覚直前、以下の経緯がありました。

• クロード利用者の除外政策
  • TCRF は、ユーザーエージェントに

    Claude-code

    を含む訪問者を自動的に「バンリスト」に登録する機能を追加していました。
  • 除外対象者は、特定の「退散してください」というエラーページ（クロードのロゴ付き）が表示されるようになっています。
• 炎上の発生
  • ある Twitter 公式認証ユーザーがこのバナーに遭遇し、バン回避を試みました。
  • その後、「自分が BAN されたこと」に対して憤慨し、不活性となっていたアーカイブページを掘り起こしました。
  • 「VM のゼロリングと OS の削除」 など、全くの作り話となる捏造記事を拡散し、Twitter 上でモブ現象を起こさせました（Kotaku などの報道もあります）。
• 法的対応の不一致
  • 私方はコメントを求められましたが、相方は Grok に「名誉毀損による訴訟」の助言を受けました。
• 警告
  • LLM はあなたの脳を腐らせます。 捏造情報やデマに流されず、自分で判断してください。

この背景は、アタックとTwitter の炎上が直前に関連していたことを示唆しています。単なる偶然ではなかった可能性が高いです。

---

DDoS アタックの概要と Linode の対応

攻撃の特徴

• 従来のボットとの違い
  • 通常のボットは数百ページの要求を送り、CPU を枯渇させる試みですが、今回の攻撃はサーバーのネットワーク接続を飽和させることが目的でした。
  • ゴミデータを flooding し、正当なトラフィックさえ通れぬレベルまで帯域幅を使用しました。
• 影響範囲
  • 悪質さと持続時間が酷く、Linode はサーバー接続をnull-route（無効化） せざるを得ませんでした。
  • 攻撃トラフィックが Linode の他の顧客にも影響を及ぼしていました。
  • Anubis などの反ボットプロキシは効果が薄かったため、十分な帯域幅を持つインフラが必要でした。

タイムラインと対応（太平洋時間）

攻撃前：異常なトラフィックの発見

• 8 月 27 日 00:11 に異常を検知しました。
• CPU グラフにおいて、システムが大量のゴミトラフィックに対応している紫色の部分が見られました。
• 流入トラフィックは莫大でしたが、サーバーはそれを全て破棄していました。
• 攻撃は約 30 分間 続き、サイト閲覧がほぼ不可能になりました。

メインアタック開始：サービス停止（8 月 27 日）

• 19:39 に第二波が始まり、サービスを停止させました。
• ポート 80 へのゴミ送信は、ufw や nginx ルールでフィルタリングされましたが、トラフィック量自体がサーバーを圧倒しました。
• やがて全てのウェブトラフィックが停止。ファイアウォールで許可されたトラフィックさえドロップされるようになりました。
• アラート通知が通常 5 回に対し、今回は 46 回 も発生しました。

初期調査と Linode サポートとのやり取り（8 月 27 日）

• 18:34 に Linode カスタマーサポートへ問い合わせました。
• 20:44 に返信が届きました：

  自動的な緩和措置が作動し、ルーターレベルで着信する TCP ポート 443 のトラフィックをブロックしています。トラフィックが減れば自動的に元に戻ります。

2 日目：耐え難い状況（8 月 28 日）

• 攻撃は 12 時間以上 も続き、Linode は依然として自動緩和措置の解除を示唆しました。
• ステータスページ対応
  • Linode の制限によりプライマリーサーバーがダウンしたため、3KB 未満の HTML を表示するだけの第二サーバーを用意し、DNS で切り替えました。
  • しかし、この「バックアップ」サーバーさえも攻撃を受け、ダウンしてしまいました。
• その他の被害
  • ブログを含む他の補助サービスも標的とされ、巨大な通知が山積しました。
  • 共有ホスティングであり VPS でないため、Anubis などに対抗する手段がありませんでした。

Linode クラウドファイアウォールの提案（8 月 28 日）

• 16:36 に Cloud Firewall についての返信がありました：

  この特定のケースでは Cloud Firewall は役に立ちません。ブロックは、トラフィックが当社のファイアウォール規則に到達する前の上流で発生しているためです。

3 日目：解決への道のり（8 月 29 日）

• 07:07 に Linode から攻撃終了の連絡が来ました：

  IPv4 アドレスに対する null route の表示は見られず、サービスが通常の運用に戻ったようです。

• しかし、アップタイムトラッカーは「ダウン」を表示し、ログは空でした。
• 15:08 になり、ブロック解除の連絡が入りましたが、接続性は回復していませんでした。
• エンジニアによる追加調査の結果：

  IP が DDoS 保護の結果としてフィルタリングされていることが再確認されました。Traffic が安全レベルに戻っていないため、ブロックは有効のままです。

Fastly への移行と課題（8 月 30 日）

• Linode の解決策が見込めない中、競合である Fastly を採用することにしました。
• バックアップサーバーへの切り替え
  • 新規の IPv4 を割り当て、IP を入れ替えて再稼働させました。
• 課題：帯域幅制限超過
  • 設定した月次支出制限（10 ドル）を超え、すぐにアカウント停止メールが届きました。
  • 約 70 万回のリクエストに対して 21 ドルを消費し、DDoS 保護オプションも有料化されました。
• 結果：アカウント停止
  • Fastly が「過剰な帯域幅の使用」を理由にアカウントを停止しました（開発用アカウントへの利用想定外という説明）。
  • また、設定中にセキュリティ上のエラー（バックエンドサーバーが認可されたフロントエンドからの要求のみを受け付けるよう未実装）を起こしており、攻撃者がスキャンして特定するリスクがありました。

Cloudflare による復旧と最終的解決

• 8 月 30 日 15:52 にサイトを Cloudflare に追加しました。
  • 「Under Attack」モードを有効化し、DDoS 防御に成功しました。
  • 加害者は Telegram と Discord で連絡を試みたため、即時ブロックを行いました。
• 9 月 1 日（6 日目）深夜
  • メインサーバーとバックアップサーバーの双方で設定を再調整し、サイトを再稼働しました。
  • 攻撃自体は数日間続きましたが、Cloudflare の緩和により完全にブロックされました。

最終終了（9 月 9 日）

• 12:00 に両方のサーバーからのゴミトラフィックが完全に消えました。
• Linode サポートから完了の確認連絡があり、攻撃は終了しました。

---

進行中の攻撃とインフラの改善

残存する低レベルアタック

• メインな DDoS アタックは終了しましたが、HTTP レベルの小規模な断続的なアタックが数日続けています。
• 頻度は一日に 1〜2 回で、約 10 分間続きます。
• サイトのアップタイムは 99.5% に回復しており、以前ほどの深刻さはありません。

ポジティブな成果とインフラ強化

この危機的状況を機に、以下のアップグレードを行いました：

• キャッシュ/分布の改善
• IPv6 完全サポート の導入
• ボットと迷惑行為の自動ブロック（Tor エグジットノード含む）
• 大多数の VPN からの解除
• Discord や Bluesky などのより良い埋め込み機能の実装
• Cloudflare による自動 Wayback Machine アーカイブ
• セキュリティとファイアウォールの強化
• HTTP/2 と HTTP/3 のサポート
• より詳細なアナリティクス（nginx ログの改善）

今後の方針

• ログインユーザーに対して Cloudflare 以外のプロキシを用意し、Cloudflare を通じてアクセスできない人々もサイトを閲覧できるようにする計画を立てています。
• 完全な移行までは時間をかけます。

---

謝辞とサポート

今回の攻撃で耐え抜いた間、皆様の忍耐とサポートに心から感謝いたします。夜通し workaround とトラブルシューティングを試みましたが、最終的にはより強く立ち上がることができました。

ウィキを支援したい場合は、Patreon や Ko-fi での寄付を検討してください。いつも通り、ありがとうございます。

コメントは敬意を持ってください。