Decoder:10G機能の構成

Document created by RSA Information Design and Development on Apr 19, 2018
Version 1Show Document
  • View in full screen mode
 

このトピックでは管理者を対象として、NetWitness Suite 11.0を使用してパケットを高速収集する場合のPacket Decoderのチューニング方法について説明します。これは、10Gインタフェース カードでパケットを収集する場合に適用されます。パケットを高速で収集するには構成を慎重に行い、Decoderハードウェアを限界まで活用する必要があります。そのため、10Gの収集ソリューションを実装する際には、このトピック全体をお読みください。

RSA NetWitness Suiteは、Decoderでの高速な収集に対応しています。より高速なネットワークからネットワーク パケット データを収集し、使用するパーサとフィードに応じて、最大で8Gb/秒(持続)および10Gb/秒(バースト)でネットワーク トラフィックを収集するようPacket Decoderを最適化できます。

こうした環境における収集を可能にする機能拡張には、以下が導入されています。

  • 高速な収集を行うため、Intel 10G NICカードとpf_ring収集ドライバの機能を使用します。
  • パケット ロスのリスクを低減するために、負荷が特定の閾値を超えると自動的にアプリケーション パーサを無効にするassembler.parse.valveの構成を導入します。アプリケーション パーサが無効の場合、ネットワーク層のパーサはアクティブなままです。統計値が超過した閾値を下回ると、アプリケーション パーサは自動的に再有効化されます。

ハードウェアの動作条件

  • シリーズ4Sまたはシリーズ5のDecoder
  • Intel 82599ベースのEthernetカード。Intel x520など。RSAが提供する10Gカードは、すべてこの要件を満たしています。2つの例は次のとおりです。
    • RSAが提供するすべてのSMC-10GEカード。
    • 10Gネットワーク インタフェースを提供する、Intelのコントローラを使用したDellネットワーク ドーター カード。これは、シリーズ5のすべてのハードウェアに含まれます。
  • シリーズ4S/Dell R620の場合のみ:デュアル ランクDIMMの96GBのDD3-1600メモリ。シングル ランクDIMMではパフォーマンスが最大10%低下する場合があります。取り付けられているDIMMの速度とランクを確認するには、次のコマンドを実行してください。
    dmidecode -t 17
  • 収集の要件を満たすのに十分な量と速度のストレージ。ストレージの考慮事項については、このトピックで後述します。
  • 各Packet Decoderが少なくとも2つのDACまたはSAN接続で構成されている。

ソフトウェアの動作条件

  • シリーズ4SなどのDell R620ベースのシステムでは、BIOSをv1.2.6以降に更新しておく必要があります。
  • 10G Decoderの機能には、RSAから提供されたDecoderのインストール イメージでのみ対応しています。必要なソフトウェアはすべて、デフォルトでインストールされています。
  • 以前のリリースからアップグレードする場合は、最初にアップグレードしてから構成を続行します。

10G Decoderのインストール

注:新しいシリーズ5のハードウェアを使用する場合は、「10G Decoderの構成」に進んでください。

NetWitness 10G Decoderをインストールするには、次の手順を実行します。

BIOSのダウンロードおよび更新

注:v1.2.6よりも古いBIOSリビジョンでは、システム内で10Gキャプチャ カードの場所を正しく識別できないことがあります。最新のv2.2.3への更新が推奨されますが、v1.2.6以降を使用している場合はBIOSの更新は必須ではありません。

  1. BIOS v2.2.3を次の場所からダウンロードします。

    http://www.dell.com/support/home/us/en/19/Drivers/DriversDetails?driverId=V7P04

  2. Update Package for Red Hat Linuxファイルをダウンロードします。
  3. NetWitnessサーバにファイルをコピーします。
  4. rootとしてログインします。
  5. ファイルの権限をexecuteに変更します。
  6. 次のファイルを実行します。

    ./BIOS_V7P04_LN_2.2.3.BIN

  7. 実行が完了して、再起動が要求された場合は、システムを再起動します。

注:BIOSのインストール プロセスには約10分かかります。

10G Decoderパッケージの検索

10G Decoderの構成に必要なパッケージは、Decoderのインストール イメージにすでに存在します。追加のパッケージをインストールすることはできません。10Gドライバ機能を提供するパッケージは次のとおりです。

  • pfring-dkms-6.5.0-6.rpm
  • ixgbe-zc-4.1.5.6-dkms.noarch.rpm

10G Decoderパッケージがインストール済みであることの確認

10G Decoderパッケージのインストールは自動的に処理されます。そのため、10G機能を有効にするための処理はありません。

  • アップグレードの一環としてカーネル パッケージをアップグレードする場合、再起動が必要です。オペレーティング システムは再コンパイルされ、アップグレードされたカーネル用のドライバがインストールされます。
  • 次に示すように収集ポート アダプタを選択する際に、利用可能な追加のPFRINGZCインタフェースが表示されている場合は、インストールに成功したことが確認できます。

10G Decoderの構成

10G Decoderを構成するには、次の手順を実行します。

  1. Decoderの[エクスプローラ]ビューで、[Decoder]を右クリックして[プロパティ]を選択します。
  2. [プロパティ]ドロップダウン メニューで[reconfig]を選択し、次のパラメータを入力します。
    update=1 op=10g
    これによりDecoderのパケット処理パイプラインが調整され、rawデータのスループットが高まりますが、解析機能は低下します。
  3. Decoderの[エクスプローラ]ビューで、[database]を右クリックして[プロパティ]を選択します。
  4. プロパティ]ドロップダウン メニューで[reconfig]を選択し、次のパラメータを入力します。
    update=1 op=10g
    これにより、非常に大規模なファイル サイズを使用してI/Oを送信するためにパケット データベースが調整されます。
  5. 収集ポート アダプタを選択します。オプションは以下のとおりです。
    • 単一ポートで収集:PFRINGZC,p1p1またはPFRINGZC,p1p2
    • 両ポートで収集: PFRINGZC,P1P1を選択し、[エクスプローラ]ビューでcapture.device.params = device=zc:p1p2,zc:p1p1を設定します。
  6. 書き込みスレッドが収集速度を維持できない場合は、次の操作を試してください。

    /datebase/config/packet.integrity.flushnormalに変更します。

    注:packet.file.sizeの値を増やすこともできますが、ファイル全体がメモリにバッファリングされるため、ファイル サイズは10GBより小さくしておいてください。

  7. (オプション)アプリケーション パースはCPUを大量に消費するため、Decoderのパケット ドロップの原因になる可能性があります。アプリケーション パースによって誘発されるドロップを軽減するために、/decoder/config/assembler.parse.valvetrueに設定します。結果は次のとおりです。

    • セッションのパースがボトルネックになると、アプリケーション パーサ(HTTP、SMTP、FTPなど)が一時的に無効になります。
    • アプリケーションParserが無効になっている間でもセッションはドロップせず、それらのセッションの再生成機能のみが影響されます。
    • アプリケーション パーサが無効になっているときに解析されたセッションにも、ネットワーク メタが(ネットワーク パーサから)が引き続き関連づけられます。
    • 統計値/decoder/parsers/stats/blowoff.countには、アプリケーション パーサをバイパスしたすべてのセッションの数が表示されます(ネットワーク パースは引き続き実行されます)。
    • セッション パースに潜在的なボトルネックがなくなると、アプリケーションParserが自動的に再度有効化されます。
    • セッションがプールから強制排除されないよう、アセンブラ セッション プールは十分な大きさにする必要があります。
    • セッションが統計値/decoder/stats/assembler.sessions.forcedによって強制的に実行されているかどうかを判断できます(これは増加します)。また、/decoder/stats/assembler.sessions/decoder/config/assembler.session.poolの差が数百以内になります。
  8. (オプション)収集用のMTUを調整する必要がある場合は、snaplenパラメータをcapture.device.paramsに追加します。以前のリリースとは異なり、snaplenは、特定の境界に切り上げる必要はありません。Decoderは、収集インタフェースに設定されたMTUを自動的に調整します。

  9. 次の構成パラメータは廃止され、必要なくなりました

    • capture.device.paramscore= parameter
    • /etc/pf_ringディレクトリの設定ファイル

    注:画像処理後にインストールされたEthernetデバイスを収集デバイスとして使用する場合、構成は必要ありません。ネットワーク インタフェースとして使用する場合、またはシステム ツールが手動設定を行わずにそれにアクセスする必要がある場合は、構成が必要です。

一般的な構成パラメータ

一般的な構成パラメータを次に示します。実際のパラメータは、使用可能なメモリとCPUリソースの量に応じて異なる場合があります。

  1. セッションとパケット プールの設定(/decoder/configの下):
    • pool.packet.pages = 1000000
    • pool.session.pages = 300000
  2. filesizeに設定されている(/database/config/packet.write.blockサイズ)未満のパケット書き込みブロック長

    注:この構成により、Decoderは巨大なページファイルにバッファリングし、ダイレクトI/Oを使用して書き込むことで、パフォーマンスを最大化します。

  3. 解析スレッド数(/decoder/configの下)。

    parse.threads =12

ストレージに関する考慮事項

10Gのライン レートレートで収集を行う場合、パケットとメタ データベースを格納するストレージ システム側でも、1400メガバイト/秒の書き込みスループットを維持できる必要があります。

Series 4Sハードウェアを使用する場合(複数のDACユニット搭載)

シリーズ4Sには、全体で48Gbit/秒のI/Oスループットスループットを発揮するハードウェアRAID SASコントローラが搭載されています。これには外付けの6Gbitポートが8つあり、4レーンのSASケーブル2本に接続します。10Gの場合の推奨構成は、これら2本の外部コネクタを使用して少なくとも2台のDACユニットのバランスを調整します。たとえば、SASカード上の1つ目のポートにDACを1台接続して、SASカード上の別のポートに別のDACを接続します。

DACが3つ以上ある環境の場合は、各ポートから均等にチェーン接続します。既存環境にDACを追加する際、DACケーブルの再接続が必要になる場合がありますが、Decoderですでに収集されたデータには影響しません。

新たにDACを追加する場合は、現在使用可能なNwMakeArrayスクリプトを使用してDACユニットをプロビジョニングします。このスクリプトを実行するたびに、1台のDACが自動的に追加され(つまり、DACを3台追加する場合は、スクリプトを3回実行する必要があります)、DACが別々のマウント ポイントとしてNwDecoder10Gの構成に追加されます。この設定によりNwDecoder10Gでは、パケットのコンテンツ リクエストで必要となる読み取りI/Oと、収集で必要となる書き込みI/Oを分離することができるため、マウント ポイントを別々にしておくことが重要になります。

SANおよびその他のストレージ構成の使用

Decoderでは、継続的スループット要件を満たしていれば、どのようなストレージ構成でもかまいません。SANにおける標準の8Gbit FCリンクでは、10Gでのパケット収集速度には不十分です。SANを使用する構成ではソフトウェアRAIDスキームを使用して複数のターゲットを統合してI/O分散を行う必要がある場合があります。したがって、SANを使用する環境では、複数のFCを使用するSANへの接続方法を構成する必要があります。

パースおよびコンテンツの考慮事項

高速でrawパケットをパースする場合に特有の問題があります。高いセッション レートおよびパケット レートでは、パースの効率が非常に重要になります。効率の悪い(つまり、パケットの検査に長い時間を費やしている)Parserが1つあると、システム全体の速度が低下し、結果的にカードでパケットのドロップが発生する可能性があります。

10Gのテストは、最初にネイティブParserだけを使用して開始します(ただし、SMB/WebMailは除く)。ネイティブParserを使用して、パケットのドロップがほとんど発生しない状態で、基準となるパフォーマンスを確定します。この処理が完了し、システムで高速での収集が問題なく行われることが証明されるまでは、Liveコンテンツをダウンロードしないでください。

システムがスムーズに機能するようになれば、Liveコンテンツ、特にParserを徐々に追加します。 

ベスト プラクティス

新規または更新いずれの環境にかかわらず、パケット ロスのリスクを最小化するために、次のベスト プラクティスに準拠することが推奨されます。注意が必要な点としては、トラフィックがそれほど増えていない環境で、10G構成への更新を実施する場合です。たとえば、収集対象のトラフィックが増加していない環境で10Gカードを導入しても、2G(持続)で収集しているようなケースでは、Decoderのパフォーマンスに大きな違いは見られません。

  • ベースライン パーサを組み込み(CPUの利用率が高いSMB/Webmailを除く)、パケット ロスがほぼ0であることを確認する。
  • Parserを追加する場合は、一度に1つまたは2つのParserのみを追加する。
  • 特にピーク トラフィック期間中に、新しく追加したコンテンツのパフォーマンスへの影響を測定する。
  • 構成変更前には発生しなかったドロップが発生し始めたら、新しく追加したすべてのParserを無効にし、一度に1つずつ有効にしながら影響を測定する。これは、パフォーマンスに影響を与えているParserを正確に特定するのに役立ちます。要件に応じて、必要なParserの修正や、場合によっては使用するParserを減らすことによってパフォーマンスを向上できる場合があります。
  • パフォーマンスへの影響は限定的ですが、Feedを追加する場合にも段階的なアプローチを取り、パフォーマンスへの影響測定に役立てるようにします。
  • アプリケーション ルールも一般的にはあまり影響は大きくありませんが、この場合もパフォーマンスへの影響を考慮しながら、段階的なアプローチで追加していくことを推奨します。

最後に、本書の[構成]セクションに記載された推奨の構成変更を加えることで、潜在的な問題を最小限に抑えることができます。

テスト済みのLiveコンテンツ

次のパーサすべてが(個別にではなく)、テストにおいて10Gで動作することが確認されています。

  • MAコンテンツ(Lua Parser x 7、Feed x 1、アプリケーション ルール x 1)
  • 4つのFeed(alert ids info、nwmalwaredomains、warning、suspicious)
  • 41のアプリケーション ルール
  • DNS_verbose_lua(DNS無効化)
  • fingerprint_javascript_lua
  • fingerprint_pdf_lua
  • fingerprint_rar_lua
  • fingerprint_rtf_lua
  • MAIL_lua(MAIL無効化)
  • SNMP_lua(SNMP無効化)
  • spectrum_lua
  • SSH_lua(SSH無効化)
  • TLS_lua
  • windows_command_shell
  • windows_executable

未テスト:

  • SMB_lua、ネイティブSMBはデフォルトで無効化
  • html_threat

その他:

  • HTTP_luaを使用すると、収集レートが9G超から7G未満に低下します。5Gをやや下回る環境では、このパーサをネイティブ パーサの代わりに使用(前述のリストに追加)しても、パケットのドロップは発生しません。 
  • xor_executableは、パースによるCPU使用率を100%に押し上げ、またパースのバックアップにより一時的に大量のドロップを発生させる可能性があります。

テスト済みのLiveコンテンツに基づく統合調整

10G Decoderでは、10Gの速度で実行しながら、単一のConcentratorに対する集計を実行します。Malware Analysis、Event Stream Analysis、Warehouse Connector、Reporting Engineでの集計は、パフォーマンスへの影響が想定され、パケット ロスにつながる可能性があります。

テストされるシナリオの場合、Concentratorの集計は45,000~70,000セッション/秒の速度で実行されます。10G Decoderの収集は、40,000~50,000セッション/秒の速度で実行されます。前述のコンテンツでは、これは約150万~200万メタ/秒になります。高いセッション レートでデータが収集されるため、次の構成変更が推奨されます。

  • Concentratorでのnice集計により、10G Decoderへのパフォーマンス インパクトを抑制します。次のコマンドは、nice集計をオンにします。
    /concentrator/config/aggregate.nice = true
  • Concentratorで大量のセッション処理をサポートするため、/sdk/config/parallel.values16に設定してConcentratorで並列値モードを有効にすることを検討します。これによって、Investigationにおいて毎秒セッション数が30,000を超えるような場合に、パフォーマンスが向上します。
  • 複数の集計ストリームが必要な場合は、代わりにConcentratorから収集することでDecoderへの影響が小さくなります。
  • その他のNetWitness Suiteコンポーネント(Warehouse、Malware Analysis、ESA、Reporting Engine)での集計が必要な環境では、コンテンツとパースのさらなる検討が必要となります。

 

You are here
Table of Contents > DecoderおよびLog Decoderのための追加の手順 > 10G機能の構成

Attachments

    Outcomes