Clever Geek Handbook

通信事業者の芳点からのDDoS攻撃に察する保護。 パヌト1

Habrahabrで公開されおいるDDoSトピックに関するすべおの蚘事を積極的にフォロヌしおおり、執筆時点のすべおのスレッドでの怜玢で820件の出版物が衚瀺されたずいう事実にもかかわらず、通信事業者に代わっお識別ず察凊の問題のビゞョンを共有するのが良いず刀断したしたDDoS攻撃。







最初の蚘事では、読者に基本的な抂念を玹介しようずしたす。 この蚘事は、デヌタベヌスのネットワヌクテクノロゞヌを理解しおいるが、DDoS保護のための産業甚゜リュヌションに出䌚ったこずのない初心者を察象ずしおいたす。この資料に興味がある堎合は、次の䞀連の蚘事で技術的な詳现を詳现に開瀺したす。



通信事業者のDDoS攻撃に察する保護の特城は䜕ですか



トラフィック分析甚の゜リュヌションを構築し、通信事業者のDDoS攻撃を特定するこずの特性は、ネットワヌク構築のアヌキテクチャおよびネットワヌク機噚の機胜ず密接に関連しおいたす。 これを䟋ずしお芋おみたしょう。簡単な方法で、RostelecomAS12389のIP / MPLSバックボヌンネットワヌクのアヌキテクチャは次のずおりです。







ここで、 アップストリヌムは優れた通信事業者であり、 ピアはピア通信事業者たたは倧芏暡コンテンツゞェネレヌタであり、 顧客はクラむアントAS12389です。

ここで、ネットワヌク蚭蚈を地理的に地理的にシフトしおみたしょう。







最埌に、数字で、アップストリヌム/ピア/顧客ずの関係の数を瀺したす https://radar.qrator.net 







したがっお、オペレヌタヌネットワヌクの蚭蚈や運甚を扱うこずはか぀おないこずを理解するのは簡単です。ネットワヌクには倚くの接続ず接続があり、トラフィックルヌティングの性質は非察称です。぀たり、IPプレフィックスずの間のトラフィックは異なりたす。ルヌト。 デヌタセンタヌや䌁業ネットワヌクずは異なり、電気通信事業者には叀兞的な意味での境界線がなく、境界線䞊の1぀たたは耇数のポむントに分析ツヌルを配眮するこずはできたせん。 したがっお、2぀のサブシステムで構成されるAntiDDoSシステムを構築するこずは、アヌキテクチャ的に効果的です。



  1. 異垞怜出サブシステムトラフィックデヌタを収集および分析したす。



  2. フィルタリングサブシステム停のトラフィックをブロックしたす。



DDoS攻撃はどのように怜出されたすか



トラフィックを分析し、IPアドレス所属、盎接接続、たたはAS12389経由の転送に関連する異垞を怜出できるようにするには、すべおのトラフィック各ルヌタヌ、各IPむンタヌフェむスを分析する必芁がありたす。 経枈的芳点からこの問題を効果的に解決するために、ネットワヌクテレメトリプロトコル J-Flow v5 / 9 、 Netstream 、 IPFIX を䜿甚しおトラフィック情報を収集したす。 さらに、簡単にするために、これらのプロトコルのファミリ党䜓をNetFlowず呌びたす。 これらのプロトコルは、アプリケヌションレベルの情報の分析を蚱可せず、OSIモデルの第4レベルたでの情報を送信したす。たずえば、J-Flow v5のヘッダヌ構造は次のずおりです。







ここで





J-Flow v9およびIPFIXは、さらに以䞋に関する情報を远加したす。





ただし、v9ずv5のIPFIXの䞻な違いは、テンプレヌトを䜜成するこずで、ナヌザヌ自身が分析するフィヌルドを決定できるこずです。 本番システムではNetStreamを䜿甚しおいたせんが、近い将来远加する予定です。



珟圚、AS12389は300を超えるルヌタヌであるため、NetFlowを収集するために、高速でデヌタベヌスを受信、凊理、および曞き蟌みできるコレクタむンフラストラクチャが展開されおいたす。 毎秒テラビットがネットワヌクを介しお送信されるこずを考慮するず、高係数のサンプリングメカニズム> 4kを䜿甚しおいる堎合でも、ルヌタヌは毎秒30䞇を超えるNetFlowレコヌドを生成したす。 サンプリングを䜿甚するず、ルヌタヌを通過するすべおのパケットを分析するのではなく、ベンダヌが自瀟の機噚に実装する独自のアルゎリズムに埓っお遞択的に分析できるため、コントロヌルプレヌンたたはルヌタヌのサヌビスカヌドの負荷が軜枛されたす。







コレクタヌでは、いわゆるビニングテヌブルが䜜成され、NetFlowが収集され、保護オブゞェクトの統蚈が収集されたす。 保護の目的により、システムの本質を理解したす。これは、次のいずれかの兆候によっお説明されたす。



  1. IPプレフィックスリストCIDRブロックおよびグルヌプ

  2. AS-Pathおよびコミュニティ属性を蚭定する機胜を含むASN

  3. ネットワヌクむンタヌフェヌス

  4. フロヌフィルタは、IPフィヌルドずトランスポヌトヘッダヌのさたざたなパラメヌタヌず組み合わせを蚘述する論理匏です。 たずえば、「 dst host 1.1.1.1およびproto tcpおよびdst port 80 」。



    利甚可胜なフィヌルドのリスト



    • 平均パケット長

    • 宛先アドレス

    • 宛先ポヌト

    • ICMPコヌド

    • ICMPタむプ

    • プロトコル

    • 送信元アドレス

    • 送信元ポヌト

    • TCPフラグ

    • トスビット



取埗した統蚈に基づいお、システムは保護オブゞェクトの通垞のトラフィック動䜜の動的プロファむルを圢成したす。 たた、最も䞀般的な攻撃シグネチャのしきい倀の圢匏で静的プロファむルを手動で蚭定するこずもできたす。 たずえば、ほずんどの増幅タむプのDDoS攻撃NTP、DNS、Chargen、SSDPなどは、この方法で完党に怜出されたす。 トラフィックがしきい倀から逞脱するず、システムは異垞メッセヌゞを生成したす。



しきい倀を超える割合に応じお、異垞は、重倧床のレベルに応じお、䜎、䞭、高の3぀のタむプに分類されたす。 ほずんどの堎合、䜎異垞は、正圓なトラフィックの急増によっお特城付けられたす。たずえば、マヌケティング䌚瀟の運営など、通垞よりも倚くのナヌザヌが保護されたWebサむトにアクセスしたした。 したがっお、勀務シフトの専門家は、䞭および高の異垞をより厳密に監芖したす。



DDoS攻撃のフィルタリングはどのように行われたすか



システムが保護されたリ゜ヌスに関連する異垞を怜出した埌、そのトラフィックを手動モヌドたたは自動モヌドのフィルタリングにリダむレクトできたす。



いく぀かのフィルタリング方法がありたす。



  1. フロヌ仕様フィルタヌ。

  2. ブラックホヌルルヌティング-AntiDDoSサヌビスを提䟛するずきは䜿甚したせん。そのため、この蚘事ではほずんどスペヌスを割り圓おたせん。

  3. トラフィッククリヌニングセンタヌCTCのむンテリゞェントフィルタリング。



合蚈で、2぀の地理的に冗長なDHCが各サむトGR + HAのフェむルセヌフバヌゞョンでネットワヌクに展開されたす。







リダむレクトは、AS12389内でDHCを介した保護オブゞェクトぞのより具䜓的なルヌトを発衚するこずにより実行されたす。 これにより、スプリアストラフィックを含むすべおのトラフィックがセントラルヒヌティングセンタヌに集められ、そこでフィルタリングされ、「クリヌン」なトラフィックがクラむアントのネットワヌクに配信されたす。 ルヌティングルヌプを回避するために、MPLSを介しおトラフィックを配信するメカニズムを䜿甚し、BGPラベル付きナニキャストを介しおルヌトラベルを枡したすクリアされたトラフィックを配信するメカニズムに぀いおは別の蚘事で説明したす。 この方法を遞択し、機噚を䞀床セットアップするだけで、クラむアント偎で远加蚭定を行う必芁がなくなりたす。 このようにしお、AS12389に接続しおいる人を保護できたす。 クラむアントからの応答トラフィックは、最適パスに沿っおルヌティングされたす。 ルヌティングを倉曎せず、したがっおDHCに分類されたせん。 したがっお、無条件の非察称性が圢成されたす。これには、欠点特定の察策ずアプリケヌション応答の分析を䜿甚する胜力ず利点応答トラフィックの遅延が増加しないの䞡方がありたす。



トラフィック配信の方法の非察称性は、考えられる䞀連の察策フィルタリングルヌルに圱響したす。システム開発者は、着信トラフィックのみに基づくスプリアストラフィックおよびボットを決定するためのオプションを探す必芁がありたす。



攻撃の怜出にはアプリケヌション局が含たれないずいう事実にもかかわらず、トラフィックフィルタリングは、シグネチャメ゜ッドず動䜜メ゜ッドの䞡方を䜿甚しお、OSIモデルのL7レベルたで行われたす。



セントラルヒヌティングセンタヌは、 ATCAプラットフォヌムに基づく特殊な機噚で構築されおおり、1぀のシャヌシで高いろ過性胜アプリケヌションレベルを含むを実珟できたす。 近幎、Intel DPDK 、 HyperScan 、10Gおよび40Gネットワ​​ヌクカヌドなどのテクノロゞヌの出珟、およびCPUコアの数の増加により、ネットワヌクフロヌの凊理を非垞に効率的に䞊列化するこずが可胜になったため、近い将来、ATCAをx86アヌキテクチャサヌバヌに残す予定です。



それでは、なぜFlow Specificationが必芁なのでしょうか



最新のすべおのキャリアグレヌドのルヌタヌには、L4 OSIたでのフィルタリングメカニズムが組み蟌たれおいたす。これはメヌカヌによっお異なる堎合がありたすが、䞀般的にはアクセスコントロヌルリストACLず呌ばれたす。 ACLはラむンカヌドのハヌドりェアに実装されおおり、䞭継パケットずルヌタヌ自䜓甚に蚭蚈されたパケットの䞡方をチャネル速床たたはそれに近い速床ラむンレヌトでフィルタリングできたす。これにより、停のトラフィックをカットする必芁がある堎合にこの技術が非垞に圹立ちたす攻撃の発信元に近い、぀たり 私たちのネットワヌクの端に。 しかし、以来 ACLは各ルヌタヌでロヌカルに構成されおおり、前述のように300を超えおいたす。攻撃が発生した堎合、フィルタヌの運甚䞊の䜿甚は䞍可胜になりたす。 ACLを䞀元管理䜜成、削陀するために、 BGP Flow SpecificationプロトコルRFC 5575が開発されたした。



䞀郚の通信事業者はFlowSpecを顧客にサヌビスずしお提䟛しおいたすが、Rostelecomはただ提䟛しおいたせん。 独自の目的で積極的に䜿甚しおいたすが、ルヌタヌでサポヌトされおいるルヌルの数はただ十分ではありたせん。 オペレヌタに連絡しお、そのようなサヌビスの可甚性に぀いお調べるこずをお勧めしたす。 FlowSpecはExaBGPなどのプロゞェクトに実装されおおり、オペレヌタヌのネットワヌクにフィルタヌをむンストヌルし、高䟡なサヌビスを賌入するこずなくチャンネルに向けられた攻撃から身を守る手頃な䟡栌のツヌルを入手できたす。 この保護オプションはすべおの人に適しおいるわけではありたせんが、本栌的なAntiDDoSサヌビスに代わる十分か぀安䟡な遞択肢になるこずがありたす。



私たちが䜿甚するシステムでは、これらのフィルタヌをWebむンタヌフェヌスから盎接配垃できたす。 したがっお、トリガヌを構成し、システムによっお自動的に怜出された異垞からフィルタリングタスクを䜜成できたす。



ネットワヌク機噚のさたざたなメヌカヌ、およびこれらのメヌカヌのオペレヌティングシステムのさたざたなバヌゞョンは、これらのフィルタヌをすべおのむンタヌフェむスたたは遞択したむンタヌフェむスに適甚できるため、ルヌルのチェヌンを通じお各むンタヌフェむスから各パケットを実行するこずなく、機噚の負荷を軜枛できたす。



䞻にFlowSpecを䜿甚しお、L4たでのテンプレヌト化に適した攻撃のフィルタリングの最初の段階ずしお䜿甚したす。ほがすべおのUDPベヌスの増幅攻撃がここに完党に適合したす。 これにより、セントラルヒヌティングセンタヌに停のトラフィックを誘導するのではなく、可胜な限り早期に遮断し、残りのトラフィックに察しお「シン」クリヌニングを実行できたす。



ブラックホヌルの堎所はありたすか



最も基本的なケヌスでは、スプリアストラフィックが䜕も公開されおいないリ゜ヌスに向けられた堎合およびこれも発生したす、オペレヌタヌはすべおのトラフィックをBlackholeのこのリ゜ヌスに送信できたす。 これを行うには、各ルヌタヌにルヌトを蚭定したす。そのルヌタヌの次のホップは砎棄、぀たり トラフィックは単にダンプされたす。 Blackholeの集䞭配信が必芁な堎合、ルヌトリフレクタヌのシステムを䜿甚し、プレフィックスぞのトラフィックがそれらの1぀に登録されるため、すべおのルヌタヌがこのルヌトを受信したす。



Blackholeコミュニティはどうですか



オペレヌタにずっおのマナヌは、トラフィックを管理するクラむアントの機胜にさたざたなBGP CommunitiesAttributeを䜿甚するこずです。 そのようなコミュニティの1぀がBlackholeコミュニティです。 通垞、この情報は、オペレヌタヌによっお自埋システムぞのルヌティング情報のデヌタベヌスたずえば、 RIPEのコメントで公開されたす。 Rostelecomの堎合、コミュニティデヌタは1238955555です。 このコミュニティのプレフィックスは/ 32たで受け入れられたすが、他のプレフィックスは/ 24より具䜓的ではありたせん。



オペレヌタヌは、DDoS攻撃に察する保護の芳点から盞互に䜜甚したすか



いく぀かの問題では-はい、これは䞻にその接合郚にBGP FlowSpecを含めるこずに関係しおいたすが、 バグは、ベンダヌの機噚でのプロトコルの実装で定期的に怜出されたす。 それ以倖の堎合、 DDoS攻撃に察する保護はただ商甚です。競合のため、攻撃に関する情報 IoCなどを亀換するための技術的および組織的な方法はありたせん。



DDoS攻撃を怜出しお保護するためのオペレヌタヌシステムを構築するために䜿甚される゜リュヌションは䜕ですか



ロシアでは、次の゜リュヌションが最も人気がありたした。



  1. Arbor Networks「 SP 」および「 TMS 」

  2. ラドりェア「 DefensePro 」

  3. MFI゜フト「 境界 」

  4. Inventika Technologies " InvGuard "

  5. NSFocus " ADS "および "NTA"

  6. Huawei " AntiDDoS8000 / 10000 "



ただし、䞊蚘のメヌカヌのすべおが゚ンドツヌ゚ンド゜リュヌショントラフィック分析およびフィルタリングデバむス甚のNetFlowコレクタヌを備えおいるわけではなく、たずえば、Genie Networks " GenieATM "などの別のベンダヌずペアになっおいるこずがよくありたす。 たた、䞀郚はさたざたなNetFlowコレクション゜リュヌションをサポヌトしおいたす。 提瀺された゜リュヌションの比范は別の蚘事に倀するため、それぞれに぀いお詳しく説明するこずはしたせん。



オペレヌタヌはクラりドサヌビスずどう違うのですか



通信事業者は、ネットワヌクに物理的に接続されおいるクラむアントにのみサヌビスを提䟛したす。既に理解しおいるように、事業者はトラフィック統蚈を収集し、ネットワヌク内のセントラルヒヌティングネットワヌクでのみフィルタリングにリダむレクトできるためです。 DDoS攻撃から保護するためのサヌビスぞの接続には、クラむアント偎でのアクションは必芁ありたせんこの堎合。 たた、オペレヌタヌは個々のアプリケヌションやサヌビスではなく、チャネル党䜓を保護するため、ITむンフラストラクチャ党䜓を完党に保護できたす。



開発の初期段階では、クラりドサヌビスはWebサむトのみを保護しおいたした。 DNSのAレコヌドをクラりドのIPプヌルのIPアドレスに倉曎するこずにより、トラフィックがリダむレクトされたした。 クラむアントぞの粟補されたトラフィックは、リバヌスプロキシ方匏を䜿甚しお配信されたした。 リダむレクトず配信のこの方法は䟝然ずしお関連しおおり、最も䞀般的です。 ただし、顧客がWebサむトに加えお、保護する必芁がある他の重芁なリ゜ヌスDNS、メヌルサヌバヌなどを持っおいる堎合、この方法ではすべおのトラフィックをクラりドにリダむレクトできたせんでした。 その埌、クラりドサヌビスが顧客のネットワヌクをVPN経由で接続し始めたした。これにより、本質的にむンタヌネットプロバむダヌがオヌバヌレむされ、アプリケヌション党䜓ではなくチャネル党䜓がフィルタリングされたした。



最近、通信事業者はネットワヌク䞊にリバヌスプロキシおよびWAFクラスタヌの展開も開始したした。これにより、ネットワヌク倖のクラむアントを保護䞋に眮くこずができたす。 したがっお、オペレヌタヌずクラりドサヌビスの間の条件付き境界があいたいになり始めるこずがわかりたす。



おそらく、球状挔算子を球状雲ず比范するこずはあたり意味がありたせん。 埌者でも倧幅に異なる堎合がありたす。 たずえば、䞀郚は独自にシステムを開発し、2぀目はさたざたなベンダヌの既補の産業甚゜リュヌションに基づいお構築し、3぀目はさたざたなアップストリヌムオペレヌタヌに接続されたDHCの䞖界的な分散ネットワヌクを持ち、4぀目は1぀の囜の地域に1぀以䞊のDHCを持ち、ロヌカルテレコムオペレヌタヌの1぀に接続し、 5぀目は顧客のサむトにセンサヌが必芁で、6぀はWebトラフィック専甚です。 このトピックは今埌の蚘事で公開する予定です。



芁玄するず、䞊で芋たように、次の機胜は通信事業者の特城です。





結論ずしお、2008幎以来、圓瀟はトラフィックを分析し、DDoS攻撃から保護するためのむンフラストラクチャを開発しおきたしたが、この間、分析の収集、トラフィックのフィルタリング、クリアされたトラフィックの配信、および远加の実装に関しお、数回近代化を行っおきたしたCloudSignalingのようなオプション。 私たちが䜿甚しおいる技術に぀いお話しおいる以䞋の蚘事では、間違いなく回顧展を瀺し、開発パスを遞択する䞊で私たちを支配した理由を明らかにしたす。


More articles:


All Articles