攻撃を受けてDDoS中和サービスに接続するのが遅すぎる理由

「前に、考えなければならなかった 。 」 このロシア語の格言は、人生の非常に多くの状況に適用できますが、これらの言葉は、サービス拒否攻撃からネットワークリソースを保護する上で二重に当てはまります。



インターネット上のどこかに人気のある競争力のあるサービスを作成する場合は、事前の計画が非常に重要です。攻撃者だけでなく、競合他社もそれに注意を払うことができます。 最終的に、予期しない大量のユーザーの流入は、本質的に分散攻撃と変わりません。



事前に防御に参加しなかった場合、このトピックに戻る必要がある条件は完全に最適ではない可能性があります。 読者にいくつかの重要なポイントを紹介することにしました-攻撃を受けており、システムに接続してサービス拒否攻撃を無効化しようとするサービスが直面する困難。



叙情的な余談：他の大陸の熱帯の国に休暇をとる場合、一般に受け入れられている旅行保険に加えて、最も危険で一般的な病気に対する予防接種の問題に対処することが役立ちます。



はい、長袖を着用して靴下でズボンを巻くと、蚊に刺される可能性は低くなります。 極端な場合、もちろん、彼らはあなたを救います。 しかし、このプロセスは遅れる可能性があります。あなたは多くの神​​経を使い、そしておそらく、医療専門家や薬のための資金をその場と帰国の両方で使うでしょう。 しかし、あなたは危険な病気に対するワクチンを取得し、保険がすべてのケースをカバーすることを確認する必要がありました。

攻撃前にトラフィックをフィルタリングするネットワークに接続する利点は何ですか？

最初の最も重要なことは、ユーザーの行動に関する知識です。 ターゲットリソースのトラフィックを監視してストレスをかけることで、リソースのユーザーの通常の動作と、リソースのトラフィック統計がどのようなものであるかを十分に認識しています。 攻撃を受けると、サービスの段階的（または高速、すべて攻撃者に依存）の劣化が発生し、その結果、リソースの通常のユーザーの動作が大幅に変化します。 場合によっては、正当なユーザーのアクションが攻撃に似始め、その結果を悪化させます。たとえば、ユーザーがブラウザーで目的のページを取得するためにユーザーが同じページを周期的に更新する場合です。



攻撃を受けているサービスの劣化が強いほど、正当なユーザーと悪意のあるボットを区別することが難しくなります。 通常の実証済みの正当な動作を使用した攻撃を見越してユーザーの行動を見たことがない場合、実際のユーザーとガベージリクエストをサーバーに送信する攻撃者ボットを区別することができる兆候によって事前にわかりません。 さらに、通常のサービスワークフローに伴うトラフィックの量もわかります。



攻撃の開始時にネットワークまたはフィルタリング機器がその中和に含まれていなかった場合、自動化および学習モデルの学習プロセスで、「ページの更新」をクリックするすべてのユーザーは、それぞれ攻撃トラフィックとほとんど区別できず、ブロックの可能性は高くなります。 リソースのユーザーの以前の動作を知っていれば、そのような状況の発生からユーザーと自分を保護できます。



同様に、通常の状況でのトラフィック量とトラフィック統計では、攻撃時にそのような情報がない場合、実際のユーザーがブロックされる可能性があるため、攻撃を無効化した後にトラフィックが正常に戻ったかどうかを確実に言うことは非常に困難です攻撃を受けているサービスの低下中に、中央値とわずかに異なる動作をしているだけです。



もちろん、このような問題は常に見つかるとは限りませんが、一部の攻撃シナリオでは特に深刻になります。 攻撃するボットの複雑さと攻撃者のcさによって、サービスのルートへの攻撃は本当に不快になる可能性があります-この場合、サービスが低下すると、ボットの動作は、単に「開くものがない」正当なユーザーの動作とほとんど区別できません。 別のタイプの攻撃の場合、原則として、データフローの点で正当な動作と悪意のある動作に大きな違いが残ります。



ありふれた日常の状況を想像してください-水道管の突破口、洪水。 準備ができていなかった、手元にプラグがなかった、パイプのシャットオフタップなどがあった、最悪のシナリオ。 すぐに穴を閉じて流れを止めることができますが、家具や子供のおもちゃはすでにアパート全体に浮かんでおり、ゲストはドアをノックしています。 それらを手放してもらえますか？ ほとんどない。

攻撃を受けて接続する場合の本当の短所と起こりうる結果は何ですか？

「病気から健康へ」とは、DDoSを無効にすることです。 そして奇妙なことに、しかし、プロの従業員と世界中の何千人もの消費者がいる市場の長い間でさえ、攻撃の開始前にDDoSを中和することを常に考えているわけではありません。 観客に適切な情報を提供することでこの状況を変えたいと思いますが、幻想は作りません-雷が打つまで、男は自分自身を交差させません。



攻撃を受けているリソースが対処しなければならない主な問題と、分散攻撃を無効にするサービスとしての問題を見てみましょう。

攻撃を受けているときにフィルタリングシステムに接続するサービスの場合、最初に自信を持って言えることは、ユーザーが部分的または完全にアクセスできない可能性が非常に高いということです。



2番目-攻撃を受けている場合、攻撃者はドメイン名だけでなくIPアドレスも知っている可能性が高いです。 また、通常、攻撃されたリソースのIPアドレスはホストに属しているため、ホストも既知であると事前に考えています。 つまり、攻撃者は攻撃ベクトルを変更するのに十分な情報を持っています。



別のホスティングプロバイダーにすばやく移動する（攻撃ではない可能性があります）か、IPトランジットプロバイダーを変更する（攻撃者の副次的な被害者である可能性があります）には、時間がかかります



もちろん、誤検知を解決することだけが困難ではありません。 攻撃下で接続しても、部分的または完全なアクセス不能の問題が解消されるわけではありません。また、攻撃がすでに開始され、既に何らかの害を引き起こしている場合、リソースを保護システムに接続することに加えて、「損傷制御」、つまり消費者と顧客の側の攻撃の結果に対処する必要があります



攻撃が「うまく行き」、重大な損害を引き起こしたことが起こります。 文字通り、これは次を意味します-通信チャネルをブロックすることに加えて、クラウドトラフィックフィルタリングプロバイダーとの接続を何らかの方法で整理する必要がありますが、専用チャネル、境界ルーターまたはバランサーは「死ぬ」ことができます（サービスを拒否）。 他のインフラストラクチャコンポーネントも悪い場合があります。たとえば、デリケートなデバイスであり、分散型サービス拒否攻撃を好まないファイアウォール（ファイアウォール）は、多くの場合、外界からの切断を調べます。 ファイアウォールの通常の動作を停止すると、ネットワーク境界に穴が開く恐れがあります。 はい、これは故障した機器を再起動することで処理されますが、それに到達し、一貫した状態に戻るまで待つ必要があります。 この間ずっと、トラフィックはフィルタリングなしで通過します。



アプリケーション層（L7）への攻撃について言えば、すべてがチャネルで問題なく、接続性はありますが、Webアプリケーションはまだ病気であり、落ち込んでおり、たとえばベースから落ちたり、それに伴って落ちたりする可能性があります。 また、既存のアーキテクチャ上の問題に応じて、通常の一貫した状態に戻すには数時間から数日かかる場合があります。



DNSまたはBGPを使用して、トラフィックフィルタリングネットワークに接続する2つの最も一般的な方法があります。 これら2つのシナリオを個別に検討します。

DNS

攻撃はドメイン名のみによって行われると想定します。



DNS攻撃を受けたサイトに接続するための典型的なシナリオは次のとおりです。DNSAレコードに攻撃されたWebサーバーの現在のIPアドレスが含まれるドメイン名で表されるネットワークリソースの所有者が助けを求めます。 すべての手続きを確認した後、Qrator Labsはクライアントに特別なIPアドレスを提供し、現在のアドレスに置き換えます。



原則として、現時点では、数時間から最大1日（RFC制限：2147483647秒）までのDNSレコードを変更するために考えられる高いTTLを考慮する必要があります-この間、古いAレコードはDNS再帰キャッシュに存在します。 したがって、攻撃の可能性があることを事前に認識している場合、DNS AレコードのTTLを低くする必要があります。



しかし、場合によってはこれでも保存できないことがあります。 結局、攻撃者は攻撃中にその有効性をチェックし、攻撃が結果をもたらさないことを確認して、スマートな悪役はフィルタリングネットワークをバイパスして、彼が「覚えている」IPアドレスで攻撃にすばやく切り替えます。



この場合、新しいIPアドレスが必要です。これは攻撃者には知られておらず、保護されたドメイン名を侵害することはありません。できれば別のアドレスブロックで、理想的には別のサービスプロバイダーから。 結局、攻撃者はいつでもさらに進んで、DDoS攻撃のベクトルを十分な能力を持つサプライヤのアドレスブロック（プレフィックス）に切り替えることができます。 まあ、私たちに-あなたは大歓迎です。 先に進みます。

BGP

BGP接続の場合、すべてが少し異なって見えます。



攻撃されたサービスに独自のアドレスブロック（プレフィックス）があり、DDoS中和サービスプロバイダーを介して独自のプレフィックスをアナウンスすることにより、保護下のインフラストラクチャ全体を完全に転送する場合、このプロセスはどのようになりますか？



攻撃を受けている自律システムがAS-SETに追加され、独自のプレフィックスをアナウンスできるようになります。その後、すべてのアップリンクがこの情報を受信して​​プレフィックスリストを更新する悪名高い日（24時間）が始まります。 当然、緊急時には、このようなクライアントに会ってこのプロセスを強制しようとしますが、これはすべての場合に可能ではなく、手動で行われます。 前述の観点から、「即座に麻酔をかける」リソースを遅滞なく保護する必要があるため、時間は重要かつ基本的なストレス要因です。



プレフィックスの所有者が事前にいくつかのプリセットを作成して攻撃の準備をする場合、Qratorフィルタリングネットワークにほぼ瞬時に適用でき、課外の時間や緊急モードで技術専門家の時間と神経を節約できます。 この場合の相互統合は、技術的なだけでなく、心理的なプロセスでもあります。



叙情的な余談：接続サービスのプロバイダーは、原則として、地域のTier-1オペレーターよりも低くない、大規模で信頼性の高い通信オペレーターからIPトランジットを購入します。 それらは、開いているデータベース（RIPE、RADBなど）から取得したリスト（prefix-list）に基づいて、クライアントから送られてくるプレフィックスをフィルタリングします。 定期的に、DDoSから保護するためのIPトランジットサービスのプロバイダーの一部は、これらのフィルターを1日に1回周期的に更新しますが、他のプロバイダーは要求時にのみこれを行います。 有能なDDoS中和サービスプロバイダーにより、プレゼンスポイントは世界中にあります。



攻撃を受けて接続する最も困難なケースは、ルーター、ファイアウォール、ロードバランサー、その他の現代技術の驚異など、さまざまな機器を備えた複雑なインフラストラクチャの所有者の魅力です。 このようなシナリオでは、DDoS無効化サービスプロバイダーへの定期的な接続でさえ複雑なプロセスであり、バランスの取れた計画的な方法で対処する必要があります。 そのようなサービスへの攻撃が発生した場合、フィルタリングネットワークへの緊急接続は多大な労力を費やし、慎重に計画する時間を残さないことは残念です。 これらの問題が解決されない限り、サービスにはユーザーのアクセスに問題があり、品質が低下します。



多くの場合、DDoS攻撃は、サービス拒否攻撃の前または後に、ハッカー攻撃と何らかの順序で組み合わされます。 関与するリスクは完全に異なる順序です：ユーザーデータの漏洩、攻撃者によるシステムへの完全なアクセスの取得。 これらの問題は、DDoSを無効化することで垂直に解決する必要があり、最悪の場合、ユーザーのアクセスがさらに長くなり、せいぜい必要なページをリクエストしようとするユーザーの遅延が増加します。

---

追記

同僚、私たちは次の重要なニュースに注目します： www.ietf.org/mail-archive/web/idr/current/msg18258.html



「ルートリーク」（ルートリーク）の発生に対する自動保護のメカニズムを導入するイニシアチブは、Qrator Labsのエンジニアが参加した作成に直接関与し、受け入れコールステージを正常に通過し、ドメイン間ルーティング（IDR）ワーキンググループに移動しました。



次のステップは、IDRの一部としてのドキュメントの改訂と、その後のステアリンググループ（ IESG ）による検証です。 これらの手順を正常に完了すると、ドラフトが新しいRFCネットワーク標準に​​なります。



著者：アレクサンダー・アジモフ、エフゲニー・ボゴマゾフ、ランディ・ブッシュ（インターネット・イニシアティブ・ジャパン）、コティカラプディ・スリラム（米国NIST）、キーアー・パテル（アルクス・インク）は、業界の変化に対する強い要望があることを認識しています。 。 しかし、このプロセスの急ぎも受け入れられず、著者は、提案された標準を多国籍事業者と小規模ホームネットワークの両方に便利にするためにあらゆる努力をします。



養子縁組の呼びかけの枠組みで支持を表明した技術専門家に感謝します。 同時に、意見を述べただけでなく、コメントを送ってくれた人たちに感謝します。 このドラフトへの以降の変更では、それらを考慮に入れます。



また、IETFメーリングリスト（draft-ymbk-idr-bgp-open-policy@ietf.org）またはQrator Labs イニシアチブサイトを通じて、追加や明確化を希望する機会がまだあることを関心のあるエンジニアに伝えたいと考えています。 。



また、最終的な決定が下されるまでに、標準には2つの実用的な実装が必要であることに注意することも重要です。 そのうちの1つはすでに利用可能です-これは、Githubで利用可能なBirdルーティングデーモンに基づいた開発です： github.com/QratorLabs/bird 。 ベンダーとオープンソースコミュニティにこのプロセスへの参加を呼びかけます。