Anti-DDoS Voxility:ピッツェリア戦争が教えてくれたこと

ピザ業界のような一見穏やかな業界で、どのようなドラマが展開されるか想像することさえできません。 そのうちの1人は偶然クラウドプロバイダーとして参加しました。2013年12月、 Cloud4Yの顧客の1つであり、モスクワおよびモスクワ地域で最大のピザ配達ネットワークであるPizza Empireは、他のプレイヤーがすでに存在する新しい地域への集中的な拡大を開始しました。





ピザにはダークサイドがあります



すべてがうまくいくだろうが、競合他社のファーストフードサービスの分野での帝国の価格政策は捨てられた。 戦争はあらゆる面で始まり、すぐにDDoS攻撃が使用されるようになりました。



開始する



エンパイアオブピザは、印刷物からオンライン広告キャンペーンまで、モスクワ近郊の大規模なネットワークで積極的な広告キャンペーンを開始しました。 競合他社がこの活動に気付いたときに問題が始まりました-他のピッツェリアチェーン-攻撃に行きました。



最初の攻撃







2013年12月24日、ピッツェリアチェーンの戦争はハイテク分野に切り替わりました。 クライアントのすべてのインターネットリソースに対するDDoS攻撃が開始されました。



「帝国」に対する攻撃の最初の段階では、他のアドレス範囲に移動することにより、攻撃のアクションからインターネットリソースを削除しました。 攻撃者はクライアントの場所を監視し、ボットネットはすぐに再構成されたため、このようなポリシーはそれほど長く機能しませんでした。 しばらくしてから攻撃は再びクライアントに移動し、サービスをブロックしました。 これは2013年12月31日まで続き、その後、Cloud4Yのすべてのアドレス範囲で大規模な攻撃が開始されました。



大量攻撃開始



2014年1月1日、クライアントが存在するCloud4Yのアドレス範囲全体に対する大規模なDDoS攻撃が開始されました。 攻撃の強度は、他のオペレーターとのすべての外部ピアリングを詰まらせ、すべての外部通信チャネルの上限帯域幅に達しました。



緊急の問題として、外部ルーターのグループ化に組み込まれたDDoS保護技術のフラッドセンサーが再構成されましたが、この状況では十分な利点がありませんでした。 ルーター自体は外部ルーティングボリュームに正常に耐えましたが、高レベルの通信事業者でも問題が発生しました(一部の外部ピアは定期的にダウンし、そのようなデータストリームのスイッチングとルーティングに対処できませんでした)。



外部通信チャネルを何らかの形で緩和する試みで、外部オペレータにUDPフローを制限して、他のクライアントのサービスに無料の帯域幅を割り当てるよう依頼しました。

クライアントのインターネットサービスは、サービスを提供する管理者による試みにもかかわらず、機能していませんでした。 サーバーは起動後数秒後に制御を失いました。 ファイアウォールのルールと制限は役に立ちませんでした。 他のCloud4Yクライアントの作業に対する攻撃の影響を排除するために、ピッツェリアネットワークの仮想リソースを別のハイパーバイザーに移動しました。 ただし、Cloud4Yが提供するSLA攻撃の強度により、サービスは多くの被害を受けました。







インシデントの詳細については、当社のWebサイトをご覧ください (SLAモニターはメインページで入手できます)。 このような激しいDDoS攻撃にもかかわらず、外部クライアントはCloud4Yクラウドサービスを利用できました。



「石膏は取り除かれ、クライアントは去る」



インターネットリソースの運用を再開するためのソリューションを探しているクライアントは、他のクラウドオペレーターの施設でリソースを複製し始めました。 DNSを新しい場所に移した後、他のクラウドオペレーター(名前は付けません)はほとんどすぐにアクセスできなくなりました(私たちも好奇心だけでなく状況を監視したため)。







Runetの広がりをさまよった後、ピッツェリアネットワークのインターネットリソースは、ヨーロッパのデータセンター間を常に移動し、攻撃の結果を示す画像が繰り返されました。 クライアントが切り替えた最後のデータセンターはヨーロッパ(オランダ、ドイツ、チェコ共和国)にありました。 この記事の執筆時点では、クライアントのオンラインリソースはバージン諸島のデータセンターにありました。



他のデータセンターへの切り替えにより、Cloud4Yに対する攻撃の強度は低下したが、クライアントの以前の場所のアドレス指定エリアへの予防的な「がらくた」がさらに数週間続いたため、このクライアントを移動した後、マネージャーはそれほど動揺しなかったと思います。



おわりに



この分布の下で、Cloud4Y外部ピアリングのDDoS保護を最大化することが決定されました。その結果、Voxility(DDoSを含むあらゆるタイプの攻撃に対する保護の主要なオペレーター)に直接専用のチャネルができました。



Cloud4Yは、最後の攻撃から1年以内にサービスとしてDDoSから最大限の保護を受けたため、顧客活動に関連する一時的なワークロードと、小規模で短いDDoS攻撃による小さなワークロードが発生しました。 しかし、彼らがこの非常にピッツェリアを叩いていたパワー攻撃は、もはや起こりませんでした。 どうする



テスト



実行中のVoxility DDoS攻撃に対する保護をテストするために、Cloud4Yはそれ自体を攻撃することを決定しました。そのため、個別のサブネット、個別の仮想化ツール、個別のインターネットリソース(実験ウサギ)が作成され、最も厳しいテストを実施することが計画されていました。







準備する



インターネットを介してテストを実施するために、このレベルのDDoS攻撃を実装でき、2013年後半から2014年初めにかけて発生した注文の実行者が見つかりました。 そのようなパフォーマーは常に匿名で作業し、彼らと直接電話で連絡することはありませんでしたが、彼らの計画を実行するためには、何かがうまくいかなかった場合に攻撃を止めることができるように彼らは常に私たちと連絡をとる必要がありました そのようなアーティストが見つかりました。



外部ルーターのグループ化は以前に再構成され、短いBGPプレフィックスを持つ攻撃されたサブネットはVoxilityを介してルーティングされました。 Voxilityが実装するセキュリティテクノロジーのアーキテクチャは次のとおりです。







  1. 保護されたリソースの訪問者はまずVoxility保護クラウドに入ります。デフォルトでは、すべてのトラフィックは最初は「分析」モードでのみ許可されます。
  2. 危険を検出した場合、Voxilityクラウドは保護モードに切り替わり、トラフィックがAnalyzer Clean Rulesに準拠している場合にのみサービスへのアクセスが許可されます。
  3. 必要に応じて、サービスへのトラフィックから悪意のあるコンポーネントが除去され、処理のために保護されたサービスに送られます。
  4. ターミナルサービスによって処理されたトラフィックは、それを要求した消費者に返されます。


テストは、次の2つの段階で実行されるように計画されました。



  1. 30分間、毎秒300メガビットの強度の実験ウサギのテスト攻撃(Voxilityの反応を決定するため)。
  2. 2時間、毎秒15 Gbpsの強度の主な攻撃。


テストプロセスでは、この計画を第3段階で補完しました。これについては後で説明します。 テストを開始する前に、独立したテストを実行しました。 独自の手段でリソースのDDoS攻撃を開始しました。 攻撃を受けたウサギはモスクワのデータセンターにあり、オランダのデータセンターから攻撃を開始しました。 攻撃の技術は公開しませんが、Voxilityを介してウサギを無事に埋めることができたと言えます。また、攻撃はVoxilityクラウドに気付かれず、ウサギは技術的な攻撃によって正常にブロックされました。 すぐに予約を行います-これはフラッド攻撃ではなく、その目的はすべての外部チャネルをスコアリングすることでした。 したがって、複雑なタイプの攻撃を検出する際にVoxilityの技術的な利点のみを経験しました。 残念ながら、Voxilityは複雑な攻撃を見つけることができず、NGINXに基づくキャッシュシステムで武装した実験用のウサギは長い間首尾よく圧倒され、Voxilityセンサーは侵入を検出して中和しませんでした。







テスト中



セルフテストを開始して、次のことをかなり危険にさらしました。

1. Voxility保護は対処できませんでした。

2.攻撃者との接触を失う可能性があり、攻撃を止めることはできません(攻撃者との通信は、ICQを介してのみ行われました)。

3. Voxilityからピアリングした場合、すべてのリソースに対して実際のDDoS攻撃を受ける可能性があり、その結果は2013年から2014年の新年新年攻撃に似ている可能性があります。



第一段階


わずかなパワー(約300 Mbit)の攻撃は最初Voxilityによってスキップされ、最初の10分以内に実験ウサギがエラー502を生成しました。10分後、Voxilityはテスト攻撃を検出し、通信チャネルの保護モードに入りました。 実験ウサギが生き返った、サービスの仕事が復元されました。 Voxilityは、過去のDDoS攻撃とその反映について報告してくれました。











第二段階


20分間のトライアル攻撃の後、攻撃強度を15ギガビットに上げるよう攻撃者に依頼しました。 コミュニケーションチャンネルとVoxilityの第1および第2段階の反応は、以下のグラフに反映されています。







Voxilityは、最初の試行を45回超えたという事実にもかかわらず、攻撃の第2波をうまく撃退しました。 攻撃の第2波の強さは攻撃の強さに対応しており、モスクワのピッツェリアのネットワークのインターネットリソースで正月休みのためにすくい上げました。

実験ウサギのサービスは引き続き動作し、Voxilityは攻撃されたサブネット(ICMP)の一部のサービスを完全に閉じました。



第三段階


Voxility保護が機能すること、および外部ピアリングに問題がないことを確認した後、攻撃者にできる限りすべてを表示するか、または非常に多くなることが判明したことを確認しました(3番目の波がチャートに表示されます):







攻撃の強度は15ギガビットから50-120ギガビットに引き上げられ、SYNトラフィックの一部を見ることができるように、Voxilityクラウドはしばらく学習する時間がなく、悪意のあるトラフィックの一部がまだチャネルに到達し始めましたが、いずれにしても、テストされたチャネルの半分は-有用なクライアントトラフィックの通過に利用可能なままでした。 監視システムでは、攻撃は次のように見えました。







まとめ



テスト結果に基づいて、DDoSおよびその他の種類の攻撃に対する普遍的かつ理想的な保護はないという結論に達しましたが、サービスとして使用するDDoS攻撃に対するVoxility保護は機能し、最も厳しい条件でもクライアントサービスを提供することができます。



ご清聴ありがとうございました。ご質問にお答えさせていただきます。



戦争は戦争であり、ホスティングは予定通りです!




All Articles