私たちのサイトをハッキングしようとする場合に何を、いつ行うか考えてみましょう。 まず、ほとんどの場合、攻撃者がサイトで脆弱性を発見し、それを利用した場合でも、脅威を排除しようとします。 第二に、サイバー犯罪者と戦うための唯一の運用ツールはIPアドレスをブロックすることですが、サイトへの攻撃が行われたすべてのアドレスに関する詳細情報がない場合、これはあまり効果的なツールではありません。
しかし、疑わしいアクティビティを表示してそれらをブロックするすべてのIPアドレスとサブネットに関する詳細な情報を事前に受信できた場合、状況はどの程度変わりましたか? いいですね。
これはElasticsearchで簡単に行えます。
この検索エンジンには、ログを分析するすべての手間をかける素晴らしいNetriskプラグインがあり、「Sankey」図(図を参照)を使用して、さまざまなトラフィックセグメントにおける疑わしいアクティビティのサイズと集中度を示します。
準備する
Netriskをインストールすることから始めましょう。 これを行うには、Elasticsearchホームディレクトリで次のコマンドを実行する必要があります(バージョン1.4.0以上が必要です)。
bin/plugin -install markharwood/netrisk
これで、プラグインがインストールされました。 しかし、それだけではありません。 彼は、IPアドレスが保存されるフィールドのマッピングが正しく構成されたインデックスを提供することを期待しています。 詳細については後で説明しますが、次のシェルスクリプトを実行して、インデックスを作成し、少量のテストデータを入力するだけです。
$ES_HOME/plugins/netrisk/exampleData/indexAnonData.sh
注意! このスクリプトは「mylogs」インデックスを作成し、その名前のインデックスが既にある場合は削除されます。
上記のすべての指示に従っている場合は、プラグインページを開くことができます: localhost :9200 / _plugin / netrisk /
打ち上げ
スクリプトによって生成されたデータを見ると、実際には貴重なものから、HTTPサーバーの応答のステータスしか得られないため、これは深刻な分析には十分ではないように思えるかもしれません。 実際、疑わしい動作を検出するにはこれで十分です。 通常、Webサーバーは200から300の範囲の応答を生成しますが、問題が発生した場合、応答のステータスを400から500に割り当てることができます。たとえば、存在しないページに誰かがアクセスしようとすると、これが発生します。 リクエストを使用して、サーバーへのすべての疑わしい呼び出しのリストをすでに取得できていることがわかります。
status:[400 TO 599]
Netriskは標準のLuceneリクエストパーサー(Kibanaと同じ)を使用しているため、疑わしいトラフィックを検出するリクエストをOR条件で追加のフィルターで補足できます。 たとえば、この方法では、UserAgentを指定せずにサイトにアクセスすることも不審であると見なされるべきであるとシステムに伝えることができます。
この段階で行われたリクエストは、それと一致するログ内のすべてのエントリが不良であることを明確に決定しないことを理解することが重要です。 いいえ、Elasticsearchは特定のIPまたはサブネットからサーバーへの疑わしい呼び出しが集中していないかログ全体を分析するように、疑わしいと仮定しています。
前述のリクエストを使用してプラグインを起動すると、Netriskはサイトにつながる疑わしいトラフィックのSankeyダイアグラムを表示します。 チャートを読むための情報を次に示します。
- 線の太さは「悪い」リクエストの数を表しますが、これは最も重要ではありません!
- 線の色ははるかに重要です-どのリクエストが優先されるかによって異なります:明るい赤はほとんどすべてのリクエストが悪いことを意味し、緑はほとんどすべてのリクエストが良いと考えることができることを意味します。 線の上にカーソルを合わせると、色の定義の基礎となる実数を見ることができます。
- この図は、各サブネット上のIPアドレスを示しています。 この情報は、特定のIPアドレスまたはサブネットから悪意のあるトラフィックの発信元を判断する際に、ウェブマスターにとって非常に価値があります。
- 特定のIPアドレスをクリックすると、Honey PotプロジェクトのWebサイトが開き、このIPアドレスに関する他のWebマスターのコメントを読むことができます。
おそらく、線の色が左から右の方向に赤から緑に変わることに気づいたでしょう。 これは、図の左側にある各ノードが通常、IPアドレスの小さなグループを表し、そこから要求が疑わしいと識別されたという事実によるものです。 次の図のノードは、動作が異なる多数のIPアドレスを含むサブネットを表しています。 ただし、一部のサブネットは完全に赤になります。 おそらく、これは、サイバー犯罪者以外の誰もこの地域のサイトに関心がないことを意味します(たとえば、ロシア語のサイトがあり、中国からの赤いトラフィックがあなたに来た場合、ほとんどの場合、これは中国のハッカーがあなたのリソースを傷つけたいことを意味します)。
どのように機能しますか?
データマッピングについて
Netriskによるリクエストは、インデックスに保存されているIPアドレスとサブネットに関する利用可能な統計に依存しています。 このような分析では、各IPアドレスを文字列として単純にインデックス付けすることはできません。IPアドレス自体とそれが属するサブネットを表すトークンに分割する必要があります(たとえば、タイプ186.28.25.186のIPアドレスは次のように分割されます)トークン:186.28.25.186、186.28.25、186.28、186)。 これは、次のマッピングルールを使用して実装できます。
マッピングルール
curl -XPOST "http://localhost:9200/mylogs" -d '{ "settings": { "analysis": { "analyzer": { "ip4_analyzer": { "tokenizer": "ip4_hierarchy" } }, "tokenizer": { "ip4_hierarchy": { "type": "PathHierarchy", "delimiter": "." } } } }, "mappings": { "log": { "properties": { "remote_host": { "type": "string", "index": "not_analyzed", "fields": { "subs": { "type": "string", "index_analyzer": "ip4_analyzer", "search_analyzer": "keyword" } } } } } } }'
このアプローチにより、各IPアドレスの階層の4つのレベルすべてで同時にクイック検索を実行できます。 (これはIPv6アドレスにも適用されます)
中身は?
Netriskは、「悪い扱い」(より正確には「潜在的に悪い扱い」)と見なされるべきものを正確に決定する要求を受け取ります。 データをフィルタリングした後、Netriskは、significant_terms集約を使用して、不審な呼び出しを最も頻繁に受信するIPアドレスまたはサブネットを判別します。 要求テンプレートは次のとおりです。
curl -XGET "http://localhost:9200/anonlogs/_search?search_type=count" -d'{ "query": { "query_string": { "query": "status:[400 TO 599]" } }, "aggs": { "sigIps": { "significant_terms": { "field": "remote_host.subs", "size": 50, "shard_size": 50000, "gnd": {} } } } }'
この要求は、最も疑わしい50個のIPアドレスとサブネットを選択します。 注目に値するいくつかのポイントがあります。
- 正しいデータを取得するには、高いshard_size値が必要です。 これにより、メモリとネットワーク、およびインデックス内の多数の一意のエントリのディスク領域に深刻な負荷がかかります。 remote_host.subsフィールドでIPアドレスのインデックスを完全に作成しない場合、これにより負荷が軽減されますが、結果の深さも削減されます。
- ElasticSearchは、デフォルトではヒューリスティック分析にJLHアルゴリズムを使用しますが、検討中のタスクにはGNDアルゴリズムがはるかに優れています。 通常、分析するとき、まれな単語は興味があります。たとえば、「Nosferatu」と「Helsing」という単語がDraculaの映画に関する一連のドキュメントに関連していることを判断することは重要ですが、一般的な単語「he」が何に関連しているのかはあまり興味がありません。 IPアドレスを分析するタスクでは、JLHアルゴリズムが提供する機能を無視し、機能性は低いが高速なGNDを利用できます。
この単一のリクエストは大量分析を行い、システム内の侵入者に関する基本情報を提供しますが、IPアドレスをブロックすることを決定する前にいくつかの情報を明確にすることをお勧めします。 これを行うには、次のクエリを使用できます。
リクエスト
{ "query": { "terms": { "remote_host.subs": [ "256.52", "186.34.56" ] } }, "aggs": { "ips": { "filters": { "filters": { "256.52": { "term": { "remote_host.subs": "256.52" } }, "186.34.56": { "term": { "remote_host.subs": "186.34.56" } } } }, "aggs": { "badTraffic": { "filter": { "query": { "query_string": { "query": "status:[400 TO 599]" } } } }, "uniqueIps": { "cardinality": { "field": "remote_host" } } } } } }
指定された疑わしいIPまたはサブネットごとに、次の情報を含む配列を取得します。
- リクエストの総数(良いものと悪いもの)。
- 不良リクエストの総数。
- サブネット内の一意のIPアドレスの総数。
疑わしいIPアドレスに関する図と詳細な統計情報が得られたので、ブロックに関する最終決定を下すことができます。
おわりに
Webサーバーのログを分析してIPアドレスなどのエンティティの動作を追跡することは複雑な計算タスクですが、取得したデータは氷山の一角にすぎません。
以下に、自分で実装できる行動分析の興味深い例をいくつか示します。
- 訪問者が私のサイトに費やす時間はどれくらいですか?
- ボットのように振る舞うIPアドレスは何ですか(CSSとJavaScriptをロードしないでください-ページレイアウト自体のみ)。
- サイトにアクセスしたときに、サイトのどのページが他のページよりも最初/最後に頻繁に表示されますか?