File Threat Protection task operation analysis

To analyze the operation of the File Threat Protection task:

  1. Stop all scan and monitoring tasks.
  2. Make sure that the on-demand scan tasks will not run during the scan or have no schedule. You can do it using Kaspersky Security Center or locally by doing the following steps:
    1. Get the list of all application tasks by executing the following command:

      kesl-control --get-task-list

    2. Get the schedule settings for the Malware Scan task by executing the following command:

      kesl-control --get-schedule <task ID>

      If the command output is RuleType=Manual, the task can only be started manually.

    3. Get the schedule settings for all your Malware Scan tasks, if any, and set them to start manually by executing the following command:

      kesl-control --set-schedule <task ID> RuleType=Manual

  3. Enable generation of application trace files with a high level of details by executing the following command:

    kesl-control --set-app-settings TraceLevel=Detailed

  4. Start the File Threat Protection task if it has not been started by executing the following command:

    kesl-control --start-task 1

  5. Load the system in the mode that caused the performance problems; a few hours is enough.

    While being loaded, the application writes a lot of information to the trace files; however only 5 files of 500 MB are stored by default, so the old information will be overwritten. If the problems with performance and resource consumption stop occurring, then they are most likely caused by on-demand scan tasks and you can proceed to analyzing the operation of ContainerScan and ODS scan tasks.

  6. Disable creation of the application trace files by executing the following command:

    kesl-control --set-app-settings TraceLevel=None

  7. Determine the list of objects that have been scanned the most times by running the following command:

    fgrep 'AVP ENTER' /var/log/kaspersky/kesl/kesl.* | awk '{print $8}' | sort | uniq -c | sort -k1 -n -r|less

    The result is loaded into less, a text viewer utility, where the objects that have been scanned the most times are displayed first.

  8. Determine whether the objects scanned the most number of times are dangerous. In case of any difficulties, contact Technical Support.

    For example, directories and log files can be considered safe if a trusted process writes to them, database files can also be considered safe.

  9. Write down the paths to the objects that are safe, in your opinion; the paths will be required to configure exclusions from the scan scope.
  10. If various services frequently write data to files in the system, such files are scanned again in the pending queue. Determine the list of paths that have been scanned the most times in the pending queue by running the following command:

    fgrep 'SYSCALL' /var/log/kaspersky/kesl/kesl.* | fgrep 'KLIF_ACTION_CLOSE_MODIFY' | awk '{print $9}' | sort | uniq -c | sort -k1 -n -r

    The files that were scanned the most times will appear at the beginning of the list.

  11. If the counter for a file exceeds several thousands in a few hours, you should check whether you can trust this file in order to exclude it from scan.

    The logic of to determine it is the same as for the previous study (see step 8): log files can be considered safe, since they cannot be launched.

  12. Even if some files are excluded from scan by the Real-time protection task, they can still be intercepted by the application. If excluding certain files from Real-time protection does not result in significant increase of performance, you can completely exclude the mount point where these files are located from the interception scope of the application. To do so, do the following:
    1. Run the following command to get the list of files intercepted by the application:

      grep 'FACACHE.*needs' /var/log/kaspersky/kesl/kesl.* | awk '{print $9}' | sort | uniq -c | sort -k1 -n -r

    2. Using this list, determine the paths used for most of the file operation interceptions and configure interception exceptions.
Page top