Webボットを検出するための1つのアプローチ、またはボットを分類するために機械学習をどのように使用したか

インターネット上のトラフィックの量は増加しています（特に、私たち全員がリモートで自分自身を見つけ、多くの人がオンラインで活動を転送した最近の数か月間）。 Webサイトのコンテンツを操作する自動化された手段の数も増えており、その結果、不要な自動化されたアクティビティのフィルタリングがますます重要になっています。今日、インターネットアクティビティの最大50％は、いわゆるWebボット（または単にボット）によって自動的に生成されます。そしてこの場合、その使用目的に関係なく、ネットワーク上でアクティブなプログラムについて話します。通常、これらのプログラムは、反復的で自動化が容易なアクションを実行します。たとえば、GoogleやYandexの検索エンジンは、クローラーを使用して、インターネット上のコンテンツとインデックスページを定期的に収集します。



したがって、Webボットには正当なものと悪意のあるものの2種類があります。正当なものには、検索エンジン、RSSリーダーが含まれます。悪意のあるWebボットの例としては、脆弱性スキャナー、スクレーパー、スパマー、DDoSボット、ペイメントカード詐欺トロイの木馬などがあります。 Webボットのタイプが特定されると、さまざまなポリシーを適用できます。ボットが正当な場合は、サーバーへの要求の優先度を下げるか、特定のリソースへのアクセスレベルを下げることができます。ボットが悪意のあるものとして識別された場合は、それをブロックするか、サンドボックスに送信してさらに分析することができます。 Webボットは、ビジネスに不可欠なデータの漏洩などの害を及ぼす可能性があるため、検出、分析、および分類することが重要です。また、Webボットトラフィックの最大66％が正確に処理されるため、サーバーの負荷が軽減され、トラフィックのいわゆるノイズが軽減されます。悪意のあるトラフィック。

既存のアプローチ

ネットワークトラフィック内のWebボットを検出するには、ホストへの要求の頻度の制限、IPアドレスのブラックリストへの登録、User-Agent HTTPヘッダーの値の分析、デバイスのフィンガープリントの作成、CAPTCHAの実装の終了、を使用したネットワークアクティビティの動作分析など、さまざまな手法があります。機械学習。



ただし、さまざまなナレッジベースと脅威インテリジェンスを使用してサイトに関する評判情報を収集し、ブラックリストを最新の状態に保つことは、コストと労力を要するプロセスであり、プロキシサーバーを使用する場合はお勧めできません。



最初の概算でのUser-Agentフィールドの分析は役立つように思われるかもしれませんが、Webボットまたはユーザーがこのフィールドの値を有効な値に変更したり、通常のユーザーになりすましてブラウザーに有効なUser-Agentを使用したり、正当なボットとして使用したりすることを妨げるものは何もありません。そのようなウェブボットを偽装者と呼びましょう。さまざまなデバイスフィンガープリントを使用して（マウスの動きを追跡したり、クライアントのHTMLページをレンダリングする機能をチェックしたり）、追加のページ（スタイルファイル、アイコンなど）の要求、JavaScriptの解析など、人間の行動を模倣する、検出がより難しいWebボットを強調表示できます。このアプローチは、クライアント側のコードインジェクションに基づいていますが、追加のスクリプトの挿入中にミスをするとWebアプリケーションが破損する可能性があるため、受け入れられないことがよくあります。



Webボットはオンラインでも検出できることに注意してください。セッションはリアルタイムで評価されます。この問題の定式化の説明は、Cabri et al。[1]、およびZi Chu [2]の作品に記載されています。別のアプローチは、セッションが終了した後にのみ分析することです。最も興味深いのは、明らかに、最初のオプションです。これにより、意思決定をより迅速に行うことができます。

提案されたアプローチ

機械学習技術とELK（Elasticsearch Logstash Kibana）テクノロジースタックを使用して、Webボットを識別および分類しました。調査の対象はHTTPセッションでした。セッションは、一定の時間間隔での1つのノード（IPアドレスの一意の値とHTTP要求のUser-Agentフィールド）からの一連の要求です。 DerekとGohaleは、30分間隔を使用してセッション境界を定義します[3]。 Iliu et al。は、このアプローチは実際のセッションの一意性を保証するものではないと主張していますが、それでも許容できます。 User-Agentフィールドは変更できるため、実際よりも多くのセッションが表示される場合があります。したがって、Nikiforakisと共著者は、ActiveXがサポートされているかどうか、Flashが有効になっているかどうか、画面解像度、OSバージョンに基づいて、より微調整することを提案しています。



User-Agentフィールドが動的に変化する場合、別のセッションの形成で許容できるエラーを検討します。また、ボットセッションを特定するために、明確なバイナリ分類モデルを構築して使用します。

• Webボット（タグボット）によって生成された自動ネットワークアクティビティ。
• 人間が生成したネットワークアクティビティ（人間にタグを付ける）。

Webボットをアクティビティタイプで分類するには、次の表からマルチクラスモデルを作成しましょう。



また、モデルのオンライントレーニングの問題も解決します。







提案されたアプローチの概念スキーム



このアプローチには、トレーニングとテスト、予測、結果の分析の3つの段階があります。最初の2つをさらに詳しく考えてみましょう。概念的には、このアプローチは、機械学習モデルを学習して適用するという古典的なパターンに従います。最初に、分類の品質メトリックと属性が決定されます。その後、特徴のベクトルが形成され、一連の実験（さまざまなクロスチェック）が実行されて、モデルが検証され、ハイパーパラメーターが選択されます。最後の段階で、最適なモデルが選択され、モデルの品質が遅延サンプルでチェックされます。

モデルのトレーニングとテスト

packetbeatモジュールは、トラフィックを解析するために使用されます。生のHTTPリクエストはlogstashに送信され、そこでタスクはCelery用語でRubyスクリプトを使用して生成されます。それらはそれぞれ、セッションID、要求時間、要求本文、およびヘッダーで動作します。セッション識別子（キー）-IPアドレスとUser-Agentの連結からのハッシュ関数の値。この段階で、次の2種類のタスクが作成されます。

1. セッションの特徴のベクトルの形成について、
2. リクエストテキストとUser-Agentに基づいてクラスにラベルを付けます。

これらのタスクはキューに送信され、そこでメッセージハンドラーがタスクを実行します。したがって、ラベラーハンドラーは、専門家の判断を使用してクラスにラベルを付けるタスクを実行し、使用されるUser-Agentに基づいてbrowscapサービスからのデータを開きます。結果はキー値ストレージに書き込まれます。セッションプロセッサは、特徴ベクトルを生成し（以下の表を参照）、各キーの結果をキー値ストレージに書き込み、キーの有効期間（TTL）も設定します。



これは、機能マトリックスが形成され、各セッションのターゲットクラスラベルが設定される方法です。このマトリックスに基づいて、モデルの定期的なトレーニングとそれに続くハイパーパラメーターの選択が行われます。トレーニングには、ロジスティック回帰、サポートベクトルマシン、決定ツリー、決定ツリーの勾配ブースト、ランダムフォレストアルゴリズムを使用しました。最も関連性の高い結果は、ランダムフォレストアルゴリズムを使用して取得されました。

予測

トラフィックの解析中に、キー値ストレージ内のセッション属性のベクトルが更新されます。セッションに新しい要求が表示されると、それを説明する属性が再計算されます。たとえば、新しいリクエストがセッションに追加されるたびに、セッション内のヘッダーの平均数（mean_headers）が計算されます。Predictorは、セッション機能ベクトルをモデルに送信し、モデルからの応答をElasticsearchに書き込んで分析します。

実験

SecurityLab.ruポータルの トラフィックでソリューションをテストしました。データ量-15GB以上、130時間以上。セッション数は10,000を超えています。提案されたモデルは統計機能を使用しているため、10未満のリクエストを含むセッションはトレーニングとテストに関与しませんでした。品質メトリックとして従来の品質メトリック（各クラスの精度、完全性、およびFメジャー）を使用しました。

Webボット検出モデルのテスト

バイナリ分類モデルを構築して評価します。つまり、ボットを検出してから、アクティビティのタイプで分類します。5倍の階層化された相互検証の結果に基づいて（これは、強いクラスの不均衡があるため、検討中のデータに必要なものです）、構築されたモデルは非常に優れており（精度と完全性-98％以上）、人間のユーザーとボットのクラスを分離できると言えます。



延期されたサンプルでモデルをテストした結果を以下の表に示します。



延期されたサンプルの品質メトリックの値は、モデル検証中の品質メトリックの値とほぼ一致します。つまり、これらのデータのモデルは、トレーニング中に得られた知識を一般化できます。

最初の種類のエラーについて考えてみましょう。これらのデータが専門的にマークアウトされている場合、エラーマトリックスは大幅に変化します。これは、モデルのデータをマークアップするときにいくつかのエラーが発生したが、モデルはそのようなセッションを正しく認識できたことを意味します。



セッションの偽装者の例を見てみましょう。12の同様のクエリが含まれています。リクエストの1つを次の図に示します。







このセッションの後続のすべての要求は同じ構造であり、URIのみが異なります。







このWebbotは、有効なUser-Agentを使用し、通常は非自動で使用されるRefererフィールドを追加し、セッション内のヘッダーの数が少ないことに注意してください。さらに、リクエストの時間的特性（セッション時間、リクエストあたりの平均時間）により、このアクティビティは自動であり、RSSリーダーのクラスに属していると言えます。この場合、ボット自体は通常のユーザーになりすます。

Webボット分類モデルのテスト

Webボットをアクティビティタイプで分類するために、前の実験と同じデータと同じアルゴリズムを使用します。延期されたサンプルでモデルをテストした結果を以下の表に示します。



libs_toolsカテゴリの品質は低いですが、評価用の例の量が不十分であるため、結果の正確性について話すことができません。より多くのデータでWebボットを分類するには、2番目の一連の実験を実行する必要があります。現在のモデルでは、RSSリーダー、検索エンジン、および一般的なボットのクラスをかなり高い精度と完全性で分離できると自信を持って言えます。



検討中のデータに関するこれらの実験によると、セッションの22％以上（合計ボリュームが15 GB以上）が自動的に作成され、そのうち87％が一般的なボット、未知のボット、RSSリーダー、さまざまなライブラリやユーティリティを使用するWebボットのアクティビティに関連しています。 ..。したがって、アクティビティのタイプでWebボットのネットワークトラフィックをフィルタリングすると、提案されたアプローチにより、使用されるサーバーリソースの負荷が少なくとも9〜10％削減されます。

Webボット分類モデルをオンラインでテストする

この実験の本質は次のとおりです。リアルタイムで、トラフィックを解析した後、機能が識別され、各セッションの機能ベクトルが形成されます。定期的に、各セッションは予測のためにモデルに送信され、その結果が保存されます。







各クラスの経時的なモデルのFメジャー



以下のグラフは、最も興味深いクラスの経時的な品質メトリックの値の変化を示しています。それらのポイントのサイズは、特定の時間におけるサンプル内のセッションの数に関連しています。







精度、完全性、検索エンジンクラスの







Fメジャー精度、完全性、libsツールクラスの







Fメジャー







精度、完全性、rssクラスのFメジャー精度、完全性、クローラークラスの







Fメジャー精度、完全性、Fメジャーのクラス人間



検討中のデータの多くのクラス（human、rss、search_engines）の場合、モデルの品質は許容範囲内です（80％を超える精度と完全性）。クローラークラスの場合、セッション数の増加とこのサンプルの特徴ベクトルの質的な変化により、モデルの品質が向上します。完全性が33％から80％に向上しました。このクラスの例の数が少ない（50未満）ため、libs_toolsクラスについて合理的な結論を出すことは不可能です。したがって、否定的な結果（品質の悪さ）は確認できません。

主な成果とさらなる発展

機械学習アルゴリズムと統計機能を使用してWebボットを検出および分類する1つのアプローチについて説明しました。検討中のデータでは、バイナリ分類のために提案されたソリューションの平均精度と完全性は95％以上であり、このアプローチが有望であることを示しています。特定のクラスのWebボットの場合、平均の精度と完全性は約80％です。



構築されたモデルの検証には、セッションの実際の評価が必要です。前に示したように、ターゲットクラスで正しいマークアップが使用できる場合、モデルのパフォーマンスは大幅に向上します。残念ながら、現在、このようなマークアップを自動的に作成することは困難であり、専門家のマークアップに頼らなければなりません。これにより、機械学習モデルの作成が複雑になりますが、データ内の隠れたパターンを見つけることができます。



Webボットの分類と検出の問題をさらに発展させるには、次のことをお勧めします。

• ボットの追加クラスを割り当てて再トレーニングし、モデルをテストします。
• Webボットを分類するための記号を追加します。たとえば、バイナリでrobots.txtページへのアクセスの有無を担当するrobots.txt属性を追加すると、他のクラスの他の品質メトリックを悪化させることなく、Webボットのクラスの平均Fスコアを3％増やすことができます。
• 追加のメタ機能と専門家の判断を考慮して、ターゲットクラスのより正確なマークアップを作成します。

著者：Nikolay Lyfenko、リーディングスペシャリスト、Advanced Technologies Group、Positive Technologies