SA構成:グローバル監査ログのトラブルシューティング

Document created by RSA Information Design and Development on Feb 17, 2017
Version 1Show Document
  • View in full screen mode
  

このトピックでは、Security Analyticsでグローバル監査ログを実装するときに発生する可能性のある問題について説明します。このトピックで解決策を確認してください。

グローバル監査ログを構成した後は、監査ログをテストして、監査ログ テンプレートで定義したとおりに監査イベントが表示されることを確認する必要があります。サード パーティ製のSyslogサーバまたはLog Decoderに監査ログが表示されない場合や、監査ログの表示が期待と異なる場合は、以下の基本的なトラブルシューティングを参照してください。それでも問題が解決されない場合は、高度なトラブルシューティングを参考にしてください。  

基本的なトラブルシューティング

サード パーティ製のSyslogサーバまたはLog Decoderで監査ログを表示できない場合は、次の手順を実行します。

  • PuppetとRabbitMQが動作していることを確認します。
  • Syslog通知サーバの構成が有効になっていることを確認します
    (この構成は、[Administration]>[システム]>[グローバル通知]にあります。[レガシー通知]を選択しないでください)。
  • グローバル監査ログの構成を確認します。

グローバル監査ログの構成グローバル監査ログの検証 で手順を確認してください。

監査ログをLog Decoderに送信する場合は、次の手順を実行します。

  • Log DecoderがConcentratorで集計されていることを確認します([Administration]>[サービス]>(Concentratorの選択)>[表示]>[構成])。
  • 最新のCEF Parserが導入され、有効化されていることを確認します。
  • 監査ログ通知テンプレートをチェックします。CEFテンプレートを使用する必要があり、Log Decoderに入力されるすべてのログでCEFテンプレートを使用する必要があります。

監査ログをサードパーティ製Syslogサーバに送信する場合は、次の手順を実行します。

  • サードパーティ製Syslogサーバ向けに構成された送信先ポートがファイアウォールによってブロックされていないことを確認します。 

高度なトラブルシューティング

グローバル監査ログを使用するには、PuppetとRabbitMQが正しく機能していなければなりません。次のグローバル監査ログ アーキテクチャ図は、監査ログに必要なコンポーネントを示しています。また、個々のサービスからSecurity Analyticsサーバ上のLogstashを経由し、構成されたサード パーティ製SyslogサーバまたはLog Decoderに至るまでの、監査ログの流れも示しています。

監査ログを一元化するため、Security Analyticsの各サービスは、ローカル ホスト上でUDPを使用してポート50514をリスンするrsyslogに監査ログを書き出します。監査ログ パッケージに含まれているrsyslogプラグ インは、追加情報を付加して、これらのログをRabbitMQにアップロードします。Security Analyticsサーバ ホストで実行されるLogstashは、すべてのSecurity Analyticsサービスからの監査ログを集計して、必要な形式に変換し、サード パーティ製SyslogサーバまたはLog Decoderに送信します。グローバル監査ログの形式とLogstashによって使用される送信先ポートの構成は、Security Analyticsのユーザー インターフェイスを使用して行います。 

グローバル監査ログの構成の定義 で手順を参照してください。  

ホスト上のパッケージとサービスの検証

Security Analyticsホスト

以下のパッケージまたはサービスは、Security Analyticsサーバ ホスト上に存在する必要があります。

  • rsyslog-8.4.1
  • rsa-audit-rt
  • logstash-1.5.4-1
  • rsa-audit-plugins
  • rabbitmq server
  • puppet master
  • puppet agent

Security Analyticsホスト以外のホスト上にあるサービス

以下のパッケージまたはサービスは、Security Analyticsサーバ ホスト以外の各ホスト上に存在する必要があります。

  • rsyslog-8.4.1
  • rsa-audit-rt
  • rabbitmq server
  • puppet agent

Log Decoder

グローバル監査ログをLog Decoderに転送する場合は、次のParserが存在し、有効化されている必要があります。

  • CEF

発生する可能性のある問題

アクションを実行したにもかかわらず、構成済みのサードパーティ製SyslogサーバまたはLog Decoderに監査ログが到達しないことがあります。 

この問題は、以下のいずれかまたはすべてが原因となって発生する可能性があります。

  • サービスが、ローカルのSyslogサーバにログを出力していない。
  • 監査ログがローカルのSyslogからRabbitMQにアップロードされていない。 
  • 監査ログがSecurity Analyticsサーバ ホストで集計されていない。
  • Security Analyticsサーバ ホストで集計されたログが、構成されたサードパーティ製SyslogサーバまたはLog Decoderに転送されていない。
  • Log DecoderがCEF形式でグローバル監査ログを受信するよう構成されていない。
    • Log Decoderの収集機能が有効になっていない
    • CEF Parserが存在しない
    • CEF Parserが有効化されていない

有効な解決策

次の表に、各問題に対する有効な解決策を示します。

                             
問題有効な解決策
サービスのログの送信先として、ローカルのSyslogサーバが指定されていない。
  • rsyslogが動作していることを確認します。
    次のコマンドを使用できます。
    service rsyslog status
  • rsyslogがUDPを使用してポート50514をリスンしていることを確認します。
    次のコマンドを使用できます。
    netstat -tulnp|grep rsyslog
  • アプリケーションまたはコンポーネントが監査ログをポート50514に送信していることを確認します。ローカル インタフェースのポート50514に対して、tcpdumpユーティリティを実行します。
    次のコマンドを使用できます。
    sudo tcpdump -i lo -A udp and port 50514

コマンド出力については、以下の「解決策の例」を参照してください。

監査ログがローカルのSyslogからRabbitMQにアップロードされていない。
  • rsyslogプラグ インが動作していることを確認します。
    次のコマンドを使用できます。
    ps -ef|grep rsa_audit_onramp
  • RabbitMQサーバが動作していることを確認します。
    次のコマンドを使用できます。
    service rabbitmq-server status

コマンド出力については、「解決策の例」を参照してください。

監査ログがSecurity Analyticsサーバ ホストで集計されていない。

  • Logstashが動作していることを確認します。
    次のコマンドを使用できます。
    ps -ef|grep logstash
    service logstash status
  • RabbitMQサーバが動作していることを確認します。
    次のコマンドを使用できます。
    service rabbitmq-server status
  • RabbitMQサーバがポート5672をリスンしていることを確認します。
    次のコマンドを使用できます。
    netstat -tulnp|grep 5672
  • Logstashレベルで生成されたエラーがあるかどうかを調べます。
    ログ ファイルの場所は、次のコマンドを使用して確認できます。
    ls -l /var/log/logstash/logstash.*

コマンド出力については、「解決策の例」を参照してください。

Security Analyticsサーバ ホストで集計されたログが、構成されたサードパーティ製SyslogサーバまたはLog Decoderに転送されていない。

  • Logstashが動作していることを確認します。
    次のコマンドを使用できます。
    ps -ef|grep logstash
    service logstash status
  • Logstashレベルで生成されたエラーがあるかどうかを調べます。
    ログ ファイルの場所は、次のコマンドを使用して確認できます。
    ls -l /var/log/logstash/logstash.

コマンド出力については、以下の「解決策の例」を参照してください。

  • 転送先のサービスが動作していることを確認します。
  • 転送先のサービスが正しいプロトコルを使用して正しいポートをリスンしていることを確認します。
  • 転送先のホストに構成されたポートがブロックされていないことを確認します。

Logstashから転送される監査ログにより、Log Decoderで解析エラーが発生している。

  • 適切な通知テンプレートを使用していることを確認します。
    Log Decoderによって解析される監査ログはCEF形式でなければなりません。Log Decoderに直接的または間接的に監査ログを転送するサービスでも、CEFテンプレートを使用する必要があります。
  • 通知テンプレートはCEF規格に従っていなければなりません。
    このガイドの手順を実行してデフォルトのCEFテンプレートを使用するか、厳格なガイドラインに従ってカスタムのCEFテンプレートを作成してください。グローバル監査ログ テンプレートの定義 で補足情報を参照してください。
  • Logstash構成を確認します。

Investigationでカスタム メタ データが表示されない

通常、メタがInvestigationに表示されない場合、そのメタのインデックスが作成されていないことを意味します。調査またはレポート作成目的でカスタムのメタ キーを使用する必要がある場合は、選択したメタ キーがLog Decoder上のtable-map-custom.xmlファイルでインデックス作成されていることを確認します。Log Decoder上のtable-map-custom.xmlファイルを変更するには、「テーブル マップ ファイルの維持」の手順に従ってください。

カスタムのメタ キーがConcentrator上のindex-concentrator-custom.xmlでもインデックス作成されていることを確認します。「サービス インデックス ファイルの編集」で追加情報を提供しています。

次の図は、Security Analyticsのtable-map-custom.xmlファイルの例を示しています([Administration]>[サービス]>(Log Decoderを選択)>[表示]>[構成])。ここでは、カスタム メタの例としてurlがハイライト表示されています。

次のサンプル コードは、前掲のtable-map-custom.xmlファイルからの抜粋です。カスタム メタの例としてurlがハイライト表示されています。

 <mapping envisionName="url" nwName="url" flags="None" envisionDisplayName="Url"/> <mapping envisionName="protocol" nwName="protocol" flags="None" envisionDisplayName="Protocol"/><mapping envisionName="cs_devservice" nwName="cs.devservice" flags="None" envisionDisplayName="DeviceService" /><mapping envisionName="cs_paramkey" nwName="cs.paramkey" flags="None" envisionDisplayName="ParamKey" /><mapping envisionName="cs_paramvalue" nwName="cs.paramvalue" flags="None" envisionDisplayName="ParamValue" /><mapping envisionName="cs_operation" nwName="cs.operation" flags="None" envisionDisplayName="Operation" /><mapping envisionName="sessionid" nwName="log.session.id" flags="None" envisionDisplayName="sessionid" /><mapping envisionName="group" nwName="group" flags="None" envisionDisplayName="group" /><mapping envisionName="process" nwName="process" flags="None" envisionDisplayName="process" /><mapping envisionName="user_agent" nwName="user.agent" flags="None"/><mapping envisionName="info" nwName="index" flags="None"/> 

次の図は、Security Analyticsのindex-concentrator-custom.xmlファイルの例を示しています([Administration]>[サービス]>(Concentratorの選択)>[表示]>[構成])。カスタム メタの例としてurlがハイライト表示されています。

前掲のindex-concentrator-custom.xmlファイルからの次のサンプル コードでは、カスタム メタの例のurlがハイライト表示されています。

 <key description="Severity" level="IndexValues" name="severity" valueMax="10000" format="Text"/><key description="Result" level="IndexValues" name="result" format="Text"/><key level="IndexValues" name="ip.srcport" format="UInt16" description="SourcePort"/><key description="Process" level="IndexValues" name="process" format="Text"/><key description="Process ID" level="IndexValues" name="process_id" format="Text"/><key description="Protocol" level="IndexValues" name="protocol" format="Text"/><key description="UserAgent" level="IndexValues" name="user_agent" format="Text"/><key description="DestinationAddress" level="IndexValues" name="ip.dst" format="IPv4"/><key description="SourceProcessName" level="IndexValues" name="process.src" format="Text"/><key description="Username" level="IndexValues" name="username" format="Text"/><key description="Info" level="IndexValues" name="index" format="Text"/><key description="customdevservice" level="IndexValues" name="cs.devservice" format="Text"/> <key description="url" level="IndexValues" name="url" format="Text"/> <key description="Custom Key" level="IndexValues" name="cs.paramkey" format="Text"/><key description="Custom Value" level="IndexValues" name="cs.paramvalue" format="Text"/><key description="Operation" level="IndexValues" name="cs.operation" format="Text"/><key description="CS Device Service" level="IndexValues" name="cs.device" format="Text" valueMax="10000" defaultAction="Closed"/> 

解決策の例

次の解決策の例は、サンプル コマンドの出力を示しています。有効な解決策の全リストは、前掲の表を参照してください。

rsyslogが動作していることを確認します。

次のコマンドを使用できます。
service rsyslog status

rsyslogがUDPを使用してポート50514をリスンしていることを確認します。

次のコマンドを使用できます。
netstat -tulnp|grep rsyslog

アプリケーションまたはコンポーネントが監査ログをポート50514に送信していることを確認します。

次の図は、ローカル インタフェースのポート50514に対してtcpdumpユーティリティを実行した出力結果を示しています。

次のコマンドを使用できます。
sudo tcpdump -i lo -A udp and port 50514

rsyslogプラグ インが動作していることを確認します。

次のコマンドを使用できます。
ps -ef|grep rsa_audit_onramp

RabbitMQサーバが動作していることを確認します。

次のコマンドを使用できます。
service rabbitmq-server status

Logstashが動作していることを確認します。

次のコマンドを使用できます。
ps -ef|grep logstash
service logstash status

RabbitMQサーバがポート5672をリスンしていることを確認します。

たとえば、次のようなコマンドを入力します。
netstat -tulnp|grep 5672

Logstashレベルで生成されたエラーがあるかどうかを調べます。

ログ ファイルの場所は、次のコマンドを使用して確認できます。
ls -l /var/log/logstash/logstash.*

問題と有効な解決策の全リストは、前掲の表「有効な解決策」を参照してください。

You are here
Table of Contents > システム構成のトラブルシューティング > グローバル監査ログのトラブルシューティング

Attachments

    Outcomes