ELKスタックを使用したTorネットワークからインフラストラクチャへの通信の分析

ElasticSeachは非常に柔軟なプラットフォームであり、受信したデータは、ELKスタックの外部でもさまざまな方法で処理できます。 このために、12を超えるさまざまなAPIが提供されています。 しかし、多くのタスクでは、Kibanaの機能で十分です。



これらの1つをコミュニティと共有したいと思います。 私にとって、他のセキュリティガードと同様に、インフラストラクチャと外部との通信を確認して理解することが重要です。 最も興味深いものの1つは、タマネギネットワーク（Tor）との通信です。







もちろん、ELKはスタックに限定されず、情報を保存および処理するための単なるツールです。 それに基づく製品の有効性は、どこかで取得する必要があるデータによって決まります。 私の場合、これはネットワークデバイスから直接受信した生のNetflowデータであり、よりインテリジェントなコレクターによる予備処理は行われません。 このアプローチには長所と短所がありますが、それについてではありません。



たとえば、出力はおよそ次の情報です。







この例では、最も興味深いフィールドのみが表示され、Netflowを介して受信した情報のほとんどは省略されていることに注意してください。 私の意見では、主な利点の1つは、ストリーム内のトラフィックの量に関するデータを操作できることです。

フィルターを作成する

すでにこの段階で、Torネットワークとの通信の問題に1つの注意事項があることを予約したいと思います。 残念ながら、あなたと私にはTorネットワークからのトラフィックのみを特定する機会がありますが、Toネットワークには特定できません。 torprojects.orgコミュニティはExitノードのリストのみを提供しますが、Entryノードのリストを一意に識別できないというトピックに関するいくつかのトピックに出会いました。



ネットワークには、おそらく着信Torノードを説明するリストがありますが、残念ながらこの情報には信頼性がありません。 出口ノードの信頼できるリストは、次のリンクで入手できます： https : //check.torproject.org/exit-addresses 。 その結果、私たちはTorからのトラフィックでのみ動作します。



次に、ELK内でこの情報を使用する方法について説明します。 データストリーム全体からTorネットワークからのトラフィックをフィルタリングするには、次のシナリオに従って構築されるフィルターを作成できます。

( '1st.Exit.Node.IP' OR '2nd.Exit.Node.IP' OR .... 'Last.Exit.Node.IP' ) AND my_regex
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

必要に応じて、「AND」の後にフィルターに絞り込みを追加します。 フィルターのパフォーマンスを確認するには、bashを使用して構造（中央に「OR」が付いたノードの終了）を手動で作成し、検索が正しく機能するかどうかをクリップボードで確認します。

 curl -XGET https://check.torproject.org/exit-addresses | egrep -o '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' | sed -e ':a' -e 'N' -e '$!ba' -e 's/\n/ OR /g'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リストは大きいため、ElasticSearchのデフォルト設定ではブール演算子の使用が多すぎると断言できるため、次の設定で/etc/elastcisearch/elasticsearch.ymlの制限を増やしてデーモンを再起動します。

 indices.query.bool.max_clause_count: 2048
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ElasticSearchの強力な機能は、要求された情報をすばやくフィルタリングするため、結果は非常に高速です。 Kibanaで検索として保存して使用します。 理論上、私たちはタスクを達成しました-あなたの目の前のタマネギネットワークからの通信。



ほとんどの場合、1時間以内にこれらはいくつかのスレッドになりますが、それぞれが興味深いものです。

フィルターを更新

問題は、Exitノードのリストに一貫性がないため、一定の規則で更新することをお勧めします。 手動の方法は適切ではありません。 理論的には、検索フィルタの値とその識別子を含むKibanaインターフェイスへのPOSTリクエストの正しい形式を見つけることができます。 したがって、Web要求を生成するには、リストを更新します。 しかし、より便利なオプションがあります。



Kibanaは、オブジェクトに関するすべての情報を同じElasticSearchクラスターのシステムインデックス「.kibana」に保存します。 そこで、Exitノードのリストを含む、以前に作成された検索クエリを説明するドキュメントを見つけることができます。







したがって、情報check.torproject.org/exit-adressesに従ってこの特定のドキュメントの「クエリ」フィールドを更新する必要があります。 これを行うために、Pythonスクリプトをアップロードしました 。現在のバージョンはこちらにあります 。 参考のために、ネタバレの下で、現時点で最新バージョンを提供します。





スクリプトはExitノードのリストを受け取り、それに基づいて検索オブジェクトの「クエリ」を生成します。 ドキュメントを更新するために、Python APIが完全に同一のリクエストで、ElasticSearchが解決できないシリアル化エラーを取得するため、「カール」OSを呼び出す必要がありました。 「curl」はquery.jsonファイルを使用します。このファイルへのパスはスクリプトで指定する必要があります。 一般に、READMEの規定に従ってコードを調整し、その後、スクリプトをサーバーのcrontabにドロップし、動的に更新される検索結果を取得します。これは後で使用できます。

トラフィック自体を分析します

最初に目にするのは、もちろん複数のスキャンです。 一般的にはもちろん、どこからでもTorから絶えずスキャンされます。 彼らはOSIの第4レベル、Webアプリケーション、およびその他すべてでリッスンします。 したがって、ファイアウォールの前ではなく収集されたネットワーク情報を分析することをお勧めします。 まず、内部に入らなかったものはすべて一掃され、次に、内部ノードのすでに変換されたアドレスが表示されます。



2番目-データの大部分は、ネットワーク上のサービスに対する完全に有効な要求です。 今日では、ネットワークの使用を匿名化するのが普通です。そのため、Torからの通信には主に最も人気のあるサーバーへの接続が含まれます。 もちろん、一部の組織（ユーザーはユーザーが必要とする以上のものを必要としている）が、この通信をハックしたいという欲求を持つ可能性があります。 確かにそのような場合があります。 しかし、私は、インターネットコミュニティの発展のこの分野を制限する権利はないので、このトラフィックを理解することを学ぶ必要があると考えています。



以前のグループの両方に特別な注意を払う必要はありません。それらを認識し、通り過ぎることを学びます。 ただし、これだけではありません。 正しい分析は、興味深い事実をタイムリーに明らかにすることができます。



ボットネットマシンであろうと標的型攻撃であろうと、ネットワーク上の攻撃者の影響をすでに受けているC＆C（コマンド＆コントロール）ノードのトラフィックをチェックします。



原則として、以下の通信の両方をC＆Cについて分析する必要があります。

• デフォルトでpingよりも大きいICMPパケット。
• 同じ症状のDNS通信-非標準の大きなパケット。

両方のサービスは、標的となる高度な持続的脅威攻撃の場合でも、トラフィックをトンネルするために、依然として積極的に使用されています。 最近の最も顕著な例の1つは、たとえば、台湾の最初の銀行に対する攻撃の場合のCobaltグループの行動（ リンク ）です。



また、非標準のWeb要求に注意することをお勧めします。 フィルタリングすることはより困難になりますが、まだいくつかのリードをお勧めします。



現在、すべての同じC＆Cの大部分がWebを通過しています。これは、このトラフィックがあらゆる組織のあらゆる組織で許可されているためです。 したがって、原則として、ネットワークからWeb以外のサーバーに接続されているTCP 80および443は興味深いものです。



また、あまり人気のないWebサーバーを対象としたクエリにも注意してください。 特に、オープンソースフレームワークに基づいたものがある場合、特にトラフィック量が標準を超えている場合。 さらに透明性を高めるには、同じElasticSearchインデックスにそのようなサーバーまたはWAFのログを入力し、HTTPフィールドと値にリクエスト自体が直接含まれる並列視覚化ウィンドウを確認します。

ELKを使用したデータ分析

根拠にならないように、ELKスタックでこのようなデータ分析を最適化する方法を示します。 たとえば、収集されたデータに基づいてICMPまたはDNSトンネリングの試みを迅速に特定しようとする試みに没頭します。



情報はすべてグラフィカル形式で認識されるので、トラフィック量の点で標準を超えるICMP通信の視覚化を作成しようとします。 通常のICMP操作がポップアップしないようにネットワーク上のアクティブなトラフィックを観察することで基準を決定しますが、スクリプトを埋めようとしたり、ICMPパケットでコマンドの出力を送信しようとすると、キャッチされる可能性があります。 ストリームごとに2KBを超える値に決めました。 前の検索からこのトラフィックを取得するには、新しいトラフィックを作成し、最後に次のパターンを追加します。

 netflow.in_bytes: {2000 TO *} AND netflow.protocol: 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、視覚化>円グラフを選択します。 拡張検索のみがデータソースとして選択されます。







セクターの角度を決定するためのパラメーターとして、パラメーター 'netflow.in_bytes'の合計を指定します。







宛先IPアドレスによってパイをセクターに分割する必要があることを示します。







Torネットワークの場合、送信元アドレスは何も言わないので（同じ通信が複数のアドレスで行われる可能性があるため）、接続はネットワーク上のアドレスによって識別されます。 しかし、ストリームを識別するのに便利なように、Torネットワークのノードアドレスが示されるパイの2番目のレベルを作成しました。



1つのニュアンスに注意したい-長い時間がかかり、25 +の一方向のパケット数を収集する通常のpingも、前述の検索パラメーターに該当します。

別の最適化を実行できます-Kibanaで手動で1つの特定のNetflowストリームのパケットあたりのバイト数を表示するフィールドを作成します。 これを行うには、[スクリプトフィールド]セクションで、痛みのない言語で次のタスクを実行するユニットを作成します。

 doc['netflow.in_bytes'].value / doc['netflow.in_pkts'].value
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このフィールドを検索に追加すると、情報を表示するときに、標準サイズのパケットをすぐに除外できます。 残念ながら、このフィールドでストリームをフィルタリングすることはできません; Kibanaはフィールドを作成するときにこれを報告します：

これらのスクリプトフィールドは、データからその場で計算されます。 ビジュアライゼーションで使用してドキュメントに表示できますが、検索することはできません。 ここでそれらを管理し、必要に応じて新しいものを追加できますが、スクリプトには注意が必要です。

ただし、ダッシュボードでは、視覚化の側に検索からの情報を直接配置し、データをマップできます。



結果は次のとおりです。







セクターが広いほど、IPアドレスが受信するデータが多くなります。 また、この例では、すべてのICMPストリームが標準のパケットサイズを持っていることがすぐにわかります。



同様の分析は、1KBを超えるストリームで解決したDNS通信にも適しています。 検索を修正し、次のクエリを追加して、同じ操作を実行します。

 netflow.in_bytes: {1000 TO *} AND netflow.protocol: 17 AND ( netflow.l4_dst_port: 53 OR netflow.l4_src_port: 53 )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おそらく、ネットワーク内の特定のノード（監視サーバーまたはDNSサーバー）が、私が提案した例に入る可能性があります。もちろん、それらをフィルターで取り除きます。 その結果、現在のサービスの偏差を示す明確な画像が得られます。 一般に、これらのサービスのこのような分析は、Torからのトラフィックだけでなく実行する必要があるため、このアプローチは一般にElasticSearchが受信するすべての情報に適用できます。

結論として

もちろん、この情報の可能な分析のリストは完全であると主張していません。 これは単なる表面的な例であり、さらに発展させることが望ましい。 読者がそのような情報を分析する方法を説明できるなら、それを共有してください。それは私とコミュニティにとって興味深いものになるでしょう。

また、ほとんどの場合、これらのヒントのいずれかは、私には発生しない引数によって（ユーティリティの面で）圧倒される可能性があります。 この場合、これらの議論を非常に聞きたいです。



もちろん、自分の行動を匿名化しようとする潜在的な攻撃者がVPN-Tor-VPN接続またはより高度な詐欺を使用している場合、このすべては表示されません。 したがって、同様の方法を使用して、インフラストラクチャ内のすべてのトラフィックを分析することをお勧めします。 しかし、この情報を表示することはすでに非常に興味深いです。



読んでくれてありがとう！ おもしろい/役に立てば幸いです。



PS読者の修正に従って責任を持って記事を修正します。 個人のメールにはテキストの品質に関するメモを記入してください。ただし、記事のトピックに直接コメントを残すためにコメントを残してください。