DDoS攻撃に対する保護のために機械学習を使用する機能

この投稿は、Qrator LabsのKonstantin Ignatovによる1C-Bitrixパートナー会議でのプレゼンテーションに基づいています。

あなたのサイトでDDoS攻撃が始まったとしましょう。 これについてどうやって知っていますか？ セキュリティシステムは、攻撃されたことをどのように判断しますか？ 保護する方法は何ですか？ 攻撃が発生した場合、どのようなアクションとイベントのシーケンスが発生しますか？

原則として、リソースの所有者は、不満なユーザーが電話をかけ始めたときにのみ攻撃について学習します。 この状況は、準備ができていないほとんどの企業で満たされています。 火災時には、救助計画を立てるのに手遅れであり、誰もが手元にある普遍的な救済策を求めて急いでいます。 しかし、問題を即座に解決するDDoSに対する「魔法の薬」はありません。 事前に準備する必要があります。

DDoS保護はプロセスです。 攻撃が発生したときではなく、事前に開始する必要があります。 明らかに、このプロセスは情報セキュリティの分野に属します。

「情報セキュリティ」という用語はどういう意味ですか？
これに関連して、我々は2つの政党の反対について話している。 攻撃者（競合他社、ランサムウェア、不満なユーザー）は、少なくともしばらくの間サイトの動作を停止する（ダウンタイムになる）ことを望みます。 リソースの所有者は、中断のない絶対的なアクセシビリティを求めています。

情報セキュリティには2つの主要な原則があります。

• 犯罪者のように考えてみてください。つまり、サイトをダウンタイムにしたい人たちを精神的に味方につけましょう。 あなたは彼らがこれをどのように行うか、彼らが必要とするかもしれないデータ、彼らがとるステップを理解する必要があります。
• 可能な限り頻繁に自問してください。特定の状況で何がうまくいかないか。 何らかの方法で何かを壊す可能性があります。 コンポーネントの接続につながる問題。 使用するソリューションの欠点は何ですか。

DDoS保護プロセス

DDoS攻撃は、限られたリソースを使い果たすことを目的としています。 任意のリソースを使用できます。

• 電話機が受け入れることができるSMSの数。
• RAMサイズ。
• チャネル容量。
• 何でも。

DDoSに対抗する問題を対応するサービスのプロバイダーに完全に移行することはできません。 システム設計の段階でこれについて考える必要があります。 大規模なチームが保護の問題に取り組む必要があります。

• ネットワークエンジニアは、チャネル容量が少なくとも正当なトラフィックに十分であり、まだマージンがあることを提供する必要があります。
• Webアプリケーション開発者は、1つの要求ですべてのRAMが使い果たされないようにする必要があります。 最先端のアンチDDoSシステムを使用している場合でも、曲がったソフトウェアは悪いサービスを提供し、サイトの障害につながる可能性があります。
• 情報セキュリティの専門家は、サーバーが配置されているIPアドレスを保護する必要があります（隠し、 "グロー"がないようにします）。

DDoS攻撃に対抗するシステムが、トラフィックフィルタリングサービスを提供するパートナー企業1C-BitrixであるQrator Labsの例でどのように機能するかを見てみましょう。 彼女の安全なIPアドレスは、1C-Bitrixの個人アカウントで確認できます。 その後、このアドレスにDNSを転送できます。 古いIPアドレスは引き続き機能します。 外部セキュリティサービスのタスクの1つは、この古いIPアドレスを誰も知らないようにすることです。 攻撃者はグローが開始するとすぐに、Qrator保護をバイパスしてインターネットリソースを攻撃できるためです。 このような場合には解決策もありますが、コストが高くなります。

攻撃に対する防御を事前に開発する必要があるという事実に加えて、防御プロセス自体を自動化することをお勧めします。 通常、攻撃者が特定のサイトに集中することはほとんどありません。 それらはすべてストリーム上に置かれ、普遍的なスクリプトが書かれています。 彼らは自動的に多くのサイトをスキャンし、あなたのサイトに脆弱性を発見し、攻撃することを決めました。 彼らはスクリプトを開始し、スリープ状態に入りました-攻撃は難しくありません。 しかし、非常に強力な専門家チームがある場合でも、防衛戦術の開発には数時間かかる場合があります。 あなたはあなたのサイトに変更を加えています、攻撃は撃退されます。 攻撃者は数時間後に目を覚まし、スクリプトの数行を変更します。おそらく、あなたは再び自分自身を守る方法を見つけ出す必要があります。 そして円で。 このモードでは、スペシャリストが48時間以上耐えることはほとんどありません。 その後、攻撃を受けて接続するには常により多くの費用がかかるため、高価な保護手段に頼らなければなりません。 攻撃が既に本格化しているときに攻撃を無効にすることは非常に可能ですが、それははるかに複雑であり、ダウンタイムを回避することはできません。 そのようなサービスの外部プロバイダーは通常、自動化を使用します。 「手動」資金はほとんど節約できません。

自動化のための機械学習

DDoS攻撃に対抗するための最新システムの自動化について話すとき、機械学習技術の使用はほとんど常に暗示されています。 機械学習の使用は、アプリケーションレベルの攻撃（L7）を中和するために必要です。 他のほとんどのタイプの攻撃は、ブルートフォースによって無力化できます。 増幅などの攻撃中に、多くの同一のパケットがチャネルに到着します。 パッケージが正当なユーザーからのものであり、ゴミがどこにあるかを理解するために、人工知能を使用する必要はありません。 すべての不良トラフィックをスキップして除外するには、大きなチャネル容量があれば十分です。 十分な容量がない場合は、Qratorなどのサードパーティの地理的に分散したネットワークが役立ちます。これは、過剰なトラフィックを処理し、ゴミを除去し、正当なユーザーから「クリーンな」パケットを提供します。

アプリケーションに対する攻撃は、別のスキームに従って発生します。 アプリケーションは、多数のパラメーターを持つさまざまな要求を受け取ることができます。 それらが多数ある場合、このスレッドはデータベースを無効にします。 この問題を解決するには、実際のユーザーからのリクエストとボットからのリクエストを認識する必要があります。 このタスクは一見して区別できないため、並外れたものです。 その決定において、機械学習の最も効率的な使用。

機械学習とは何ですか？
まず第一に、それは次の2つのフェーズを持つ単なるアルゴリズムのセットです。

• 最初のフェーズはトレーニングです。アルゴリズムに何をすべきかを伝えます。
• 2番目のフェーズは、実際の「知識」の適用です。

アルゴリズムには3つのタイプがあります。

• 人からのフィードバック（教師とのトレーニング）で-アルゴリズムに何をすべきかを教えてから、彼らは学習します。 分類および回帰の問題に使用されます。
• データからのフィードバック（教師なしのトレーニング）-アルゴリズムにデータを表示するだけで、たとえば、それらの異常を見つけたり、これらまたはそれらのオブジェクトを自由裁量でグループ化します。 それらは、異常のクラスタリングと検索の問題を解決するために使用されます。
• 媒体からのフィードバック（制御理論）。 たとえば、今日のTwitterのサイトへのリンクの数に基づいてリソースのスケーリングの程度を選択した場合。 つまり、平均して1つのサーバーで一定レベルの負荷を維持します。

機械学習のタスクの例として、クライアントの1つの入力トラフィックのレベルに関する統計を取りました（上のグラフ）。 そして、一番下のグラフは、テストデータに基づく予測です（曲線の最初の青いセクション）。



上記はトラフィック量の日々の変化です2番目の図では、負荷開始のグラフを見て、アルゴリズムは次のトラフィックを予測します。 これは回帰の例です。

学習プロセスに対する攻撃者の影響

機械学習アルゴリズムを使用して、特定のランダム変数の分布の数学的期待値、分散、またはその他の数値特性の推定値が計算されます。

情報セキュリティの原則に準拠するには、アルゴリズムは2つの基本要件に従って動作する必要があります。

• 最初の段階で、アルゴリズムはソースデータに現れる可能性のある異常を無視できる必要があります。
• アルゴリズムがすでにタスクに取り組んでいる第2段階では、なぜこの決定またはその決定をしたのかを理解する必要があります。 たとえば、なぜリクエストを正当なものとして分類したのか。

私たちの場合、トレーニング用のデータはユーザーのアクティビティに関する情報です。 これは、攻撃者が学習するデータの少なくとも一部に影響を与えることができることを意味します。 しかし、攻撃者が望むものをアルゴリズムが正確に学習するように一般的な統計に影響を与えるという素晴らしいアイデアを思いついたらどうでしょうか？ これはよく発生する可能性があります。つまり、この可能性を事前に防ぐ必要があります。

クライアントの1人との奇妙な活動に関する社内レポートの例を次に示します。



毎晩、同時に、パッケージの数が増加しました。 致命的ではなく、サイトはオープンし続け、負荷は許容範囲内にありました（グラフ上では対数目盛）。 この理由は何でもかまいません。おそらく、システム管理者が何かを台無しにして、cronで特定の時間の毎日のバックアップバックアップの操作を書いた可能性があります。 しかし、違法トラフィックの通過を許可するアルゴリズムを誰かが教えようとしているのかもしれません。

これを行うことができ、これから自分自身を守ることができるのは簡単なことではありません。最高の人々は彼らのソリューションに取り組んでいます。このトピックに関する多くの科学記事がすでにWeb上にあります。 これまでのところ、誰もアルゴリズムに「悪い」ことを教えることができず、誰かが試してみる準備ができています。 次に、攻撃者が成功しない理由を説明します。

これに対処する方法は？
最初の段階（トレーニング）では、堅牢性やブレークポイントなどの概念が重要になります。

堅牢性は、予測された推定値にどれだけ簡単に影響を与えることができるかの尺度です。
限界点-評価をゆがめるのに十分なトレーニングサンプルのサンプル数。

両方の用語は互いに非常に近いものですが、2番目の用語は私たちに近いものです。 これは、トレーニングセット内の歪んだ不正確な要素の数、つまり調査対象のソースデータの数を意味し、予測の結果に影響を与えることができます。

ブレークポイントがゼロの場合、アルゴリズムはそれ自体でブレークする可能性があります。 ブレークポイントが1に等しい場合、1つの間違った要求をスローするだけで十分であり、システムは何をすべきでないかを予測します。

ブレークポイントの値が高いほど、アルゴリズムのトレーニングに影響を与えるのが難しくなります-したがって、攻撃者にとってより高価になります。 ブレークポイントが高くなるようにシステムをトレーニングした場合、反作用の問題は経済面に移ります。 より少ないお金を使った人が勝ちます。

理想的には、保護にかかる費用はごくわずかであり、それを克服するには多大な費用が必要です。

第2段階（アルゴリズムの改良）では、すべてが計画どおりに失敗する可能性があることを覚えておく必要があります。 場合によっては、事後を分析する必要がありますが、実際に何が起こったのか。 したがって、アルゴリズムがどのように機能し、なぜ機能したかを「伝える」ことができると便利です。 アルゴリズムの動作を理解することは、自動化されたプロセスを「監視」するのに役立ち、インシデントのテスト、デバッグ、および調査のタスクを促進します。

データ収集

機械学習アルゴリズムにはデータが必要です。 どこで入手できますか？ 基本的に、ここにはすべてが手元にあります...

どのようなデータを収集する必要がありますか？
まず、すべての枯渇性のあるリソースを観察する必要があります。

• 接続の数。
• トラフィック量;
• 空きメモリ。
• CPU使用率
• 他の消耗リソース。

そのようなデータを収集して保存するのは簡単です-これには多くのツールがあります。 そのようなデータの量は予測可能です。 毎分1メガバイトのテレメトリデータを記録する場合、DDoS攻撃の開始後でも、1メガバイトを記録します。 まだこれを行っていない場合は、開始する時間です。

分析用の2番目のタイプのデータはユーザーの行動であり、ログに反映されます（基本的にはaccess.logおよび\またはデータベースクエリを保存するログです）。 それらはマシンにとって便利なフォーマットでなければなりません。

テレメトリとは異なり、ログの量はリクエストの数に対して少なくとも直線的に増加します。 これは、リソースが非常に不足しているDDoS攻撃中に特に注意を要する場合があります。 CPUは100％ロードされており、システムは2GBのログを保存しようとしています。 重大な状況でこのタスクが開始されないか、中断されることを確認する必要があります。 しかし、少なくとも一部のログが攻撃を受けても保存されるのは悪くありません。

すべてのログを保存できるわけではなく、一部のみを保存できます。 しかし、あなたはこれに賢明にアプローチする必要があります。 10回ごとのリクエストを記録するのは意味がありません。セッションで保存する必要があります。 たとえば、IPアドレスから非暗号化ハッシュを計算し、これらのハッシュの特定の範囲のみを保存できます。非暗号化ハッシュに1〜100の範囲の値を取得させます。すべてのリクエストを保存することから始めます。 時間がない場合、ハッシュが1〜90の範囲にあるIPアドレスからの要求のみを保存します。 フローに対処できるようになるまで間隔を短くします。

また、システムの「純粋な動作」のログの少なくとも小さなサンプルが常に必要です（つまり、攻撃を受けていない）。 それらを保存しなくても、定期的に小さなダンプを記録して、DDoS攻撃がない場合のユーザーの動作を把握できます。

格納されたテレメトリとログから何を学ぶことができますか？
テレメトリに基づいて、サーバーリソースが使い果たされる時期を判断するアルゴリズムを教えることができます。 ログがある場合、攻撃者の動作が通常のユーザーとどのように異なるかを分析できます。 さまざまな基準に従ってユーザーをグループ化することができます。たとえば、大きな負荷をかける一方で収入をもたらさないユーザーを選択できます。 なぜこれが必要なのでしょうか？ サーバーが通常の負荷にまったく対応していない場合（攻撃がない場合）、残念ながら、正当なユーザーの1人を禁止する必要があります。 誰？ 明らかに、「購入」をクリックする人ではありません。

タスクの例

実際には、通常、アルゴリズムは個別に使用されるのではなく、タスクのチェーン（パイプライン）に追加されます。あるアルゴリズムの出力で取得されたものは、別のアルゴリズムの入力として使用されます。 または、あるアルゴリズムの結果は、別のアルゴリズムを構成するためのパラメーターとして使用されます。

チェーンに分解されるタスクの例を検討してください。

タスク番号1。 サイトの将来の計画負荷を推定する

タスクは次のステップに分解されます。

• 負荷とは何か、時間や曜日によって負荷がどのように変化するかを理解します。 その結果、いくつかのタイプの負荷を取得する必要があります。 たとえば、平日、週末、新しいIPhoneのプレゼンテーション中およびプレゼンテーション直後の負荷。
• 現在の負荷レベルがどのタイプに属するかを推定します（現時点では攻撃はないと考えています）
• 現在の負荷とそのタイプの利用可能なデータに基づいて計画値を予測します。

タスク番号2。 攻撃の兆候が見られる場合、誰かを禁止する必要があるかどうかを決定する
現時点では、攻撃があることは確かです。 おそらく、攻撃に関係するIPアドレスの一部をブロックする必要があります。 しかし、積極的なブロックは、一部の正当なユーザーが禁止されるという事実につながります。 この状況はFalse Positiveと呼ばれ、そのようなケースを最小限に抑えるよう努力する必要があります（アルゴリズムは誤って-False-害を引き起こす人のグループにユーザーを割り当てます-Positive）。 サーバーがユーザーに影響を与えずに攻撃を「ダイジェスト」する（つまり、すべての要求を処理する）ことができる場合、何もする必要はありません。 したがって、サーバーがダウンタイムなしで攻撃に耐える能力を評価する必要があります。 タスクは次のステップに分解されます。

• エラーの数と失敗の数のリクエスト数への依存性を判断します。
• フィルタリングする必要があるクエリの数を決定します。

明らかに、このタスクは、サーバーの可用性という主な目標の達成につながるチェーンの一部です。 たとえば、次の手順では、ブロックする必要があるクエリを決定する必要があります。

タスク番号3。 サーバーが正当な負荷に対応していない場合、ビジネスの損失を抑えて実際のユーザーをフィルタリングできる要求
この問題では、サーバーの正当な負荷が耐えることができるよりも大きい状況を考慮します（悪意のあるトラフィックを考慮しなくても）。 残念ながら、そのような状況は起こります。 この問題を解決するには、問題番号2の最初の2つのステップを実行する必要があります。 つまり、このタスクもチェーンの一部です。

次に、次の手順を実行します。

• セッションの兆候を強調します。 たとえば、訪問者がチェックアウトページにアクセスしたか、広告キャンペーンのリンクをたどったか、ユーザーがサイトで承認されたかなどです。 すべてのセッションとその属性のテーブルを長期間にわたってコンパイルします。
• セッションを重要度でマークします。

理想的には、最も重要でない人だけを禁止するために、現在のセッションからの各セッションからの可能性のある利益を計算するとよいでしょう。 しかし実際には、通常、ヒューリスティックが適用されてタスクが簡素化されます。セッションの重要性が低い兆候があるユーザーをブロックします。

問題№1について考えてみましょう
クライアントの1つの入力負荷を示すグラフを覚えていますか？ 実際、美のために彼は浄化されています。 実際のチャートは次のようになります。



多くの巨大なバーストが見られ、通常の負荷レベルよりも数桁高くなっています。 また、負荷が不安定で、日が非常に異なることもわかります。 つまり、そのようなデータに基づいて堅牢なモデルを構築するタスクは簡単ではありません。

このテーマに関して山ほどの記事が書かれており、多くの研究が行われています。 しかし、広く受け入れられている理想的な解決策はありません。

次のアプローチを使用できます。

• 絶対偏差の使用。
• 堅牢な正規化。
• 非線形可逆変換（シグモイド）。
• 分布の仮定が必要な場合の「重い尾」。
• 「悪い」サンプルがトレーニングセットに分類される可能性を減らすためのサンプリング。

原則として、それを受け入れることができます

• ツリーベースのアルゴリズムでは、ブレークポイント<最小リーフサイズ。
• ブレークポイントをクラスタリングするとき<最小クラスターサイズ。

たとえば、堅牢な正規化と非線形の可逆変換を適用すると、次のようになります。



上記はソースデータです。 2番目のグラフは、ロバストな正規化の結果であり、異常の影響を減らすのに役立ちます。 最終的なグラフは、非線形可逆変換の結果です。 異常があるという事実は、2番目のグラフですでに理解されていますが、その後、その絶対値はもはや私たちにとって大きな関心事ではなくなりました。 非線形変換の助けを借りてそれを「カット」します。 作業しやすいデータが得られます。

同じグラフをカラー画像として視覚化できます。



この画像は、左から右へ、上から下へ1行ずつ読み取られます。 水平-1日の始まりからの秒数、垂直-日付。 黄色と赤（たとえば、右上隅）は高負荷を示します。

上記のアプローチを適用した後、負荷レベルによって異なる日をグループ化し、それらをクラスター化できます。



次の図に、より明確に反映された3種類の負荷を確認できます。



右側は、さまざまな種類の日の予想負荷です。 左側には、標準偏差（分位点散布）の堅牢な類似物があります。

これを実際の状況に適用します。 紫色の線は、一定期間の負荷を反映しています。 青い破線の曲線に最も近い。 つまり、これは、負荷を予測するときに注目する必要があるタイプです。

機能グループを検索する

ログの操作はより困難です。なぜなら、 それらの情報は、複雑なネスト構造の形式で保存されます。 機械学習のログは、事前の準備なしでは適切ではありません。 タスクの内容に応じて、リクエストまたはセッションから機能を選択できます。

最初のケースでは、各リクエストを個別に分析します。たとえば、不正なボットの兆候を探します... 2番目のケースでは、実際にユーザーの行動を分析します。

リクエスト属性の例：

• 静的または動的クエリ
• リクエスト処理時間
• この要求を処理するために必要なメモリの量

セッション属性の例：

• 訪問者はブラウザの最新バージョンを使用していますか
• ブラウザのインターフェース言語は、サイトの設定で選択した言語と一致していますか？
• 訪問者は静的にロードしますか？
• favicon.icoが要求された回数。
• 訪問者がチェックアウトページにアクセスしたかどうか。

これらは単純な記号であり、分析の開始前にそれらについて知っており、要求またはセッションを受け入れ、特定の記号の値の配列を返す基本関数を使用して取得できます。 しかし実際には、そのような兆候は分析には十分ではありません。 より多くの情報を抽出する必要があります。つまり、まだ知らない新機能を強調する方法を学ぶ必要があります。

たとえば、ログに/ loginで終わるURLのリクエストの一部が含まれている場合、それを記号としてマークし、この記号に従って各リクエストをマークできます（1または0でマーク-/ loginのリクエストのURLが終了するかどうか）。 または、example.comからの要求に単位を付け、残りにゼロを付けることができます。 または、リクエスト処理の期間（長、高速、中）で記号を強調表示することもできます。
つまり、実際には、データを見て、必要な兆候を理解しようとします。 これは、いわゆる特徴抽出プロセスの本質です。 潜在的な兆候は無限にあります。 さらに、機能のグループまたはセットも新しい機能を形成します。 これはタスクを複雑にします。

そのため、タスクは2つのサブタスクに分割されます。

• 強調する重要な機能。
• 記号のグループを識別します。各記号は本質的に記号でもあります。

実際には、次のようになります。



上の図では、クエリは記号に変わります。 次の図では、兆候をグループ化し、新しい兆候を特定し、発生頻度を計算しました。
この問題では、約60,000件のクエリを分析しました（これはそれほど多くはありませんが、これは単なる例です）。



右側の列は、この属性グループに対応するクエリの数を示しています。 数量が異なり、1つのリクエストが複数のグループに分類されることがわかります。 つまり、一部のグループに分類されなかったクエリがあります。 10個のゼロまたは1の配列で各リクエストをマークします。 1はリクエストがグループに対応することを意味し、0はリクエストがグループに該当しないことを意味します。 したがって、60,000x10のマトリックス形式の配列を取得します。 上記のように、この数値情報を使用できます。

そのような兆候を強調するために、特別なアルゴリズムが使用されます。 ここでは詳細に説明しません。

一般的な考え方は、ログを特別なデータベースに変換することです。 このデータベースは、多くのクエリに応答できる必要があります。 たとえば、すべての基本記号のログで特定の基準を満たすすべての可能な組み合わせを検索し、発生頻度で並べ替えます。

別のタイプのデータベースは、セットではなくシーケンスで機能します。 セッションは実際には一連のリクエストであるため、これはセッションの分析に必要です。 このようなデータベースは、特定のタイプのすべてのサブシーケンスを区別できます。 たとえば、すべてのセッションのすべてのサブシーケンスの中から特定の基準を満たすサブシーケンスをログで検索し、それらのサブシーケンスをそれらが出会ったセッションの数でソートします。

3番目のタイプのデータベースでは、1つのセッション内でサイトのある部分から別の部分への遷移を操作できます。 つまり、各セッションはグラフになりました。 データベースは、特定の基準を満たすすべてのサブグラフを検索し、それらが会ったセッションの数でそれらをソートできる必要があります。

このプロセスはパターン検出と呼ばれます。 パターンは、セット、シーケンス、またはグラフです。

この分析を使用して、関心のあるユーザーのグループを見つけることができます。 このような分析の結果は、手動で調べることもできます。
事前にこれらすべてを準備する必要があります

繰り返しますが、これには時間がかかります。 DDoS保護は、（攻撃時に）単純に取得してオンにすることはできません。事前に準備する必要があります。
適切な人材を見つけてトレーニングする必要があります。 トレーニングに使用できるデータを収集する必要があります。 何かを調べ、手動で調べ、ボトルネックを見つける必要があるかもしれません。 セキュリティシステムアルゴリズムをトレーニングする必要があります。 サーバーまたはメールデーモンが保護されていないIPを「シャイニング」していないことを確認する必要があります。

これはすべて大きなプロセスの一部であり、すぐに実行することはできません。

一方、DDOS保護システムの結果はビジネスインテリジェンスに使用できることに注意してください。 たとえば、マーケティング部門の仕事に、収入を得るために禁止しないことを決めたユーザーのグループのデータを提供します。