All Activity

Problem Description, Symptoms & Impact 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: Select a host for troubleshooting and move it to a test group Install latest pf on it and reboot check the situation Check if the issue is caused by Device Control component and if the issue persists if this component is disabled Check if the issue persists under main policy and under default policy 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. Please see this public article for more details: https://support.kaspersky.com/KESWin/12.1/en-US/38595.htm It states "it is not recommended to add more than 1000 trusted devices, as this can cause system instability." To reduce the list of trusted devices, you can use wildcard * for the same type of printer.

In NAgent 15, klmover was updated and now requires NAgent uninstallation password, if it is set in NAgent's policy. Right now the password can't be passed to klmover as an argument, but it can be supplied via echo: echo <password>|klmover -address <administration server ip> Because cmd doesn't parse quotes and spaces in echo properly, if klmover is started from cmd and the password contains characters requiring quotes, klmover should be run from powershell. Powerhell has a Start-Process command that allows to run a process as a different user, in this case it can be used in a batch script like this: cd "C:\Program Files (x86)\Kaspersky Lab\NetworkAgent\" powershell -Command "Start-Process powershell '-Command echo <password>|.\klmover.exe -address <address>' -Verb RunAs" But if it is run as a scheduled task in a group policy, it would be better to set the task to run as a user with administrator privileges and set it to run with highest privileges. Previous NAgent klmover versions are not compatible with NAgent 15.

Problem Description, Symptoms & Impact Network security assessment tools detect multiple vulnerabilities in the SVMs. Workaround & Solution Below is a list of detected vulnerabilities and solutions or reasons why it can't be fixed. Open ports SVMs have ports 22 and 80 open for communication with the Deployment Wizard and providing updates to Light Agents respectively. They are hardcoded, and therefore can't be changed or closed without at least partially breaking functionality of the product. Browsable Web Directories SVMs use them to share updates with Light Agents, and Light Agents need to be able to check for updates. This is not a problem as there are only read-only Light Agent updates available there. Weak SSH encryption By default SVMs use weak ssh key exchange algorithms. To fix that without losing ability to configure the SVM via Deployment Wizard, add the following in /etc/ssh/sshd_config on SVMs: KexAlgorithms diffie-hellman-group-exchange-sha256

Scenario After the deployment of KSC in the environment, the Backup task fails with the following error using the KSC Backup task or klbackup utility (screenshot is below). All the permissions were correctly assigned on the shared folder, and ports were opened, but still the backup was failing. There were no blocking events in the Firewall traffic logs. Error -1963 ('Database connection is broken " 'Connection failure{08S01};' LastStataement='select type from sys.system_object where name = 'dsm_os_host_info';'" Root cause The issue was identified to be the IPS module of the Firewall (Fortinet/Paloalto) in the environment. When the backup task was initiated, the IPS module was blocking the SQL backup query with "SMB Injection/Attack" signatures. Solution Disable the IPS policy on the Firewall for KSC and MS SQL servers and the backup task will be completed successfully.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. This article is about Kaspersky Endpoint Security for Windows (KES for Windows) The complete encryption procedure is as follows: 1. During authentication, a private key is generated based on the username and password 2. The private key is used to decrypt the user’s storage and extract the primary key 3. The primary key is checked against the identifier specified in the file header. If it matches, the file encryption key is extracted from the header. 4. The file contents are decrypted using the key obtained in the previous step. 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.

Problem Description, Symptoms & Impact The installation of the Network Agent isn't possible on a device because of the error System error 0x1F (A device attached to the system is not functioning.) Diagnostics In the MSI Log and Application Eventlog can be found the following line: (1192/0x0 ("System container 'LOC-PUB-6EEB50F8D2EB46029DB4CCB77E0DA651' is corrupt") Workaround & Solution The issue comes from a corrupt cryptostorage in the OS. It's not a KL related issue, although there is a possible solution to fix it. On the problem host launch cmd.exe with administrative privileges Run klcryptstgclean.exe: klcryptstgclean -tl 4 -tf $klcryptstgclean_trace.txt -l klcryptstgclean.log Try to install NAgent. If it doesn't help, perform actions from the Cryptostorage-1.docx file. If installation fails again, send to Kaspersky Support the following files: "$klcryptstgclean_trace.txt", "klcryptstgclean.log", new GSI with klnagent installation logs. It is not KSC and klnagent related issue. It is OS related issue. If workaround doesn't help, try sfc /scannow command, OS restore, OS reinstallation or contact MS support.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Product: Any KSC version Problem Description, Symptoms & Impact Network Agent local installation errors: "Setup Wizard cannot process the command line", "Setup wizard cannot process the internal error." Diagnostics Error can be found on the screenshots or in the installation log. Workaround & Solution Some leftover registry records should be deleted, but there are too many different cases to describe them all. Collect detailed information about the error, GSI (https://support.kaspersky.com/common/diagnostics/3632) with Windows Event Log and following registry hives export, and create a case in https://companyaccount.kaspersky.com for further investigation by Kaspersky Experts. Registry hives to export: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\ HKEY_CLASSES_ROOT\Installer\Products This article describes how to export registry keys: https://support.kaspersky.com/common/diagnostics/8576#block2 RCA Leftovers of previously installed Network Agent.

Description and cautions This article describes how to install a patch on multiple SVMs at once via Kaspersky Security Center. Details Create an installation package from a .kud file included with the patch Advanced → Remote installation → Installation packages → Create installation package Choose Create an installation package for a Kaspersky application Choose a name for the package Select the .kud file in the file picker Create a remote installation task for that package Select the installation package → Install application If there is a separate group for SVMs, choose Install on a group of managed devices, otherwise choose Select devices for installation Select the administration group/devices to install the patch on Use default installation settings Choose Do not place license key in installation package Choose No account required Start patch installation

General information Kaspersky Web Traffic Security does not have a regular function of integration with external services via the ICAP protocol, however, it can be added by manually changing the configuration files of the built-in proxy server from the technical support mode. Important: ICAP integration works in synchronous mode - data transfer is suspended until the ICAP server processes the request. This may introduce additional delays in the processing of user traffic, thus reducing the performance of the proxy server. The external ICAP service must be able to process a sufficient number of concurrent requests and be designed for the target load according to the manufacturer's recommendations. Integration options Below are several configuration options depending on which data streams you want to pass through an external ICAP service. To reduce the load, additional filtering of requests using ACL rules is possible. The configuration fragment for the selected integration option must be added to the built-in proxy server configuration file template according to the instructions at the end of the article. In the examples, the chain of ICAP services is built in such a way that first the request is sent to an external ICAP, and secondly it is checked against KWTS. If necessary, the order can be changed by changing the adaptation_service_chain directive accordingly. The address of the ICAP service and the method of interaction with it are determined by the icap_service directive: icap_service is_ext_req reqmod_precache bypass=0 icap://IPADDRESS:PORT/PATH bypass - determines how the proxy server will behave when the service is unavailable: bypass=0 - the service is required and if it is unavailable, the user will see an error instead of the requested page bypass=1 - if the service is unavailable, it will be skipped icap://IPADDRESS:PORT/PATH - ICAP service address: IPADDRESS - service IP address (domain name cannot be specified) PORT - TCP port number PATH - path to the service (check the value in the documentation for the service) Option 1. Sending only HTTP requests to external ICAP (REQMOD stream) The option of sending only HTTP requests to an external ICAP service can be used when integrating with external DLP systems (for example, Infowatch Traffic Monitor). Transferring all HTTP requests to an external ICAP service icap_service is_ext_req reqmod_precache bypass=0 icap://IPADDRESS:PORT/REQMODPATH adaptation_service_chain is_req_chain is_ext_req is_kav_req adaptation_access is_req_chain allow all Transfering HTTP requests to an external ICAP service with POST and PUT methods only icap_service is_ext_req reqmod_precache bypass=0 icap://IPADDRESS:PORT/REQMODPATH adaptation_service_chain is_req_chain is_ext_req is_kav_req acl acl_inspect_methods method POST PUT adaptation_access is_req_chain deny !acl_inspect_methods adaptation_access is_req_chain allow all Similar to previous point + additional filter - do not send requests from certain accounts (username starts with svc_) icap_service is_ext_req reqmod_precache bypass=0 icap://IPADDRESS:PORT/REQMODPATH adaptation_service_chain is_req_chain is_ext_req is_kav_req acl acl_inspect_methods method POST PUT adaptation_access is_req_chain deny !acl_inspect_methods acl acl_bypass_users proxy_auth_regex -i svc_.* adaptation_access is_req_chain deny acl_bypass_users adaptation_access is_req_chain allow all Similar to option 1 point 2 + additional filter - do not send requests when accessing certain URLs from the /etc/squid/bypass_urls.txt file icap_service is_ext_req reqmod_precache bypass=0 icap://IPADDRESS:PORT/REQMODPATH adaptation_service_chain is_req_chain is_ext_req is_kav_req acl acl_inspect_methods method POST PUT adaptation_access is_req_chain deny !acl_inspect_methods acl acl_bypass_urls url_regex "/etc/squid/bypass_urls.txt" adaptation_access is_req_chain deny acl_bypass_urls adaptation_access is_req_chain allow all Option 2: Send only HTTP responses to external ICAP (RESPMOD stream) The option of sending only HTTP requests to an external ICAP service can be used when integrating with external incoming traffic analysis systems, such as Kaspersky Anti Targeted Attack Platform. Sending all HTTP responses to an external ICAP service icap_service is_ext_resp respmod_precache bypass=0 icap://IPADDRESS:PORT/RESPMODPATH adaptation_service_chain is_resp_chain is_ext_resp is_kav_resp adaptation_access is_resp_chain allow all Similar to previous point + additional filter - do not send requests from certain accounts (username starts with svc_) icap_service is_ext_resp respmod_precache bypass=0 icap://IPADDRESS:PORT/RESPMODPATH adaptation_service_chain is_resp_chain is_ext_resp is_kav_resp acl acl_bypass_users proxy_auth_regex -i svc_.* adaptation_access is_resp_chain deny acl_bypass_users adaptation_access is_resp_chain allow all Similar to option 2 point 1 + additional filter - do not send requests when accessing certain URLs from the /etc/squid/bypass_urls.txt file icap_service is_ext_resp respmod_precache bypass=0 icap://IPADDRESS:PORT/RESPMODPATH adaptation_service_chain is_resp_chain is_ext_resp is_kav_resp acl acl_bypass_urls url_regex "/etc/squid/bypass_urls.txt" adaptation_access is_resp_chain deny acl_bypass_urls adaptation_access is_resp_chain allow all Option 3. Sending both HTTP requests and HTTP responses to external ICAP (REQMOD and RESPMOD streams) The option of sending HTTP requests/responses to an external ICAP can be used when integrating with external web traffic analysis systems that require both data streams, or when combining two external services according to options 1 and 2. Transferring all HTTP requests/responses to an external ICAP service icap_service is_ext_req reqmod_precache bypass=0 icap://IPADDRESS:PORT/REQMODPATH icap_service is_ext_resp respmod_precache bypass=0 icap://IPADDRESS:PORT/RESPMODPATH adaptation_service_chain is_req_chain is_ext_req is_kav_req adaptation_service_chain is_resp_chain is_ext_resp is_kav_resp adaptation_access is_req_chain allow all adaptation_access is_resp_chain allow all Similar to previous point + additional filter - do not send requests from certain accounts (username starts with svc_) icap_service is_ext_req reqmod_precache bypass=0 icap://IPADDRESS:PORT/REQMODPATH icap_service is_ext_resp respmod_precache bypass=0 icap://IPADDRESS:PORT/RESPMODPATH adaptation_service_chain is_req_chain is_ext_req is_kav_req adaptation_service_chain is_resp_chain is_ext_resp is_kav_resp acl acl_bypass_users proxy_auth_regex -i svc_.* adaptation_access is_req_chain deny acl_bypass_users adaptation_access is_resp_chain deny acl_bypass_users adaptation_access is_req_chain allow all adaptation_access is_resp_chain allow all Similar to option 3 point 1 + additional filter - do not send requests when accessing certain URLs from the /etc/squid/bypass_urls.txt file icap_service is_ext_req reqmod_precache bypass=0 icap://IPADDRESS:PORT/REQMODPATH icap_service is_ext_resp respmod_precache bypass=0 icap://IPADDRESS:PORT/RESPMODPATH adaptation_service_chain is_req_chain is_ext_req is_kav_req adaptation_service_chain is_resp_chain is_ext_resp is_kav_resp acl acl_bypass_urls url_regex "/etc/squid/bypass_urls.txt" adaptation_access is_req_chain deny acl_bypass_urls adaptation_access is_resp_chain deny acl_bypass_urls adaptation_access is_req_chain allow all adaptation_access is_resp_chain allow all Making changes to the built-in proxy server configuration The option of sending only HTTP requests to an external ICAP service can be used when integrating with external incoming traffic analysis systems, such as Kaspersky Anti Targeted Attack Platform. Connect to the cluster node via SSH to access the technical support mode. If the selected configuration option requires an external file with access lists (for example, bypass_urls.txt for options 1.4, 2.3, 3.3), place it in the /etc/squid directory. This must be done before any changes are made to the built-in proxy configuration template. Change to the directory where the built-in proxy configuration file templates are located: cd /opt/kaspersky/kwts-appliance-addon/share/templates Make a backup copy of the squid.conf.template file if you haven't already: cp -p squid.conf.template squid.conf.template.backup Open the squid.conf.template file for editing using a text editor: vim squid.conf.template Go to the end of the file, paste the configuration fragment for integration with an external ICAP service in the place indicated below (existing lines are marked in black, they do not need to be modified in any way, green is the lines to be added) adaptation_send_client_ip on adaptation_send_username on icap_enable on icap_service is_kav_req reqmod_precache icap://127.0.0.1:1344/av/reqmod icap_service is_kav_resp respmod_precache icap://127.0.0.1:1344/av/respmod ### --> put your external ICAP configuration here <-- ### adaptation_access is_kav_req allow all adaptation_access is_kav_resp allow all icap_service_failure_limit -1 An example of inserting a configuration fragment (for option 1.2): adaptation_send_client_ip on adaptation_send_username on icap_enable on icap_service is_kav_req reqmod_precache icap://127.0.0.1:1344/av/reqmod icap_service is_kav_resp respmod_precache icap://127.0.0.1:1344/av/respmod ### External ICAP configuration begin ### icap_service is_ext_req reqmod_precache bypass=0 icap://x.x.x.x/reqmod adaptation_service_chain is_req_chain is_ext_req is_kav_req acl acl_inspect_methods method POST PUT adaptation_access is_req_chain deny !acl_inspect_methods adaptation_access is_req_chain allow all ### External ICAP configuration end ### adaptation_access is_kav_req allow all adaptation_access is_kav_resp allow all icap_service_failure_limit -1 Save changes to squid.conf.template In order for the changes in the template to be applied, change some setting of the built-in proxy server through the web interface. For example, you can turn off logging (Settings - Built-in proxy server - Log), save the changes, and then return the previous value back. Check that the changes have made their way into the main configuration file of the built-in proxy server: less /etc/squid/squid.conf Check the status of the squid service, it should be running: systemctl status squid This completes the procedure. The described actions must be repeated on each node of the Kaspersky Web Traffic Security cluster.

Issue In KATA 4.1, when Central Node was used as Sensor, it was possible to access Traffic Capture and disable protocol, e.g SMTP. CN-Sensor - https://support.kaspersky.com/help/KATA/4.1/en-US/199500.htm Standalone Sensor - https://support.kaspersky.com/help/KATA/4.1/en-US/199500_1.htm In KATA 5.0, this possibility is missing from docs and from CN and only available on Standalone Sensor: Solution Workaround is to use CLI and access predecessor configuration directly: Settings section #console-settings-updater get /kata/configuration/product/preprocessor_span | python3 -m json.tool | grep \"traffic\" -A 23 "traffic": { "buffer_size_limit": 4096, "checksum_validation": false, "enable": true, "enable_dns": true, "enable_ftp": true, "enable_http": true, "enable_smtp": false, "enable_ssl": true, "ftp_data_expired_timeout": "PT60S", "ftp_data_supposed_max_size_bytes": 10485760, "iface_groups": [ { "ifaces": [ "ens192" ], "core_id": null } ], "pcap_filter": "", "pcap_snaplen": 1600, "pcap_timeout": 10, "tcp_threads_number": 16 }, Example disable SMTP, enable the rest #console-settings-updater set --merge /kata/configuration/product/preprocessor_span '{"traffic": {"enable_dns": true, "enable_ftp": true, "enable_http": true, "enable_smtp": false}}' Example change #console-settings-updater get /kata/configuration/product/preprocessor_span | python3 -m json.tool > /tmp/preprocessor_span.json #vim /tmp/preprocessor_span.json #console-settings-updater set /kata/configuration/product/preprocessor_span @/tmp/preprocessor_span.json

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Product: KSC 11 and more recent versions Consider the following problematic scenario: You use a caching proxy server to download updates for the KSC Server, for example, Squid. KSC is configured to download updates via https (default config). $up2date-1103-eka.log analysis KL uses the HTTP public key pinning mechanism to verify update server authenticity; a certificate used for authentication is self-signed by KL. A certificate revocation list is also implemented. More information about the certification revocation process is available here: https://learn.microsoft.com/en-us/archive/blogs/ieinternals/understanding-certificate-revocation-checks https://technet.microsoft.com/en-us/library/ee619754(WS.10).aspx A recent update of CRL was performed at the end of July 2023. CRL is available on this link: http://crl.kaspersky.com/cdp/KasperskyLabPublicServicesRootCertificationAuthority.crl Old CLR was valid till 23.7.2023 and is expired now. When KSC requests the CRL file, the proxy server sends back to KSC the cached version of it and the CRL verification fails. The details can be found in the $up2date-1103-eka.log to identify the issue precisely. 04:01:48.817 0x326c INF httpcli cert_revoke 0x70e2908 Got error: 0xa0010019 (http_client::eCrlHasExpired) 04:01:48.817 0x326c INF httpcli Req 0x70e2908 <- HttpsErrorOccurs: Revocation Error [0xa0010019 (http_client::eCrlHasExpired) 04:01:48.892 0x1d0c INF updater core: ========= Downloading primary index result TLS error ========= Troubleshooting steps To solve the problem, an administrator of the proxy server should turn off caching of the http://crl.kaspersky.com/cdp/KasperskyLabPublicServicesRootCertificationAuthority.crl file. It is recommended to turn off caching for all files downloaded from public update servers using this mask: *.kaspersky.com *.kaspersky-labs.com An alternative workaround: Set a server flag for KSC using the following commands: klscflag.exe -fset -pv klserver -s Updater -n DisableKLHttps -t d -v 1 Also, set a server flag for Update Agents (Distribution Points) that get updates from the Internet, if any: klscflag.exe -fset -pv klnagent -s Updater -n DisableKLHttps -t d -v 1 Explicitly set an update task to use HTTP sources for URLs, for example, http://p00.upd.kaspersky.com. The full list of HTTP-enabled sources can be found in the <insecure_sites_list> parameter at http://dnl-05.geo.kaspersky.com/updates/upd/updcfg2.xml

Видимо, речь об этой теме. Судя по ответам, вопрос у разработчика AG больше по самому уведомлению, которое не скрывается и периодически о себе напоминает, чем по существу несовместимости.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Problem Description, Symptoms & Impact It is not possible to use a proxy server for KATA 5.0 and/or KATA 5.1 CN on TCP ports 8080, 8090 or 8091. If you will configure in KATA 5.0/5.1 proxy server connection settings using one of those ports, then such configuration will result in KATA update task failure and KSN connection errors right after those settings will be applied. This happens due to the fact, that KATA uses ports 8080, 8090 and 8091 for it's internal services and there are preconfigured default iptable rules that prevent incoming and outgoing connection on those ports for external hosts outside of the KATA cluster, which in turn results in connection errors if those ports are also used by the product for outgoing connections to a proxy server. Diagnostics It can be easily confirmed if a KATA server will be facing those updater and KSN issues, by either checking the current proxy server configuration in the product's web interface: if either of the listed ports 8080, 8090 or 8091 is used, then the KATA server is probably facing the issue. Or alternatively you can run the iptables -nvL DOCKER-USER command and check if the number of the rejected packages in the corresponding rules for ports 8080, 8090 and 8091 steadily increases upon running update task in KATA: Workaround & Solution To avoid this issue use one of the following 2 options: Do not use proxy server for KATA connections, configure direct internet connection for KATA CN nodes. Use a proxy server on a different port, for example port 3128 is quite standard option in such cases.

Description 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 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/ 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. Next solution is temporary and should not be used in production for extended periods of time. 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 If nothing helps, submit the case to the Kaspersky support with traces, GSI report including Windows event logs and a full memory dump. 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

Here's how to change web UI certificate for KATA SB. Create backup of original files with same rights as it was before (you can check them with ll /etc/nginx/ssl command) cp -p /etc/nginx/ssl/server.crt /etc/nginx/ssl/server.crt.orig cp -p /etc/nginx/ssl/server.key /etc/nginx/ssl/server.key.orig Replace original files cat my_cert.crt > /etc/nginx/ssl/server.crt cat my_cert.key > /etc/nginx/ssl/server.key Restart nginx service systemctl restart nginx.service Rights and owner of files should be the same ll /etc/nginx/ssl -rw-r----- 1 root klusers 1.5K Aug 11 2022 server.crt -rw------- 1 root root 1.7K Aug 11 2022 server.key

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Problem Description, Symptoms & Impact When trying to activate KES with valid License for KATA EDR (License contains Licensing object 184), Activation Task results in error "Internal data incompatible with this application". Cause The KATA Built-In KES component EDR (KATA) responsible for integration is not installed on target machine. Diagnostics In KSC -> Application properties, Endpoint Detection and Response (KATA) component version is listed as <N/A>, "Not installed" may be masked with "Not supported by license". In registry, [HKEY_LOCAL_MACHINE\Software\Wow6432Node\KasperskyLab\\protected\KES.21.13\Installer\features] Key "AntiAPTFeature"=dword:00000001 is missing In logs: in *.SRV.log (trace file) line for bundles::BundlesControllerImpl::GetNotInstalledFeatures lists (1) and 1 is missing from bundles::InstalledFeaturesProvider::InstalledFeaturesProvider line 09:58:42.239 0x2bf4 INF bundles bundles::BundlesControllerImpl::GetNotInstalledFeatures Not installed features (1): 1 09:54:03.788 0x2050 INF bundles::InstalledFeaturesProvider::InstalledFeaturesProvider{ 3 (AVScannerAndCoreFeature) 0 (AdminKitConnectorFeature) 24 (AdvancedThreatProtectionFeature) 27 (AmsiFeature) 7 (ApplicationControlFeature) 17 (BehaviorDetectionFeature) 4 (CriticalScanTask) 23 (EssentialThreatProtectionFeature) 11 (ExploitPreventionFeature) 8 (FileThreatProtectionFeature) 19 (FirewallFeature) 5 (FullScanTask) 14 (NetworkThreatProtectionFeature) 12 (RemediationEngineFeature) 25 (SecurityControlsFeature) 18 (UpdaterTask) 22 (WholeProductFeature) } in *.SRV.log (trace file) for good machine bundles::InstalledFeaturesProvider::InstalledFeaturesProvider will list 1 (AntiAPTFeature) 08:14:31.733 0x1e30 INF bundles::InstalledFeaturesProvider::InstalledFeaturesProvider{ 3 (AVScannerAndCoreFeature) 0 (AdminKitConnectorFeature) 24 (AdvancedThreatProtectionFeature) 1 (AntiAPTFeature) 7 (ApplicationControlFeature) 15 (BadUSBAttackPreventionFeature) 17 (BehaviorDetectionFeature) 4 (CriticalScanTask) 6 (DeviceControlFeature) 23 (EssentialThreatProtectionFeature) 11 (ExploitPreventionFeature) 8 (FileThreatProtectionFeature) 5 (FullScanTask) 16 (MailThreatProtectionFeature) 14 (NetworkThreatProtectionFeature) 12 (RemediationEngineFeature) 25 (SecurityControlsFeature) 18 (UpdaterTask) 21 (WebControlFeature) 20 (WebThreatProtectionFeature) 22 (WholeProductFeature) } Solution NB! EDR Optimum, EDR Expert and EDR (KATA) components are not compatible with each other. Only one can be installed. Create Change Components Task for affected machines Execute Task Verify the component is installed. How to check that KES 'KATA' component is enabled, up and running 1) Let's check that component is enabled first In GSI > Registry > HKLM_Software_Wow6432Node_KasperskyLab.reg.txt > [HKEY_LOCAL_MACHINE\Software\Wow6432Node\KasperskyLab\\protected\KES.21.13\Installer\features] > "AntiAPTFeature"=dword:00000001 (should be like this) 2) Search in *.SRV.log (trace file) for bundles::InstalledFeaturesProvider::InstalledFeaturesProvider 08:14:31.733 0x1e30 INF bundles::InstalledFeaturesProvider::InstalledFeaturesProvider{ 3 (AVScannerAndCoreFeature) 0 (AdminKitConnectorFeature) 24 (AdvancedThreatProtectionFeature) 1 (AntiAPTFeature) 7 (ApplicationControlFeature) 15 (BadUSBAttackPreventionFeature) 17 (BehaviorDetectionFeature) 4 (CriticalScanTask) 6 (DeviceControlFeature) 23 (EssentialThreatProtectionFeature) 11 (ExploitPreventionFeature) 8 (FileThreatProtectionFeature) 5 (FullScanTask) 16 (MailThreatProtectionFeature) 14 (NetworkThreatProtectionFeature) 12 (RemediationEngineFeature) 25 (SecurityControlsFeature) 18 (UpdaterTask) 21 (WebControlFeature) 20 (WebThreatProtectionFeature) 22 (WholeProductFeature) }

Don't apply to PCN, it will lead to the disconnection of all SCNs attached and will not restore automatically Problem Description A PCN connection request got stuck in the "Waiting" status and doesn't result in failure. The reboot doesn't help. It can happen if, for example, a SCN IP was specified instead of PCN. Solution Run the following commands as root: Cancel PCN connection request # console-settings-updater get /ipsec > /home/admin/ipsec.orig.json && chmod 777 /home/admin/ipsec.orig.json # console-settings-updater set /ipsec "{}" Clear the browser cache. Reload the page. Alternatively, force the reload (Ctrl+F5 in FF). The server status will revert to the Standalone solution. Select the Distributed solution, specify the correct IP of PCN and retry to connect. To restore config in case of error: Cancel PCN connection request # console-settings-updater set /ipsec @/home/admin/ipsec.orig.json

Application of exclusions for KES configured in the KES Cloud environment can differ on Windows Client and Windows Server. If exclusions are set up for all components by selecting checkboxes as shown in the screenshot, then the exclusions will only apply to the component selected by the checkbox. KES behavior may differ on the Windows Client and Windows Server operating systems. To apply exclusions to all components on both the Windows Client and Windows Server operating systems, disable all the checkboxes. To apply the same settings in KES, select the All Components parameter in the local interface of KES as shown in the screenshot. Apply the settings described above if you have an unexpected detection on the Windows Server operating systems when the detected file is already added to the exclusions.

As stressed in the product documentation, Sandbox, which is deployed as a Virtual Machine, should have an exact sizing, violation of which may lead to various issues. The only parameter that can be varied is a CPU clock rate. Common mistake The most notable mistake regarding scaling up VM sandboxes is an attempt to make one huge Sandbox VM with two to four times the required RAM/CPU as dedicated resources. Correct approach is to create a respective number of additional VMs and distribute these resources between them. For example, if you want to double the performance of a KATA Sandbox VM instead of adding 15 more CPU cores and 32 more gigabytes of RAM to an existing Sandbox, you need to deploy a new Sandbox VM with the following resources: CPU: 15 cores, 2.1 GHz or higher RAM: 32 GB HDD volume: 300 GB Two network adapters with 1 Gbit/s data transfer rate Virtual machine settings: Only VMware ESXi hypervisor is fully supported. Nested virtualization is enabled Supported VMware ESXi versions 6.5, 6.7U3 or 7.0 hypervisor. Entire CPU clock rate reserved. For a minimum CPU clock this means 12*2100=25200 MHz reserved. For a clock rate higher than 2.21Hz, use the following formula to calculate the entire CPU clock rate: 12 * <clock rate in MHz>. Entire RAM reserved (32 GB). Expose hardware assisted virtualization to the guest OS check box selected. Latency Sensitivity option set to High. No Secure Boot. The maximum number of simultaneously running virtual machines set to 12. Please note, these cannot be checked from a debug report or from inside of the VM, as these settings are configured in a hypervisor. Checking VMX file Obtain a .vmx file of the respective sandbox VM. Demo video showing how to locate a .vmx file. Note, that in this video the goal is to modify the .vmx, and we only need to access it for reading, therefore, there is no need to unregister a VM from inventory as done in video. All the following lines in .vmx file must match exactly with the following two exceptions: For sched.cpu.min, the value can be higher than 25200, see formula above. Line uefi.secureBoot.enabled might be absent, which is OK. Correct .vmx settings numvcpus = "15" sched.cpu.units = "mhz" sched.cpu.min = "26400" memSize = "32768" sched.mem.min = "32768" vhv.enable = "TRUE" sched.cpu.latencySensitivity = "high" uefi.secureBoot.enabled = "FALSE" ethernet0.present = "TRUE" ethernet1.present = "TRUE" Checking number of slots In the Sandbox web interface window, select the Administration section. In the Guest virtual machines group of settings, in the Maximum simultaneous VMs field, number of simultaneously running virtual machines must equal 12.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Product: KSC 11+ Applies also to the update utility version 4.1 and more recent. Consider the following problematic scenarios: You have installed KSWS on the KSC server and enabled Traffic Security component and Traffic Security uses MITM mechanism to analyze traffic. You use a 3rd party software or hardware appliance for traffic filtering and this appliance disrupts connections to HTTPS-enabled public update servers. It can be a hardware appliance like BlueCoat or F5, FortiGate SSL Deep Inspection, or a software proxy like Squid that uses ICAP to redirect traffic to another security application for scanning. KL uses HTTP public key pinning mechanism to verify update server authenticity; certificate used for authentication is self-signed by KL. Using any MITM-based solutions for SSL traffic inspection will lead to failures in establishing connection between KSC and a HTTPS-enabled KL update source. It happens because any MITM traffic inspection will forward a wrong certificate to KSC after inspection and KSC11 will break the connection. The following string can be found in up2date trace: self signed certificate in certificate chain The following trace files are required for accurate diagnostic: $up2date-1103.*, $up2date-1103-eka.* Please bear in mind that Kaspersky Support needs KSC traces mentioned above to be collected BEFORE you apply any of the workarounds listed in this post. Troubleshooting steps If you have KSWS blocking traffic, add Up2Date.exe process or the update source certificate to trusted in Traffic Security settings. If you use a 3rd party appliance to filter traffic, you can explicitly allow traffic signed by KL certificate. Otherwise you can use HTTP to download updates. There are two ways to make KSC use HTTP: Set a server flag on KSC using following commands: klscflag.exe -fset -pv klserver -s Updater -n DisableKLHttps -t d -v 1 and on Update Agents (Distribution Points) getting updates from the internet, if any: klscflag.exe -fset -pv klnagent -s Updater -n DisableKLHttps -t d -v 1 Explicitly set update task to use HTTP sources URLs, for example http://p00.upd.kaspersky.com. Full list of HTTP-enable sources can be found in <insecure_sites_list> parameter in http://dnl-05.geo.kaspersky.com/updates/upd/updcfg2.xml Download updates using update utility 4.0. More recent version of update utility uses https.

Description and cautions This is short article about how to burn KATA ISO on USB drive. For KATA 4.0/4.1 you need 8Gb USD drive, for 5.0/5.1 - 16Gb at least. 3d party solutions are involved, therefore success is not guaranteed. Ventoy is more preferable working method. Details Download latest Rufus release or Ventoy, how to use Ventoy described here or Balena http:// https://etcher.balena.io/ [Rufus part] Open it and select respective KATA ISO. KATA 4.0/4.1 Rufus config should be like on screenshot below (Partition scheme GPT, Target system UEFI) For KATA 5.0/5.1 (Partition scheme MBR, Target system BIOS or UEFI) After clicking Start choose Write in DD image mode.

Description and cautions Here's how to configure export only detects from KWTS to external syslog server, which accepts TCP stream on facility local1. Details Create file /etc/rsyslog.d/kwts-detects.conf with contents as per below (replace SERVER:PORT by your external syslog server, @SERVER:PORT if UDP is in use instead of TCP) $ActionQueueFileName KWTSDetects $ActionQueueType LinkedList $ActionQueueMaxDiskSpace 1g $ActionResumeRetryCount -1 $ActionQueueSaveOnShutdown on if ($syslogfacility-text == 'local1' and ( $msg contains 'av-status="Detected' or $msg contains 'encrypted="Detected' or $msg contains 'macros="Detected' or $msg contains 'ap-status="Detected' or $msg contains 'mlf-status="Detected' or $msg contains 'kata-alert="Detected' )) then { @@SERVER:PORT } Restart rsyslog service like this: systemctl restart rsyslog

Problem No option to change Local Administrator/Cluster Administrator in pseudo-graphic menu available by default . Solution a) Upgrade to 5.1 b) Follow steps: Download an archive with WHL packets. Upload it to KATA CN to /tmp/change_password.zip Extract (we have no unzip shipped by default): echo -e "import zipfile\nwith zipfile.ZipFile('/tmp/change_password.zip', 'r') as z:\n z.extractall('/tmp/')" | python3 Become root: sudo su Confirm this is a right node: docker ps | grep kedr_database_server Install installer patch: installer-1.0-py3-none-any.whl pip3 install --ignore-installed --no-deps /tmp/installer-1.0-py3-none-any.whl Install docker_utils patch: docker_utils-1.0-py3-none-any.whl pip3 install --ignore-installed --no-deps /tmp/docker_utils-1.0-py3-none-any.whl Restrict changing password to root: which kata-web-admin-change-password | xargs chmod 754 Change password by running: kata-web-admin-change-password Enter new password in the prompt, no confirmations or validation will be given Selecting the correct node Script must be executed on a node with kedr_database_server container, by default it is the processing one installed first, node2 in cluster. In case it is executed on a wrong node, a hint will be given which is a right one.

Description and cautions You may experience low time to live value set in ICMP network packets sent by klnagents. The following can be seen in wire shark traffic dump: Explanation: There are two modes of distribution point search: 0 - search of the nearest DP using a tool similar to traceroute. It generates a number of ICMP packets to find out the neatest route to DP - this is the default mode. 1 - selection of random DP without sending such amount of ICMP packets. This mode is configured on administration server computer via klcsflag utility and is enabled for all managed hosts. The following command should be started as administrator on KSC Server computer to switch to mode 1: klscflag.exe -fset -pv klserver -n SrvChooseUaMode -v 1 -t d Restart of kladminserver service is required to apply changes. The distribution point will be randomly selected among all DPs available.

Description and cautions KSN connection error on KATA web may appear. Details It could be fixed unless you don't have permanent KSN errors, you have to check it in ksn_proxy.log DEBUG level. Key word is ErrCount. If you don't see Errcount: 0 in log, then you don't have access to our KSN servers which are: *.ksn.kaspersky-labs.com ksn-*.kaspersky-labs.com ds.kaspersky.com 2. In order to fix this web error do as below For KATA 4.0/4.1 Under root at CN execute: apt-settings-manager set --merge /configuration/preprocessor '{"ksn": {"non_dl_formats": ["GeneralHtml", "GeneralTxt", "ExecutableJs", "ImageGif", "ImageJpeg", "ImagePng", "ArchiveCab"], "request_threads": 4, "timeout": "PT1.5S"}}' * PT1.5S means 1,5 seconds, don't increase it more Then let's increase "errors_increase_threshold": 100 (actually you have to check ksn_proxy debug log in order to understand how much KSN connection errors you have and adjust this parameter accordingly) apt-settings-manager set --merge /configuration/monitoring_prometheus '{"ksn_proxy": {"errors_increase_threshold": 100, "errors_window_period": "10m", "scraping_alert_for_interval": "1m", "scraping_evaluation_interval": "30s"}}' If this helps, then make this change persistent: vim /etc/opt/kaspersky/apt-swarm/swarm_config.json "ksn": { "non_dl_formats": [ Numbered list "GeneralHtml", "GeneralTxt", "ExecutableJs", "ImageGif", "ImageJpeg", "ImagePng", "ArchiveCab" ], "request_threads": 4, "timeout": "PT0.5S" <<<<< set 1.5S Find "ksn_proxy": { "errors_increase_threshold": 2, <<<<< set 100 "errors_window_period": "10m", "scraping_alert_for_interval": "1m", "scraping_evaluation_interval": "30s" For KATA 5.+/6.+ Use one line: console-settings-updater set --merge /kata/configuration/product/monitoring_prometheus '{"alert_settings": {"ksn_proxy": {"errors_increase_threshold": 100}}}' if value 100 doesn't help you may increase it to 150-200. Or use long way: Under root at CN execute console-settings-updater get /kata/configuration/product/monitoring_prometheus | python3 -m json.tool > /tmp/monitoring_prometheus Make changes in /tmp/monitoring_prometheus (via vim or nano) by finding following block "ksn_proxy": { "errors_increase_threshold": 100, <<<<<< put here value 100 instead of default 2 Save file (ESC:wq!) Put changes back to container console-settings-updater set /kata/configuration/product/monitoring_prometheus @/tmp/monitoring_prometheus If value 100 doesn't help you may increase it to 150-200.