Decoder：10G機能の構成

 

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

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

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

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

ハードウェアの動作条件

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

ソフトウェアの動作条件

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

10G Decoderのインストール

注：新しいSeries 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 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. 収集ポート アダプタを選択します。オプションは以下のとおりです（以下の例では、「p1p1」と「p1p2」はプレースホルダーであり、独自のインタフェース名で置き換える必要があります）。
   • 単一ポートで収集：PFRINGZC,p1p1またはPFRINGZC,p1p2
   • 両ポートで収集： PFRINGZC,P1P1を選択し、［エクスプローラ］ビューでcapture.device.params = device=zc:p1p2,zc:p1p1を設定します。

6. 書き込みスレッドが収集速度を維持できない場合は、次の操作を試してください。

   /datebase/config/packet.integrity.flushをnormalに変更します。

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

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

   • セッションのパースがボトルネックになると、アプリケーションParser（HTTP、SMTP、FTPなど）が一時的に無効になります。
   • アプリケーションParserが無効になっている間でもセッションはドロップせず、それらのセッションの再生成機能のみが影響されます。
   • アプリケーションParserが無効になっている間でも、セッションにはネットワーク メタ（ネットワークParser）が引き続き関連づけられます。
   • 統計値/decoder/parsers/stats/blowoff.countには、アプリケーションParserをバイパスしたすべてのセッションの数が表示されます（ネットワークParser引き続き実行されます）。
   • セッション パースに潜在的なボトルネックがなくなると、アプリケーション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.paramsのcore= parameter
   • /etc/pf_ringディレクトリの構成ファイル

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

一般的な構成パラメータ

以下に、一般的な構成パラメータを挙げます。実際のパラメータは、メモリと使用可能な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のパフォーマンスに大きな違いは見られません。

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

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

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

次のParserが全て（単体毎ではなく）、テストにおいて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をやや下回る環境では、このParserをネイティブParserの代わりに使用（前述のリストに追加）しても、パケットのドロップは発生しません。 
• 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セッション/秒の速度で実行されます。前述のコンテンツでは、これは約1,500,000～2,000,000メタ/秒になります。高いセッション レートでデータが収集されるため、次の構成変更が推奨されます。

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

新しいストレージの追加時に読み取り/書き込み処理を最適化する

10G Decoderは、読み取り処理と書き込み処理を複数のボリュームにわたってずらして実行するよう最適化されています。そのため、現在書き込み中のファイルと次に書き込まれるファイルは、それぞれ別のボリューム上に置かれます。これにより、最後に書き込まれたファイルからデータを読み取るときに、現在書き込み中のファイルは別のボリューム上にあるため、RAIDボリュームでスループットを最大限に高めることができます。ただし、Decoderの使用後にボリュームが追加された場合は、すでにフルになっているボリュームがあり、新しいボリュームだけが新しいファイルを書き込める場所になるため、処理をずらして実行する機能は制限されます。

この状況を改善するため、管理者は、少なくとも2つのボリュームを持つ既存のNetWitness Platformデータベース（パケット、ログ、メタ、セッション）でstaggerコマンドを実行することで、全ボリュームにわたってファイルをずらして処理し、読み取り/書き込みパターンを最適化できます。この機能の主な用途として、新しいストレージを既存のDecoderに追加したときに、収集を再開する前にボリュームをずらして実行できます。

このコマンドの構成ノードは、セッション、メタ、パケットの各データベースです。各ノードは/database/config（通常はルート ノード）の配下にあります。Decoderの構成ノードは次のとおりです。

• /database/config/packet.dir
• /database/config/meta.dir
• /database/config/session.dir

これらの構成ノードのフォーマットについては、『NetWitness Platformコア チューニング ガイド』に記載されています。

一般的に、staggerコマンドは10G Decoderのみ（通常はパケットのみ）で有効です。複数のボリュームが存在する場合は、パケットの格納と取得のパフォーマンスを最大限に高めることができます。このシナリオでは、Decoderは空き容量の最も多いボリュームを常にいっぱいにします。ボリュームのサイズがほぼ同じである場合、実行をずらす書き込みパターンになり、読み取りと書き込みの最大スループットを全ボリュームにわたって達成できます。ただし、この状態になるのは、当然のことながら、Decoderの初期導入時に複数のパケット ストレージ ボリュームが存在している場合だけです。

一般的な用途として、既存のDecoderにストレージを追加して保存期間を長くすることが挙げられます。ただし、格納済みパケットで既存のボリュームがすでにいっぱいになっている導入環境にストレージを追加すると、Decoderは既存のストレージにパケットをロールアウトする前に、新しいストレージをパケットでいっぱいにします。その結果、現在書き込み先として使用されている同一ボリュームで読み取り処理の大半が行われるため、読み取り/書き込みパターンが最適ではなくなります。10G導入環境では、書き込み処理の実行中に読み取り処理がボリュームからブロックされます。ファイルはメモリー内にバッファリングされてから書き込まれるため、そのボリューム上のすべての読み取りが停止されるわけではありませんが、読み取りパフォーマンスは最適化されません。

staggerコマンドを使用すると、ストレージを追加した後で、すべてのボリューム（既存および新規）にわたってファイルをずらして処理するよう指定できるため、読み取りパフォーマンスが最適化されます。

注意：このコマンドは、ストレージがマウントされ、Decoderがそのストレージを使用するよう構成された後（たとえば、マウント ポイントをpacket.dirに追加した後）でのみ実行してください。

このコマンドの欠点は、処理をずらすのに時間がかかることと、staggerの実行中にDecoderでパケットを収集できないことです。

推奨されるワークフロー：

1. すべてのストレージを追加し、マウント ポイントを構成します。
2. 新しいストレージ マウント ポイントをpacket.dir（またはsession.dir/meta.dir）に追加して、サービスを再起動します（非常に重要です）。
3. 収集が停止していることを確認します。
4. staggerを実行する一方で、その処理を開始した接続が、処理が完了するまで決して終了しないよう注意します。接続が終了すると、staggerによる処理はキャンセルされます。処理がキャンセルされた場合、staggerですでに処理されたファイルはそのまま残ります。この処理を再開するには、同じコマンドを再実行します（すでに実行済みの作業を再実行する必要はありません）。staggerをNwConsoleから実行する場合は、timeout 0コマンドを実行してからstaggerコマンドを送信します。これにより、通常の30秒のコマンド タイムアウトが回避されます。
5. staggerコマンド終了後に収集を開始します。

このコマンドのパラメータは次のとおりです。

• type：時間差をおいて処理するデータベース（セッション、メタ、パケット）。通常、時間差をおいた処理に有効なのはパケット データベースだけですが、セッションまたはメタ データベースの複数のボリュームが存在する場合は、それらのデータベースに対して使用することが可能です。セッションおよびメタ データベースは、書き込むデータの量がパケット データベースよりも大幅に少ないため、staggerによるパフォーマンスの向上はさほど顕著となりません。
• dryRun：true（デフォルト）の場合、実行される処理の説明だけが返されます。falseの場合は、ファイルの読み取り/書き込みパターンが実際に最適化されます。ファイルの処理を実際にずらすには、falseを渡す必要があります。

NwConsoleからの使用例：

login <decoder>:50004 <username> <password>

timeout 0

send /database stagger type=packet dryRun=false

RESTful APIを使用してこのコマンドを実行する場合は、サービスからのタイムアウトを防ぐため、追加のパラメータ expiry=0を指定してください。また、処理が完了する前にHTTPクライアントが切断されないようにすることも必要です。