DLP検出サーバーの状態が「不明 (Unknown)」と表示される
search cancel

DLP検出サーバーの状態が「不明 (Unknown)」と表示される

book

Article ID: 249768

calendar_today

Updated On:

Products

Data Loss Prevention Enforce

Issue/Introduction

このドキュメントは、Data Loss Prevention (DLP) 検出サーバーの状態が「不明 (Unknown)」と表示される場合の、様ざまな状況に対応するトラブルシューティングの要となる情報を提供しています。
例:

  • DLP Enforceサーバーのコンソールで、システム > サーバーとDetectors > 概要 の配下に、1台、または複数台の検出サーバーの状態が「不明」と表示される。
  • 既存のDLP環境に検出サーバーを追加し、MonitorControllerサービスを再起動した後、すべてのサーバーの状態が「不明」と表示される。
  • Enforceサーバーと検出サーバーのアップグレード後、すべてのサービスは実行中だが、検出サーバーの状態に「実行中」と「不明」が交互に表示される。
    これを確認するには、システム > サーバーとDetectors > 概要 を表示し、「このページを更新」アイコンを何度かクリックしてください。
    ページの更新を行うたびに、検出サーバーの状態が変更されることが確認できます。
  • Enforceサーバーのコンソールにログイン後、状態が「不明」の検出サーバーをクリックすると、FileReaderの状態が「選択項目の実行中」または、「停止」と表示される。
  • Enforceサーバーのアップグレード後、検出サーバーをアップグレードする前に状態を確認すると、状態が「不明」と表示される。

注意: Cloud Detector の状態が「切断」、または「不明」と表示される場合は、Landing page: DLP cloud detectors disconnected (broadcom.com) をご覧ください。

問題の状況によりますが、以下のようなエラーが表示される場合があります。

ネットワーク関連に問題がある場合:

EnforceサーバーのMonitor Controller ログより:

FINE: failed to finish connection to: test:incidentwriter:[IP ADDRESS]:8100
com.vontu.communication.transport.exception.TransportException: java.net.ConnectException: Connection timed out: no further information
.......
Caused by: java.net.ConnectException: Connection timed out: no further information
......
FINE: connect operation in SSLConnect failed
com.vontu.communication.transport.exception.TransportException: java.net.ConnectException: Connection timed out: no further information
........
May 12, 2010 11:57:06 AM com.vontu.communication.transport.ConnectWrapperOperation select
INFO: connectOp select failed

検出サーバー

VontuMonitor ログより:

INFO   | jvm 12   | 2012/03/22 02:47:04 | WrapperSimpleApp: Encountered an error running main:
INFO   | jvm 12   | 2012/03/22 02:47:04 | WrapperSimpleApp: com.vontu.boxmonitor.BoxMonitorException: Monitor Error 4162.

BoxMonitor ログより:

16/03/2012 2:25:17 AM com.vontu.boxmonitor.BoxMonitor main|
SEVERE: (BOXMONITOR.2) BoxMonitor failed to startup
com.vontu.boxmonitor.BoxMonitorException: Monitor Error 4162.

以下のエラーが表示される場合もあります。

Sep 25, 2014 10:11:31 AM com.vontu.communication.transport.ServerChannelManager <init>
SEVERE: failed to init server channel channel manager
Sep 25, 2014 10:11:31 AM com.vontu.communication.transport.ServerChannelManager SEVERE: failed to init server channel channel manager java.net.BindException: Cannot assign requested address

SSL/Keystoreに問題がある場合:

検出サーバーのboxmonitorログに、以下のようなログが記録されます。

INFO: Operation com.vontu.communication.transport.AcceptWrapperOperation:1481653881505:null:com.vontu.communication.transport.SessionIdentifier@708fc9e5 failed with exception: com.vontu.communication.transport.exception.TransportException: javax.net.ssl.SSLHandshakeException: no cipher suites in common
com.vontu.communication.transport.ChannelManager handleOperationFailure
INFO: removing session from cache: com.vontu.communication.transport.SessionIdentifier@708fc9e5 for id: null

新たに検出サーバーを追加した場合:

monitor controllerログに以下のようなログが記録されます。

XXX XX, XXXX XX:XX:XX XX com.vontu.communication.transport.OperationManager enqueue
INFO: blocking on op mgr queue

この場合、問題を解決にするには、検出サーバーを増やすためにJavaの最大ヒープメモリ容量maxmemoryを増やしてください。
Javaのmaxmemoryは、検出サーバー12台あたり4GB必要です。

FileReaderの状態が「選択項目の実行中」または、「停止」と表示される場合:

検出サーバーのFileReaderログに、「no disk space」のエラーが記録され、それ以降ログが書き込まれていません。

発見スキャン (Discover Scan) を主な目的とするDLP環境では、すべての検出サーバーの状態が「不明」と表示されます。

Cause

  • ネットワーク接続の問題
  • SSL/Keystoreの問題
  • リソースやチューニングの問題
  • 大量の検出サーバー
    大量の検出サーバーがある環境では、すべてのトランスポート接続でオペレーションを制御するEnforceサーバーのキューがオーバーロードする可能性があります。
    このような問題が発生した場合、すべての検出サーバーの状態が「不明」と表示されます。
    既存の環境に新しい検出サーバーを追加した場合に多く発生することが知られています。
  • 検出サーバーの状態に「実行中」と「不明」が交互に表示される場合
    Enforceサーバーのアップグレード処理が完了しておらず、検出サーバーからの状態のアップデートを受信するためにMonitor Controllerに使用されているポートと同じポートで、検出サーバーに接続しています。
  • FileReaderの状態が「選択項目の実行中」または、「不明」と表示される場合
    検出サーバーのディスク容量が100%使用されています。
  • 不適切なJavaの最大ヒープメモリがSymantecDetectionServerControllerプロセスに割り当てられています。
  • Enforceサーバーが新しいバージョンにアップグレードされ、検出サーバーが同じバージョンにアップグレードされる前に、検出サーバーのサービスを再起動されました。

Resolution

 

ネットワーク接続の問題

以下の手順に従って、ホストに接続できるか、名前解決はできるか、IPフィルタリングの問題はないかなどの診断を行ってください。

  1. Enforce UIの設定で使用されている、検出サーバーのホストや完全修飾ドメイン名 (FQDN) を確認します。
  2. EnforceサーバーでWindowsのコマンドプロンプト (Windows)、または、ターミナルウィンドウ (Linux) を起動します。
  3. 検出サーバーのIPアドレスに対し、Pingを実行します。
    ※正しいIPアドレスやホスト名に置き換えて実行してください。
    例) ping 10.10.10.1 
想定される結果 次の手順
ping (ホスト名) 実行時のエラーメッセージ 
"...could not find host..."
名前解決に問題がある可能性があります。
ネットワーク管理者にご相談ください。
100% packet loss
(すべての ping リクエストがタイムアウトする)
検出サーバーに接続できません。
ネットワークとルーティングの問題を解決し、再度pingテストを行ってください。
Packet loss 
(いくつかの ping リクエストがタイムアウトする)
Enforceサーバーと検出サーバー間にネットワークの問題があります。ネットワークとルーティングの問題を解決し、再度pingテストを行ってください。
0% packet loss

次の項目に進んでください。

 

nslookupコマンドの実行

以下のようにnslookupコマンドを実行します。 (Windows、Linux共通)

コマンド 例)
nslookup <server name> 
nslookup <server name>.example.com

出力 例)
Server:
Address:
Name: <server name>
Address: 10.10.10.1
Server:
Address:
*** <server name> can't find <server name>: Non-existent domain

想定される結果 次の手順
DNSに登録されている名前やIPアドレスと、Enforceサーバーに登録されている検出サーバーの設定にに相違がある。

クエリの結果とサーバー名やIPに違いがある場合、問題を解決するために、DNSサーバー管理者にご相談ください。

短期的解決方法としては、EnforceサーバーのローカルHostsファイルにホスト名、またはFQDNを追加してください。

Windows: c:\windows\system32\drivers\etc\hosts 
Linux: /etc/hosts

記入例)
10.10.10.1    <server name> <server name>.example.com

通信ポートのテスト

Telnetクライアントを使って、Enforceサーバーから検出サーバーのデフォルトの通信ポート8100接続します。

telnet <server name> 8100

想定される結果 次の手順
...Could not open connection... すべてのネットワーク、またはホストベースのファイアウォールで、Enforceサーバーから検出サーバーへの受信が、ポート8100で許可されていることをご確認ください。
...Connection refused... ポート8100が他のアプリケーションで使用されている可能性があります。
他のアプリケーションとポートが衝突していないか、システム管理チームにご相談ください。
Telnet session Could not open connection to the host, on port 8100: Connect failed 検出サーバーで、「Symantec Detection Server」サービスが実行中であることを確認します。
また、ポート8100が開いており、netstatコマンドを実行すると、ステータスがLISTENINGと表示されることをご確認ください。
注意: Network Monitorの場合、複数のIPアドレスがある場合、ポート8100でListening しているIPがキャプチャカードのIPアドレスでないことを確認してください。
キャプチャカードのIPアドレスである場合、configフォルダのcommunication.propertiesで設定されているバインドアドレスを確認してください。

上記の手順で問題を解決できない場合、以下の操作を行ってください。

  1. 検出サーバー上で、\Protect\Config\Communication.propertiesファイルをテキストエディタで開きます。
    デフォルトでは、serverBindName = はコメントアウトされています。

    例)
    # Transport bind address. 
    # The IP address of the NIC that transport server sockets and the registry should be bound to; 
    # The sockets will be bound to the default IP address on the machine if this value is not specified. 
    # serverBindName =

  2. 上記の設定の場合、MonitorサービスはデフォルトのIPアドレスにバインドされます。
  3. serverBindName = の設定に古いIPアドレスが入力されている、または、Monitor Serviceに特定のIPアドレスをバインドしたい場合、その行をコメントアウトするか、新しいIPアドレスを入力します。
  4. 必要に応じて "serverBindName="の設定をアップデートします。
  5. 以下のように、検出サーバー上でVontu Monitorサービスを再起動します。
    1) スタート > ファイル名を指定して実行 を選択し、services.msc と入力し実行します。
    2) Vontu Monitorサービスを右クリックし、再起動を選択します。
  6. Enforceサーバーのコンソールを確認し、検出サーバーと通信をしているか確認します。

その他の解決策:

以下のように、DLPサービスで使われているアカウントのアクセス権を制限する、ネットワークアクセスコントロールリスト (ACL) が設定されていないことを確認してください。

  1. 検出サーバーで、スタート > 名前を指定して実行 を選択し、services.msc を起動します。
  2. それぞれのDLPサービスを右クリックし、「プロパティ」を開きます。
  3. 「ログオン」タブを開きます。
  4. サービスのログオンに使用されているアカウントをメモします。
  5. アカウントに設定されているアクセス権に問題がないことを確認します。
    上記の手順について追加のサポートが必要な場合、ベンダーへお問い合わせください。

------------------------------------------------------------------------------------------

SSL/Keystore の問題:

各サーバーは、Enforceに最初に追加された時に作成される独自のKeystoreを持っています。
これはEnforceサーバーのKeystoreディレクトリ\SymantecDLP\Protect\keystoreにある以下のフォーマットに合致するファイルで確認することができます。

  • enforce..sslKeyStore
  • monitor####.timestamp.sslKeyStore

Monitor名の最後につけられる数字は、殆どの場合、検出サーバーのmonitor ID を反映しています。

monitor IDを確認するには、サーバーの概要画面で検出サーバーにマウスカーソルを重ね合わせ、ウィンドウの下部に表示されるjavascriptの情報を確認してください。

Keystoreファイルの名前は、大文字/小文字を区別します。あるOS
から別のOSにコピーする際は、この名前が変更されていないことをご確認ください。
例: monitor.timestamp.sslKeyStore

この名前が変更された場合、VontuMonitor サービス起動時に、Linux Monitorは以下のような問題を報告する場合があります。

ログのメッセージ ログ 解決方法
"Unable to resolve the full path of the configuration file, start: No such file or directory" VontuMonitor.log – 検出サーバー Enforceと影響のある検出サーバーの両方で、protect ユーザーが/keystore ディレクトリに対して適切なアクセス権を持っていることをご確認ください。
また、/keystoreディレクトリに適切なkeystoreファイルがあることをご確認ください。
javax.net.ssl.SSLHandshakeException: no cipher suites in common VontuMonitor.log -検出サーバー EnforceサーバーのMonitorController.propertiesと検出サーバーのCommunication.propertiesのSSLcipherSuiteに
共通のSSL アルゴリズム が記載されていることをご確認ください。

 

リソースやチューニングの問題

メモリ不足の監視

VontuMonitorログに、以下のようなエラーが記録されていることがあります。

# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 59136 bytes for Chunk::new
JVM exited unexpectedly.

これはVontuMonitorが正常に動作するために十分なメモリがないことを表しています。

検出サーバーで問題が発生している場合は、\Protect\config\VontuMonitor.confを開き、以下のJava Heap Sizeの値をメモします。

wrapper.java.initmemory
wrapper.java.maxmemory

デフォルトで、これらの値は128/256に設定されています。
この値を増やすには、ベストプラクティスのガイドラインに従ってください。

  • メモリの値は常に128の倍数として増加させます。 (すなわち、128、512、1024、…)
  • maxmemoryは常にinitmemoryの値の2倍になるよう設定し、サーバー上の利用可能なRAMより大きくならないよう設定します。

Vontu Monitorサービスを再起動します。
問題が解決されない場合は、検出サーバーを再起動してください。
これにより、OSにつかまれているリソースが解放されます。

監視コントローラ (Monitor Controller) のリソースが 上限に達している場合

大量の検出サーバーがある環境では、すべてのトランスポート接続でオペレーションを制御するEnforceのキューで「オーバーロード」が発生する可能性があります。
このような問題が発生した場合、すべての検出サーバーの状態が「不明」と表示されます。
多くの場合、既存の環境に新規の検出サーバーを追加した際に発生します。

以下の手順に従って、トランスポート接続のオペレーションのキューサイズを増やしてください。

注意: この変更により、より多くのリクエストが処理のためにキューに入るようになるため、メモリに若干の影響が発生します。

  1. Enforceサーバーで\SymantecDLP\Protect\configを開きます。
  2. MonitorController.propertiesファイルをテキストエディタで開きます。
  3. maxQueueSizeの設定を検索します。
    デフォルトでこの設定は、5000に設定されており、すべてのトランスポート接続でプッシュされるオペレーションの最大値を制御します。
  4. maxQueueSizeの値を10000に変更します。
    この値であれば、大規模環境でみられるオペレーションのリクエストの数を、メモリへの影響を与えることなく処理することができます。
  5. MonitorControllerサービスを再起動します。

監視コントローラ (Monitor Controller) で設定されているメモリ上限が低すぎる場合

以下のエラーがVontuMonitorController.log (Linux のみ) に記録されます。

java.lang.OutOfMemoryError: unable to create new native thread

メモリ不足のエラーに「unable to create new native thread」のメッセージが含まれている場合、RedHad Linuxで1ユーザーが同時に実行できるプロセス数が制限されていることが原因となって問題が発生している可能性が高いです。

  1. rootレベルのユーザーとしてEnforceサーバーにログインします。
  2. rootに切り替えます。su - root
  3. 以下のコマンドを実行し、limitsファイルを画面に表示します。
    cat /etc/security/limits.conf
  4. limits.d ファイルを見直し、protectユーザーに対する明示的な制限を確認します。

protectユーザーに明示的な制限がかかっていない場合、以下をlimits.confファイルに追加し、プロセス数の上限をデフォルトの1024より上の値を設定してください。

protect soft    nproc   4096
protect hard    nproc   63536

サービスのクラッシュ

検出サーバーのVontuMonitor.logに、以下のエラーが繰り返し記録されます。

# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate bytes for ChunkPool::allocate
# An error report file with more information is saved as:
# \Protect\bin\hs_err_pidNNNN.log
JVM exited unexpectedly.

サードパーティーアプリケーションによって、Java.exeが正常に起動できない場合があります。hs_err_pidXXXファイルを収集し、サポートに連絡されることをお勧めします。

大量の検出サーバー

以下の手順に従って、トランスポート接続のオペレーションのキューサイズを増やしてください。

注意: この変更により、より多くのリクエストが処理のためにキューに入るようになるため、メモリに若干の影響が発生します。

  1. Enforceサーバーで\SymantecDLP\Protect\configを開きます。
  2. MonitorController.propertiesファイルをテキストエディタで開きます。
  3. maxQueueSizeの設定を検索します。
    デフォルトでこの設定は、5000に設定されており、すべてのトランスポート接続でプッシュされるオペレーションの最大値を制御します。
  4. maxQueueSizeの値を30000に変更します。
    この値であれば、大規模環境でみられるオペレーションのリクエストの数を、メモリへの影響を与えることなく処理することができます。
  5. 変更を保存し、ファイルを閉じます。
  6. MonitorControllerサービスを再起動します。
  7. 短い時間内に、Enforceコンソールにすべての検出サーバーが報告されます。

検出サーバーの状態に「実行中」と「不明」が交互に表示される

アップグレードプロセスを停止してください。

  1. Enforceサーバーでタスクマネージャを開きます。
    スタート > ファイル名を指定して実行 を選択し、taskmgr を起動します。
  2. 「upgrader-java」という名前のプロセスを検索します。
  3. 「upgrader-java」プロセスを右クリックし、「プロセスの終了」を選択します。

FileReaderの状態が「選択項目の実行中」または、「停止」と表示される

  1. 検出サーバーのディスクが容量不足になっていないことを確認してください。
    検出サーバーのローカルでログインします。
    [Windows] スタート > 名前を指定して実行 を開き、diskmgmt.msc を起動します。
    [Linux] df -h またはdf –a を実行します。
  2. ディスクの使用量が100%の場合、ドライブの空きを増やしてください。
  3. 検出サーバーのDLPサービスを再起動します。

Enforceサーバーのアップグレード後、検出サーバーの状態が「不明」と表示される

検出サーバーがEnforceサーバーと同じバージョンのアップグレードされる前に検出サーバーのサービスが再起動された場合、Enforceサーバーと検出サーバーを再接続させるには、検出サーバーをEnforceサーバーと同じバージョンにアップグレードする必要があります。

SymantecDetectionServerControllerプロセスへの不適切なメモリの割り当て

日ごと/週ごとに大量の増分スキャンを実行し、多数のDiscoverスキャンを同時に実行するようなDLP環境では、
SymantecDLPDetectionServerControllerプロセスに相当量のJavaヒープメモリを割り当てる必要があり、この割り当てが適切に行われない場合、EnforceサーバーのSymantecDLPDetectionServerControllerプロセスが停止し、すべての検出サーバーの状態が「不明」と表示されることが確認されています。

サービスの再起動では問題は解決されず、しばらくすると再びサービスが停止する可能性があります。これは、Enforceログに問題を特定する有用な情報が記録されない、または全く記録されないサイレント障害である可能性があります。
この問題を確認するために一番いい方法は、Enforceサーバー上の個々のDLPプロセスのメモリ使用量を監視し、どのプロセスが最大割り当てに近い状態で実行されているかを確認することです。

注意: 最大に近いメモリを割り当てられたJavaプロセスの実行すると、パフォーマンスが低下し、ガーベージコレクションによりCPUを過剰に消費するため避けるべきです。

プロセスが最大割り当てに近い状態で実行される場合、サーバー上の利用可能なRAMと他のDLPサービスやプロセスへのヒープ割り当てを考慮して最大割り当ての値を増やす必要があります。

Additional Information

※ このドキュメントは、以下のドキュメントを元に作成されています。

DLP Detection servers show "Unknown" status