ウイルス検索の問題に関する調査では、以下の情報が必要となります。
1. 発生した問題、ServerProtectの使用環境に対する基本的な情報
(1) 問題は今も続いていますか。また、発生頻度はどのくらいありますか。
(2) 問題は再現できますか。
(3) 問題が再現できる場合は、その手順をお伝えください。
(4) 問題はServerProtectをインストールした全コンピュータの何台中何台で起きていますか。
(5) 問題は特定のプラットフォームで起きていますか。
(6) この問題が起こる前、コンピュータは正常に動いていましたか。
(7) 問題が起こる前、システムまたはネットワークに変更を加えましたか。
(8) ServerProtectのSecurityPatchや弊社から個別に提供したHotfix(修正モジュール)を適用した経緯があれば、SecurityPatch名やHotfix名を教えてください。
2. OSの基本情報
(1) OSのバージョン情報
Red Hat Enterprise Linux の場合:
# cat /etc/redhat-release
SuSE Linux Enterprise Server / Novell Linux Desktop の場合:
# cat /etc/SuSE-release
(2) bootディレクトリの情報
# ls –al /boot
(3) カーネルのrpmパッケージ情報
# rpm –qi kernel
(カーネルパッケージが複数インストールされている場合、uname –a の結果を元に現在起動中のカーネルのrpmパッケージ情報を取得します。)
# rpm –qi kernel-2.6.9-5.EL (例)
(4) インストールディレクトリの権限
# ls –l /
# ls –l /opt
(5) コンピュータ上に存在しているカーネルフックモジュール(KHM)の情報
# cd /opt/TrendMicro/SProtectLinux/SPLX.module
# ls -al | grep splxmod
(6) KHMのチェックサム
# md5sum /opt/TrendMicro/SProtectLinux/SPLX.module/*
(7) KHMのロード状況
# lsmod | grep splxmod
(8) splxサービスの現在の状態
# /etc/init.d/splx status
(9) ウイルスファイルが格納されていたディレクトリの権限
# ls –l <ウイルスファイルのディレクトリパス>
(10) SPLXのビルド情報
# rpm -qa | grep splx
(11) KHMのバージョン
# modinfo /opt/TrendMicro/SProtectLinux/SPLX.module/splxmod.ko
(12) KHMの作成元について
弊社サポートセンターにご依頼いただき弊社より提供したKHMでしょうか、それともお客様独自にコンパイルされたKHMでしょうか。
以上の情報を”GeneralInfo.txt”と言うファイル名のテキストファイルへまとめて出力してください。
(13) CDT(Case Diagnostic Tool)データの取得
# /opt/TrendMicro/SProtectLinux/SPLX.util/DiagnosticTool
Collecting product info...
Collecting system info...
Collect info success!
上記コマンド実行後、/var/log/TrendMicro/CDT_Data/ 配下にある下記のファイルを取得してください。
YYYYMMDD-hhmmss.tgz
(YYYYMMDD-hhmmss は、データを取得した日時[年月日-時分秒])
※ tgzファイルの中身は、ファイル名と同じ名前のディレクトリ内に保存されています。
3. システムのログファイル
初期設定では、/var/log/messages に記録されます。
ログローテートされたファイル(/var/log/messages.*)も含めて採取してください。
4. ServerProtectのデバッグログ
(1) viなどのテキストエディタで、/etc/syslog.confへ下記のエントリを追記します。
local3.debug /var/log/vsapiapp.log (vsapiapp デバッグログ用)
kern.debug /var/log/khm.log (カーネルフックモジュールデバッグログ用)
カーネルフックモジュールデバッグログはリアルタイムスキャンの問題が発生している際のみに設定ください。 カーネルフックモジュールデバッグログは短期間に多くのメッセージを出力します。 多量のSyslogの出力にてCPU使用率への負荷が発生する可能性がございます。 業務影響の少ない時間の実施、目安として数分程度の実施をご検討ください。
また、実施前にtmsplx.xml内のRealtimeExcludeCommandに*imjournalの値を追加ください。 ファイル:
/opt/TrendMicro/SProtectLinux/tmsplx.xml
<P Name="RealtimeExcludeCommand" Value="vsapiapp:splx*:AuPatch:entity:ssh*:syslog*:systemd*:khelper:abrt-hook-ccpp:request-key:keyctl:nfsidmap:rsyslog*:irqbalance:*imjournal"/>
(2) syslogdデーモンを再起動します。
# systemctl restart syslog
(3) SPLXサービスを停止します。
#systemctl stop splx
(4) viなどのテキストエディタで、/opt/TrendMicro/SProtectLinux/tmsplx.xmlファイルの以下の部分を編集します。
P Name="UserDebugLevel" Value="5" (vsapiappデバッグログ用。初期設定では”1”)
P Name="KernelDebugLevel" Value="3" (カーネルフックモジュールデバッグ用。初期設定では”0”)
(5) SPLXサービスを起動します。
#systemctl start splx
(6) 問題を再現させます。
(7) 以下のファイルにデバッグログは出力されますので、これらを取得します。
/var/log/vsapiapp.log
/var/log/khm.log
(8) 手順(4)で書き換えたtmsplx.xmlファイルおよび、手順(1)で書き換えた/etc/syslog.confファイルを元の値に戻します。
(9) SPLXおよびsyslogdサービスを再起動し、デバッグモードを終了します。
#systemctl restart splx
# systemctl restart syslog
5. 事象発生時のタイムライン
システム時計をもとに、ログの取得時刻や作業の実行時刻の記録も
開始してください。
出来るだけ詳細な情報(月、日、時、分単位)での記録をお願いします。
記載例)
20**/**/** 実施
10:05 xxxサーバにてシステム時計の時刻を確認
10:15 xxxサーバにて製品デバッグログの取得を開始
10:17 並行して、xxxサーバにて同時に製品デバッグログの取得を開始
10:20 現象が再現されることを確認
10:25 xxxサーバ/xxxサーバにて各データの取得