本セクションでは、本アプリケーション使用時によく起こる問題について説明し、それらの問題に対処するガイダンスを提供ます。技術サポートに連絡する必要がある場合、本セクションは、サポート担当者による支援に必要な情報を収集するために役立ちます。
セキュリティ・コンソールまたはスキャン・エンジンの問題が起こっている場合、ログファイルを参照することがトラブルシューティングとして有効である場合があります。ログファイルは、ルーチン・メンテナンスおよびデバッグ目的にも有用です。
本セクションでは、スキャンイベントに関連するスキャンログは扱いません。スキャンログを表示するをご参照ください。
ログファイルは、セキュリティ・コンソール上の [installation_directory]/nsc/logsディレクトリ、およびスキャン・エンジン上の [installation_directory]/nse/logsにあります。以下のログファイルを利用可能です:
以前の製品バージョンでは、API情報はnsc.logに保存されていました。
[yyyy-mm-ddThh:mm:ss GMT] [LEVEL] [Thread:NAME] [MESSAGE]
例:
2011-12-20T16:54:48 [INFO] [Thread:Security Console] Security Console started in 12 minutes 54 seconds
当該日付および時刻は、メッセージを生成するイベントのオカレンスに対応しています。
重大な問題のトラブルシューティングのためにログファイルを読む場合は、まずERRORレベルおよびWARNレベルのメッセージを探すことが有用でしょう。
スレッドにより、メッセージを生成したプロセスが識別されます。
デフォルトでは、INFOレベル、およびINFOレベルより高い深刻度レベルのメッセージがすべてのログファイルに表示されます。これは、INFO、WARN、ERRORの各メッセージが表示され、DEBUGメッセージは表示されないということを意味します。どの深刻度レベルをログファイルに表示するかを変更可能です。例えば、WARNおよびERROR深刻度レベルを持つメッセージ以外は、すべてフィルターで除外したいというケースが考えられます。または、メンテナンスやデバッグの目的でDEBUGメッセージを含めたいかもしれません。
設定ステップは、セキュリティ・コンソールでも分散型スキャン・エンジンでも同じです。表示するログ深刻度レベルを設定するには、以下のステップに従います:
注意: user-log-settings.xmlファイルにおいて、デフォルトとはnsc.log fileまたはnse.log fileを指し、インストールされたコンポーネントがセキュリティ・コンソールであるか分散型スキャン・エンジンであるかにより異なります。
<!--
and -->
:<!-- <property name="default-level" value="INFO"/> -->
<property name="default-level" value="DEBUG"/>
<property name="default-level" value="DEBUG"/>
<property name="auth-level" value="DEBUG"/>
<property name="access-level" value="DEBUG"/>
<property name="mem-level" value="DEBUG"/>
変更は約30秒後に適用されます。
トラブルシューティング・ページのログを送信をクリックして、スキャン・エンジンにより生成されたログを技術サポート宛てに送信できます。
注意: 直リンクを利用できない場合のため、オプションとしてSMTP(電子メール)送信メカニズムもサポートしています。詳細については、技術サポートまでお問い合わせください。
ログを送信するには:
セキュリティ・コンソールに、ログをアップロードするためのボックスが表示されます。
当該メッセージで、スキャンエラー、サポートケース、異常なシステム動作のレポートについて言及します。
セキュリティ・コンソールが直接インターネットアクセスを有していない場合、プロキシサーバーを利用してログを技術サポート宛てに送信可能です。
アップデートのプロキシ設定を設定するには:
管理ページが表示されます。
セキュリティ・コンソール設定パネルが現れます。
技術サポート宛てにログを送信するためのセキュリティ・コンソール設定パネル:プロキシ設定
スキャンの結果が不正確となる(偽陽性、偽陰性、誤ったフィンガープリントなど)場合、スキャンログ機能を利用して、技術サポートチームが原因をトラブルシューティングするのに役立つデータを収集可能です。アセット設定エクスポート(ACES)は、Windowsレジストリキー、SSHコマンド実行ファイル、およびファイルバージョンといったトラブルシューティングに役立つ情報を、スキャン中に収集するロギング機能です。
以下は、ACESログファイルの例です:
<ace:collected_object>
<ace:source-id>0</ace:source-id>
<ace:thread-activity>do-unix-create-system-fingerprint@example.com:22</ace:thread-activity>
<ace:remote_execution_item id="42">
<ace:command>freebsd-version</ace:command>
<ace:rc datatype="int">0</ace:rc>
<ace:stdin status="does not exist"/>
<ace:stdout>10.0-RELEASE
</ace:stdout>
<ace:stderr status="does not exist"/>
<ace:start_time datatype="int">1443208125966</ace:start_time>
<ace:end_time datatype="int">1443208125982</ace:end_time>
</ace:remote_execution_item>
</ace:collected_object>
本機能を利用するには、2 つの主要ステップを行います:
注意: 個別のサイトまたは ACES ロギングが有効化されている小さなサイトを、スキャンすることを推奨します。
ACES ロギングはデフォルトでは、アセット設定エクスポートスキャンテンプレート上で有効化されます。しかし、特定の環境でより良く機能するよう調整されたカスタム・テンプレートを利用してスキャンしてもよいでしょう。カスタム・スキャンテンプレート上で ACES を有効化するには:
注意: 現在のところ、デフォルト 設定では ACES ロギングを提供していませんが、今後のアップデートで一部の ACES 機能を提供する予定です。
当該テンプレートでサイト全体をスキャンする場合は、テンプレートをサイト設定に追加してからサイトをスキャンします。スキャンテンプレートを選択するをご覧ください。
注意: ACES ロギングでは、スキャンするアセットの数によっては、ディスク容量に負担がかかるほど多量のデータが収集される場合があります。
特定のアセットを当該テンプレートで手動スキャンする場合、そのテンプレートをスキャンダイアログに追加します。手動スキャンを実行するをご参照ください。
ACESロギングを有効化したスキャンはそれぞれ、ACESデータのZipアーカイブをスキャンディレクトリ内に保存します。以下で特定可能です:
[installation_directory]/nse/scans/[silo_ID]/[scan_ID]/ACES.zip.
例:
/opt/rapid7/nexpose/nexpose/nse/scans/00000000/0000000000000001$/ACES.zip
特定のスキャン ID を決定するには、以下のステップを行います:
スキャン ID を決定する
複数の診断を実行して、システムパフォーマンスに影響を与えている問題を明確にできます。
社内アプリケーション問題のための診断を実行するには:
セキュリティ・コンソールにトラブルシューティングページが表示されます。
リクエストした診断の実行後に、セキュリティ・コンソールに結果の表が表示されます。各項目には赤または緑のアイコンが付記されており、それぞれのシステムコンポーネントに問題があるかどうかが示されます。
起動中にサブシステムの危機的なエラーが起こった場合、本アプリケーションは適切なメンテナンスタスクをキューに入れ、その障害に対応しようと試みます。その後、本アプリケーションはメンテナンス・モードで再起動します。
あなたが管理者である場合、ログオンして障害の原因を調査可能です。必要に応じて、問題をトラブルシューティングするための特定ステップを行うことが可能です。
2通りの回復タスクを利用可能です:
本アプリケーションは、メンテナンス・ウェブサーバーでデフォルトのポート3780が利用できないと、非常に致命的な障害のケースではメンテナンス・モードでの再起動に失敗する場合があります。これは、すでに実行中のインスタンスがある場合、または1つ以上の主要設定ファイルが無効/紛失している場合に、起こる可能性があります。これらは.nsc、.xml、および.userdbといった拡張子を持つファイルです。
アイドルセッションにおいてウェブ・インターフェース・セッションがタイムアウトした場合、セッションをリフレッシュできるログオンウィンドウがセキュリティ・コンソールに表示されます。ウェブ・ブラウザとセキュリティ・コンソール・ウェブサーバーとの間の交信上の問題によりセッションのリフレッシュが妨げられている場合には、エラーメッセージが表示されます。未保存の作業がある場合、ユーザーはそのページを離れたりブラウザを閉じたりしないでください。交信上の問題が解決した後に、その作業が失われる可能性があります。
交信上の障害は、以下の理由のいずれかにより起こります。これらのいずれかが起こった場合、適切な措置をとってください:
ユーザーのセッション・リフレッシュのリクエストに対するセキュリティ・コンソールの応答の顕著なディレイも、障害メッセージが現れる原因となる場合があります。
あるユーザーが不正確なパスワードで何度もログオンを試行すると、本アプリケーションはロックアウトをリセットするまで当該ユーザーをロックアウトします。
デフォルトのロックアウト閾値は、試行4回です。グローバル管理者は、セキュリティ・コンソール設定:ウェブサーバーページでこのパラメータを変更可能です、セキュリティ・コンソール・ウェブサーバーのデフォルト設定を変更するをご参照ください。
以下の3つの方法のいずれかを利用して、ロックアウトをリセット可能です:
アカウントロック解除
を実行します。コマンド・コンソールを利用する。時折、スキャンに通常より長い時間がかかる、または完全に停止したように見えることがあります。
スキャンにどれだけ時間がかかるか正確に予測することは不可能です。スキャン時間は、ターゲットアセットの数およびスキャンテンプレートの綿密さや複雑さといった要素により異なります。しかし、以前のスキャンにかかったスキャン時間と比較することで、スキャン完了までの時間が例外的に長くなっているかどうかを監視可能です。
一般的に、単一ホスト上でスキャンが8時間以上実行されている場合、または任意サイト上で48時間以上実行されている場合は、特定の問題についてチェックすることをお薦めします。
スキャンの開始、一時停止、再開、または停止を試みて、操作が進行中であると伝えるメッセージが長時間表示される場合、これはセキュリティ・コンソールのスキャン・エンジンとの交信におけるネットワーク関連のディレイが原因であると考えられます。低帯域幅または高レイテンシーのネットワークにおいて、スキャン操作の遅延はセキュリティ・コンソール/スキャン・エンジン交信におけるタイムアウトの頻発をもたらす可能性があります。これにより、スキャン ステータス情報を受信するセキュリティ・コンソール内でラグが発生する場合があります。タイムアウトを低減させるため、スキャン・エンジン応答タイムアウト設定を増やすことが可能です。セキュリティ・コンソールと分散型スキャン・エンジンとの接続を設定するをご参照ください。
メモリの問題が原因で、スキャンが遅くなる/失敗する場合があります。メモリ不足をご参照ください。
本アプリケーションが発見する各ターゲットホストについては、脆弱性のチェックが実行される前にそのポートがスキャンされます。ターゲットポートの範囲は、設定可能なスキャンテンプレート設定です。スキャン時間は、スキャンされるポートの数に比例して増加します。
特に、UDPポートのスキャンは遅い場合があります。なぜなら、本アプリケーションはデフォルトでは、1秒に最大2つまでのUDPパケットを送信して、ほとんどのネットワークデバイスのTCP/IPスタックに組み込まれているICMP帯域制限メカニズムがトリガされることを回避しているからです。
スキャン速度を高めるには、よく知られたポートのみ、またはホストに関連するサービスで知られている特定のポートのみを検査するよう、スキャン設定することを検討してみてください。ユーザーガイドのスキャン・テンプレートに取り組む、およびスキャンパフォーマンスを調整するをご参照ください。
スキャン・エンジンがスキャン中にオフラインになった場合、スキャンは停滞しているように見えます。スキャン・エンジンがスキャン中にオフラインになったら、データベースは不完全なスキャンからのデータを削除しなければなりません。このプロセスにより、以下のスキャンログに類似したメッセージが表示されます:
DBConsistenc3/10/09 12:05 PM:Inconsistency discovered for dispatched scan ID 410, removing partially imported scan results...
スキャン・エンジンがオフラインになったら、再起動してください。その後スキャン・エンジン設定パネルに移動して、スキャン・エンジンがアクティブであることを確認します。ユーザーガイドの分散型スキャン・エンジンを設定するをご参照ください。
進行中の、または完了したスキャンのアクティビティログを表示可能です。
スキャンログを表示するには:
コンソールにスキャンログが表示されます。
別のユーザーがスキャンを停止すると、スキャンは停滞しているように見えます。このケースに当てはまるかどうか判定するには、以下に類似したメッセージのログがないか調べてください:
Nexpose3/16/09 7:22 PM:Scan [] stopped:"maylor" <>
スキャンログを表示するをご参照ください。
時折、レポート生成に通常より長い時間がかかる、または完全に停止したように見えることがあります。レポート・エラーは、セキュリティ・コンソール・ログで見つけることができます。
メモリの問題が原因で、レポート生成が遅くなる/失敗する場合があります。メモリ不足をご参照ください。
データベース速度は、レポート生成の速度に影響を与えます。時間と共に、古いスキャンからのデータがデータベース内に蓄積されます。これによりデータベースの速度が落ちます。
レポート生成が遅くなったと認識される場合、以下の例に見られるように、他のレポートタスクと期間が一致しないレポートタスクがないか、セキュリティ・コンソール・ログで調べます:
nsc.log.0:Reportmanage1/5/09 3:00 AM:Report task serviceVulnStatistics finished in 2 hours 1 minute 23 seconds
データベースをクリーンアップすることで、多くの場合、レポート生成速度を向上させることができます。データベースの定期的なメンテナンスにより、残余スキャンデータおよびホスト情報が削除されます。スキャンログを表示するおよびデータベースバックアップ/復元およびデータ保持をご参照ください。
スキャンおよびレポートはメモリに負担がかかるタスクですので、これらの操作に関するエラーはメモリの問題であることが多いです。設定を変更して、メモリ使用量を制御可能です。メモリの問題の一部はシステムリソースの制御方法に関連しています。
本アプリケーションがクラッシュした場合、ログファイルに以下のメッセージがあるかチェックして、そのクラッシュの原因がメモリ不足であるかを確認可能です:
java.lang.OutOfMemoryError:Java heap space
このメッセージが表示された場合、技術サポートまでご連絡ください。指示がない限り、本アプリケーションを再起動しないでください。
スキャンはメモリに負担がかかり、かつ頻繁に起こるため、スキャンでのメモリ使用量を制御することが重要です。これを行うと、見返りとして、メモリの問題によりスキャン・パフォーマンスに影響が出ることはなくなります。メモリ制限がスキャンに影響を及ぼさないよう徹底するための戦略を、いくつか挙げてみます。
ターゲットホストの数が増えると、スキャン情報を保存するために必要なメモリ量も増えます。スキャンされるホストの脆弱性スキャンの数があまりにも多いと、メモリ不足のためスキャンが停滞する可能性があります。
任意のスキャンの複雑性を低減するには、2~3のアプローチを試してみてください:
1つのスキャンで発見された任意の脆弱性をパッチした後に、除外したIPアドレスまたは脆弱性をサイト設定に追加して、再度スキャンを実行してください。
さらなる情報については、ユーザーガイドの分散型スキャン・エンジンを設定するおよびスキャン・テンプレートに取り組む、およびスキャンパフォーマンスを調整する。
複数の同時スキャンの実行により、セキュリティ・コンソールのメモリ不足が生じます。同時スキャンの数を減らすことで、メモリを節約できます。
スキャンの度にメモリ不足になる場合は、サーバーへのメモリの追加をご検討ください。メモリを追加するには、サーバーのオペレーティング・システムのアップグレードも必要かもしれません。本アプリケーションは、32ビットのオペレーティングシステムよりも64ビットのオペレーティングシステム上で実行する場合、より多くのメモリに対処できます。ただし、64ビットのオペレーティング・システム上で実行するには、8 Gbのメモリが必要です。
スキャンによるメモリ負担を軽くする方法の詳細については、以下の章をご参照ください:
時折、システムアップデートが失敗する場合があります。システムログを検証して理由を見つけることが可能です。
本アプリケーションは、以前適用されたアップデートをアップデート・テーブル内で追跡します。アップデート・テーブルが破損すると、本アプリケーションはどのアップデートをダウンロードし適用すべきか認知できなくなります。
アップデート・テーブルの破損が原因でアップデートをインストールできない場合、スキャン・コンソール・ログに以下に類似したメッセージが含まれます:
AutoUpdateJo3/12/09 5:17 AM:NSC update failed:com.rapid7.updater.UpdateException:java.io.EOFException
at com.rapid7.updater.UpdatePackageProcessor.getUpdateTable(Unknown Source)
at com.rapid7.updater.UpdatePackageProcessor.getUpdates(Unknown Source)
at com.rapid7.updater.UpdatePackageProcessor.getUpdates(Unknown Source
)
at com.rapid7.nexpose.nsc.U.execute(Unknown Source)
at com.rapid7.scheduler.Scheduler$_A.run(Unknown Source)
これが起こった場合、技術サポートまでご連絡ください。スキャンログを表示するをご参照ください。
デフォルトでは、本アプリケーションはアップデートを自動的にダウンロードおよびインストールします。本アプリケーションはアップデートをダウンロードしても、インストール試行に失敗する場合があります。
上記が起こったかどうかを、スキャンログを見て確認可能です。
長期間非アクティブとなっている、アップデートのタイムスタンプをチェックします。
AU-BE37EE72A11/3/08 5:56 PM:updating file:nsc/htroot/help/html/757.htm
NSC 11/3/08 9:57 PM:Logging initialized (system time zone is SystemV/PST8PDT)
update now
コマンド・プロンプトを利用して、手動でアップデートを再試行可能です:
コマンド・コンソールページが現れます。
update now
を入力して、実行をクリックします。セキュリティ・コンソールに、アップデート試行が成功したかどうかを示すメッセージが表示されます。スキャンログを表示するをご参照ください。
ファイルの破損が原因で本アプリケーションがアップデートを実行できない場合、スキャン・コンソール・ログに以下に類似したメッセージが含まれます:
AU-892F7C6793/7/09 1:19 AM:Applying update id 919518342
AU-892F7C6793/7/09 1:19 AM:error in opening zip file
AutoUpdateJo3/7/09 1:19 AM:NSC update failed:com.rapid7.updater.UpdateException:
java.util.zip.ZipException:error in opening zip file
at com.rapid7.updater.UpdatePackageProcessor.B(Unknown Source)
at com.rapid7.updater.UpdatePackageProcessor.getUpdates(Unknown Source)
at com.rapid7.updater.UpdatePackageProcessor.getUpdates(Unknown Source)
at com.rapid7.nexpose.nsc.U.execute(Unknown Source)
at com.rapid7.scheduler.Scheduler$_A.run(Unknown Source)
ファイルの破損が原因でアップデートに失敗するということは、アップデート・ファイルのダウンロードには成功しましたが、無効であったという意味です。これが起こった場合、技術サポートまでご連絡ください。スキャンログを表示するをご参照ください。
セキュリティ・コンソールとアップデート・サーバーとの間の接続が確立できない場合、ログに以下に類似したメッセージが現れます。
AU-A7F0FF3623/10/09 4:53 PM:downloading update:919518342
AutoUpdateJo3/10/09 4:54 PM:NSC update failed:java.net.SocketTimeoutException
java.net.SocketTimeoutExceptionは、アップデート・サーバーへの接続が確立できないことを意味します。接続が中断された場合、障害が起こる前のその他のアップデートは成功しています。
update now
コマンド・プロンプトを利用して、手動でアップデートを再試行可能です。アップデートの中断およびスキャンログを表示するをご参照ください。