DDoS攻撃と電子商取引：高度なセキュリティアプローチ

さまざまな企業によって発行されたDDoS攻撃に対する保護に関するマーケティング資料では、同じ計画のエラーが繰り返し発見されています。 つまり、誰かのレポートから取られた、たとえば400 Gbit / sの量の記録された攻撃に関するデータは、すべてが悪く、何かを緊急に行う必要があると結論付けられますが、同時に、提供されるサービスの特性は、フィルタリングされた攻撃の量の上限を示します10 Gb / sで そして、そのような矛盾は頻繁に発生します。



これは、サービス自体を作成する専門家が、そのような強力な攻撃が実際に存在するとはまったく信じていないために発生します。 これらの専門家自身も、彼らが知っている誰もそのような攻撃に直面しなかったからです。 したがって、eコマースに関連する質問が発生します。現在どの脅威が実際に関連しており、どの脅威はそうではないのでしょうか。 リスクを評価するには？ これらすべてとそれ以上のことは、 Bitrix Summer FestカンファレンスでのArtyom Gavrichenkovのレポートで説明されています。

攻撃の分類

最初に、どんな種類の攻撃について話しましょう。 分類の基準として、攻撃の対象、つまり、まったく無効になっているものを取り上げます。 この場合、OSIモデルに従ってさまざまなレベルで実行される4つの主要な攻撃クラスを区別できます。



最初のクラス（L2） -チャネルの「目詰まり」。 これらは、チャネル容量の枯渇により外部ネットワークへのアクセスを奪うことを目的とした攻撃です。 どうでもいいです 原則として、「何でも」-増幅タイプの大規模な「トラフィックの観点から」攻撃がこの目的に使用されます（NTP-、DNS-、RIP- ...増幅は任意であり、リストすることは意味がありません）。 一般に、ICMPフラッドなど、すべての種類のフラッドはこのクラスの攻撃に属します。主なタスクは、たとえば1ギガビット/秒のチャネルに少なくとも1.1ギガビット/秒を満たすことです。 これでアクセスを終了できます。



2番目のクラス（L3）は、ネットワークインフラストラクチャの機能の違反です。 このクラスには、とりわけ、ネットワークアナウンスメント（ハイジャック）を伴うBGPプロトコルのフレームワーク内でルーティングの問題を引き起こす攻撃、または中継ネットワーク機器で問題を引き起こす攻撃（接続追跡テーブルのオーバーフローなど）が含まれます。 このクラスの攻撃は非常に多様です。



3番目のクラス（L4）は、TCPスタックの弱点、つまりトランスポートレベルでの攻撃の悪用です。 HTTPおよび他の多くのプロトコルの基礎となるこのトランスポートプロトコルは、非常に複雑です。 たとえば、開いている接続の大きなテーブルを使用します。各テーブルは、実際にはステートマシンです。 そして、このマシンに対する攻撃は、DDoS攻撃の3番目のクラスを構成しています。 SYN Floodタイプ攻撃は、前の2つのレベルで損傷を引き起こさず、サーバー自体に到達し、その結果、TCPスタックに対するアプリオリ攻撃である場合、3番目のクラスに起因する可能性もあります。 また、これには、多数の接続のオープン（TCP接続フラッド）が含まれ、プロトコルテーブルのオーバーフローにつながります。 原則として、3番目のクラスには、 SlowLorisやSlow POSTなどのツールの使用も含まれます。



4年生（L7）-Webアプリケーションの劣化。 これには、一般的なGET / POST / HTTP Floodから、サーバーがリソースを使い果たすまでデータベース、メモリ、またはディスクから特定の情報を繰り返し検索および取得することを目的とした攻撃に至る、あらゆる種類の「カスタム」攻撃が含まれます。



攻撃をギガビットで評価することは、主に最低レベル（L2）で意味があることに注意してください。 たとえば、すべての製品で高度な検索を使用するMySQLを無効にするには、多くのギガビットも心も必要ありません。 5000個のボットから積極的に検索を要求してページを更新し、場合によっては同じもの（被害者のサーバーのキャッシュ設定に応じて）を更新するだけで十分です。 このような攻撃では、多くの人が問題を抱えています。 50,000個のボットの攻撃中に誰かが「沈み」、最も安定したシステムは最大100,000個のボットの攻撃に耐えます。 昨年同時期に、同時攻撃ボットの最大登録数は419,000に達しました。

攻撃からの保護

上記の各レベルで対比できるものを見てみましょう。



L2 別のスクラップに加えて、スクラップに対する受容はありません。 攻撃帯域が100ギガビット/秒を超える場合、これらのギガビットは、たとえばプロバイダーまたはデータセンターの側などのどこかで処理する必要があり、問題は常に「ラストマイル」にあります。 BGP Flow Specテクノロジーを使用すると、パケットシグネチャによって攻撃の一部をフィルタリングできます。たとえば、ソースポートによって増幅を簡単に遮断できます。 ただし、この方法は非常に高価であり、すべてに対して保護することはできません。



L3 L3では、ネットワークインフラストラクチャだけでなく、ネットワークインフラストラクチャを分析する必要があります。 典型的な例-2008年、パキスタンは独自の誤りにより、BGPハイジャックを使用してYouTubeプレフィックスを傍受しました。 つまり、このビデオホスティングのトラフィックの大部分はパキスタンにリダイレクトされました。 残念ながら、そのような不幸を自動的に処理することは不可能であり、すべてを手動で行う必要があります。 しかし、戦いが始まる前に、この問題（プレフィックスの盗難）が発生したことを判断する必要があります。 これが発生した場合は、ネットワークオペレーター、データセンターの管理者、ホスティング事業者などに連絡する必要があります。 問題の解決に役立ちます。 しかし、これにはネットワークインフラストラクチャの高度な分析が必要です。なぜなら、ハイジャックの兆候は、一般的な場合、ある時点からインターネット上でのこのネットワークのアナウンスが「非定型」であり、以前とは異なるためですその前に。 したがって、タイムリーに検出するには、少なくともアナウンスの履歴が必要です。



独自の自律システム（AS）がない場合、このレベルでの戦闘攻撃はデータセンター（またはプロバイダー）の義務であると見なすことができます。 ただし、通常、1つまたは別のデータセンターがこの問題にどの程度真剣に取り組んでいるかを事前に言うことはできません。



L4 第4レベルの攻撃から保護するには、TCPクライアントの動作、サーバー上のTCPパケット、およびヒューリスティック分析を分析する必要があります。



L7 L7では、行動、相関分析、監視を行う必要があります。 分析と監視のためのツールがなければ、同じNginxを使用して攻撃を撃退することは不可能であり、攻撃との戦いはいずれにせよ手作業に変わります。

リスク評価

そこで、着信HTTPリクエストをどこで受け入れて処理しますか。

• 購入またはリースされた物理サーバー
• クラウドホスティング
• CDN

リスクを評価するには、Probability＆Impact Matrixなどの便利なツールを使用できます。







横軸には、特定のイベントの結果の重大度がプロットされ、縦軸にはその確率がプロットされます。 この場合の白いフレームは、DDoS攻撃のリスクの現在のレベルを示しています。



攻撃の確率を決定するものは何ですか？ まず第一に、攻撃は競争の手段です。 市場セグメントが多少落ち着いている場合、ほとんどの場合、長時間攻撃はありません。 しかし、競争が激化する場合は、保護の準備をする必要があり、白いフレームを軸に沿って移動する必要があります。



しかし、DDoS攻撃で最悪なのは影響です。 攻撃があなたのホスティング事業者にあるとしましょう。 現時点であなたがアンチDDoSソリューションのプロバイダーに頼ったとしても、彼が助けることができるという事実ではありません。 問題は、Webサーバーからデータベース、その他の重要なコンポーネントまで、「すべて」が置かれているIPアドレスが攻撃者に既に知られていることです。 また、DNSで他のアドレスを指定しても、一定の確率でこれは何の役割も果たさず、攻撃は直接続行されます。 最良の場合、このホスティングから移動する必要があります。 また、この場合、営業時間中に準備が整っていないサイトに移動し、サーバーが横たわっているよりも、ITプロジェクトにとって悪いことを思い付くことが難しいため、問題は「非常に深刻」と評価できます。 まあ、おそらく、 バーミンのパッチ -はい、それは間違いなく悪いです:)



同じホスティングでIPを変更するだけでは不十分なのはなぜですか？ 新しいアドレスは同じ自律システム（AS）からのものだからです。 今日、攻撃者はすでに自律システムのプレフィックスのリストを見ることができます。 したがって、新しいアドレスであなたを見つけることは難しくありません;自律システムのすべてのアドレスを攻撃するのに十分です。



特定のネットワークリソースが、1つまたは別のネットワークレベルの攻撃の影響を受けやすい程度を評価してみましょう。







ホスティング ほとんどのホスティング会社は、トラフィックが100 Gb / sを大幅に超える強力な攻撃を除外できません。 サーバーへの最後のマイルを含みます。 したがって、来る洪水のすべて、またはほとんどすべてを独立して処理する必要があります。 そして、第7レベルでは、これがサーバーであり問題であるため、分析を自分で行う必要があります。



L3では、ほとんどの場合、リソースのためにホスティング全体からプレフィックスを盗むことはないため、危険性はそれほど高くありません。 これは、攻撃者にとって非常に時間と費用がかかります。 これは実行できますが、非常に正当な理由が必要です。 もちろん、特にホスティングネットワークインフラストラクチャにパフォーマンスの問題がある場合は、すべてのライフルールに例外があります。



重要な点があります。多くのベンダーは、ラックに設置され、サーバーにつながるアップリンクとダウンリンクを含む高価な保護機器を提供しています。 問題は次のとおりです。使用している機器を含め、ネットワークはラストマイルよりも安定していません。 いずれにせよ、ラッシュアワーの間にプロセッサの負荷が100％に近くならないように、パフォーマンスに余裕を持たせてください。 そうしないと、小さなジャンプが失敗する可能性があります。 攻撃者が経験が浅く、自分で対処できる場合は、リクエストの調査、アウトバーンのスクリプトの作成、fail2banの構成などに安全性の余裕が必要です。



また、保護されていないリソースに物理的に配置されている場合は、最大30％の確率でDNSを変更しても役に立たないことに注意してください。 これは、最近のアメリカの金融会社に対する攻撃の経験からも明らかです。 そのため、非常に自信を持って、セキュリティで保護されていないホスティングから迅速に移行する必要があると言えます。



クラウド 。 クラウドにはエニーキャストネットワークが必要です。つまり、同じプレフィックスが世界中の多くの場所からアナウンスされる必要があります。 1か所では数百ギガビットの攻撃を消化することができず、1年でテラビット攻撃が予想されるためです。 分散構造のため、チャネルに対する攻撃のリスクは大幅に削減されます。 しかし、エニーキャストネットワークでも、毎秒400〜500ギガビットの攻撃が大量に発生します。 これに備える必要がありますが、誰もがそうするわけではありません。



攻撃者がインフラストラクチャを悪用できないように、ネットワークを分散する必要があります。 データベースにアクセスする際の問題の悪用からリソースを節約することはできないため、生産性のマージンが必要です（2回が望ましい）。



そして最後に、最も「面白い」ことは、クラウドが多くのユーザートラフィックを消化できることですが、それに対して費用を支払う必要があります。 過去1か月でアカウントが数万ドルに達すると、携帯電話の切断が開始されるか、破産により単純にオフになります。 そのため、クラウドにとどまることで、攻撃に対する保護の問題を完全に解決できるわけではありません。 それはあなたが保護される前に回復力を高めるだけです。



Cdn 。 CDNは大量のトラフィックを処理するように設計されているため、「静的」（画像、CSSなど）に簡単に対処できます。 チャネル容量を使用すると、すべてがクラウドと同じになります。 しかし、インフラストラクチャレベルでははるかに興味深いものです。 CDNには、すべてのリソースサービスが関連付けられているDNSサーバーが常にあります。 クラウドの場合、ネットワークインフラストラクチャを単純なエニーキャストの背後に隠すことができる場合、99.9％のCDNで、ユーザーをCDN上の最も近いポイントにリダイレクトするDNSルーターが表示されます。 さらに、CDNには、Anycastおよびそのネットワークからポイントが取り出され、ユーザーに近い外部ネットワークに配置されます。 したがって、デフォルトでは保護されません。 それらは単に保護することは不可能です。 ここでは、CDNのDNSがどれだけ安全であるか、ネットワークから攻撃されたノードを緊急シャットダウンする準備がどの程度できるかにかかっています。 しかし、これは一般的ではありません。 地域ごとにユーザーを分散させるDNSサーバーは、保護され、安定し、考え抜かれなければなりません。

一般的なネットワークアーキテクチャのヒント

• エニーキャストアドレスは非常に便利です。 そして最も重要なことは、それをレンタルすることができます。 エニーキャストルーターを使用したバランシングと冗長性は、DNSバランシングよりもはるかに信頼性があります。
• IPv4が終了していることに注意してください。現在、大規模な組織の場合は、このアドレススペースの最後の部分を取得できます。 将来的にはIPv6のみを取得し、このスペースには多くのユーザーがいないため、これを使用する必要があります。
• 物理サーバーからアプリケーションを切り離すことをお勧めします。 「Docker」という言葉は言語を要求しますが、ここでは特定のテクノロジーに執着したくありません。 アプリケーションをどこかでホストする場合、ドキュメント、インストールスクリプトのセットを用意し、展開と構成を自動化します。一般に、同じデータベースを使用して同じアプリケーションを別のサイトのサーバーに展開する準備を整えます。 なぜなら、問題はあなただけでなく、あなたとは無関係に、あなたが受け入れられている人々からも始まるからです。 これはかなり一般的な状況です。

現在まで、脅威の平均レベルは、単独で対処することが非常に困難なレベルに達しました。 攻撃者が攻撃を組織することは、被害者が防御するよりもはるかに簡単です。 そして、2日間休眠した後、システム管理者は絶対に攻撃者に対抗できなくなります。 そのため、1C-Bitrixクライアント向けの新しいサービスを開始しました。1年に10日間無料でご利用いただけます。 攻撃を受けているのであって、攻撃を受けているのではありません-関係ありません。 問題が発生した場合は、サイトのコントロールパネルにある最新バージョンの「1C-Bitrix：Site Management」に大切なボタンがあります。クリックしてください。恥ずかしがらないでください。