Host Troubleshooting
  • 19 Mar 2024
  • 2 Minutes to read
  • Dark
    Light
  • PDF

Host Troubleshooting

  • Dark
    Light
  • PDF

Article summary

About this Article
This article covers Host Configurations, some of the scenarios and their troubleshooting steps. 


Host Protection Configurations

Host Protection is highly configurable to meet the needs of the high variance in deployments. All configurations can be viewed using below command and each configuration shows a description explaining what the configuration controls.

vsp-cli config hmm view -–options


The most useful configurations are:

  1. fswalkProcesses – The number of processes to spawn during the host File System walk (FS-walk) to determine all the binary files
  2. eventMonitorThreads – The number of threads to spawn in parallel to handle the incoming HMM agent messages
  3. fsExclusionList – A list of paths to exclude during FS-walk
  4. logLevel – The desired log level for the component
  5. regexExclusions – A list of regex strings of incidents not to be reported to CMS
  6. trustedInstallers – A set of trusted installers/publishers. Executables that belong to these installers/publishers are not reported to CMS


Kernel Caching Parameters Configuration

[Version 3.0.0 and Above]

To optimize the Host Protection response time, allowlisted processes/libraries are stored in kernel cache. This enables the block/suspend/allow action decision to be taken faster.

Three parameters can be configured for process/library caching for Host Protection. They can be configured using Vsp-cli commands as described below:

  1. kernalMaxCacheTime - Defines the duration (in minutes) for which a process/library can be retained in kernel cache
    1. Allowed Values -  1 to 1440 minutes (1 day)
    2. Default Value - 30 minutes
    3. Sample Usage - The below command sets the parameter kernalMaxCacheTime to 10 minutes
      vsp-cli config hmm edit kernelMaxCacheTime 10
  2. kernalMaxCacheEntries - Defines the number of processes/libraries that can be stored in a bucket in the kernel cache 
    1. Allowed Values -  32 to 256 entries per bucket
    2. Default Value - 32 entries per bucket
    3. Sample Usage - The below command sets the parameter kernalMaxCacheEntries to 64 entries
      vsp-cli config hmm edit kernelMaxCacheEntries 64
  3. holdCachedProcesses - To enable/disable caching
    1. Allowed Values -  true (Disable)/false (Enable - Default)
    2. Sample Usage - The below command disables process/library caching in kernel
      vsp-cli config hmm edit holdCachedProcesses true

Once the configuration is complete, restart the VSP services using the commands:

sc stop vsp
sc start vsp


Obtain Blocked/Suspended Processes

Execute the below command to obtain the current list of blocked/suspended processes

vsp-cli host get-blocked-procs


Obtain the current Allowlist

Execute the below command to export a current copy of the allowlist stored in memory

vsp-cli host export ./vsp_host_allowlist.json


Hosts not in sync OR Legitimate Processes Reported

Symptom: VSP-Host is out-of-sync with CMS allowlist or legitimate processes are reported as incidents 

Recommended Actions: Follow the steps below:

  1. Stop all the VSP services
  2. Delete the files located in the directory: $VSP_VAR_HOME/hmm/fswalk/
  3. Start the VSP services
NOTE
If the out of sync issue occurs during the initial profile creation, ensure that the profile is deleted on CMS after stopping the VSP services and before restarting the probe


Hosts not auto-associated with Profiles after upgrade

Symptom: Hosts are not auto-associated with the profiles after VSP upgrade in cases where the Probe is in connected state and profiles are imported with tags 

Recommended Actions: Restart the Probe to ensure that the auto-association is successful


Scan Errors

Symptoms:

  1. Scan errors may occur on associated hosts during two scenarios:
    1. Probe is restarted during a host scan by VSP
    2. CPU utilization peaks and scan is aborted before completion
  2. On the Host Monitoring page, the below icon indicates that there are one or more out-of-sync hosts

Recommended Workaround:

Disassociate the specific host and associate it again to overcome the scan error


Persistence of Scan Error on CMS after Probes Recovery

Symptom: When Probes are in maintenance mode for a certain period of time and stopped, a scan is initiated. If the VSP-Manager is stopped/restarted during the scan, an error is displayed on CMS. This persists even after VSP-Manager restarts 

Recommended Actions: Disassociate and associate the probe instance to recover from the scan error


Was this article helpful?