All Activity

Description As part of proactive security, you may wish to add sha256 to block the execution of application or malicious applications without having the original source files. This article explains how to perform this action. How To Create a text file containing the sha256 you want to block. Use the AppRulesGenerator.exe app to generate an xml file: Import the generated .xml file into the KSWS policy: AppRulesGenerator.exe can be downloaded here.

Description After successful installation kesl-supervisor.service may refuse to start with the following error: kesl-supervisor.service: Control process exited, code=exited status=203 journalctl -xe command provide more information related this error ***** kesl-supervisor.service: Failed to execute command: Permission denied kesl-supervisor.service: Failed at step EXEC spawning /var/opt/kaspersky/kesl/install-current/etc/init.d/kesl-supervisor: ***** kesl-supervisor.service: Control process exited, code=exited status=203 kesl-supervisor.service: Failed with result 'exit-code'. Failed to start kesl. Root cause SElinux is enabled on the system and prohibits execution of the service. Solution You can check SELinux status by running: $ sestatus If SELinux is enabled, then use the dedicated online help article to disable, configure and re-enable it.

Sometimes one may need to enable transmitted traffic capturing in KATA (in example, for local testing of Suricata detections). Here's how to do it. Instructions for KATA 3.7.* In file /etc/modprobe.d/pf_ring.conf set enable_tx_capture=1. File should look like this: options pf_ring enable_tx_capture=1 min_num_slots=16384 Stop apt-preprocessor and suricata services: systemctl stop apt-preprocessor.service systemctl stop suricata.service Reload pf_ring module: rmmod pf_ring modprobe pf_ring Start apt-preprocessor and suricata back systemctl start apt-preprocessor.service systemctl start suricata.service Instructions for KATA 4.0/4.1 In file /etc/modprobe.d/pf_ring.conf set enable_tx_capture=1. File should look like this: options pf_ring enable_tx_capture=1 min_num_slots=16384 Stop docker service: systemctl stop docker Reload pf_ring module: rmmod pf_ring modprobe pf_ring Start docker back systemctl start docker Instructions for KATA 5.0 In file /etc/pf_ring/pf_ring.conf set enable_tx_capture=1. File should look like this: options pf_ring enable_tx_capture=1 min_num_slots=16384 Stop docker service: systemctl stop docker Reload pf_ring module: rmmod pf_ring modprobe pf_ring Start docker back systemctl start docker With these changes, KATA will capture and process both incoming and outgoing traffic.

Problem Sometimes it is necessary to replace the KSN proxy address in products like KSWS, KESS or KES after restoring KSC from backup or when Server moved to new Hardware. Unfortunately, there are no settings in the policy for this. Solution The corresponding option can be found in the properties of Installation packages node in KSC. See the effects of changing this value: Note that after changing these settings, you must also rebuild the Network Agent installation packages, even if the change is propagated to connected clients.

Все равно ситуация очень и очень странная, раньше не выдавало и тут вдруг с новой версией стало выдавать. Тоже Adguard пользуюсь и ниразу проблем с Касперский не было. Тоже склоняюсь, что попытка продвинуть свой блокировщик, который откровенно говоря работает не очень. В подсказке в приложении выдает, что якобы какие-то функции защиты не будут доступны в такой связке. Вот тут и напрашивается какие именно???

Problem In some cases KESMac is not able to start protection components: Or, the status "Allow encrypted traffic to be inspected" is not changing: Solution 1) Please get acquainted with the article https://support.kaspersky.com/kis20mac/error/15031#block1; 2) If the article above did not help, try to remove the FireFox user's profiles directory via Terminal: rm -rf ~/Library/Application\ Support/Firefox/Profiles Removal of the Firefox profiles deletes the user's data stored in the browser, like saved logins and passwords, visited websites and other. Make backup if needed. Then, reboot the host and check the issue reproduction.

The KESMac 12 and the KESMac 11.3 patch C allows adding particular processes into the trusted section named Trusted Applications. 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: The Trusted applications section as seen in the policy creation wizard. Naturally, it can be configured later by modifying the policy. Update the plugin to at least version 11.3.0.33 to get the new functionality. 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. Trusted Applications are only available for configuration via KSC policy; i.e. it is currently impossible to add application to exclusions having no KSC installed. Additionally, an appropriate application control plug-in for KESMac must be downloaded and installed on the KSC prior to using Trusted Application functionality. It can be found on the corresponding download page. 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:

Article applies to KSC13-14.2 versions. Sometimes you need to keep KSC tracing on for a long period of time to catch the error and there is little disk space left on the system disk. Step-by-step guide There is a way to change the default location of $klserver-1093.log file - use klscflag.exe utility" klscflag.exe -tset -pv "klserver" -l 4 -d O:\Temp O:\temp can be changed to any existing folder name in file system. Remember to create this folder before running the command. In order to revert trace file location to default value, delete the value TraceDir from HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\KasperskyLab\Components\34\1093\1.0.0.0\Debug: Same applies to klnagent trace - custom settings should be written to the following registry branch: [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\KasperskyLab\Components\34\1103\1.0.0.0\Debug] Additional option: TraceMaxSizeMB is an optional value that enables trace files rotation for all services of the Kaspersky Security Center. The value of it variable determines the total size of trace files in MB. The absence of the variable or its zero value means that rotation is disabled. Maximum variable value is 102400 (0x19000), which means 100 GB. Example of reg file: REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\KasperskyLab\Components\34\1093\1.0.0.0\Debug] "TraceDir"="O:\\Temp" "TraceLevel"=dword:00000004 "TraceMaxSizeMB"=dword:00002000 In this example, trace files rotation is enabled and total trace file size of 8192 MB (8 GB). Logs will be saved to O:\temp. Note: in KSC14, klscflag.exe utility can be found in KSC installation folder, no need to copy the tool.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Article applies to KSC13-14.2 Consider the following scenario: Open KSC MMC console; Go to Kaspersky licenses; Select KSC license. Devices on which the license key is active is zero regardless of fact that this key is assigned as active on KSC Server: Explanation In older versions of Kaspersky applications, several license key files were provided to activate different products - one for KSC - 1 license unit and another for workstations and servers (Kaspersky Security for WS and FS) - in this example, 150 license units. In this example, 151 license units. In newer versions of Kaspersky applications, an activation code is provided (activation 2.0 format). When you activate an application with this activation code, total number of license unit is 150, this is 1 fewer than 151 because KSC Server consumed 1 license. Solution The license for KSC server is not counted. This applies only to activations codes. Re-configure Report on usage of license keys to display all summary fields; Re-generate the report - it will display KSC license as active on KSC Server: Open the properties of KSC server→License keys to make sure it is activated with a valid license.

This article applies to Endpoint Agent for Linux. To collect LENA debug or ANY traces, please follow this guide. Default traces location is '/var/log/kaspersky/epagent/'. Default dumps location is '/tmp/agentdumps' Public collect.sh script was updated to collect LENA-related information and gather these folder as well. How to: enable LENA ANY traces For KATA-EDR (on-premises) customers to tune LENA performance by exclusions, ANY level logs are required. To enable ANY logging: Become root sudo su - Use one-liner to enable ANY tracing level: sed -i 's/LENA_TRACE_LEVEL=none/LENA_TRACE_LEVEL=any/g' /etc/opt/kaspersky/epagent/service.conf && systemctl restart epagent Modify the config file /etc/opt/kaspersky/epagent/service.conf /etc/opt/kaspersky/epagent/service.conf KESL_FIFO_PATH=/run/log/kesl-messages AUDIT_FIFO_PATH=/run/log/audit-messages LENA_TRACE_LEVEL=none <-- set any here instead of none LENA_DUMPS=yes Save the modided value. Careful, CaSe sensitive values! LENA_TRACE_LEVEL=any ← correct LENA_TRACE_LEVEL=none ← correct LENA_TRACE_LEVEL=ANY ← wrong LENA_TRACE_LEVEL=None ← wrong To apply changes, restart epagent service systemctl restart epagent Wait until the problematic behavior is reproduced; Stop traces /opt/kaspersky/epagent/sbin/lenactl --traces --off Double-check that produced traces indeed contain ANY-level information use this command: grep -q ANY /var/log/kaspersky/epagent/lena*; if [[ $? == 0 ]]; then echo "ANY logs"; else echo "Not ANY :("; fi As an addition you can check for how long ANY traces were gathered like grep -h ANY /var/log/kaspersky/epagent/lena* | awk '{print $1}' | cut -d '.' -f 1 | uniq And as final accord you can check whether you gathered enough ANY traces to be analyzed and sneak-peek what processes are producing excess load grep -ha "from auditd" /var/log/kaspersky/epagent/lena* | grep -oE "\"exe\"\:\[\"[^\"]+\"" | sort | uniq -c | sort -nr | sed -e 's/$/\]/' | grep -E "[0-9]{3,}\s+\"" Collect the produced logs and system information in one go using collect.sh script How to: enable LENA debug traces Debug traces take less space and are suitable for troubleshooting issues not-related to Performance or 3rd party compatibility. Enable debug traces: /opt/kaspersky/epagent/sbin/lenactl --traces --on This method is not suitable for ANY traces and will override ANY traces level set previously by DEBUG value Wait for a while until the problematic behavior is reproduced; Disable traces: /opt/kaspersky/epagent/sbin/lenactl --traces --off Collect the produced logs and system information in one go using collect.sh script How to: enable LENA log rotation To add log rotation, add to /etc/opt/kaspersky/epagent/service.conf following strings: /etc/opt/kaspersky/epagent/service.conf LENA_ROTATION_COUNT=10 <-- set max number of log files LENA_ROTATION_FILE_SIZE=100m <-- set the size of each file To apply changes, restart epagent service systemctl restart epagent

Problem Messaged are delayed for 50 minutes and in /var/log/maillog there are following entries: Dec 10 12:07:07 ksmg KSMG: put to asp quarantine: message-id="": relay-ip="10.10.1.1": action="Postponed": size=21958: mail-from="test@example2.com": rcpt-to="test@example.com" Solution This is a a feature which delays some suspicious messages for 50 minutes (by default) and then rescan them with newer bases and information in KSN. This can be turned off in Settings -> Protection -> Anti-Spam -> Use reputation filtering. The delay can be tweaked in Settings -> Protection -> Anti-Spam Quarantine. Delayed (quarantined) messages are visible in Message Queue section of KSMG and can be forced to be delivered from there with 'Flush' button. Which messages to delay or not to delay can be tweaked with bases, so if you get messages that are delayed but shouldn't, then please provide message samples to Kaspersky Support for investigation as 'false positives'. For KSMG 2.0 (Use Anti-Spam Quarantine and Maximum Quarantine duration options accordingly):

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Problem There is no mechanism to replace client root certificate used for iOS MDM via reserve certificate. That's why replacing the client root certificate used for iOS MDM will cause iOS MDM server to lose synchronization with all devices. Details of active certificate can be viewed in the properties of iOS MDM server, on the "Certificates' tab. Step-by-step guide The iOS MSM Server Client Root certificate replacement procedure includes the following steps: Backup iOS MDM Server configuration via kliosbackup utility: kliosbackup -backup(-restore) -path BACKUP_PATH [-pwd PASSWORD] Backup Kaspersky Security Center configuration via klbackup utility or ‘Backup of Administration Server data’ task; Create a new certificate in the PKCS#12 format using the PKI infrastructure; Submit the certificate to the input of the klsetsrvcert tool just the same way as it is described in the corresponding Kaspersky Security Center versions online help articles (for example, for KSC 14.2: https://support.kaspersky.com/KSC/14.2/en-US/227838.htm? klsetsrvcert -t MCA {-i <inputfile> [-p <password>] | -g <dnsname>} [-l <logfile>]. These actions will update the iOS MSM Server Client Root certificate, you may check C:\ProgramData\KasperskyLab\adminkit\1093\cert\klsrvmdm.cer to make sure that a new one certificate has been installed. Recommendations: Validity: up to 5 years Key length: 4096 bits (2048 bits is also possible, but for a five-year certificate it is still better to use 4096) Setting the EKU (Extended Key Usage) for this certificate in Client Authentication Automatic replacement of the client root certificate used for iOS MDM and issued through Administration server tools has been implemented since KSC 12.2 and higher.

Problem You may encounter issues with KEA that may include: Excessive resource consumption Freezes, crashes etc. Solution Install the latest available core patch. Adding KEA CF to KEA installation package is not supported and will not work, patches need to be installed separately. To install patch using KSC or locally use the following keys, /qn can be added for silent install as usual How to install patch msiexec /p private_critical_fix_99.msp DISCLAIMER=1 EULA=1 PRIVACYPOLICY=1 When installing on servers it is advisable to use additional SERVERPROFILE=1 key for optimized performance (works for core patches starting from CF8 for KEA 3.12 and newer) Additional recommended key for Server installations: msiexec /p private_critical_fix_99.msp DISCLAIMER=1 EULA=1 PRIVACYPOLICY=1 SERVERPROFILE=1 For password-protected installations additional key is needed: UNLOCK_PASSWORD=password For detailed info see article https://forum.kaspersky.com/topic/how-to-install-patches-on-password-protected-kea-kaspersky-endpoint-agent-38148/ Things to keep in mind: All Core patches are cumulative; That means all previous fixes are included. Newer KEA versions include fixes done in previous versions. It's not always necessary to keep KEA at latest core, but it's worth starting your troubleshooting with installing the latest one.

Kaspersky Endpoint Agent, as many other products, has a few different ways of enabling traces. Traces folder NB! The folder specified for traces must exist and be writable. KEA will neither create folder nor display any error if it doesn't exist. One may choose which is best suitable for their needs: Traces with restart In 99% cases, information that is written only during initialization, that is, after KEA restart, is critical for investigation. Unless specified otherwise, always perform KEA restart when collecting traces (after traces are enabled), either by restarting KEA service , via services.msc In some cases, Kaspersky Support Engineer may ask to perform the restart after the reproduction, in that case, restart KEA not after starting traces, but 2 minutes before stopping traces. or using CLI: Elevated cmd (as Admin) sc restart soyuz Verification: traces with restart will always contain the lines with the below text: Traces with restart kata. codeinjection.rule If the text is nowhere to be found, traces are collected without restart and are of zero to no use, such traces need to be recollected following the procedure. Using the agent.exe utility When working with KEA on local host, use cmd or Powershell, started as Administrator, however in some cases KEA installation folder is restricted and requires Local System account to be accessed (one can use Windows Scheduler or, if approved, psexec tool to execute command under Local System). To enable KEA traces: C:\Program Files (x86)\Kaspersky Lab\Endpoint Agent>agent.exe --trace enable --folder C:\path\to\folder To disable traces: C:\Program Files (x86)\Kaspersky Lab\Endpoint Agent>agent.exe --trace disable Modifying registry key Traces This option is specifically useful when you have troubles starting KEA service. Modify the registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\KasperskyLab\SOYUZ\4.0\Trace\Configuration For your convenience, there's also a registry key with example of Debug configuration next to this one: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\KasperskyLab\SOYUZ\4.0\Trace\Configuration(Example) logging=on;layout=basic;sub-system=*;sink=folder(c:\traces\);level=debug;roll=51200 Notice that in this example traces folder is configured to be c:\traces\. As previously mentioned, the folder specified for traces must exist and be writable so if you decide to use this configuration "as is" you need to create c:\traces folder manually. To disable traces, restore original content of the registry key (logging=off? Disable traces HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\KasperskyLab\SOYUZ\4.0\Trace\Configuration logging=off Dumps Enable dumps HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\KasperskyLab\SOYUZ\4.0\CrashDump "Enable"=dword:00000001 "Folder"="c:\\traces\\" "Enable(Example)"=dword:00000001 "Folder(Example)"="c:\\traces\\" Notice that in this example dump folder is configured to be c:\traces\. This folder must exist and be writable so if you decide to use this configuration "as is" you need to create c:\traces folder manually. To disable traces, restore original content of the registry key: Disable dumps HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\KasperskyLab\SOYUZ\4.0\CrashDump "Enable"=dword:00000000 Using KSC console Enabling traces and dumps Execute the following steps: In the properties of target host in KSC console, locate Endpoint Agent app Open Properties of Endpoint Agent, and navigate to Troubleshooting tab and enable traces and dumps(if needed). NB! It's recommended to write traces to C:\ProgramData\Kaspersky Lab\ folder! To be able to retrieve the traces using Remote Diagnostics Utility configure the traces folder to be the same as respective EPP traces folder, e.g.: For KES %ProgramData%\Kaspersky Lab\KES\Traces For KSWS %programfiles(x86)%\Kaspersky Lab\Kaspersky Security for Windows Server\~TraceFiles Retrieving traces To download files remotely, execute the following steps: Connect to target host with Remote Diagnostics Utility Navigate to KES Trace files folder: Locate soyuz_*.log, proton_*.log, klnagent_*.log - these are Endpoint Agent trace files: Download these files using the 'Download' button. Enabling traces from installation https://forum.kaspersky.com/topic/how-to-enable-kea-traces-from-installation-kaspersky-endpoint-agent-38143/

Problem OAuth consent validation algorithm is the same for Exchange online, OneDrive and SharePoint online. Initial steps of consent validation algorithm are basically the following: A user is redirected to the Microsoft website, where the user agrees to provide necessary permissions for our Azure application. KS365 receives an OAuth callback confirming that the consent was received. But we do not trust this callback as it can be forged. The user is redirected to the Microsoft website to receive an access token that will be used for the validation of the user authenticity. KS365 receives the callback with the access token. After that, the user is redirected to the KS365 website, where the user's session will be started. Step-by-step guide When the user is redirected back to our website on the 4th step, they can encounter the HTTP 401 error: In theory, the user should have successfully authorized as all the necessary data is stored in the browser cookies. Thus, the issue must be on the user's browser side. In such cases, we recommend to attempt the following: Try to add the integration with Exchange Online/Sharepoint Online/OneDrive in a different browser (or even try a different host with different browser versions/settings). Check browser settings related to cookies: if they are supported/enabled, try disabling auto-delete of cookies if it is enabled, etc.

To use HAProxy as a load balancer in front of KWTS (iso installation and built-in proxy used) we recommend the following: HAProxy configuration: global log 127.0.0.1 local2 chroot /var/lib/haproxy pidfile /var/run/haproxy.pid maxconn 4000 user haproxy group haproxy daemon stats socket /var/lib/haproxy/stats defaults mode tcp log global retries 3 timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout check 10s maxconn 30000 frontend kwts_proxy bind *:3128 mode tcp default_backend kwts_proxy_pool backend kwts_proxy_pool balance leastconn mode tcp server kwts_node1 10.10.1.42:3128 check send-proxy server kwts_node2 10.10.1.43:3128 check send-proxy where 10.10.1.42 and 10.10.1.43 are KWTS IP addresses; 3128 is the port where KWTS built-in proxy is listening (Settings → Built-in proxy server → Common → Port); 8080 is the port of the load balancer. Configure KWTS to use PROXY protocol header (Settings → Built-in proxy server → Common → Load balancing → Mode); Make sure HAProxy IP address is in trusted list on KWTS (Settings → Built-in proxy server → Common → Load balancing → Trusted load balancers); If Kerberos proxy authentication is used, make sure keytab contains SPN record of FQDN address of the load balancer; Make sure that browser is configured to use FQDN and port of load balancer.

KATA / EDR is using only one certificate for all connections (like WebServer and Client Connections). When you plan to replace it, do it in an early stage of deployment. If you want to replace the TLS certificate, you will need to: Reauthorize mail sensors (KSMG, KLMS) on Central Node. Reconfigure connection of Central Node, PCN and SCN to Sandbox. Reconfigure Endpoint Agent traffic redirection to Sensor and trusted connection with Endpoint Agent. Upload a new certificate in Active Directory (if you use it in Active Directory). Prepared TLS certificate must satisfy the following requirements: The file must contain the certificate itself and a private encryption key for the connection. To generate a pem from your PKI PFX you can use the following command: openssl pkcs12 -in mySecureCertificate.pfx -out kata.pem -nodes The file must be in PEM format. The private key length must be 2048 bits or longer. After replacing the certificate don't forget to replace it in KEA Policy → KATA Integration → KATA Integration Settings → Add new TLS certificate (not the Add Client certificate). The certificate you specify needs to be in CRT Format. You can get it by "Downloading" the Certificate from CN → Settings → General Settings → Download.

You may want to obtain list of EDR agents ever connected to KATA. Step-by-step guide KATA 3.7+ Connect to Central Node via ssh, choose Technical support mode, become root: $ sudo -i Execute command: sudo -u postgres psql antiapt -c "select * from agent_status;" KATA 4.0/4.1/5.0/5.1 psql -U kluser -h 127.0.0.1 antiapt -c "select * from agent_status;" All agents with only hostname, ip, last_packet_time columns can be exported this: psql -U kluser -h 127.0.0.1 antiapt -c "select hostname,ip,last_packet_time from agent_status;" > /tmp/agents Export all agents from SCNs connected to PCN execute psql -U kluser -h 127.0.0.1 primarydb -c "select hostname,ip,last_packet_time from agent_status;" > /tmp/agents Then open Excel and make import from Data -> From Text/CSV from /tmp/agents (download it to local computer first). The resulting output will be the list of agents.

Problem If you install standalone Kaspersky Endpoint Agent, both KSC installation package and local installer provide option to choose, which KEA components to install: However, when KEA is installed in built-in scenario, bundled with KES or KSWS, you don't get to choose and KEA is installed in default configuration, with all the components. There's a way to select installed KEA components even for built-in scenarios. Using install_props.json for changing installed components As KEA section of Online Help states, it is possible to configure installation options via install_props.json. EDR Optimum help even describes how to use it for built-in scenario. However, installer options for components selection are not covered by Online Help. Directives and values ADDLOCAL directive defines, which components of KEA will be installed. REMOVE directive defines which components will not be installed. There are five possible values for directives in KEA now: Name Feature ALL Default value. Installs all available features, can only be used this way: ADDLOCAL=ALL Core Core functionality of Endpoint Agent. Must be installed. KATA KATA/EDR Expert and other message brokers integration. SB Kaspersky Sandbox integration EDR EDR Optimum Example This example will install Endpoint Agent with KATA integration, but without Kaspersky Sandbox integration: [Setup] ADDLOCAL=Core,KATA REMOVE=SB How to use the file File (example) with options should be placed next to the Kaspersky Endpoint Agent installer, endpointagent.msi. For the remote installation via KSC, location should be similar to C:\ProgramData\KasperskyLab\adminkit\1093\.working\share\Packages\KES_<version>\exec\agent

Problem Using EDR, you may encounter an issue where you're unable to view incident card regarding a detection in KSC Web Console. It looks like this: Here we will discuss known causes of such behavior (several products are involved, so causes may be different). Possible causes and solutions MDR In MDR, incidents are to be viewed using the dedicated MDR Console, and KSC version 13 and newer with configured MDR plug-in. KSC 12.* Web Console will not receive the data; this is expected behavior. KES+KEA If you first install KES without EA component, and then a standalone KEA package, KES EDRO integration will be disabled and killchain will not work. Here is a quick way to determine if KEA was installed as a component of KES. Open regedit, then navigate to: [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\KasperskyLab\protected\KES\Installer\features] "AntiAPTFeature" = "1" If the value is 0, proceed to the workaround to enable the component as described below. To fix this, we ran Change application components task on the host, enabling Endpoint Agent in KES. If KES/KEA integration is configured correctly, we can find the following in KES traces: 12:08:37.426 0x2a18 INF edr_etw Start processing detect = http://www.virusanalyst.com/eicar.zip//eicar/eicar.com, recordId = 6, taskId = 1128, result = 0 12:08:37.426 0x2a18 INF edr_etw Start processing actions = http://www.virusanalyst.com/eicar.zip//eicar/eicar.com, action = 4, recordId = 6, taskId = 1128, edrAction = 3489660999, result = 0 12:08:37.442 0x2a18 INF edr_etw Killchain is enabled! 12:08:37.442 0x2a18 INF edr_etw SystemWatcher is running! 12:08:37.442 0x2a18 INF edr_etw product::component::edr::`anonymous-namespace'::IsSystemWatcherDetect begin 12:08:37.442 0x2a18 INF edr_etw product::component::edr::`anonymous-namespace'::IsSystemWatcherDetect end 12:08:37.442 0x2a18 INF edr_etw product::component::edr::`anonymous-namespace'::InvestigateProcessIds begin 12:08:37.442 0x2a18 INF edr_etw product::component::edr::`anonymous-namespace'::InvestigateProcessIds end 12:08:37.442 0x2a18 INF edr_etw Finish processing detect = http://www.virusanalyst.com/eicar.zip//eicar/eicar.com threat status = 1, recordId = 6, taskId = 1128,result = 0 12:08:37.458 0x1f18 INF edr_etw Finish processing AV detect result = 0 Searching for ThreatID in KEA traces: 12:08:37.426 0x2a18 INF amfcd ThreatsProcessingEventsLogic::OnTreatActionImpl: ctx:0x23d68510 [TI 0x1b8dd490: id = 0x6, : tdid = {7F620459-6C51-9E46-9A5D-689A9B0D0098}, name = http://www.virusanalyst.com/eicar.zip//eicar/eicar.com, add info: <none>, 0x0] 0x4 0x0 KES+KEA (upgrade from KESB to EDR Optimum) EDR Optimum requires KSC 12.1 or newer to work. This includes the Network Agent, which is a part of KSC, and is generally installed on the host alongside KES. Using an outdated version of Network Agent (10.5, 11, etc.) will lead to the mentioned error when opening incident cards. If Network Agents were not upgraded along KSC, it's better upgrading them for EDR Optimum. KES 11.7+ Check that EDR Optimum feature is enabled in registry (GSI > Registry > HKLM_Software_Wow6432Node_KasperskyLab.reg.txt ). [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\KasperskyLab\protected\KES\Installer\features] EdrOptimumFeature = 1 If value is 0, run Change application components task on the host, enabling EDR Optimum in KES. Also in traces (*.SRV.log) you can search for sentence bundles::InstalledFeaturesProvider::InstalledFeaturesProvider and check that EDROptimumFeature is there, for instance in example below such component is missing KES.21.9.6.465_05.18_14.00_3952.SRV.log 11:00:36.897 0x26a0 INF bundles::InstalledFeaturesProvider::InstalledFeaturesProvider{ 3 (AVScannerAndCoreFeature) 28 (AdaptiveAnomaliesControlFeature) 0 (AdminKitConnectorFeature) 24 (AdvancedThreatProtectionFeature) 27 (AmsiFeature) 7 (ApplicationControlFeature) 17 (BehaviorDetectionFeature) 30 (CloudControlFeature) 4 (CriticalScanTask) 6 (DeviceControlFeature) 23 (EssentialThreatProtectionFeature) 11 (ExploitPreventionFeature) 8 (FileThreatProtectionFeature) 19 (FirewallFeature) 5 (FullScanTask) 2 (HostIntrusionPreventionFeature) 16 (MailThreatProtectionFeature) 14 (NetworkThreatProtectionFeature) 12 (RemediationEngineFeature) 25 (SecurityControlsFeature) 18 (UpdaterTask) 21 (WebControlFeature) 20 (WebThreatProtectionFeature) 22 (WholeProductFeature) } KSWS+KEA The same rule applies: KEA component needs to be installed in KSWS. KSWS does not have a "Change application components" task in KSC, so this has to be taken into account during KSWS deployment. Here is a quick way to determine if KEA was installed as a component of KSWS. Open regedit, then navigate to: [HKEY_LOCAL_MACHINE\Software\Wow6432Node\KasperskyLab\\WSEE\11.0\Install] "Features"="AntiCryptorNAS=0;AntiCryptor=0;AntiExploit=0;AppCtrl=0;AVProtection=0;DevCtrl=0;Fim=0;Firewall=0;ICAPProt=0;IDS=0;Ksn=0;LogInspector=0;Oas=0;Ods=0;RamDisk=0;RPCProt=0;ScriptChecker=0;Soyuz=0;WebGW=0" (Soyuz needs to be set to 1) If Soyuz is set to 0, apply workaround to enable it. KSWS allows to change its components locally or via cli. Here is the example of how to set Soyuz=1 when KEA was installed not as a component of KSWS: 1. Locate ks4ws_x64.msi or ks4ws.msi (depends on OS architecture) 2. Create custom installation package based on ks4ws_x64.msi or ks4ws.msi from p.1 with parameters as per screenshot (add UNLOCK_PASSWORD= if KSWS is protected by password in policy) 3. Deploy package on problematic servers with KSWS and KEA, then check registry that Soyuz=1 4. Check host's properties at KSC side - EDRO should be in Running state in KEA If KSWS/KEA integration is configured correctly, we can find the following in KSWS traces: 19:57:04.577 7a8 1310 info [edr] Published ThreadDetected: VerdictName : HEUR:Win32.Generic.Suspicious.Access RecordId : 0 DatabaseTime : 18446744073709551615 ThreatId : {ffb58079-6d8d-4a62-8ab0-021ff4ed61c5} IsSilent : false Technology : 3489661023 ProcessingMode : 3489660948 ObjectType : 3489660934 ObjectName : C:\Windows\System32\wbem\WmiPrvSE.exe Md5 : e1bce838cd2695999ab34215bf94b501 Sha256 : 1d7b11c9deddad4f77e5b7f01dddda04f3747e512e0aa23d39e4226854d26ca2 UniquepProcessId: 0xf7c807730e051a0d NativePid : 3360 CommandLine : AmsiScanType : AmsiScanBlob : FileCreationTime: 1601-01-06T23:09:56.075520800Z Searching for ThreatID in KEA traces: 19:57:05.583 704 9b0 debug [bl] ThreatsHandler: detect v2 verdictName: HEUR:Win32.Generic.Suspicious.Access detectTechnology: 0xd000005f processingMode: 0xd0000014 objectType: 0xd0000006 objectName: C:\Windows\System32\wbem\WmiPrvSE.exe nativePid: 3360 uniquePid: 17854528913448180237 nativePidTelemetry: 3360 uniquePidTelemetry: 17854528913448180237 downloaderUniqueFileId: <none> downloadUrl: <none> isSilentDetect: false threatId: ffb58079-6d8d-4a62-8ab0-021ff4ed61c5 19:57:05.583 704 650 info [evtstt] NetworkConnectionHandler statistics: queueSize=0, received=59675, processed=59675, dropped=0, queueBytes=191 19:57:05.583 704 650 info [evtstt] NetworkConnectionHandler statistics: queueSize=0, received=59676, processed=59676, dropped=0, queueBytes=132 19:57:05.583 704 650 info [evtstt] NetworkConnectionHandler statistics: queueSize=0, received=59677, processed=59677, dropped=0, queueBytes=371 19:57:05.583 704 9b0 debug [bl] Threats Handler: event processed, id = 2 19:57:05.584 704 1fc debug [killchain] Message discarded: name = ThreatDetect The verdict is Message discarded, this means the detection won't trigger killchain generation. No such entries can be found in traces, which might mean that EPP integration is not configured correctly (EDR component is disabled in KSWS). Check killchain presence on the host If all pre-requisites are met, it's worth checking if killchain files are actually created on the host. To check that, run cmd.exe as Administrator and check the c:\ProgramData\Kaspersky Lab\Endpoint Agent\4.0\Data\killchain\detects folder contents. Archives with <threat_id>.zip names should be present in the folder: C:\WINDOWS\system32>dir "c:\ProgramData\Kaspersky Lab\Endpoint Agent\4.0\Data\killchain\detects" Volume in drive C has no label. Volume Serial Number is 8010-ADC0 Directory of c:\ProgramData\Kaspersky Lab\Endpoint Agent\4.0\Data\killchain\detects 08/16/2021 12:20 PM <DIR> . 08/16/2021 12:20 PM <DIR> .. 08/16/2021 09:34 AM 636 0349c190-4ac3-4da4-9b64-07835298660f.zip //this is an archive with killchain info 08/16/2021 12:18 PM 696 1d306aa7-f37f-4ab2-969e-d337d398a995.zip 08/16/2021 09:34 AM 637 23a5dc93-5776-43c8-b949-79c102aa1184.zip 08/16/2021 12:19 PM 691 27bc9ea3-200b-49d2-b8b0-df7954cd428a.zip 08/16/2021 12:19 PM 683 40673c70-9e8e-420f-b5ce-65b406862b94.zip 08/16/2021 12:19 PM 688 590b6e30-4509-4b25-bdb0-062f89b7e062.zip 08/16/2021 12:20 PM 693 67993612-dc82-45a2-9e5b-74756adc46eb.zip 08/16/2021 12:20 PM 685 6a892bd1-f452-42d0-80b0-cb953cd7fc26.zip 08/16/2021 12:19 PM 686 a63fbafa-fcef-46f7-935f-42be4392a172.zip 08/16/2021 12:19 PM 699 d9d4f5eb-42b2-4460-8f8a-eb63bbef8791.zip 08/16/2021 12:19 PM 686 f6042624-9840-4a6e-9b30-9270cce22236.zip 11 File(s) 7,480 bytes 2 Dir(s) 240,763,092,992 bytes free

The KESMac 12 and the KESMac 11.3 patch C allows adding particular processes into the trusted section named Trusted Applications. 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: The Trusted applications section as seen in the policy creation wizard. Naturally, it can be configured later by modifying the policy. Update the plugin to at least version 11.3.0.33 to get the new functionality. 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. Trusted Applications are only available for configuration via KSC policy; i.e. it is currently impossible to add application to exclusions having no KSC installed. Additionally, an appropriate application control plug-in for KESMac must be downloaded and installed on the KSC prior to using Trusted Application functionality. It can be found on the corresponding download page. 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:

Introduction Often problems with Kerberos are difficult to diagnose but they occur if you're deploying KWTS for the first time. There are three functional places in the product where Kerberos authentication can be used: Proxy authentication This is needed for users to authenticate on the proxy server automatically without login prompt. If login prompt pops-up, then Kerberos authentication failed. LDAP authentication This is needed for KWTS to synchronize LDAP cache with LDAP servers (simply put - with domain controllers). This cache is used in Rules creation and if KWTS has user login information for a given session supplied by proxy server, then traffic can be matched against those Rules that are defined by groups in AD for example. SSO This is needed to authenticate users on KWTS web administration console itself. SSO works only for one domain, as it is for KSMG as well. Check the documentation https://support.kaspersky.com/KWTS/6.1/en-US/166491.htm Read Kerberos and LDAP parts. Terminology FQDN - https://en.wikipedia.org/wiki/Fully_qualified_domain_name . In our use cases looks like: kwts.example.com SPN - Unique ID of the service in the network for authentication over the Kerberos protocol. In our use cases looks like: HTTP/<FQDN>@<realm Active Directory service in the upper case> or HTTP/*****@*****.tld Creating keytabs for multiple nodes For LDAP, SSO and Proxy authentication you need to create two keytabs: Keytab For LDAP without SPN Keytab for SSO and Proxy with SPN In this example there are two servers in cluster kwts1.example.com and kwts2.example.com and Realm (Domain) is EXAMPLE.COM. Please bear in mind that hostname of KWTS node in OS MUST be in lower-case. If it's in upper-case change hostname via command hostnamectl set-hostname kwts1.example.com First you remove any existing kwts users from AD and create new ones *****@*****.tld and *****@*****.tld Then for LDAP you don't need SPN, so create LDAP keytab like so (replace <password> with user password): ktpass.exe /crypto AES256-SHA1 /ptype KRB5_NT_PRINCIPAL /out C:\kwts-ldap.keytab /princ kwts-ldap-user@EXAMPLE.COM /pass <password> You can now add C:\kwts-ldap.keytab to LDAP settings and force LDAP synchronization. For SSO and Proxy authentication you then create a first keytab like so (do not use upper case letters in FQDN part kwts1.example.com/kwts2.example.com of SPN, this will not work for SSO): ktpass.exe -princ HTTP/kwts1.example.com@EXAMPLE.COM -mapuser kwts-control-user@EXAMPLE.COM -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass <password> -out C:\kwts-control-1.keytab Then using this keytab you create a new keytab with a second record in it: ktpass.exe -princ HTTP/kwts2.example.com@EXAMPLE.COM -mapuser kwts-control-user@EXAMPLE.COM -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass <password> -in C:\kwts-control-1.keytab -out C:\kwts-control-2.keytab -setupn -setpass If there are more servers, then please add more entries in the same manner. You can now add C:\kwts-control-2.keytab to SSO settings. When testing SSO you should use https://kwts1.example.com and https://kwts2.example.com URLs, not IP. If you are asked for credentials then it means that SSO doesn't work. For SSO on Internet Explorer and Chrome it is important that https://kwts1.example.com and https://kwts2.example.com are added to Local Intranet zones in IE settings (refer to https://support.kaspersky.com/ksmg/228052 - article is for KSMG, but fully applicable to KWTS as well): Open Internet Explorer and click the Settings gear icon in the top-right corner. Select Internet options. Select the Security tab. Select the Local Intranet zone and click the Sites button. Make sure that the first two options, Include all local (intranet) sites not listed in other zones and Include all sites that bypass the proxy server are checked. Click Advanced and add the KWTS addresses, one at a time, to the list of websites. In this example add https://kwts1.example.com and https://kwts2.example.com. Click Close. Click OK to save your configuration changes. For Firefox: Open the low level Firefox configuration page by loading the about:config page. In the Search text box, enter: network.negotiate-auth.trusted-uris Double-click the network.negotiate-auth.trusted-uris preference and enter KWTS address. Separate multiple addresses with a comma. Click OK. Now, if SSO works fine you can add the same C:\kwts-control-2.keytab to Proxy authentication settings and test it. When testing proxy authentication make sure proxy address in browser settings is set to kwts1.example.com or kwts2.example.com. IP address will not work. Creating SSO/Proxy keytabs for two domains (or more) for two nodes and a balancer Users from *both* domains must connect to KWTS via proxy1-kwts.firstdomain.ru FQDN, this is not optional. On domain controller of FIRSTDOMAIN.RU (user: control-user-domain1): C:\Windows\system32\ktpass.exe -princ HTTP/proxy1-kwts.firstdomain.ru@FIRSTDOMAIN.RU -mapuser control-user-domain1@FIRSTDOMAIN.RU -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass password1 +dumpsalt -out c:\Temp\1.keytab Assuming we've got salt "FIRSTDOMAIN.RUHTTPproxy1-kwts.firstdomain.ru" (salt usually consists of DOMAIN + HTTP + fqdn string, it is case sensitive, and doesn't change in the scope of a single user) C:\Windows\system32\ktpass.exe -princ HTTP/proxy2-kwts.firstdomain.ru@FIRSTDOMAIN.RU -mapuser control-user-domain1@FIRSTDOMAIN.RU -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass password1 -in c:\Temp\1.keytab -out c:\Temp\2.keytab -setupn -setpass -rawsalt "FIRSTDOMAIN.RUHTTPproxy1-kwts.firstdomain.ru" C:\Windows\system32\ktpass.exe -princ HTTP/balancer-kwts.firstdomain.ru@FIRSTDOMAIN.RU -mapuser control-user-domain1@FIRSTDOMAIN.RU -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass password1 -in c:\Temp\2.keytab -out c:\Temp\3.keytab -setupn -setpass -rawsalt "FIRSTDOMAIN.RUHTTPproxy1-kwts.firstdomain.ru" On domain controller of SECONDDOMAIN.RU (user: control-user-domain2): Copy c:\Temp\3.keytab from FIRSTDOMAIN.RU domain controller to c:\Temp\3.keytab on SECONDDOMAIN.RU domain controller C:\Windows\system32\ktpass.exe -princ HTTP/proxy1-kwts.firstdomain.ru@SECONDDOMAIN.RU -mapuser control-user-domain2@SECONDDOMAIN.RU -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass password2 +dumpsalt -in c:\Temp\3.keytab -out c:\Temp\4.keytab Assuming we've got salt "SECONDDOMAIN.RUHTTPproxy1-kwts.firstdomain.ru". C:\Windows\system32\ktpass.exe -princ HTTP/proxy2-kwts.firstdomain.ru@SECONDDOMAIN.RU -mapuser control-user-domain2@SECONDDOMAIN.RU -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass password2 -in c:\Temp\4.keytab -out c:\Temp\5.keytab -setupn -setpass -rawsalt "SECONDDOMAIN.RUHTTPproxy1-kwts.firstdomain.ru" C:\Windows\system32\ktpass.exe -princ HTTP/balancer-kwts.firstdomain.ru@SECONDDOMAIN.RU -mapuser control-user-domain2@SECONDDOMAIN.RU -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass password2 -in c:\Temp\5.keytab -out c:\Temp\6.keytab -setupn -setpass -rawsalt "SECONDDOMAIN.RUHTTPproxy1-kwts.firstdomain.ru" Apply 6.keytab in SSO and Built-in proxy kerberos authentication settings. Notable differences and restrictions in Kerberos keytab requirements For Proxy and SSO authentication FQDN that is specified in keytab must always match the real and used FQDN. For Proxy authentication the address that is used in browser proxy settings MUST match the FQDN in keytab. For SSO, the address in the address bar in the browser that is used to access KWTS web interface MUST match the FQDN in the keytab and MUST match the real FQDN of KWTS and FQDN that is configured in OS. But for LDAP the FQDN in keytab SPN should just have valid records in DNS including PTR record. It is also not necessary for LDAP keytab to have an SPN at all while you must have it for Proxy and SSO; For LDAP authentication it is not possible to have multiple SPN entries in keytab. But in case of Proxy and SSO authentication you can create multiple entries. However for LDAP it is not needed (see 1); You cannot have SPN duplicates in the same domain. Meaning that you can't create two different keytabs that have duplicate SPN (which includes FQDN), you must not have SPN duplicates with different mapped users; User which was used to create keytab must contain only latin characters in Distinguished Name, so in the entire path to the user in AD there must not have Cyrillic or other characters. To sum up usually you must create two keytabs: For Proxy and SSO that have all the SPNs with all FQDNs of proxy and secondary nodes (to which fallback if control node fails); For LDAP that doesn't have an SPN or has one that just has an FQDN with valid DNS records but is not duplicate to any SPN in 1. How KWTS connects to LDAP servers using keytab There is no ldap server address configuration in KWTS. It takes the REALM (Domain) from keytab, for example EXAMPLE.COM, then the following DNS requests of type SRV are sent: _ldap._tcp.example.com _kerberos._tcp.example.com In KWTS console such requests can be reproduced with dig srv _ldap._tcp.example.com dig srv _kerberos._tcp.example.com There you will see a list of domain controllers, ports, weighs and priorities. For more information on SRV records see https://en.wikipedia.org/wiki/SRV_record LDAP servers are listed in _ldap._tcp.example.com , default port 389. _kerberos._tcp.example.com is needed for Kerberos, default port 88. Connection is tried to each one from the list (one at a time, with a timeout) until a it is successfully established or the list is exhausted. LDAP+Kerberos diagnostics To diagnose LDAP synchronization issues first turn on Debug level traces (link). Then reproduce the problem by clicking Synchronize button in LDAP settings. In 10-20 minutes depending on the size of your domains and number of them you should be able to check traces either directly on the server like so: grep LdapC /var/log/kwts-traces | less or by getting the built-in collect and looking in kwts-traces files by other means (link). For example, if you see the following errors: Sep 29 15:30:01 srv-proxy2 KWTS LdapCache[33227]: 33227 DBG trying to connect ldap://server.local:389 Sep 29 15:30:01 srv-proxy2 KWTS LdapCache[33227]: 33227 WRN Couldn't connect ldap://server.local:389 Sep 29 15:30:01 srv-proxy2 KWTS LdapCache[33227]: 33227 ERR CheckFailedException - LDAP error (-2) : Local error - Cannot perform LDAP SASL interactive bind operation. At /tmp/buildbot/core_ldap_cache-kwts_linux-64/build/source/ldap/connection.cpp(203) Then make sure you can connect to server.local:389 with telnet and verify that: On KWTS you can resolve server.local by FQDN and resolve PTR for its IP. Domain controller PTR record should be matched to A record otherwise Kerberos will not work and the error will be exactly as in above log; On server.local you can resolve KWTS by FQDN and resolve PTR for its IP; Time on KWTS servers is synchronized properly with an NTP server. How to use multiple domains in LDAP Create multiple LDAP connections in LDAP settings, one for each domain and use a separate keytab for each; Make sure that a specific DNS server can resolve _kerberos._tcp. and _ldap._tcp. SRV records for each domain. For that in the main domain DNS server you can create stub DNS zones for each domain; Configure KWTS to use that DNS server. Proxy authentication diagnostics Check squid logs: /var/log/squid/cache.log shouldn't contain errors regarding Kerberos or NTLM /var/log/squid/access.log should contain usernames of authenticated users For example: negotiate_kerberos_auth.cc(182) : pid=63851 :2020/06/03 11:28:00| negotiate_kerberos_auth: ERROR: gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information. Request ticket server HTTP/kwts.test.local@TEST.LOCAL kvno 2 found in keytab but not with enctype rc4-hmac Means that keytab was created with AES128 or AES256 encryption but the user with which it was created doesn't have AES128 or AES256 enabled in user settings (Properties → Account → Account Options → This account supports Kerberos AES 128/256 bit encryption). Trace kinit: Run on KWTS: KRB5_TRACE=/tmp/kr.tr kinit -Vkt /etc/squid/auth_krb5.keytab HTTP/FQDN@REALM where HTTP/FQDN@REALM is the SPN of used keytab. For standalone (not built-in proxy) instead of /etc/squid/auth_krb5.keytab specify the real path to keytab); Check output of the command AND /tmp/kr.tr file, it should contain detailed trace. SSO authentication diagnostics Check logs in /var/log/kaspersky/kwts/extra/ For example in webapi.log if you see ERROR:root:GSSError: (('Unspecified GSS failure. Minor code may provide more information', 851968), ('Request ticket server HTTP/*****@*****.tld found in keytab but does not match server principal HTTP/dpc-kwts-01.example.com@', 100005)) [pid: 14648|app: 0|req: 701/53178] 10.199.5.19 () {50 vars in 4127 bytes} [Wed Oct 14 14:12:46 2020] GET /web/api/get-session-info?cb=1602673966446 => generated 224 bytes in 12 msecs (HTTP/1.1 403) 3 headers in 93 bytes (1 switches on core 0) That means that there are two PTR records in DNS for KWTS IP address. Remove one that is not for the FQDN that should be used to access KWTS web interface. ./celery.log:[2020-06-02 18:00:47,860: ERROR/ForkPoolWorker-1] there are no valid principal for HTTP service on kwts.example.com host in keytab data; <class 'kerberos.KrbError'>: ('Principal not found in keytab', -1) ./webapi.log:ERROR:root:there are no valid principal for HTTP service on kwts.example.com host in keytab data; <class 'kerberos.KrbError'>: ('Principal not found in keytab', -1) Means there is no SPN record in keytab for the FQDN which was accessed by the web browser. ./webapi.log:ERROR:root:GSSError: (('Unspecified GSS failure. Minor code may provide more information', 851968), ('Request ticket server HTTP/*****@*****.tld kvno 6 found in keytab but not with enctype rc4-hmac', 100005)) Means the keytab was created with AES128 or AES256 cryptography but it is not enabled in user settings in AD. ./webapi.log:ERROR:root:GSSError: (('Unspecified GSS failure. Minor code may provide more information', 851968), ('Request ticket server HTTP/*****@*****.tld kvno 8 not found in keytab; keytab is likely out of date', 100005)) Means keytab was created with wrong user password or password was changed after keytab was created. Time out sync between KWTS and DC On KWTS time is far behind DC: ./webapi.log:ERROR:root:GSSError: (('Unspecified GSS failure. Minor code may provide more information', 851968), ('Ticket not yet valid', 100005)) On KWTS time is far ahead DC: ./webapi.log:ERROR:root:GSSError: (('Unspecified GSS failure. Minor code may provide more information', 851968), ('Ticket expired', 100005)) On KWTS time is slightly ahead DC: ./webapi.log:ERROR:root:GSSError: (('Unspecified GSS failure. Minor code may provide more information', 851968), ('Clock skew too great', 100006)) Also you can upload the keytab to the server via WinSCP and trace kinit as in proxy authentication diagnostics. If kinit is successful but browser doesn't authenticate check that web interface FQDN is added to trusted servers in browser settings. See for example: https://docs.cloudera.com/documentation/enterprise/5-12-x/topics/cdh_sg_browser_access_kerberos_protected_url.html Please note that if the keytab that you are adding does not contain an SPN with FQDN from 'hostnamectl' command output, you will get "Invalid keytab file for the Control node". In that case change hostname to FQDN with: hostnamectl set-hostname FQDN Useful tricks Run the following in PowerShell (on DC) to get the list all users for which keytabs were created with SPN that starts with "HTTP/" Get-ADUser -Filter 'UserPrincipalName -like "HTTP/*"' A faster way to find if there are duplicates: setspn -X This command would remove SPN for a specific user kaspersky: setspn -D HTTP/FQDN kaspersky On Windows workstations you can also get the current list of Kerberos tickets with klist Sometimes there might be an incorrect old ticket, in that case you can purge ticket: klist purge You can also request a ticket manually with klist get HTTP/kwts.example.com

Problem KSC Web Console can be used for monitoring purposes. It is particularly important to have no timeout disconnection errors in this scenario. To avoid them, the timeout before Web Console disconnects can be increased. Step-by-step guide All you have to do is the following: Edit node.js web server config file located at C:\Program Files\Kaspersky Lab\Kaspersky Security Center Web Console\server\config.json Change the following values and restart KSC WC services: "clientIdleTimeout": 2147483600, "clientLogoutTimeout": 2147483600, "serverLogoutTimeout": 2147483600, This value represents the maximum possible timeout period, which is about 24 days.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. This article is about Kaspersky Endpoint Security for Windows (KES for Windows) Problem 3d party video monitoring solution from HIKVision and KES 11.3 or more recent version, up to 12.0 When you open the URL of video web server, for example, http://172.17.64.5/ the error Playback interrupted occurs. The problem occurs because video software does not comply with HTTP RFC. Use the following key words to identify the problem in KES SRV trace: rtsp://172.17.64.5/Streaming/ .......................................................................... GET /SDK/playback HTTP/1.1 ......................................................................... Incorrect HTTP header (replace the example IP with one of web server's) Solution Add the executable of the web browser to Trusted applications: Tick the option "Do not scan network traffic"; Specify the IP address of the web server in question (in our example, 172.17.64.5) . When adding Internet Explorer to Trusted applications, please make sure to add the x86 version, which is run by default: %ProgramFiles(x86)%\Internet Explorer\iexplore.exe Unfortunately, it is not possible to add an IP subnet or IP range to the list of excluded IP addresses in trusted applications settings. In recent versions of KES, the following event is logged to local reports: Event: Connection blocked Application name: chrome.exe Application path: C:\Program Files\Google\Chrome\Application Application PID: **** User name: **** User type: Active user Component: Protection Event date: **** IP address: 1.1.1.1 Protocol: HTTP or HTTPS Resource name: office365atwork.com Result: The HTTP connection is terminated. Resource name: office365atwork.com Reason: The format of transferred data does not allow to scan it for threats. If you trust this resource, add it to scan exclusions.

You may need to add a batch of prevention rules to KATA. To speed up the process, we have created a script sample. Adding more than 1000 prevention rules will require additional PF to improve Web UI performance. Please contact technical support to get this PF. Adding more than 5000 prevention rules is highly NOT recommended as it may result in drastic performance degradation on both CN and Endpoint Agent. Step-by-step guide Script sample. To run it, you need any machine with 2 pre-requisites: sh or bash should be installed on the machine machine should have access to KATA Web UI To use the script, please place a file with hashes (each hash should be on new line in this file) near the script, and please fill in the variables required for script operation: #Fill in your KATA IP or FQDN address KATA_IP="" #Default port is 8443 KATA_PORT="8443" #You need Senior Security Officer account to add preventions USER="SSO" PASS="" To run the script, pass the file with hashes as argument to the script: sh add_prev.sh /path/to/file/with/hashes.txt Once the script is completed, it may take 5-10 minutes for the preventions to appear in Web UI. Export user's prevention rules from KATA 4.0/4.1/5.0 1) Under root execute: docker exec -it `docker ps | grep kedr_database_server | awk '{print $1}'` psql -U kluser antiapt -c "select * from agent_prevention_settings;" > /tmp/prevention_rules 2) Then import /tmp/prevention_rules to Excel as Data > From Text/CSV