L3/L4 から L7 まで：DDoS の多層防御アーキテクチャをどう構築するか

前回の記事『DDoS 攻撃の種類を徹底解説：ボリューム型攻撃、CC から L7 攻撃まで』では、DDoS 攻撃の種類によって消費されるリソースが異なることをお伝えしました。

Volumetric Attack は Bandwidth を消費し、Protocol Attack は Connection を消費します。そして Application Layer では、HTTP Flood や CC Attack が Web Server、API、Database Resource を直接消費することがあります。

そのため、最終的な結果がどれもサービスの異常であっても、その背後にある問題はまったく異なる場合があります。大量の UDP Traffic の核心的な問題は通常 Network Layer で起きますが、大量の Login Request は一見正常な HTTP Request を通じて Application Resource を消費し続けることがあります。

現代の DDoS 対策は、どれだけの攻撃トラフィックに耐えられるかだけでなく、攻撃が発生する Layer に応じて異なる識別と対処の方法を取る必要があります。そしてこれこそが、多層防御アーキテクチャの核心です。

なぜ単一の防御機構だけでは不十分なのか

攻撃が L3/L4 で発生する場合、企業は大量の Packet、Connection、Reflection Traffic に直面することがあります。攻撃が L7 に入ると、攻撃者が送るのは HTTP Protocol に完全に準拠した Request である可能性があります。

たとえば POST /login は正常なユーザーから来ていることもあれば、Automated Client が Login API を呼び出し続けていることもあります。Network Layer から観察するだけでは、こうした正常な形式の Request がビジネスにリスクをもたらしているかどうかを判断するのは困難です。

そのため、各 Security Mechanism は互いを置き換えるものではなく、それぞれ異なる層の問題に対応します。

• Network / Transport Layer：主に Traffic、Packet、Connection を観察
• Application Layer：判断材料が HTTP Request、URI、API Endpoint、Request Rate へと広がる
• より複雑な Automated Traffic：さらに Client、Session、Behavior の分析が必要

多層防御の目的は、各 Layer の異常を、それに適した場所で識別し対処することです。

Layer 1｜DDoS Protection：まず L3/L4 の異常トラフィックに対処する

多層防御の第一層は、Network / Transport Layer の異常に対処することです。

SYN Flood は大量の未完了コネクションによって Connection Resource を消費することがあります。UDP Flood、ICMP Flood、DNS Reflection などの攻撃は、短時間で大量の異常な Traffic を生み出すことがあります。そのため L3/L4 防御の主な役割は、こうしたトラフィックが Application にさらに影響を及ぼす前に、Network / Transport Layer の Attack Pattern を識別して対処することです。

ByteShield DDoS Protection は、次の攻撃タイプをカバーしています。

• Land Flood、ICMP Flood
• SYN Flood、SYN-ACK Flood、ACK Flood、FIN/RST Flood
• TCP Reflection、Connection Exhaustion
• TCP/UDP Fragmentation
• DNS Reflection / Amplification

さらに GEOIP、Black/Whitelist などの条件でトラフィックを制御し、ICMP、TCP、UDP などの Protocol ごとに分類して対処できます。

この層で主に注目するのは BPS、PPS、SYN Rate、Concurrent Connections です。これらの指標に明らかな異常が現れた場合は、まず Network / Transport Layer が攻撃を受けていないかを確認する必要があります。

Layer 2｜CC Defense：L7 では Request を判断し始める

Network Layer に明らかな大容量トラフィックの異常がないからといって、サービスが攻撃を受けていないとは限りません。

Application Layer では、攻撃が大量の HTTP Request へと姿を変えることがあります。たとえば POST /login、GET /search、GET /api/query は、単独で見ればどれも正常かもしれません。しかし短時間に大量に発生したり、Authentication、Database Query、Search などの高コストな Endpoint に集中したりすると、Application Resource を消費し続けることがあります。

L7 防御では、HTTP Request と Request Pattern が正常なビジネスの利用シナリオに合っているかどうかを、さらに踏み込んで判断する必要があります。

ByteShield CC Defense は、複数の HTTP 条件を組み合わせたマッチングでカスタムルールを作成し、レート制限、行動ベースの検証、JS などの対処方法と組み合わせることができます。APP と API のシナリオでは、アルゴリズム署名による Request の検証や、Challenge Mechanism と組み合わせて Client Verification の判断材料を増やすことも可能です。

攻撃元がより分散している場合は、IP Blocklist だけでは不十分なことがあります。そのため Request Pattern と行動の特徴から異常を分析し、ネットワーク全体の連携によって、識別した CC Attack の特徴と関連する防御ポリシーを同時に反映させることもできます。

この層では、防御が観察する情報も Traffic、Packet、Connection から HTTP Request、URI、API Endpoint、Request Frequency へと広がります。

Layer 3｜Bot Management：Request から一歩進んで Behavior を理解する

より複雑な L7 のシナリオでは、単一の Request を判断するだけではまだ不十分なことがあります。

正常なユーザー、正当な Crawler、Malicious Bot は、いずれも同じ GET /product/123 を送る可能性があります。Automated Traffic がさらに Distributed IP、異なる User-Agent、Request Interval を使い、一般的な閲覧フローまで模倣するようになると、IP や固定の Request Rule だけに頼って Client を見分けることはいっそう難しくなります。

そのため L7 防御では、Request Analysis から Client と Behavior Analysis へと範囲を広げる必要があります。

ByteShield Bot Management は、既知の Bot Library とインテリジェントな識別機構によって、さまざまな Automated Traffic を分類します。対象には、パートナー Bot、監視 Bot、アグリゲーター Bot、悪意ある UA Bot、検索エンジンを偽装した Bot、その他の既知の Automated Traffic が含まれます。

ただし、Bot そのものが悪意あるトラフィックというわけではありません。検索エンジン、Monitoring Service、パートナーサービスも、正常かつ必要な Bot Traffic を生み出すことがあります。そのため Bot Management の目的はすべての Bot を遮断することではなく、まずその種類と挙動を識別し、ビジネス上のニーズに応じて観察、遮断、ブロック、人間とボットの判別、精密なアクセス制御などの対策を取ることです。

この層では、判断材料も単一の HTTP Request から Client、Session、Behavior へと広がります。

Traffic、Request から Behavior へ：多層防御はどう機能するのか

三つの防御層を並べてみると、ByteShield の多層防御の全体的なロジックが見えてきます。

全体のロジックは次のように簡潔に表せます：Traffic → Request → Behavior

つまり、Network Layer でのトラフィック識別から、Application Layer の Request Analysis、さらにその先の Behavior Analysis へと段階的に広げていくということです。

多層防御とは、すべてのトラフィックを遮断することではない

多層防御の目的は、すべての Security Control に同じ遮断ロジックを適用させることではありません。

正常な User、正当な Crawler、パートナーサービス、Malicious Bot がウェブサイトのトラフィックに同時に存在することがあるため、各 Security Layer はそれぞれ最も識別に適した問題に対応すべきです。

ByteShield DDoS Protection は主に異常な Traffic、Packet、Connection に対応します。CC Defense はさらに HTTP Request、Access Frequency、Client Verification を分析します。Bot Management は Bot Type と Behavior に応じて異なる管理ポリシーを適用します。

Application や Business Layer に近づくほど、理解すべき情報はより細かくなります。

「トラフィックを吸収する」から「トラフィックを理解する」へ

大規模な Volumetric Attack がなくなったわけではありません。そのため Network Layer の DDoS Protection は、今もセキュリティアーキテクチャ全体の重要な基盤です。

しかし攻撃が Application Layer に入ると、現在何 Gbps を受けているかを知るだけでは不十分です。企業が観察すべきシグナルは、BPS、PPS、Connection から、RPS、URI、API Endpoint、Client、Session、Behavior へと広がります。

L3/L4 では Traffic を見て、L7 では Request を見る。より複雑な Automated Traffic では、さらに Behavior を理解する必要があります。

ByteShield：L3/L4 から L7 まで多層のセキュリティ防御を構築

企業ごとに Traffic Pattern、Application Architecture、API の使い方、ビジネスシナリオは異なり、必要となる Security Policy も変わってきます。

ByteShield は DDoS Protection、CC Defense、Bot Management を通じて、Network Traffic、HTTP Request から Automated Behavior まで、それぞれの層に応じた防御と管理の仕組みを構築し、Web、APP、API のビジネスがさまざまな種類の Attack Traffic から受けるサービスへの影響を軽減するお手伝いをします。

多層防御の核心は、耐えられる攻撃トラフィックを引き上げることだけではありません。より重要なのは、層ごとにトラフィックの識別能力を高め、さまざまな種類の異常を適切な Layer で発見し対処できるようにすることです。

よくある質問

なぜ単一の DDoS 防御機構だけでは不十分なのですか？

L3/L4 攻撃は大量の Packet、Connection、Reflection Traffic が中心ですが、L7 攻撃は HTTP Protocol に完全に準拠した Request である可能性があります。Network Layer から観察するだけでは、正常な形式の Login や API リクエストがビジネスリスクを引き起こしているかどうかを判断するのは困難です。そのため、各 Layer の機構がそれぞれ最も識別に適した問題に対応する必要があります。

DDoS Protection、CC Defense、Bot Management はそれぞれ何を担当しますか？

DDoS Protection は L3/L4 の異常な Traffic、Packet、Connection に対応し、主に BPS、PPS、SYN Rate、Concurrent Connections を観察します。CC Defense は L7 で HTTP Request、URI、API Endpoint、Access Frequency を分析します。Bot Management は Client、Session、Behavior から Automated Traffic を識別し、管理します。

Bot Management は検索エンジンやパートナーの Bot まで遮断してしまいませんか？

一律に遮断することはありません。Bot Management の目的は、まず Bot の種類と挙動を識別し、ビジネス上のニーズに応じて観察、遮断、ブロック、人間とボットの判別、精密なアクセス制御などの対策を取ることです。検索エンジン、Monitoring Service、パートナーサービスが生み出す正常な Bot Traffic は維持できます。

攻撃元が分散している場合、CC Defense はどう対処しますか？

攻撃元が分散している場合、IP Blocklist だけでは不十分なことがあります。CC Defense は Request Pattern と行動の特徴から異常を分析し、APP と API のシナリオではアルゴリズム署名で Request を検証します。さらにネットワーク全体の連携により、識別した CC Attack の特徴と防御ポリシーを同時に反映させます。

関連するご要望がありましたら、ByteShield のセキュリティ対策サービスをご覧いただくか、ByteShield チームにお問い合わせください。現在のアプリケーションアーキテクチャとビジネス要件に合わせて、最適なソリューションをご提案します。