サイトが「そんなにトラフィックはないのに、まったく読み込まない」——ファイアウォールのログには一見何の変哲もない HTTP リクエストが並んでいるとしたら、それはおそらく CC攻撃（CC攻撃） に直面しています。
CC（Challenge Collapsar）攻撃は DDoS ファミリーの中で最も欺瞞性の高い存在です。Tbps 級の帯域は不要です。数百台の感染マシンと数千の接続だけで、アプリケーション層の防御を持たないサイトを停止させられます。そして何も異常に見えないため、オンコールのエンジニアは「アプリを再起動すれば」と1時間を無駄にするかもしれません。
CC攻撃の仕組み
名前の由来は初期の攻撃ツール「Challenge Collapsar」です。核心は実に単純です。
サーバー資源を最も消費するページを、ひたすら継続的にリクエストすること。
たとえば：
- 数百万行を
LIKE '%term%'で走査する検索エンドポイント - 重い結合（JOIN）でデータを集計するレポートページ
- ディスクから大きなファイルをストリーミングするダウンロードエンドポイント
- 毎回書き込みを行う送信エンドポイント
攻撃者は大量のプロキシ IP プールを使い、これらのエンドポイントを同時かつ反復的に叩きます。個々のリクエストは まったく正常に見えます——有効なセッション、本物のブラウザー User-Agent——しかし CPU、データベース接続プール、バックエンドサービスは数分で枯渇します。負荷時に 400ms かかる検索エンドポイントを例にとると、ボットネットからの持続的な 1秒あたり200リクエスト でデータベースの接続プールが埋まり、総帯域が 5 Mbps を超えなくても本物のユーザーはログイン画面でタイムアウトし始めます。
重要な洞察：CC攻撃が標的とするのは 資源消費 であって、帯域ではありません。だから帯域や高防御IPを買い足してもほとんど無意味です——足りなくなるのは「パイプ」ではなく、データベースが応答できるクエリ数 だからです。
CC攻撃と従来のDDoSの違い
| 項目 | ボリューム型DDoS | CC攻撃 |
|---|---|---|
| 層 | L3 / L4（ネットワーク、トランスポート） | L7（アプリケーション） |
| トラフィック規模 | 数百Gbps〜Tbps | 時にはわずか数Mbps |
| リクエストの特徴 | 明らかに不正なパケット | 本物のユーザーとほぼ同一 |
| 標的となる資源 | 帯域、コネクション表 | CPU、メモリ、データベース、バックエンド |
| 防御手法 | 帯域洗浄、レート制限 | 振る舞い分析、ボットチャレンジ、精密スロットリング |
| 検知の難易度 | 比較的容易 | 極めて困難 |
一言で言えば：ボリューム型DDoSは家ごと水浸しにするが、CC攻撃はスパイを中に忍ばせて水も電気も使い果たさせる。
なぜCC攻撃は止めにくいのか
3つの理由があり、どれも単純な防御を無力にします。
- トラフィックが小さすぎて警報を鳴らさない。 多くの監視システムは帯域で閾値を設定します。CC攻撃は通常のピークトラフィックにすら及ばないこともあり、「帯域は正常」というダッシュボードが、データベースが溶けている間に安心させてしまいます。
- リクエストは正当である。 攻撃者は実在するページを、有効なパラメータと整ったヘッダーでリクエストします。破棄すべき不正パケットは存在しません。
- 送信元は分散し偽装されている。 攻撃者は実在の residential プロキシ�プールを借り、ブラウザーのクッキーや TLS 指紋まで模倣します——単純な IP ブロックリストは完全に失敗します。なぜなら「悪い」IP は本物の顧客が使う IP と同じだからです。
4層の防御戦略
第1層：資源の分離
まず、攻撃が重要なものに到達できないようにします。
- 分離：資源を食うエンドポイント（検索、レポート、エクスポート）をコア業務のエンドポイントから切り離し、理想として別のサービスプールに配置し、検索ストームが決済を飢えさせないようにします。
- キャッシュ と事前計算結果を追加し、同じクエリがデータベースに触れずにキャッシュ回答を返せるようにします。
- IPごとの同時接続制限 とエンドポイントごとのタイムアウトを設定し、攻撃者のコストを引き上げ、被害範囲を抑えます。
第2層：精密スロットリングとレートベースライン
一律のレート制限は使わないでください——それはセール中に本物のユーザーを単に劣化させるだけです。正しいアプローチは：
- エンドポイントごとに 通常トラフィックのベースライン（QPS、応答時間、リクエスト署名の構成）を確立する。
- ベースラインから外れたら 自動的にデグレード——キューイング、キャッシュ提供、検証要求——ハードブロックではなく。
- ログインや送信エンドポイントには、1秒あたり数百リクエストが本当に害になるため、より厳しいポリシーを適用する。
第3層：ボットチャレンジ
守る価値のあるエンドポイントには、ボットネットが安価に突破できない検証を追加します。
- JSチャレンジ（クライアントは計算を実行する必要がある——residential プロキシプールやヘッドレススクリプトは大規模に突破できず、攻撃者のリクエストあたりのコストが上がる）。
- 行動指紋（TLS 指紋、リクエストのリズム、本物のブラウザーが見せる人間的なマイクロポーズの欠如）。
- 必要な場所でのみ CAPTCHA。
トレードオフ：検証はユーザー体験に影響します。それを有効にするのは 攻撃中 または 高リスクエンドポイントのみ にとどめ、デフォルトでサイト全体に適用しないでください——そうすると存在しない脅威のために自社の顧客に課金することになります。
第4層：専門家の介入を伴うプロの洗浄
CC攻撃には通常、抑制のための リアルタイムなポリシー調整 が必要です——攻撃者は数分でルールを観察して適応し、User-Agent を切り替えたり検索からエクスポートへ移ったりします。静的なルールセットはすぐに陳腐化します。まさにここがプロの保護サービスの価値です。
AwayDDoS の 深層洗浄層 はアプリケーション層の振る舞いを継続的にモデル化し、7×24のセキュリティ専門家が攻撃中に能動的に介入 してルールを調整します。詳しくは 対策ソリューション をご覧ください。
よくある誤解
「CDN を前段に置いたから CC には安全だ」——CDN は一部を和らげますが、CDN がキャッシュするのは静的アセットだけです。CC攻撃が実際に標的とする動的リクエスト（検索、ログイン、API コール）はそのままオリジンへ通されます。本当に必要なのは 深いアプリケーション層の振る舞い分析 であって、エッジキャッシュだけではありません。
まとめ
CC攻撃が危険なのは、極めて安く、極めて見分けにくい ことです——residential プロキシのサブスクリプションは1日数ドルで、保護されていないデータベースを埋め尽くせます。対策は帯域を買い足すことではなく、深さを作ることです：資源分離、精密スロットリング、ボットチャレンジ、専門家の介入が連携すること。
サイトが「トラフィックは低いのに居続け不能」というパターンを見せたら、今すぐご相談 いただき、無料の攻撃署名分析をご利用ください。このテーマが初めてなら、DDoS攻撃とは？完全入門ガイド からどうぞ。