多くのシナリオでは、データ パケットに基づいてデータ パケット内の脅威を判断する必要があります。既存のデータ パケットの場合、そのデータ パケットがどのような種類の攻撃であるかをどのように判断するのでしょうか?
方法 1 は経験に基づいており、SQL インジェクションやコマンド実行などの一般的な WEB 攻撃を判断するのは比較的簡単です。ただし、マイニングのトラフィック特性や特定のツールの特性など、脅威は常に変化するため、詳細な調査と比較を行わないと、最初から判断することが困難な場合がよくあります。
方法 2 では、特定のネットワーク セキュリティ ベンダーのデバイスにデータ パケットをインポートしますが、これらのデバイスは商用デバイスであることが多く、課金が必要な一方で、商用デバイスでは誤検知とアラームのバランスが考慮されることがよくあります。対処するシナリオは比較的考慮する必要があり、複雑であり、漏洩が発生することは避けられません。
このとき、セキュリティアナリストがローカルトラフィック分析ツールを構築し、二次的に蓄積すれば、ニーズに応じて便利な武器を形成できます。現在、セキュリティ業界には主に、suricata、Snort、Zeek というトラフィック脅威検出用の 3 つのエンジンが含まれています。その中で、suricata と Snort は、既知の脆弱性、既知の WEB 攻撃手法、ハッキング ツール、マルウェアなどを含む既知の脅威の発見に偏っています。ZEEK は、主要な動作の記録による脅威ハンティングを通じて未知の脅威を発見することを好みます。
これら 3 つのトラフィック検出エンジンについては、対応する github からそれぞれダウンロードして Linux システムにインストールし、再生検証のために pcap を 3 つのエンジンに送信できます。ただし、同じデータパケットを 3 つのエンジンで別々に操作する必要があり、3 回必要になるのは比較的面倒です。このとき、suicata、snort、zeekの3つのトラフィックプローブエンジンをコントローラーで一元管理し、結果を統一的に提示するdaltonオープンソースプロジェクトを利用することができます。
dalton のオープンソースアドレスはこちらdalton は docker という形でサービスを提供しているので、やはり使い勝手が良いので docker のバージョンを最新のものにアップデートする必要があります。ダルトンの指示によると、次のようになります。
docker service docker start
./start-dalton.sh
この時点で、インストール スクリプトは、コントローラー、nginx、redis、suricata、Snort、zeek およびその他のコンテナーなどのダルトン サービス関連のコンテナーを含む複数の Docker コンテナーをダウンロードします。ダルトンが正常にインストールされると、以下の図 1 のようになります。 ：図
1
このうち、snort、suricata、zeekはトラフィック側のプローブコンテナ、dalton_controllerはトラフィックプローブスケジューリング制御コンテナ、dalton_webはWEB UIコンテナ、dalton_redisはメッセージキュー格納コンテナです。図 2 に示すように、UI によって開かれたポートはポート 80 であることがわかり、対応する IP アドレスに直接アクセスできます。 図 2 指定されたエンジン バージョン (通常は新しいバージョンを選択) と再生するルール セットを選択し
ます
。次のように suricata を例として、pcap に戻ります 図 3: 図
3
は上の図 3 に示すとおりです。Suricata の 6.0 バージョンが選択されており、ルール セットは Suricata に付属のルール セットで、出力ログはSuricata に付属する eve 形式のログ。この比較の鍵となるのはルール セットの選択ですが、Suricata のルールは比較的少ないため、セキュリティ アナリストが蓄積する必要がある点でもある Suricata のルール セットを充実させることが推奨されます。セキュリティ アナリストにとって、独自の要件を満たすルール セットを収集することは非常に重要です。次のリンクは、github 上の共通のルール セットです。
https://github.com/klingerko/nids-rule-library
https://github.com/al0ne/suricata-rules
https://github.com/travisbgreen/hunting-rules
https://github.com/xNymia/Suricata-Signatures
その中で、nids-rule-library に含まれるルール セットは、以下の図 4 に示すように、比較的豊富です。 図 4 は、proofpoint などの一部の大手セキュリティ企業が、オープンなルール セットとプロの有料ルール セット (年次報告書) を提供していることを
示しています。
手数料は5000元）、ルール変更は主に攻撃方法に関連する傾向があります。Talos Labs は、Snort 用の脆弱性ルール セットも維持しており (年会費は約 300 元で、比較的非常に安価です)、変更されたルール セットは主に既知の脆弱性に関連するルールに偏っています。さらに、デジタル証明書インテリジェンス、悪意のある IP インテリジェンス、悪意のあるドメイン名のハード パケットなど、悪用や OSINT などのオープン ソース インテリジェンス ソースが多数あります。これらのルール セットを含めて、個人の分析ライブラリとして使用することをお勧めします。上記の定期的に更新されるルール セットを dalton ディレクトリの下の rulesets ディレクトリに配置すると、ページ上でそれを選択できるようになります。上に示した 3 つのルールセットの場合。
Dalton はさまざまな形式のアラームを提供しており、操作の結果を以下の図 5 に示します。
図 5
一般的に、アラート内のアラームだけを確認する必要があります。さらに多くのコンテンツを確認して、脅威ハンティングに関連する作業を実行したい場合は、以下の図 6 に示すように、eve json 内のコンテンツを確認できます。eve json のコンテンツは、アラートに加えて、異常異常イベントや smb、decrpc などのさまざまなプロトコルのメタソース情報を記録する機能も提供し、異常の観点からより多くの可能性のあるコンテンツを分析できます
。
動作の発見。
上記は dalton の suricata 部分の紹介にすぎませんが、snort や zeek についても同様です。どのような種類のトラフィック検査エンジンであっても、ルールセットは非常に重要であることに注意してください。個人のセキュリティ アナリストのシナリオはパフォーマンスの影響を考慮する必要がなく、直面するトラフィック シナリオも非常にシンプルであるため、Snort、Suricata、Zeek のすべてのルール セットを Github 上に収集して更新することをお勧めします。定期的にそれらを実行することで、ローカル ツールの検出能力が極限に達します。セキュリティアナリストのフォローアップコラム「こちら 」では、以下の内容を紹介します。
- Github に基づいてローカル検出ルールの個人コレクションを作成する方法。
- ダルトンの分析ログに基づいて、攻撃技術ポイントの関連付けが実行され、セキュリティ イベント検出ツールが構築され、ルール アラームからセキュリティ イベントへのアップグレードが完了します。
この記事は CSDN の村の若者によるオリジナルの記事であり、許可なく複製することはできません。ブロガーのリンクはここにあります。