🥇内部ネットワークのセキュリティを監視するツールとしてのフロープロトコル

企業内または部門内のネットワークのセキュリティの監視というと、情報漏洩の制御や DLP ソリューションの導入を連想する人が多いでしょう。そして、質問を明確にして内部ネットワークへの攻撃をどのように検出するかを尋ねると、通常、答えは侵入検知システム (IDS) について言及されるでしょう。そして、10～20年前には唯一の選択肢だったものが、今日では時代錯誤になりつつあります。内部ネットワークを監視するには、より効果的で、場合によっては唯一可能なオプションがあります。それはフロープロトコルを使用することです。フロープロトコルは、元々はネットワークの問題を検索 (トラブルシューティング) するために設計されましたが、時間が経つにつれて、非常に興味深いセキュリティツールに変わりました。どのようなフロープロトコルがあり、どれがネットワーク攻撃の検出に優れているか、フローモニタリングを実装するのに最適な場所、そのようなスキームを展開するときに何に注意するか、さらには家庭用機器でこれらすべてを「解除」する方法についても説明します。この記事の範囲内です。

「なぜ内部インフラストラクチャのセキュリティ監視が必要なのか?」という質問には立ち入りません。答えは明らかのようです。しかし、それでも、今日ではそれなしでは生きていけないことをもう一度確認したい場合は、見てファイアウォールで保護された企業ネットワークに 17 の方法で侵入する方法についての短いビデオ。したがって、内部モニタリングは必要なことであると理解しており、あとはそれをどのように組織できるかを理解するだけであると仮定します。

ネットワークレベルでインフラストラクチャを監視するための XNUMX つの主要なデータソースを取り上げます。

当社がキャプチャして分析のために特定の分析システムに送信する「生の」トラフィック、
トラフィックが通過するネットワークデバイスからのイベント、
フロープロトコルの XNUMX つを介して受信されたトラフィック情報。

raw トラフィックのキャプチャは、歴史的に最初に登場したものであるため、セキュリティ専門家の間で最も人気のあるオプションです。従来のネットワーク侵入検知システム（最初の商用侵入検知システムは、1998 年に Cisco が買収した Wheel Group の NetRanger でした）は、特定のシグネチャ（以下の「決定ルール」）が検索されるパケット（およびその後のセッション）を正確にキャプチャしていました。 FSTEC 用語)、シグナリング攻撃。もちろん、IDS だけでなく、他のツール（Wireshark、tcpdum、Cisco IOS の NBAR2 機能など）を使用して生のトラフィックを分析することもできますが、これらのツールには通常、情報セキュリティツールと通常のツールを区別する知識ベースが不足しています。 ITツール。

つまり、攻撃検知システムです。ネットワーク攻撃を検出する最も古くて最も一般的な方法。境界 (企業、データセンター、セグメントなど) ではうまく機能しますが、最新のスイッチネットワークやソフトウェアデファインドネットワークでは失敗します。従来のスイッチをベースに構築されたネットワークの場合、攻撃検出センサーのインフラストラクチャが大規模になりすぎて、攻撃を監視するノードへの接続ごとにセンサーをインストールする必要があります。もちろん、どのメーカーも喜んで何百、何千ものセンサーを販売してくれるでしょうが、あなたの予算ではそのような出費を賄うことはできないと思います。価格の問題が目の前にあるように見えますが、シスコ（そして私たちは NGIPS の開発者です）でもこれを行うことはできなかったと言えます。私は立つべきではありません - それは私たち自身の決定です。さらに、このバージョンではセンサーをどのように接続するかという疑問が生じます。隙間に？センサー自体が故障した場合はどうなりますか? センサーにバイパスモジュールが必要ですか? スプリッター（タップ）を使用しますか？これらすべてにより、ソリューションの価格が高くなり、どのような規模の企業にとっても手の届かないものになります。

SPAN/RSPAN/ERSPAN ポート上でセンサーを「ハング」させ、必要なスイッチポートからのトラフィックをセンサーに誘導することができます。このオプションは、前の段落で説明した問題を部分的に解決しますが、別の問題が発生します。SPAN ポートは、送信されるすべてのトラフィックを完全には受け入れることができず、十分な帯域幅がありません。何かを犠牲にしなければなりません。一部のノードを監視せずに残すか (最初に優先順位を付ける必要があります)、ノードからすべてのトラフィックを送信するのではなく、特定の種類のトラフィックのみを送信します。いずれにせよ、いくつかの攻撃を見逃す可能性があります。さらに、SPAN ポートは他のニーズにも使用できます。その結果、お客様が所有するセンサーの数でネットワークを最大限にカバーするために、既存のネットワークトポロジを見直し、場合によっては調整を行う必要があります (これを IT 部門と調整します)。

ネットワークで非対称ルートが使用されている場合はどうなるでしょうか? SDN を導入済み、または導入予定の場合はどうすればよいでしょうか? トラフィックが物理スイッチにまったく到達しない仮想化マシンまたはコンテナを監視する必要がある場合はどうすればよいでしょうか? これらは、従来の IDS ベンダーが回答方法を知らないため、好まない質問です。おそらく彼らは、これらのファッショナブルなテクノロジーはすべて誇大宣伝であり、あなたには必要ないと説得するでしょう。おそらく彼らは、小さく始める必要性について話すでしょう。あるいは、ネットワークの中心に強力な脱穀機を置き、バランサーを使用してすべてのトラフィックをそこに誘導する必要があると言うかもしれません。どのようなオプションが提供される場合でも、それがどのように自分に適しているかを明確に理解する必要があります。その後、ネットワークインフラストラクチャの情報セキュリティを監視するアプローチの選択を決定します。パケットキャプチャの話に戻りますが、この方法は引き続き非常に人気があり重要ですが、その主な目的は国境管理であると言いたいと思います。組織とインターネットの間の境界、データセンターとネットワークの残りの部分の間の境界、プロセス制御システムと企業セグメントの間の境界。これらの場所では、従来の IDS/IPS が依然として存在し、タスクに適切に対処する権利があります。

XNUMX 番目のオプションに進みましょう。ネットワークデバイスからのイベントの分析は、攻撃検出の目的にも使用できますが、小規模なクラスの侵入のみを検出できるため、主要なメカニズムとしては使用できません。さらに、これには何らかの反応性が内在しています。攻撃は最初に発生し、その後ネットワークデバイスによって記録される必要があります。これは何らかの形で情報セキュリティの問題を示します。そのような方法はいくつかあります。これは、syslog、RMON、または SNMP である可能性があります。情報セキュリティのコンテキストにおけるネットワーク監視の最後の XNUMX つのプロトコルは、RMON と SNMP を使用すると、たとえばデバイスの中央の負荷を監視できるため、ネットワーク機器自体に対する DoS 攻撃を検出する必要がある場合にのみ使用されます。プロセッサまたはそのインターフェイス。これは最も「安価」な方法の XNUMX つ (誰もが syslog または SNMP を持っています) ですが、内部インフラストラクチャの情報セキュリティを監視するすべての方法の中で最も効果的ではありません。多くの攻撃は単純に隠蔽されます。もちろん、それらを無視すべきではなく、同じ syslog 分析は、デバイス自体の構成の変更やその侵害をタイムリーに特定するのに役立ちますが、ネットワーク全体に対する攻撃の検出にはあまり適していません。

XNUMX 番目のオプションは、いくつかのフロープロトコルのいずれかをサポートするデバイスを通過するトラフィックに関する情報を分析することです。この場合、プロトコルに関係なく、スレッドインフラストラクチャは必ず XNUMX つのコンポーネントで構成されます。

フローの生成またはエクスポート。この役割は通常、ルータ、スイッチ、またはその他のネットワークデバイスに割り当てられ、ネットワークトラフィックをそれ自体を通過させることで、そこから主要なパラメータを抽出し、収集モジュールに送信することができます。たとえば、Cisco は、仮想および産業用ルータやスイッチだけでなく、ワイヤレスコントローラ、ファイアウォール、さらにはサーバでも Netflow プロトコルをサポートしています。
回収の流れ。現在のネットワークには通常、複数のネットワークデバイスがあることを考慮すると、フローの収集と統合という問題が発生します。この問題は、受信したフローを処理して分析のために送信する、いわゆるコレクターを使用して解決されます。
流れ解析アナライザーは主な知的タスクを引き受け、さまざまなアルゴリズムをストリームに適用して、特定の結論を導き出します。たとえば、IT 機能の一部として、このようなアナライザーはネットワークのボトルネックを特定したり、ネットワークをさらに最適化するためにトラフィック負荷プロファイルを分析したりできます。また、情報セキュリティに関しては、このようなアナライザーはデータ漏洩、悪意のあるコードの拡散、または DoS 攻撃を検出できます。

この XNUMX 層アーキテクチャが複雑すぎると考えないでください。他のすべてのオプション (おそらく、SNMP および RMON で動作するネットワーク監視システムを除く) もこれに従って機能します。ネットワークデバイスまたはスタンドアロンセンサーなど、分析用のデータジェネレーターがあります。アラーム収集システムと監視インフラ全体の管理システムを備えています。最後の XNUMX つのコンポーネントは XNUMX つのノード内で組み合わせることができますが、多かれ少なかれ大規模なネットワークでは、スケーラビリティと信頼性を確保するために、通常は少なくとも XNUMX つのデバイスに分散されます。

各パケットのヘッダーと本体データ、およびパケットを構成するセッションの調査に基づくパケット分析とは異なり、フロー分析はネットワークトラフィックに関するメタデータの収集に依存します。いつ、どれだけ、どこから、どのようにして...これらの質問は、さまざまなフロープロトコルを使用したネットワークテレメトリの分析によって答えられます。当初、これらは統計を分析し、ネットワーク上の IT 問題を見つけるために使用されていましたが、その後、分析メカニズムが開発されるにつれて、セキュリティ目的で同じテレメトリにそれらを適用できるようになりました。フロー分析はパケットキャプチャに取って代わるものではない、またはパケットキャプチャに代わるものではないことを再度注意してください。これらの方法にはそれぞれ独自の応用分野があります。ただし、この記事の文脈では、内部インフラストラクチャの監視に最も適しているのはフロー分析です。攻撃が回避できないネットワークデバイス (ソフトウェア定義のパラダイムで動作するか、静的ルールに従って動作するかに関係なく) があります。従来の IDS センサーはバイパスできますが、フロープロトコルをサポートするネットワークデバイスはバイパスできません。これがこの方法の利点です。

一方、法執行機関や独自のインシデント調査チームに証拠が必要な場合は、パケットキャプチャなしでは対応できません。ネットワークテレメトリは、証拠を収集するために使用できるトラフィックのコピーではありません。情報セキュリティの分野での迅速な検出と意思決定に必要です。一方、テレメトリ分析を使用すると、すべてのネットワークトラフィックを「書き込む」ことはできません (どちらかというと、Cisco はデータセンターを扱っています:-) が、攻撃に関係するネットワークトラフィックのみを「書き込む」ことができます。この点に関するテレメトリ分析ツールは、従来のパケットキャプチャメカニズムを適切に補完し、選択的なキャプチャと保存のためのコマンドを提供します。それ以外の場合は、大規模なストレージインフラストラクチャが必要になります。

250 Mbit/秒の速度で動作するネットワークを想像してみましょう。このボリュームすべてを保存したい場合、31 秒のトラフィック送信には 1,8 MB、108 分間には 2,6 GB、10 時間には 108 GB、1 日には 500 TB のストレージが必要になります。帯域幅 5 Gbit/s のネットワークから毎日のデータを保存するには、216 TB のストレージが必要です。しかし、一部の規制当局はセキュリティデータを何年も保存することを要求しています...フロー分析の実装に役立つオンデマンド記録は、これらの値を桁違いに削減するのに役立ちます。ちなみに、記録されたネットワークテレメトリデータと完全なデータキャプチャの量の比率について言えば、それは約 XNUMX 対 XNUMX です。上記と同じ値の場合、毎日のすべてのトラフィックの完全な記録を保存すると、それぞれ XNUMX GB と XNUMX GB になります (通常のフラッシュドライブに記録することもできます)。

生のネットワークデータを分析するツールの場合、データを取得する方法はベンダー間でほぼ同じですが、フロー分析の場合は状況が異なります。フロープロトコルにはいくつかのオプションがあり、セキュリティの観点からその違いについて知っておく必要があります。最も人気のあるのは、Cisco によって開発された Netflow プロトコルです。このプロトコルにはいくつかのバージョンがあり、機能や記録されるトラフィック情報の量が異なります。現在のバージョンは 9 番目 (Netflow v10) で、これに基づいて業界標準の Netflow vXNUMX (IPFIX としても知られる) が開発されました。現在、ほとんどのネットワークベンダーは、自社の機器で Netflow または IPFIX をサポートしています。ただし、フロープロトコルには他にもさまざまなオプション (sFlow、jFlow、cFlow、rFlow、NetStream など) があり、sFlow が最も人気があります。導入の容易さから、国内のネットワーク機器メーカーで最も多く支持されているのがこのタイプです。事実上の標準となった Netflow と sFlow の主な違いは何ですか? いくつかの重要な点を取り上げます。まず、sFlow の固定フィールドとは対照的に、Netflow にはユーザーがカスタマイズ可能なフィールドがあります。次に、これがこのケースで最も重要なことですが、sFlow はいわゆるサンプリングされたテレメトリを収集します。 Netflow および IPFIX の非サンプリングのものとは対照的です。それらの違いは何ですか?

あなたが本を読むことに決めたと想像してください。」セキュリティオペレーションセンター: SOC の構築、運用、保守私の同僚、ゲイリー・マッキンタイア、ジョゼフ・ムニッツ、ナデム・アルファダンの著書です (リンクから本の一部をダウンロードできます)。目標を達成するには 10 つのオプションがあります。本をすべて読むか、ざっと目を通し、20 ページまたは 64 ページごとに止めるか、ブログや SmartReading などのサービスで重要な概念の再説明を見つけるかです。したがって、非サンプリングのテレメトリは、ネットワークトラフィックのすべての「ページ」を読み取り、各パケットのメタデータを分析します。サンプリングされたテレメトリは、選択されたサンプルに必要な情報が含まれていることを期待して、トラフィックを選択的に調査します。チャネル速度に応じて、サンプリングされたテレメトリは、200 番目、500 番目、1000 番目、2000 番目、10000 番目、または XNUMX 番目のパケットごとに分析のために送信されます。

情報セキュリティ監視のコンテキストでは、これは、サンプリングされたテレメトリが DDoS 攻撃の検出、スキャン、悪意のあるコードの拡散には適しているものの、分析のために送信されたサンプルに含まれていないアトミック攻撃やマルチパケット攻撃を見逃す可能性があることを意味します。非サンプリングテレメトリにはそのような欠点はありません。これにより、検出される攻撃の範囲がさらに広がります。以下は、ネットワークテレメトリ分析ツールを使用して検出できるイベントの短いリストです。

もちろん、一部のオープンソース Netflow アナライザーでは、これを行うことができません。その主なタスクはテレメトリを収集し、IT の観点から基本的な分析を実行することだからです。フローに基づいて情報セキュリティの脅威を特定するには、標準またはカスタムの Netflow フィールドに基づいてサイバーセキュリティの問題を特定し、さまざまな脅威インテリジェンスソースからの外部データで標準データを強化するさまざまなエンジンとアルゴリズムをアナライザーに装備する必要があります。

したがって、選択肢がある場合は、Netflow または IPFIX を選択してください。ただし、国内メーカーのように、機器が sFlow でのみ動作する場合でも、セキュリティの観点からメリットを得ることができます。

2019 年の夏、私はロシアのネットワークハードウェアメーカーが持つ機能を分析したところ、NSG、Polygon、Craftway を除くすべてのメーカーが sFlow のサポートを発表しました (少なくとも Zelax、Natex、Eltex、QTech、Rusteleteh)。

次に直面する疑問は、セキュリティ目的でフローサポートをどこに実装するかということです。実際、この質問は完全に正しく提起されているわけではありません。最新の機器は、ほぼ常にフロープロトコルをサポートしています。したがって、私は質問を別の方法で再定式化します。セキュリティの観点からテレメトリを収集するのが最も効果的なのはどこですか? 答えは明らかです。アクセスレベルでは、すべてのトラフィックが 100% 表示され、ホストに関する詳細情報 (MAC、VLAN、インターフェイス ID) が得られ、ホスト間の P2P トラフィックも監視できます。悪意のあるコードのスキャン検出と配布には重要です。コアレベルではトラフィックの一部が表示されないだけですが、境界レベルでは全ネットワークトラフィックの XNUMX 分の XNUMX が表示されます。しかし、何らかの理由で、攻撃者が境界を迂回せずに「出入り」できる外部デバイスがネットワーク上にある場合、そこからのテレメトリを分析しても何も得られません。したがって、カバレッジを最大限に高めるには、アクセスレベルでテレメトリ収集を有効にすることをお勧めします。同時に、仮想化やコンテナーについて話している場合でも、フローサポートは最新の仮想スイッチにもよく見られ、そこでのトラフィックも制御できることは注目に値します。

しかし、このトピックを取り上げたので、物理的または仮想的な機器がフロープロトコルをサポートしていない場合はどうなるのかという質問に答える必要があります。それとも、その組み込みは禁止されていますか (たとえば、信頼性を確保するために産業セグメントなど)? それとも、これをオンにすると CPU 負荷が高くなりますか (これは古いハードウェアで発生します)? この問題を解決するために、特殊な仮想センサー (フローセンサー) が存在します。これは本質的にはトラフィックを自身を通過させ、フローの形式で収集モジュールにブロードキャストする通常のスプリッターです。確かに、この場合、パケットキャプチャツールに関連して上で説明したすべての問題が発生します。つまり、流れ解析テクノロジーの利点だけでなく、その限界についても理解する必要があります。

フロー分析ツールについて話すときに覚えておくべきもう XNUMX つの重要な点です。セキュリティイベントを生成する従来の手段に関連して EPS メトリクス (XNUMX 秒あたりのイベント数) を使用する場合、この指標はテレメトリ分析には適用できません。これは FPS (XNUMX 秒あたりの流量) に置き換えられます。 EPS の場合と同様、事前に計算することはできませんが、特定のデバイスがそのタスクに応じて生成するスレッドのおおよその数を推定することはできます。さまざまな種類の企業デバイスや条件のおおよその値を記載した表をインターネット上で見つけることができます。これにより、分析ツールに必要なライセンスとそのアーキテクチャがどのようなものかを見積もることができます。実際のところ、IDS センサーは「プル」できる特定の帯域幅によって制限されており、フローコレクターには理解する必要がある独自の制限があります。したがって、大規模で地理的に分散されたネットワークでは、通常、複数のコレクターが存在します。説明したところ、シスコ内部でネットワークがどのように監視されているか、私はすでにコレクターの数を示しました - それらは21個あります、そしてこれはXNUMXつの大陸に点在し、約XNUMX万台のアクティブなデバイスを数えるネットワーク用です。

Netflow監視システムとして独自のソリューションを使用していますシスコステルスウォッチ、特にセキュリティ問題の解決に焦点を当てています。異常で疑わしい、明らかに悪意のあるアクティビティを検出するためのエンジンが多数組み込まれており、クリプトマイニングから情報漏洩、悪意のあるコードの拡散から詐欺まで、幅広いさまざまな脅威を検出できます。ほとんどのフローアナライザと同様に、Stealthwatch は XNUMX レベルのスキーム (ジェネレータ - コレクタ - アナライザ) に従って構築されていますが、検討中の内容に関連して重要な多数の興味深い機能が追加されています。まず、パケットキャプチャソリューション（Cisco Security Packet Analyzer など）と統合されているため、選択したネットワークセッションを記録して、後で詳細な調査や分析を行うことができます。次に、特にセキュリティタスクを拡張するために、特別な nvzFlow プロトコルを開発しました。これにより、エンドノード (サーバー、ワークステーションなど) 上のアプリケーションのアクティビティをテレメトリに「ブロードキャスト」し、さらなる分析のためにコレクタに送信できます。オリジナルバージョンの Stealthwatch がネットワークレベルで任意のフロープロトコル (sFlow、rFlow、Netflow、IPFIX、cFlow、jFlow、NetStream) で動作する場合、nvzFlow サポートによりノードレベルでもデータ相関が可能になります。システム全体の効率が向上し、従来のネットワークフローアナライザーよりも多くの攻撃が検出されます。

セキュリティの観点から Netflow 分析システムについて語るとき、市場がシスコの単一ソリューションに限定されないことは明らかです。商用ソリューションと無料またはシェアウェアソリューションの両方を使用できます。 Cisco ブログで競合他社のソリューションを例として引用するのは非常に奇妙です。そのため、名前は似ていますが、それでも異なる XNUMX つの人気のあるツール、SiLK と ELK を使用してネットワークテレメトリを分析する方法について少しお話します。

SiLK は、アメリカの CERT/CC によって開発されたトラフィック分析用のツールセット (インターネットレベルの知識のシステム) であり、今日の記事の文脈では、Netflow (最も一般的なバージョン 5 および 9)、IPFIX をサポートします。および sFlow を使用し、さまざまなユーティリティ (rwfilter、rwcount、rwflowpack など) を使用してネットワークテレメトリ上でさまざまな操作を実行し、ネットワークテレメトリ内の不正なアクションの兆候を検出します。ただし、注意すべき重要な点がいくつかあります。 SiLK は、次のようなコマンドを入力してオンライン分析を実行するコマンドラインツールです (200 バイトを超える ICMP パケットの検出)。

rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15

あまり快適ではありません。 iSiLK GUI を使用することもできますが、作業が大幅に楽になるわけではなく、視覚化機能が解決されるだけで、アナリストの代わりになるわけではありません。そしてこれがXNUMXつ目のポイントです。すでに強固な分析基盤、異常検出アルゴリズム、対応するワークフローなどが備わっている商用ソリューションとは異なり、SiLK の場合はこれらすべてを自分で行う必要があり、すでに準備が整っているものを使用する場合とは若干異なる能力が必要になります。使用するツール。これは良いことも悪いこともありません。これは、ユーザーが何をすべきかを知っていることを前提としたほとんどすべての無料ツールの機能であり、これを支援するだけです (商用ツールは、ユーザーの能力にあまり依存しませんが、ユーザーの能力にあまり依存しません。アナリストが少なくともネットワークの調査と監視の基本を理解していること）。さて、SiLK に戻りましょう。アナリストの作業サイクルは次のようになります。

仮説を立てます。私たちは、ネットワークテレメトリ内で何を探すのかを理解し、特定の異常や脅威を識別するための固有の属性を知る必要があります。
モデルの構築。仮説を立てたら、同じ Python、シェル、または SiLK に含まれていないその他のツールを使用して仮説をプログラミングします。
テスト中。次は、仮説の正しさをチェックする番です。仮説は、「rw」、「set」、「bag」で始まる SiLK ユーティリティを使用して確認または反駁されます。
実際のデータの分析。産業運営においては、SiLK は何かを特定するのに役立ちます。アナリストは、「期待したものは見つかりましたか?」、「これは仮説に対応していますか?」、「誤検知の数を減らすにはどうすればよいですか?」、「どのようにすればよいですか?」という質問に答える必要があります。認識レベルを向上させるには? » 等々。
改善。最終段階では、以前に行ったことを改善します。テンプレートの作成、コードの改善と最適化、仮説の再定式化と明確化などを行います。

このサイクルは Cisco Stealthwatch にも適用され、最後の XNUMX つだけがこれら XNUMX つのステップを最大限まで自動化し、アナリストのエラーの数を減らし、インシデント検出の効率を高めます。たとえば、SiLK では、手書きのスクリプトを使用して悪意のある IP に関する外部データを使用してネットワーク統計を充実させることができます。また、Cisco Stealthwatch では、ネットワークトラフィックにブラックリストの IP アドレスとの相互作用が含まれている場合に即座にアラームを表示する組み込み機能があります。

フロー分析ソフトウェアの「有料」ピラミッドの上位に行く場合は、完全に無料の SiLK の後に、Elasticsearch (インデックス付け、検索、およびデータ分析)、Logstash (データ入出力) という XNUMX つの主要コンポーネントで構成されるシェアウェア ELK があります。 ) と Kibana (視覚化)。すべてを自分で記述する必要がある SiLK とは異なり、ELK には、ネットワークテレメトリの分析を自動化する既製のライブラリ/モジュール (一部は有料、一部は有料) がすでに用意されています。たとえば、Logstash の GeoIP フィルタを使用すると、監視対象の IP アドレスを地理的位置に関連付けることができます (Stealthwatch にはこの機能が組み込まれています)。

ELK には、この監視ソリューションに不足しているコンポーネントを完成させるかなり大規模なコミュニティもあります。たとえば、Netflow、IPFIX、sFlow を使用するには、次のモジュールを使用できます。エラスティフローNetflow のみをサポートする Logstash Netflow モジュールに満足できない場合。

ELK には、フローの収集とそのフロー内での検索の効率が向上していますが、現在、ネットワークテレメトリの異常や脅威を検出するための豊富な組み込み分析機能がありません。つまり、上記のライフサイクルに従って、違反モデルを独自に記述し、それを戦闘システムで使用する必要があります (そこには組み込みモデルはありません)。

もちろん、ELK にはより洗練された拡張機能があり、ネットワークテレメトリの異常を検出するためのモデルがすでにいくつか含まれていますが、そのような拡張機能には費用がかかります。ここで問題となるのは、そのゲームにろうそくの価値があるかどうかです。同様のモデルを自分で作成し、そのモデルを購入してください。監視ツールの実装を選択するか、ネットワークトラフィック分析クラスの既製のソリューションを購入します。

一般に、ネットワークテレメトリの異常や脅威を監視するための既製のソリューション (Cisco Stealthwatch など) をお金を出して購入するか、自分で考え出してカスタマイズする方が良いかという議論には入りたくないのです。新しい脅威ごとに SiLK、ELK、nfdump、または OSU フローツール (最後の XNUMX つについて話しています) 私は言いました前回）？誰もが自分自身で選択し、XNUMX つの選択肢のいずれかを選択する独自の動機を持っています。ネットワークテレメトリは、社内インフラのネットワークセキュリティを確保する上で非常に重要なツールであり、メディアで形容詞とともに名前が言及される企業のリストに加わることがないように、ネットワークテレメトリを無視すべきではないことを示したかっただけです。」「ハッキングされた」、「情報セキュリティ要件に準拠していない」、「データと顧客データのセキュリティについて考えていない」。

要約すると、内部インフラストラクチャの情報セキュリティ監視を構築する際に従うべき主要なヒントをリストしたいと思います。

周囲だけに限定しないでください。ネットワークインフラストラクチャを使用（および選択）して、トラフィックをポイント A からポイント B に移動するだけでなく、サイバーセキュリティの問題にも対処します。
ネットワーク機器の既存の情報セキュリティ監視メカニズムを検討し、それを使用します。
内部監視の場合は、テレメトリ分析を優先します。これにより、すべてのネットワーク情報セキュリティインシデントの最大 80 ～ 90% を検出できると同時に、ネットワークパケットをキャプチャするときに不可能なことを実行し、すべての情報セキュリティイベントを保存するためのスペースを節約できます。
フローを監視するには、Netflow v9 または IPFIX を使用します。これらは、セキュリティコンテキストでより多くの情報を提供し、IPv4 だけでなく、IPv6、MPLS なども監視できるようにします。
非サンプリングフロープロトコルを使用します。これにより、脅威を検出するためのより多くの情報が提供されます。たとえば、Netflow や IPFIX などです。
ネットワーク機器の負荷を確認してください。フロープロトコルを処理できない可能性もあります。次に、仮想センサーまたは Netflow Generation Appliance の使用を検討してください。
まず最初にアクセスレベルで制御を実装します。これにより、すべてのトラフィックを 100% 確認できるようになります。
選択肢がなく、ロシアのネットワーク機器を使用している場合は、フロープロトコルをサポートするもの、または SPAN/RSPAN ポートを備えたものを選択してください。
エッジの侵入/攻撃検知/防御システムと、内部ネットワーク(クラウドを含む)のフロー分析システムを組み合わせます。

最後のヒントについては、以前にも説明した例を示したいと思います。シスコ情報セキュリティサービスは、以前はほぼ完全に侵入検知システムと署名方法に基づいて情報セキュリティモニタリングシステムを構築していましたが、現在ではそれらがインシデントの 20% のみを占めるに過ぎないことがわかります。さらに 20% はフロー分析システムに当てはまります。これは、これらのソリューションが気まぐれではなく、現代の企業の情報セキュリティサービス活動における実際のツールであることを示唆しています。さらに、その実装にとって最も重要なものは、ネットワークインフラストラクチャであり、情報セキュリティ監視機能をネットワークに割り当てることでさらに保護できる投資です。

ネットワークフローで特定された異常や脅威への対応については特に触れませんでしたが、監視が脅威の検出だけで終わるべきではないことはすでに明らかだと思います。その後に応答が続く必要があり、できれば自動または自動モードで応答する必要があります。しかし、これは別の記事で取り上げます。

追加情報：

PS. 上記の内容をすべて聞き取りやすい場合は、このメモの基礎となった XNUMX 時間のプレゼンテーションをご覧ください。

出所： habr.com

内部ネットワークのセキュリティを監視するツールとしてのフロー プロトコル

コメントを追加します 返信をキャンセル

内部ネットワークのセキュリティを監視するツールとしてのフロープロトコル

コメントを追加します返信をキャンセル