During KES installation on a host, an entry is added to Windows context menu. When KES version is upgraded, the old context menu entry may remain, and a new entry is added to it. 
As a result, it might look like this:

Diagnostics

To check the information about the entries, start PowerShell as administrator, then run:
Get-AppxPackage -AllUsers > c:\<folder_path>.file_name.txt

Workaround and solution

1. Starting from KES 12.5, unregister ShellEx entries.
   Replace KES.%version% with the actual KES version in the following commands. For instance, for KES 12.9 it'll be KES.12.9.0 
   "%ProgramFiles(x86)%\Kaspersky Lab\KES.%version%\x64\PackageRegistrator.exe" /unregall
2. Then register back: 
   "%ProgramFiles(x86)%\Kaspersky Lab\KES.%version%\x64\PackageRegistrator.exe" /reg
3. If ShellEx registration doesn't help to return the context menu entry, re-install KES.

Google Antigravity might be unable to sign in with Google account when KES for Windows Web Threat Protection and Encrypted connections scan are functioning on the host. No specific error, just nothing happens after pressing Open Antigravity.

Additionally, if sign in was successful, projects might be not loaded properly:

Reason

antigravity.exe doesn't accept KES certificate, and sign-in fails.

When opening projects, connection from localhost to localhost is established, but the server side stops sending data. KES doesn't block it, only holds. 

Workaround and solution

Add the below applications as Trusted to prevent KES from processing their traffic with option Do not scan network traffic:

C:\Users\*\AppData\Local\Programs\Antigravity\Antigravity.exe

C:\Users\*\AppData\Local\Programs\Antigravity\resources\app\extensions\antigravity\bin\language_server_windows_x64.exe

Just enable KES tracing and driver trace will also be running. It will be stored in C:\ProgramData\Kaspersky Lab\KES\Traces and have name like KES.%version%_MM.DD_HH.mm_PID.drivers.etl

Batch scripts to run driver logs altogether

ETW_drivers.zip

On demand

1. Download attached archive and extract it into desired folder.
2. Run elevated CMD(as administrator. Otherwise you'll get an access denied error).
3. CD to the folder where the script file drivers_on_demand.cmd resides and run it.
4. Driver trace will start till you hit any key in the cmd and stop immediately. Driver logs should be present in the same folder where script was executed.

On demand for long time (split log files)

1. Download attached archive and extract it into desired folder.
2. Run elevated CMD (as administrator. Otherwise you'll get an access denied error).
3. CD to the folder where the script file drivers_on_demand_long_time.cmd resides and run it.
4. Driver trace will start till you press any key in the cmd and stop if you press it again. Driver logs should be present in the same folder where script was executed.

On boot

1. Download attached archive and extract it into desired folder.
2. Run elevated CMD(as administrator. Otherwise you'll get an access denied error).
3. CD to the folder where the script file enable_drivers_boot.cmd resides and run it. Do not run it more than once, and do not try to run disable_drivers_boot.cmd before the reboot.
4. Driver trace will start after reboot. To stop the capture, run disable_drivers_boot.cmd, also from elevated CMD.

   Quote

   Use this .cmd file only when the problem is reproduced during Windows startup. Otherwise, use on demand bat files. 

    

There are several problems with similar causes:

1) KESL postinstall script produces error.

Warning: Failed to set up KSN

2) KESL is installed and running. However, the kesl-control command outputs something like that:

kesl-control --app-info

Connection refused. Invalid user permissions for /var.

Only root user should have write access to this path.

kesl-control --app-info

Could not connect to Kaspersky Endpoint Security 11.2.2 for Linux

3) KESL is installed and running, kesl-control indicates no problems. However, kesl-gui shows the Application is currently unavailable error.

4) KESL is installed and running, nagent indicates no connectivity problems. However, KSC shows that KESL is stopped and can't be started.

5) (Starting from 11.3) KESL journal errors "RemoteConnectionRejected"

EventType=RemoteConnectionRejected
EventId=4385
Initiator=Product
Date=2024-04-09 16:28:59
DangerLevel=Critical
Reason=InvalidPermissions
Path=/var
Process=/var/opt/kaspersky/kesl/11.4.0.1096_1684141407/opt/kaspersky/kesl/bin/kesl-control

6) (Starting from 11.3) Nagent errors "Remote Connection Rejected"

Note that in case the problem is with nagent itself (i.e not kesl-control or kesl-gui), nagent actually will not send these events to KSC due to very same issue.

Root cause

KESL service implements defensive internal logic which denies connections from not "trusted" processes. One of the causes is that the process executable file or some library it loads can be overwritten by a non-root user:

1) The Owner is not "root".

2) FS write permission is granted to "Group" or "Other".

Such errors often serve as indication of some erratic configuration. For example:

• Some system administrators change ACL for /opt or other folder (which is supposed to not be widely accessible) to 777 because they don't want to work via sudo;
• In Astra Linux, the owner of the /var directory is sometimes changed to the fly-dm service user due to an error in the fly-dm package. Astra developers confirmed this bug and released fix. If the issue reproduces with new fly-dm versions, address Astra support.
• LD_PRELOAD variable may be used to load arbitrary libraries for any given process including KESL. This is usually the case when you see non-root permissions errors for some third-party libraries.

Solution

To restore proper permissions, use the chown and/or chmod commands:

Please exercise caution and rely upon common sense when changing permissions for / and folders straight under /.

It depends on the environment which files/folders are checked, thus a complete list cannot be provided.

1)

2) (kesl 11.3+) check for RemoteConnectionRejected events. Path parameter should contain faulty directory. Check for events by directly querying events.db, or querying event database via kesl-control, or kesl-control errors depending on scenario.

See examples

3) To get a full list of files loaded by KESL or klnagent, you can read /proc/<pid>/maps. Use commands in the example below to filter out all application-specific files that are located in the folders listed above and to see what other files are used:

Behaviour Stream Signatures or BSS is a major part of System Watcher. Sometimes its logs are required to diagnose the issue.

Step-by-step guide

1. Run <path_to_kes_folder>\avp.com trace on /bss
2. Ensure that BSS logs and KES traces are being generated in the %Programdata%\Kaspersky Lab\ folder(%ProgramData%\Kaspersky Lab\KES\Traces for KES 11.5). BSS trace will have .bsse$ extention.
3. Reproduce the issue, specify the timestamps when the issue had reproduced (HH:MM:SS format is mandatory)
4. Run <path_to_kes_folder>\avp.com trace off /bss
5. BSS log will have now .bsse extention.
6. Provide KES tracing, BSS logs and all other files requested.

Description

Starting from KES Windows version 12.6, it can parse third-party mail base files, but still can't re-assemble them. Malware scan tasks runs in folders where mail base files for Thunderbird or TheBat! are located and finds threats in old mail items.  

Diagnostics

After choosing Resolve or setting "Disinfect, delete if disinfection fails" in the KSC task, nothing changes, and another malware scan task anyway finds the same threats. 

Workaround and solution

Since KES cannot re-assemble third-party mail base files, it also cannot delete the mail items in them. 

It's required to perform manual deletion of infected mail items in mail base file, after that, compact folders in it.

1. Open mail base file in mail program (Thunderbird or TheBat!)
2. Find and delete the infected email (reported by KES)
3. Compact folders in the mail program

• guide for Thunderbird: https://support.mozilla.org/en-US/kb/compacting-folders
• guide for TheBat!: https://www.ritlabs.com/en/support/help/63/

Why it's necessary to perform compacting folders:

A deleted message is only logically marked for deletion, but physically, it still remains in the mail base file. Compacting folders will remove these items completely.

1. Enable Network Threat Protection
2. Connect another Mac via a thunderbolt cable
3. Try to send any data from one computer to another
4. Connection times out

Workaround & Solution

Connect computers by other means or disable NTP when using Thunderbolt bridge.

RCA

This issue is caused by a bug in macOS' built-in packet filter and was reported to apple.

Local installation from a standalone package fails

Diagnostics

Check installation logs of the product. We are looking for the following string:

09.02.2022 17:06:19.453 00000374.000028B4 L1  KLSTD: #1, Error was caught in KLERR_throwError, c:\a\b\a_6vlf7p9h\s\csadminkit\development2\klri\pkginst\klpkinst.cpp@1061. Error params: (1187/0x0 ("Bad parameter "VerifyCertDate""), "KLSTD", c:\a\b\a_6vlf7p9h\s\csadminkit\development2\klri\pkginst\klpkinst.cpp@1061) Error loc: ''. 

This string means that a certificate in the package is out of date

Workaround & Solution

In order to fix the problem you should:

1. Log in to your KESCloud console
2. Change a language \ proxy settings of the existing installation package
3. Save changes
4. Return needed language \ proxy settings
5. Save changes
6. Download a new standalone package and install products

This article is about Kaspersky Endpoint Security for Windows (KES for Windows)

Problem

When KES installation fails with error message "Failed to access local group policy. Error 0x80004005", installation log should be checked. If it contains something similar, follow the steps below.

MSI (s) (F4:94) [11:27:28:103]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI9735.tmp, Entrypoint: DisableWindowsDefender
DisableWindowsDefender: Entering DisableWindowsDefender in C:\Windows\syswow64\MsiExec.exe, version 5.0.15063.0
DisableWindowsDefender: Failed to access local group policy. Error 0x80004005.
DisableWindowsDefender: DisableWindowsDefender: finished. Return value 1603.
CustomAction DisableWindowsDefender returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 11:27:28: InstallExecute. Return value 3.

According to the log, something is preventing KES from disabling Windows Defender. The KES installer calls the MS API function OpenLocalMachineGPO(GPO_OPEN_LOAD_REGISTRY)
https://msdn.microsoft.com/en-us/library/aa374275(v=vs.85).aspx, which returns an error.

This problem is not related to KES, therefore only workarounds can be suggested. Most likely, the problem is related to Group Policy and is on the Microsoft Windows side.

Solution

In case it will not help

Here are some additional ways to solve the problem. No guarantee that they will work, and no responsibility for the effect, as they are not related to KL products. 

• registry.pol related issues
  1. Delete C:\Windows\System32\GroupPolicy\Machine\registry.pol
  2. Restart the SMS Agent Host service to force ConfigMgr to reload the policies. Sometimes it is also necessary to reinstall the ConfigMgr client.
• gpt.ini related issues
  • Replace C:\Windows\System32\GroupPolicy\gpt.ini with a copy from an unaffected computer.

Description and cautions

The original scenario located on the page https://support.kaspersky.com/kes11mac/diagnostics/15299, requires a lot of efforts and manual manipulations.

I am offering a bit easier and time-saving approach doing the same.

Details

All the commands from the original document are saved here, but placed together and being run one after another consequently; the old product logs are also wiped up in order to avoid mess:

1. Login under root:

   sudo -i

2. Enable KESMac KLnagent tracing:

   rm -rf /Library/Logs/Kaspersky\ Lab/* /Library/Logs/klnagent_trace.log && launchctl unload /Library/LaunchDaemons/com.kaspersky.klnagent.plist && cat /Library/LaunchDaemons/com.kaspersky.klnagent.plist > /Library/LaunchDaemons/com.kaspersky.klnagent.plist.backup && chmod ugo+w /Library/LaunchDaemons/com.kaspersky.klnagent.plist && curl -o klnagent_enabled_traces.zip -J -L https://media.kaspersky.com/utilities/CorporateUtilities/klnagent_enabled_traces.zip && unzip klnagent_enabled_traces.zip && cat klnagent_enabled_traces.plist > /Library/LaunchDaemons/com.kaspersky.klnagent.plist && chmod ugo-w /Library/LaunchDaemons/com.kaspersky.klnagent.plist && launchctl load /Library/LaunchDaemons/com.kaspersky.klnagent.plist

   
   Now you can check the log is being written:

   ls -lh /Library/Logs/klnagent_trace.log

3. In case you need to enable KESMac tracing, refer to the specially dedicated article https://support.kaspersky.com/kes11mac/diagnostics/15041;
4. It is time to reproduce the issue;
5. When it is done, disable KESMac KLnagent tracing the same manner (ensure, you are still under root: sudo -i):

   launchctl unload /Library/LaunchDaemons/com.kaspersky.klnagent.plist && chmod ugo+w /Library/LaunchDaemons/com.kaspersky.klnagent.plist && cat /Library/LaunchDaemons/com.kaspersky.klnagent.plist.backup > /Library/LaunchDaemons/com.kaspersky.klnagent.plist && chmod ugo-w /Library/LaunchDaemons/com.kaspersky.klnagent.plist && launchctl load /Library/LaunchDaemons/com.kaspersky.klnagent.plist

6. Upon finish, gather the collect package (https://support.kaspersky.com/collect)

   curl -o collect.tar.gz -L "https://box.kaspersky.com/f/00a1a6d8beb24554a72d/?dl=1" && tar -zxvf collect.tar.gz && chmod +x collect.sh && sudo ./collect.sh

Symptoms

OS hang, sometimes with open file errors in journals

Customer application degrades with errors "unable to open file", "too many open files"

Hangs and third-party (compatibility) issues often require advanced data collection and are sophisticated to investigate. However, a quick check is possible:

On a system where KESL has worked for some time (not immediately after reboot/restart), validate the output of the following command, ran as root, for numerous records of /usr/bin or /usr/sbin folders

lsof | grep -E 'kesl.+DIR.+\/usr\/s?bin'

Root Cause

Under heavy load, KESL may display linear increase in file descriptors usage (sysctl - fs.file-nr) up to system-wide limit (sysctl - fs.file-max) and eventually degradation.

Workaround

Schedule restart of KESL service every week/day, depending on intensity of descriptors growth.

NB: KESL restart will also reset progress of certain tasks like "malware scan" and "database update". Schedule KESL restart outside of tasks timeframes.

Solution

This issue was fixed in KESL 12.1.0.1274, so an update to that or newer version should fix it.

• Download Apple configurator via App Store.

• Run Apple Configurator.

• Connect your iOS device.
• Unlock the device and tap Trust.
• Select your device and click on the Prepare button

• Select 'Manual Configuration'. Check 'Supervise devices' and 'Allow devices to pair with other computers' (if you want to allow it). Click on the Next button.

• Leave it on "Do not enroll in MDM" and click on the Next button

• Click on the Skip button

• Enter information about your organization (only 'Name' filed is mandatory'). Click on the Next button.

• Select 'Generate a new supervision identity'. Click on the Next button.

• In the next window you should choose which steps will be presented to the user in Setup Assistant. You can choose 'Show all steps', 'Do not show any of these steps' and 'Show only some' steps - in this options you must select the steps. Click on Prepare button.

• Enter password for your macOS account
• Click on Erase button. Your device will be reset to factory settings.

• Wait while your device will be prepared 

• When your device will be turned on, you should see that your device is supervised and managed by your organization in device settings

Now you can install iOS MDM profile to this device and apply iOS MDM policy with options for supervised devices.

The both filesystem and network activity of which can be ignored by the product increasing performance.

Please, however, note that this could be potentially risky. 

https://support.kaspersky.com/KESMac/11.3_adminguide/en-US/194142.htm

Problem

This article will describe a few ways to configure KES for Mac to exclude some of the software from the scope of the product.

Solution

Trusted applications

In order to have an ability to exсlude an application from scanning with KES, a function of Trusted Applications available in Kaspersky Endpoint Security for Mac can be used:

In some specific cases it might be required to put several binaries to Trusted Applications simultaneously in order to take effect. So, a final solution might include several path-based exclusions accompanied by a few BundleID-based ones.

Common exclusions for developers

It's suggested excluding the following paths: "/Library/Developer/CommandLineTools" and "/Library/Toolchains" for the standard developers' utilities, as well as the "/Applications/Xcode.app/*" for the XCode.

At the same time, in case you use alternative tools, contact Kaspersky Support to get the exact paths for further exclusions.

Excluding TCP 443 from port monitoring

Additionally, in case of HTTPS-connectivity issues, unchecking port 443 in Monitored ports may also help:

Problem Description, Symptoms & Impact

KES File Threat Protection sometimes can't check Microsoft office documents from mounted Google Drive shares, therefore generating Processing error events. This issue is caused by an incompatibility between Google Drive VFS driver and KES. There are no plans on making KES compatible with Google Drive.

Workaround & Solution

As a workaround, add files with Office extensions stored on the share to exclusions, this shouldn't lower protection, because Office creates a temporary copy of a document when it is opened, which will not be in the exclusion scope and will still be checked. Example for .xlsx files: Path\to\google\drive\folder\*.xlsx, where Path\to\google\drive\folder is replaced with an actual path.

Download Apple configurator via App Store.

Run Apple Configurator.

Connect your iOS device.

Unlock the device and tap Trust.

Open the iOS device → Console.

Reproduce the issue.

Save the log in Apple configurator.

Send the collected log file to Kaspersky support for further analysis.

While WTP/NTP is enabled, nft utility produces errors (stderr) like

These errors are caused by a bug in nft utility and xt_TPROXY dynamic library. This effect does not indicate functionality issues.

This bug may be reported to netfilter.org developers.

Explanation

Whenever nft utility lists traffic rules, it dynamically loads extension libraries (for example, from /usr/lib/x86_64-linux-gnu/xtables in Debian OS) including TPROXY and CONNMARK.

When nft encounters first ipv4 rule, it sets global "family=ipv4" state via xtables_set_nfproto function, then loads libxt_TPROXY.so which has both ipv4 and ipv6 targets, but ipv6 are ignored due to the flag.

After that, nft processes ipv6 rules but there are no ipv6 targets for them. As a result, nft utility produces errors "XT target TPROXY not found".

In KES 12.0, the way Device Control component works has been changed. See changelog: https://support.kaspersky.com/help/KESWin/12.0/en-US/127969.htm

Due to these changes, you may notice that printing order becomes slow after you have upgraded KES to version 12.0 or higher. This delay may be around 30-60s or even 10-15 minutes. When you disable KES, it becomes instant. In some exceptional cases, the delay may be so big that it's impossible to print anything and the system hangs. The issue affects both local printers and network printers.

Diagnostics

First of all, test if the issue persists with Device Control component disabled. If it does, move any device to a separate group for testing, create a new default KES policy there and check if the issue persists on default policy or not. If everything is fine under default policy, this is a clear sign that something is wrong with your configuration.

Additionally, try latest PF for KES and check if the issue persists on it. There are some optimizations there that fix some Device Control issues and it can improve the performance, but if the issue is in the policy configuration, it won't help much.

Workaround & Solution

Troubleshooting steps:

1. Select a host for troubleshooting and move it to a test group
2. Install latest pf on it and reboot check the situation
3. Check if the issue is caused by Device Control component and if the issue persists if this component is disabled
4. Check if the issue persists under main policy and under default policy
5. Check policy configuration and check how many devices have been added to Trusted Devices list. If there are several hundred entries or more, try to find a way to reduce their amount. 

This article is about Kaspersky Endpoint Security for Windows (KES for Windows)

The operating system generates private key for file decryption based on the authentication credentials. Until you log in to the system, only the encrypted versions of files can be accessed, so their contents are unreadable.

KES uses several types of keys to handle encrypted files:
— Administration Server's public key is stored in the Network Agent distribution package and gets on the client computer when protection is deployed.
— User’s private key is generated by the operating system based on the username and password. Private keys are not saved to the hard drive. The key stays the same if the account credentials remain the same. However, a new key is generated if the user or password changes.
— Primary key is created on the client computer when FLE is enabled. This key is used to encrypt all files. A copy of the primary key is saved in the computer's key storage, which in turn is encrypted using the KSC's public key. It is also saved in all active users' key storages, which are encrypted using their private keys. Thus, after authentication, any user can decrypt his or her storage and access the primary key.
— File encryption keys: a separate key is generated to encrypt each file

When a file is encrypted, its name and other external attributes are not changed.

VMWare guest using Kaspersky products hanging or crashing due to driver conflicts between drivers used by VMWare NSX (vnetWFP.sys, previously vnetflt.sys) and Network Threat Protection component.

This problem is known to happen with following versions of KES and VMware Tools:

• KES 11.6 with VMWare Tools 10.0.9
• KES 11.6 and 11.7 with VMWare Tools 11.3.5
• KES 12 with VMWare Tools 10.1.7

Troubleshooting steps

1. Update VMWare Tools
   Sometimes there may be a bug in the driver built into VMWare Tools, and ESXi updates its images only through manually installed patches, and it compares installed version only to the version in it's storage, so even if ESXi says that the VM has current version of VMWare Tools, it may actually be outdated. Because of that, a new VM may run with outdated drivers.
   ESXi and VMWare Tools compatibility matrix: https://interopmatrix.vmware.com/Interoperability?col=1,&row=39,&isHidePatch=true&isHideGenSupported=false&isHideTechSupported=false&isHideCompatible=false&isHideNTCompatible=false&isHideIncompatible=false&isHideNotSupported=true&isCollection=false
   Latest supported VMWare Tools version for ESXi 6.5 and 6.7: https://packages.vmware.com/tools/releases/12.1.5/windows/
   VMWare Tools for ESXi 7.0 and newer: https://packages.vmware.com/tools/releases/latest/windows/

2. If that did not help, uninstall NSX Network Introspection drivers of VMWare Tools: https://kb.vmware.com/s/article/2149764
   This is the driver that is causing the conflict on VMWare's side, therefore removing it will resolve the conflict and should resolve the issue.

Disable Network Threat Protection in KES settings or in the policy, if it's controlled by KSC.
Network Threat Protection is using klwfp.sys driver, and that driver is causing the conflict with vnetWFP.sys. With that component turned off, the driver loads on startup, but doesn't do anything, avoiding conflict with vnetWFP in most cases.
Open KES Window -> Settings -> Network Threat Protection -> switch Network Threat Protection off
Open KES policy properties -> Essential Threat Protection -> Network Threat Protection -> Uncheck Network Threat Protection checkbox

Related Information

How to collect KES traces: https://support.kaspersky.com/kes11/diagnostics/14364

How to collect a full memory dump: https://support.kaspersky.com/common/diagnostics/10659

Link to GSI: https://media.kaspersky.com/utilities/ConsumerUtilities/GSI-6.2.2.43.exe

While installing KES for Windows via KSC installation package the following error appears and interferes with installation.

Possible causes:

1. KES components installed already before installation.

2. Required driver files were not found.

Workaround & Solution

Use kavremover and reinstall KES with the latest patch.

In case kavremover will not help, please collect procmon and KES installation logs, actual GSI with event logs and submit the case to the Kaspersky support. 

This instruction describes how to create an installation package (.pkg) for the MacOS operating system from the standalone installation package of Kaspersky Endpoint Security for Mac.

You may need to create such a package to automate the installation of Kaspersky Endpoint Security software via third-party systems (e.g. AirWatch).

Details

Files

Munki tool (with predefined files)

Prerequisites

• Kaspersky Security Center
• MacOS machine
• Python must be installed

Usage

• Create a standalone installation package for Kaspersky Endpoint Security for Mac (https://support.kaspersky.com/KSC/14/en-US/182663.htm)
• On a MacOS machine:

Unzip the file munki-munki-pkg-e018bf1.zip to Desktop.

Open Terminal and navigate to the directory munki-munki-pkg-e018bf1

Copy the built standalone installation package (kesmac11.2.1.145.sh) to the postinstall file in the kesmac/scripts/ directory:

Modify the code of the standalone installation package with the vim editor

Replace the section in the file  to the modified section (note that the line "#!/bin/sh" must be the first line in the file, there must be no empty lines before it):

Add the execution bit:

You can also change the metadata (if needed) in the nagent/build-info.plist file

Perform the assembly:

The built package will be available in the kesmac/build directory with the name <name of package from build-info.plist>.pkg

Important

KSC and KS4Android are implemented but KSC is offline and could not access Internet. KUU can be used for updating KS for Android and distribute the update databases. But after running KUU (Kaspersky Update Utility), you cannot find actual KES for Android versions. 

Solution

AV bases for new KESM versions will appear in KUU UI after running KUU with empty application list. 

The KUU settings should look like the following (in order to update the list of supported applications, you need first to press 'Start' with a blank application list as follows):

Unfortunately, at current moment KSWS console allows us to make exclusions ONLY for Ports, IP-addresses, and Processes:

But we have ability to make site and domain exclusions for Traffic Security via registry workaround.

To implement workaround, we need to create and fill following REG_MULTI_SZ key:

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\KasperskyLab\WSEE\11.0\Environment\ICAP\IgnoreDomains]

To make changes in this hive, you can add necessary permissions to your account OR you can run regedit in SYSTEM context (psexec -s -i regedit.exe).

kesl-control --app-info outputs the following error:

One of the most common root causes is Fanotify is disabled (or KESL could not access it) and kernel module compilation also failed.

A special utility can  be used for this directly on the affected machine with KESL installed:

In case, an operating system does not support Fanotify technology, it is required to install some additional packages and build a kernel module for KESL.

A part of required packages may be found on the Hardware and software requirements section of the product documentation, for example for KESL 11.3; In addition to this, new packages kernel-headers-XXX and kernel-devel-XXX must be installed, where XXX - an operating system kernel version.

Use the following scenario to install those packages and build a kernel module for KESL:

for RHEL based OS: 

for Debian based OS: 

Reboot the system;

Run the post-install script: 

And reboot the service: 

In case of any further issues, please contact Kaspersky Support.

This article is about Kaspersky Endpoint Security for Windows (KES for Windows)

This informational message does not mean that Self-Defense accuses any process of being under malware attack, it proactively blocks certain operations that could pose a potential threat to processes.

The number of events depends on the activity of applications that inhabit the system, especially from their periodic activities, polls on a timer, on emerging events, and so on. The event in the reports is informational - it can be simply disabled it in the settings. It's not expected to react to these events.

More specifically, it's usually the update programs and VMWare services try to access application processes. The update programs want to restart all processes when the update is finished so that they don't have to reboot the system. But KES doesn't allow them to restart our processes. 

The applications causing these events:

• Microsoft Edge Update
• Google Installer
• Windows installer
• VMware Authorization Service
• Host Process for Windows Services
• Client Server Runtime Process

It is normal for such a request to fail, and this should not be a concern. These events can be turned off in active KES policy: General settings→Interface→Notifications: informational messages→Self-Defense restricted access to the protected resource.