All Activity

This info applies to KSC12-14.2. Web Console port can be changed from default port 8080 to 443 or any other port not occupied by the operating system or a third-party application. 1. Open file "C:\Program Files\Kaspersky Lab\Kaspersky Security Center Web Console\server\config.json" with any text editor and type the port you would like to use instead of 8080: 2. Restart all Kaspersky Security Center Web Console services via services.msc to apply changes.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. 0 - Update completed successfully 1 - All files are up-to-date (No available updates) Result codes depending on OS type: Windows Linux(FreeBSD) -1 255 Command line parsing exception -2 254 Update Utility error (exception or another malfunction including incorrect command line arguments) -5 251 Update process failure (Not all components are updated, File does not exist on update source, Invalid file signature, Index file damaged, File is not valid XML structure or does not exist) or network error -6 250 Bases are not consistent after update -3 253 Fail (error code for other update process failures)

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Same info can be found here: https://support.kaspersky.com/16010 Starting from version 11.5, some file versions, registry and file system paths may differ from the release version and refer to the product line version. Release full build version Product line version GUID 12.9.0.384 21.21.7.384 {392B5F59-AC1A-4487-98C8-6CF1031263C0} 12.8.0.505 21.20.8.505 {A7992CE9-7B14-4974-8120-A083A16DFA79} 12.7.0.533 21.19.7.533 {CA36FF7F-D8FA-4D89-B077-005198E7E840} 12.6.0.438 21.18.5.438 {C9EF800D-54AA-4F60-AB96-5A3966550F53} 12.5.0.539 21.17.7.539 {8E779D67-C811-4A86-9D42-36BDB19E6018} 12.4.0.467 21.16.6.467 {27534751-4A40-48BD-B393-BC3BF28C876E} 12.3.0.493 21.15.8.493 {8409A30E-CDF7-4800-B389-FB0A8FB6CE2C} 12.2.0.462 21.14.5.462 {B524FBEF-035B-455E-AA3A-2ABA729C62F8} 12.1.0.506 21.13.5.506 {D8E156BC-0E64-47F7-8E4F-0DCD80F2A6D3} 12.0.0.465 21.9.6.465 {E70CCFE8-163C-4E2B-BC36-61B747DAD590} 11.11.0.452 21.8.5.452 {BF39B547-8E24-4E11-8179-183B2F7C83EB} 11.10.0.399 21.7.7.399 {305A9EC9-294E-4555-A7C5-E1C767E01C11} 11.9.0.351 21.6.7.351 {6BB76C8F-365E-4345-83ED-6D7AD612AF76} 11.8.0.384 21.5.11.384 {1F39E63E-3F9C-4E21-928B-136C6362E88B} 11.7.0.669 21.4.20.669 {F4ECE08F-50E9-44E2-A2F3-2F3C8DDF8E16} 11.6.0.394 21.3.10.394 {7EC66A9F-0A49-4DC0-A9E8-460333EA8013} 11.5.0.590 21.2.16.590 {7B437856-99E3-4F01-B31C-B5A26465C633}

Product version/Environment KSWS 10.1/11.X Windows Server Requirements for the server on which Kaspersky Security for Windows Server is deployed Description of Error Run installation of the application or the console with the setup file. Error "Please go to the Control Panel to install and configure system components" pops up and installation doesn't run. Solution Unpack the installation file and run the .msi file inside instead of the setup: *\ksws_11.0.1.897_en\client\ks4wstools*.msi for the console *\ksws_11.0.1.897_en\server\ks4ws*.msi for the application

Try the following: 1. Check if the Administration Server is configured to use a proxy server on the Kaspersky Security Center server. 2. Try to clear the updates repository. Download the updates once again and check behavior. If you still have issues, Delete the Download updates repository task and create a fresh task.

Problem The "Install application remotely" task wizard presents an option to specify an SSH certificate as account credentials, if Linux package is selected for installation. The wizard does not accept certain certificates and fails to provide informative error messages why this happens. Examples: Failed to upload the certificate. Failed to import the private key of the certificate. Root cause KSC 13.2 only accepts PEM certificates, they start with header line of the following format: -----BEGIN RSA PRIVATE KEY----- However, most modern Linux systems use openssh, which offers an ssh-keygen tool to generate certificates. Starting from ~2018 it generates certificates in its own openssh structure if used with default settings. The header looks as follows: -----BEGIN OPENSSH PRIVATE KEY----- Solution As a workaround, generate a cetificate in the PEM/RSA format. Using ssh-keygen (newer versions): use -m flag to switch to the old PEM format. # ssh-keygen -t rsa -m PEM Using PuTTYgen: Generate the SSH-2 certificate, then navigate to Conversions → Export OpenSSH key (do not choose "force new file format").

Может лучше этим заняться разработчикам AdGuard, раз они в курсе несовместимости с антивирусами?

Maximum validity of the custom certificate (administration server/web console): A maximum of 5 years can be stored as the maximum validity for the certificate for the administration server The maximum validity for the certificate for the web console cannot exceed 397 days Two different certificates must be used: After the specified time has expired, a new certificate must be generated manually (at best 90 days in advance) and stored as a replacement certificate. Clients that do not identify themselves with the administration server within 90 days must be reconnected manually https://support.kaspersky.com/KSC/13.2/en-US/227839.htm The certificate must be replaced using klsetsrvcert: https://support.kaspersky.com/KSC/13.2/en-US/227838.htm In general, it is important that the custom certificate meets the following requirements: https://support.kaspersky.com/KSC/13.2/en-US/155201.htm https://support.kaspersky.com/KSC/13.2/en-US/191451.htm Custom certificate should also have a certificate signing permission, it is vital in case of using Distribution Points. Certificates issued by public CA do not have this permission, so they cannot be used: https://support.kaspersky.com/KSC/13.2/en-US/155201.htm How to create a pkcs12 file with an ordered certificate chain: The certificate chain is very important for connecting devices to find out if the ssl certificate is created by a trusted authority. After that is done do the following: 1. Create an empty file (C:\temp\cert-chain.txt) on your PC and past the following inside it: -----BEGIN CERTIFICATE----- (Your Primary SSL certificate from C:\temp\your_domain_name.crt) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Your Intermediate certificate from C:\temp\TheIntermediateCA.crt) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Your Root certificate part from C:\temp\TheTrustedRoot.crt) -----END CERTIFICATE----- 2. Now replace the content inside the brackets with your certificates (which you can export via XCA; PEM txt format). The order above is VERY important, so do not mix it. 3. Export the private key (unencrypted in text format) with XCA from your certificate and store it inside C:\temp\server.pemkey 4. Now merge everything together as pkcs12 (filename extension for PKCS #12 files is .p12 or .pfx). To do that open a CMD (run as admin) and perform: openssl pkcs12 -export -inkey C:\temp\server.pemkey -in C:\temp\cert-chain.txt -password pass:ABCD -out C:\temp\certificate(chain_and_key).pfx 5. Your PFX file is now ready to be used. KSC - Information about the self-signed certificate: The self-signed certificate when installing the KSC has a maximum validity of 1 year (limit of 397 days). The Administration Server certificate is created automatically during the installation of the Administration Server component and is saved in the %ALLUSERSPROFILE%\Application Data\KasperskyLab\adminkit\1093\cert folder. A new certificate will be generated by the Administration Server as a reserve certificate 90 days before the expiry date of the current certificate. The new certificate automatically replaces the current certificate one day before the expiration date. All Network Agents on client devices will be automatically reconfigured to authenticate Administration Server with the new certificate. Clients that do not identify themselves with the Administration Server within 90 days must be reconnected manually. Proxy for the web console The option can be implemented only when installing the web console on another device and accessing the Administration Server.

SNMP daemon on SVM should have the following default settings: protocol version: v2c rocommunity name: public listening address and port: 0.0.0.0:161 access type: read only transport: UDP logging: syslog The following statistics can be received from SVM: # Description Name Identifier 4.1 CPU Statistics UCD-SNMP-MIB::systemStats 4.2 Memory Statistics UCD-SNMP-MIB::memory 4.3 Load average statistics UCD-SNMP-MIB::laTable 4.4 Disk statisitcs HOST-RESOURCES-MIB::hrStorageTable 4.5 Network statistics IF-MIB::ifTable 4.7 Amount of desktop VMs connected KSVLA-MIB::ksvlaProtectedDesktopCount 1.3.6.1.4.1.23668.1491.1539.1.1 4.8 Amount of server VMs connected KSVLA-MIB::ksvlaProtectedServerCount 1.3.6.1.4.1.23668.1491.1539.1.0 4.9 ODS running status: - in progress (if all ODS Tasks are running) - waiting (if at least one ODS task is waiting for processing) - none (if no ODS tasks are running/waiting at all) KSVLA-MIB::ksvlaODSStatus 1.3.6.1.4.1.23668.1491.1539.0.0 4.10 ODS queue lenght: amount of VMs awaiting ODS processing KSVLA-MIB::ksvlaODSQueueLenght 1.3.6.1.4.1.23668.1491.1539.0.1 4.11 Amount of simualtaneously running ODS tasks KSVLA-MIB::ksvlaODSTaskCount 1.3.6.1.4.1.23668.1491.1539.0.2 4.12 Current percent of an allowed physical memory consumption - In case of watchdog is on use WDSERVER_MAX_MEM const from ScanServerLaunch.sh as maximum - In case of watchdog is off use 100% as maximum KSVLA-MIB::ksvlaMemoryConsumption 1.3.6.1.4.1.23668.1491.1539.3.0 4.13 Current percent of an allowed swap consumption - In case of watchdog is on use WDSERVER_MAX_SWAP const from ScanServerLaunch.sh as maximum - In case of watchdog is off use 100% as maximum KSVLA-MIB::ksvlaSwapConsumption 1.3.6.1.4.1.23668.1491.1539.3.1 4.14 Main processes state (running/stopped): -- scan server daemon KSVLA-MIB::ksvlaScanServerStatus 1.3.6.1.4.1.23668.1491.1539.2.0 -- klnagent daemon KSVLA-MIB::ksvlaKlnagentStatus 1.3.6.1.4.1.23668.1491.1539.2.1 -- nginx daemon KSVLA-MIB::ksvlaNginxStatus 1.3.6.1.4.1.23668.1491.1539.2.2 -- watchdog KSVLA-MIB::ksvlaWatchdogStatus 1.3.6.1.4.1.23668.1491.1539.2.3 Change SNMP community name Edit file /etc/snmnp/snmpd.conf Change public into the string recommunity on your own Save changes Restart SNMP daemon - systemctl restart snmpd Move on SNMPv3 Stop SNMP daemon - systemctl stop snmpd Launch the command - net-snmp-config --create-snmpv3-user -ro -a "authpass" -x "privpass" -X AES -A SHA "user" "authpass" is the private key/password for generating HMAC when connecting to snmpd, "privpass" is the private key/password for encrypting snmp traffic, "user" is the username for snmpd. "authpass" and "privpass" we can say passwords, which should be generated by you own "user" - user name for snmpd This command will make mpdifications into two files - /etc/snmp/snmpd.conf and /var/lib/net-snmp/snmpd.conf Restart SVM

This is a workaround and should be used if you can't check it the standard way. 1. Collect GSI 2. Open this file (see screenshot) and press ctrl+f and search for the word, for example, Firewall. Immediately you'll get a line with the installed components.

In Compact Diagnostic Interface Can be checked in "About the application" window. In Kaspersky Security Console Can be checked in Action -> Information about the application and available module updates...

The Application Control component has a category called Browser extensions. There is a known limitation for it in Chrome. If an extension runs in an already running Chrome process (many of them run as newly started Chrome processes, especially for extension reasons), it cannot be blocked because it is not a newly started process and the extension itself is not an executable. It requires an .exe file to load. An extension that is already running cannot be blocked by application control (it has already been allowed to load into memory, so there is no way to restrict it from that point on).

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. What is the role of Kaspersky in BitLocker encryption process ? Basically, KES BitLocker management is a COM object that is registered in the system and changes the BitLocker component settings in accordance to the settings that are specified in the KES policy. Afterwards it stores the recovery data received from BitLocker component on the KSC side. Also, it provides error-reporting and verifies that the settings that were specified in the policy are left intact and return errors, if this is not the case. You can manage BitLocker using a number of tools and approaches, KES is just one of them, that do share the same principles with the rest. You can enable BitLocker manually, using GPO, using native Microsoft's solutions, using various similar 3rd party solutions, and using KES BitLocker management. Each of those have their own pros and cons. Is there a guide for the recovery by means of AD in case of Kaspersky Bitlocker encryption? KES only enables encryption (changes settings for the component), stores the recovery data received from it, reports the status, that's it. Naturally, BitLocker recovery data can be stored besides KSC in AD and other BitLocker management tools. Storing keys in AD is possible, for example like this: https://blogs.technet.microsoft.com/askcore/2010/04/06/how-to-backup-recovery-information-in-ad-after-bitlocker-is-turned-on-in-windows-7/ but this has nothing to do with functionality of Kaspersky products. What happens in case if Kaspersky Security Center is down/not reachable, and I want the recovery key for Kaspersky Bitlocker Encryption? In this case recovery keys from this KSC will not be available as well. A valid KSC backup containing the recovery keys should be used for a recovery in this case. Is there an opportunity to export all recovery keys at once for all encrypted devices? It is not possible to export recovery keys in volume from KSC to a txt file, for example. This data is stored in a protected (encrypted) format in the KAV db and can be extracted only using KES management plugin over KSC console individually for each host. Is there an approximate algorithm for the initial implementation of BitLocker encryption using KES management? Make sure that the encrypted hosts will be serviced by a healthy KSC infrastructure (backups are performed regularly, no errors in Kaspersky Event log that needs to be addressed, healthy database with plenty room for growth, no cloned hosts, etc.). Create a scope of devices for KES Bitlocker implementation testing, that will consist of devices representing most widespread hardware & software configurations that is used in your enterprise. Devices should have default firmware settings configured on them. Attach to the test devices as much peripheral devices as possible (again most widespread configurations that is likely to be attached to encrypted devices during its regular usage) USB headsets, dongles, external flash drives, tokens, card-readers, etc... Deploy KES Bitlocker management and encrypt devices using actual KES version on a limited scope of test devices in production. Use the desired Bitlocker configurations, that is expected to be used in production. Monitor the user experience on the test devices in actual production environment during the pilot testing period. Make sure that it was encrypted successfully and there are no errors, recovery data is available for all test hosts, and the data can be successfully recovered from those devices using the recovery procedures (especially for the devices with multiple hard drives, that both hard drives can be unlocked assuming access to the data is lost completely and Bitlocker password is forgotten). Also make sure that the procedure itself is well-documented and is clearly understood by the local IT staff, that will execute it in production. Prohibit the end-users to adjust firmware settings on the hosts with encryption, prior to deploying encryption to production on the whole set of devices, by setting a BIOS password, for example. Deploy to production.

This behavior is expected. We have no control over a system booting in Safe mode, because Safe mode is a special boot mode for OS diagnostics and repair. It is not possible to enable KES booting when Safe mode is running. However, booting in Safe mode can be disabled using GPOs or the local registry. It can be done by a local administrator. One of the ways to disable Safe Mode is described here.

Step-by-step guide Open Outlook. Go to File → Options → Add-ins. Check add-in options for the KES plugin. Make sure that scan on receive and scan on send are enabled. If problem persists, enable KES tracing. Restart Outlook. Send e-mail with infected .doc file. Send another e-mail with EICAR. Stop traces and send them to the Kaspersky support for further analysis.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. This article is about Kaspersky Endpoint Security for Windows (KES for Windows) Version: any KES11.* on any OS Scenario: The following error appears during the installation: Error 27310. Failed to install the directory file for the digital signature Solution: 1. Run kavremover utility as administrator. 2. Delete KES drivers (if they were not deleted by kavremover) located here - C:\Windows\System32\drivers\ 3. Go to c:\Windows\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} and delete all KasperskyLab_*.cat files 4. Reboot 5. Install KES 6. If the issue will not be solved, try to restore catroot https://answers.microsoft.com/en-us/windows/forum/all/cant-rename-catroot2-and-softwaredistribution/ac10e0ba-9ead-4284-91e5-31acc430bd08

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Version: KES 11.* Scenario: You're unable to boot into encrypted machine after FDE applied due to some problems with preboot agent or operating system. The the safest and one of the most trivial options to restore the data from encrypted hdd or decrypt it 'in place' is going through KES related ‘challenge-response’ procedure using another (i.e. proxy) machine with KES and FDE installed. KSC 11 HostA with KES 11.1 (corrupted hdd with FDE policy applied) HostB with KES 11.1 (recovery host) * KES version should be the same or higher than the one used on the affected PC and with the same AES module, it should be managed by the same KSC server but initially without FDE policy applied. Solution: Disconnect encrypted hdd from HostA. Connect encrypted drive to HostB as a secondary. HostB is installed with KES and FDE but no FDE policy applied (DO NOT apply encryption policy to HostB once secondary hdd connected to avoid multiple encryption which will cause data corruption). The following pop-up window will appear once attempt to access the encrypted hdd: Save the file. On KSC, find the HostB. Right-click its property -> click on "Grant access in offline mode" -> navigate to "Data Encryption" tab: Browse and select the saved "challenge file". You will be prompted to save the "response file". At HostB KES console, you can see a notification at the bottom, click at notification and input the "response file" you saved from KSC. You can access the encrypted hdd from HostB. Transfer all important data you want to restore to another backup drive or deploy Kaspersky FDE 'Decrypt all hard drives' policy to the proxy-computer (HostB) in order to decrypt the 'affected' drive connected as a secondary. The previously encrypted hdd can be connected back to HostA as primary in case it was decrypted successfully and the disk is healthy.

Может лучше было бы связаться с разработчиками и устранить несовместимость. При этом разработчики Adguard на github писали, что связывались с Касперский насчет прояснения ситуации и тишина. Как и мне тоже по этому поводу не ответили до сих пор на обращение в тех поддержку INC000017682270. Хотя у меня премиальная подписка.

There are 2 methods of installing iOS MDM on the user's device: Via AppStore (iTunes Store); Via Manifest URL (with manual placement of the package). How to install via AppStore Installation via AppStore involves a special key named App ID. This process is fully automatic and requires no actions from the KSC administrator. In KSC, you need to specify the application name (this name will be used in KSC event log) and the application ID. The application ID can be learned from its URL. Disregard the letters id. Example: Gmail has the ID 422689480 To install an app on a device after the application's description has been published on the server, perform the corresponding command (Install application to device). How to install via Manifest URL Manual installation requires more actions from the company (in particular, from the KSC administrator). To perform an installation, you need: An application signed with a developer certificate. Depending on what certificate is used, you may need a provisioning profile with the corresponding UDID installed on the device. Manifest for the application. Manifest is an XML file that contains information about the application, including its name, version, and the location of its installation package Workflow: The user fills out the manifest with the application details (icon, metadata, .ipa package location). Next, the user needs to upload the manifest to the web server and create a new application in the iOS MDM server properties with a link to the created manifest. ATTENTION! The link must lead to the manifest, not the ipa file. Selecting an application: Selecting a device and installing the application on it:

KATA 4.0/4.1 is compatible with KSMG 2.0, KSMG 1 and KLMS 8.0.3. Second thing to notice is that KSMG integration has a few bugs on KATA side. Thankfully, all known issues are fixed in a PF, which is recommended for all who integrate KSMG/KLMS and KATA4. KATA4.0 Step-by-step guide Download container with fix. file_name : kata_scanner_35f8753e6d.tar.gz md5 : 2adb09c0bd13dfc03c6a5c8980dde4ff container_name: kata_scanner container_version: kata_scanner:35f8753e6d service_name: kataedr_main_1_kata_scanner Copy file kata_scanner_35f8753e6d.tar.gz to KATA CN check md5: md5sum /var/opt/kaspersky/apt/files/kata_scanner_35f8753e6d.tar.gz MD5 should be 2adb09c0bd13dfc03c6a5c8980dde4ff, after that import the container, no need to decompress: docker load < /var/opt/kaspersky/apt/files/kata_scanner_35f8753e6d.tar.gz If the load is successful, the result would be the the container version, like kaspersky/kata/kata_scanner:35f8753e6d Change container tag in /etc/opt/kaspersky/apt-swarm/image_versions.json to the new version (kata_scanner:bb3be18444 -> kata_scanner:35f8753e6d) "kata_scanner": "kaspersky/kata/kata_scanner:35f8753e6d", Update the image used for service kata_scanner by running the command: docker service update kataedr_main_1_kata_scanner --image "kaspersky/kata/kata_scanner:35f8753e6d" To verify that kata_scanner service runs new container, run: docker service ls | grep kata_scanner Sample output, note container version 4up6sm5yetnj kataedr_main_1_kata_scanner replicated 1/1 kaspersky/kata/kata_scanner:35f8753e6d *:8081-8082->8081-8082/tcp КАТА 4.1 Fixing mail processing Step-by-step guide Download container with fix. file_name : kata_scanner_66e20ed.tar.gz md5 : 288ddb650ed9c08ca1fe57e188c41c67 container_name: kata_scanner container_version: 66e20ed service_name: kataedr_main_1_kata_scanner Step-by-step: kata_scanner Download a container. Copy the file kata_scanner_66e20ed.tar.gz to KATA CN. Check md5: md5sum /var/opt/kaspersky/apt/files/kata_scanner_66e20ed.tar.gz MD5 should be 288ddb650ed9c08ca1fe57e188c41c67. After that, load the container, no need to decompress: docker load < /var/opt/kaspersky/apt/files/kata_scanner_66e20ed.tar.gz If the load is successful, the result would be the container version, like Loaded image: kaspersky/kata/kata_scanner:66e20ed Use it to change the container version in /etc/opt/kaspersky/apt-swarm/image_versions.json. Set the correct version: "kata_scanner": "kaspersky/kata/kata_scanner:66e20ed", Confirm that the changes are correct and are not breaking anything: cat /etc/opt/kaspersky/apt-swarm/image_versions.json | python -m json.tool | grep "kata_scanner:" Update the image used for the kata_scanner service with the new version of the container that we have just added: docker service update kataedr_main_1_kata_scanner --image "kaspersky/kata/kata_scanner:66e20ed" Verify that the kataedr_main_1_kata_scanner service runs the new container by running: docker service ls | grep kata_scanner Confirm the new version tag 66e20ed: Sample output, note container version mtgzlqu3beny kataedr_main_1_kata_scanner replicated 1/1 kaspersky/kata/kata_scanner:66e20ed *:8081-8082->8081-8082/tcp Fixing autoprevention rules for composite objects step-by-step guide Download container with fix. file_name : hunts-fixed-prevs.tar.gz md5 : 604d0918ddcb8b91cac694a15d96d501 container_name: hunts_event_processor container_version: 2610c63 service_name: kataedr_main_1_hunts_event_processor Copy file hunts-fixed-prevs.tar.gz to KATA CN (e.g via scp) check md5: md5sum /var/opt/kaspersky/apt/files/hunts-fixed-prevs.tar.gz MD5 should be 604d0918ddcb8b91cac694a15d96d501, after that import the container, no need to decompress: docker load < /var/opt/kaspersky/apt/files/hunts-fixed-prevs.tar.gz If the load is successful, the result would be the the container version, like kaspersky/kata/hunts_event_processor:2610c63 Change container tag in /etc/opt/kaspersky/apt-swarm/image_versions.json to the new version (hunts_event_processor:0e5fabb -> hunts_event_processor:2610c63) "hunts_event_processor": "kaspersky/kata/hunts_event_processor:2610c63", Check that json is changed and valid (outputs the string from previous step if all is ok): cat /etc/opt/kaspersky/apt-swarm/image_versions.json | python -m json.tool | grep 2610c63 Update the image used for service kata_scanner by running the command: docker service update kataedr_main_1_hunts_event_processor --image "kaspersky/kata/hunts_event_processor:2610c63" Expected output "verify: Service converged" To verify that kata_scanner service runs new container, run: docker service ls | grep hunts_event_processor Sample output, note container version r8m0jcrtkiu0 kataedr_main_1_hunts_event_processor replicated 1/1 kaspersky/kata/hunts_event_processor:2610c63 Fixing dashboards step-by-step guide For dashboards, two containers should be replaced: web_backend and clickhouse_metrics_importer. Service name Container name Download link kataedr_main_1_web_backend kaspersky/kata/management/management_ui/web_backend:4e30ad8 https://box.kaspersky.com/f/d66c6aa3ebe1483c9558/?dl=1 kataedr_main_1_clickhouse_metrics_importer kaspersky/kata/clickhouse_metrics_importer:0e5fabc https://box.kaspersky.com/f/fe0e562798fe4d1e9730/ Please replace them both as per instructions above. This cumulative fix container should be applied to all installations. https://box.kaspersky.com/f/d66c6aa3ebe1483c9558/?dl=1 file_name: web_backend_4e30ad8.tar.gz md5: 9aa87ce646c28cc30f5002f837d10104 container_name: web_backend container_version: "kaspersky/kata/management/management_ui/web_backend:4e30ad8" service_name: kataedr_main_1_web_backend Step-by-step: web_backend Download a container. Check md5: md5sum /var/opt/kaspersky/apt/files/web_backend_4e30ad8.tar.gz MD5 should be 9aa87ce646c28cc30f5002f837d10104. After that, load the container: docker load < /var/opt/kaspersky/apt/files/web_backend_4e30ad8.tar.gz If the load is successful, the result would be the container version, like Loaded image: kaspersky/kata/management/management_ui/web_backend:4e30ad8 Use it to change the container version in /etc/opt/kaspersky/apt-swarm/image_versions.json. Set the correct version: "web_backend": "kaspersky/kata/management/management_ui/web_backend:4e30ad8", Confirm that the changes are correct and are not breaking anything: cat /etc/opt/kaspersky/apt-swarm/image_versions.json | python -m json.tool | grep "web_backend:" Reload the docker service with the new version of the container that we have just added: docker service update kataedr_main_1_web_backend --image "kaspersky/kata/management/management_ui/web_backend:4e30ad8" Verify that the kataedr_main_1_web_backend service runs the new container by running: docker service ls | grep kataedr_main_1_web_backend Confirm the new version tag 4e30ad8: Sample output, note container version 5nb5ghavmtl5 kataedr_main_1_web_backend replicated 1/1 kaspersky/kata/management/management_ui/web_backend:4e30ad8 KSMG You should add vacuum command to the crontab and run it every 6 hours Cron scheduler should be added similar to this (under root): For KSMG 2.0.1 there is no need to add this command to cron. KSMG 2.0 $ sudo -i # crontab -e # Run at minute 0 past every 6th hour: 0 */6 * * * /opt/kaspersky/ksmg/libexec/postgresql/psql -h /var/run/ksmg -U kluser -d kata_quarantine -c 'vacuum full;' KSMG 1.1.2.30 $ sudo -i # crontab -e # Run at minute 0 past every 6th hour: 0 */6 * * * /opt/kaspersky/klms/libexec/postgresql/psql -h /var/run/klms -U kluser -d kata_quarantine -c 'vacuum full;'

Problem Environment: Citrix Virtual Apps and Desktops (Citrix XenApp and XenDesktop) with enabled option Citrix UPL (User Personalization Layer) Citrix App Layer Non-English Operation System localization. After installation of KSV LA 5.2, you can face the error "The specified path does not exist" which appears by launching any executable file. Possible root cause Both Citrix technologies use separate vhd files for creating VMs by using Citrix App Layer and for roaming profiles used by Citrix UPL. As the result, the merge of vhd files processes and Citrix driver returns incorrect path of where the executable files are. Workaround Install Kaspersky Light Agent 5.2 and ensure it does not connect to SVM. Disable Self Defense and exit LA. Add registry file from this archive. Launch installation of the latest cumulative patch from the archive (all further released Cumulative PFs will contain the fix as well). As soon as LA informs the restart is needed, restart VMs. Connect LA to SVM. Problem should be solved.

ATTENTION! All mechanisms described below will be applicable to all further released Cumulative Patches for Kaspersky Linux Light Agent 5.2. On-Demand Scan exclusion mechanism has not been changed. The following mechanism of exclusions with installed Cumulative Patch for Kaspersky Linux Light Agent 5.2 is applicable to On Access Scanning only. 1. File Scanning Exclusion (an exclusion does not end with ‘/’) If the option "Include subfolders" is enabled for exclusions from file scan, the label "IGNORE fanotify" will be set for this file. In this case, processing of an object with the excluded file will not be intercepted by Kaspersky Linux Light Agent 5.2 at all. 2. Folder exclusion (an exclusion ends with "/") without the enabled option "Include subfolders" This exclusion will be processed by Kaspersky Linux Light Agent 5.2 after the excluded folder is intercepted and file operation resolved. 3. Folder exclusion (exclusion ends with "/") with the enabled option "Include subfolders" This type of exclusion can be split into two processing mechanisms: Excluded folder is not a mount point. This exclusion will be processed by Kaspersky Linux Light Agent 5.2 after the excluded folder is intercepted and file operation resolved. If one of the subfolders in the excluded folder is a mount point, this subfolder will be ignored and not scanned, without processing this exclusion by Kaspersky Linux Light Agent 5.2. It means that this subfolder is excluded on the low level (fa-notify). Example: There is a directory “/path/to/folder” which is not a mount point. The folder “/path/to/folder” has the following subfolders: “notmountsubfolder”, which is not a mount point "mountsubfolder", which is a mount point The folder “/path/to/folder” is added to exclusions with the enabled option "Include subfolders". Exclusion of the two subfolders will be processed in the following way: Exclusion of subfolder “notmountsubfolder” will be processed by Kaspersky Linux Light Agent 5.2 after its interception and resolving. Exclusion of subfolder “mountsubfolder” will be processed without Kaspersky Linux Light Agent 5.2 interception and resolving this subfolder directory, i.e. on the low level (fa-notify) Excluded folder is a mount point. In this case this folder and all its subfolders (including the subfolders which might be mount points) will be excluded without Kaspersky Linux Light Agent 5.2 interception and resolving all subfolders, i.e. exclusions are set on the low level (fa-notify). Local installation: Copy the *.sh file on the Linux VM with Kaspersky Light Agent 5.2 installed. Grant execution access: chmod +x <path_to_file/*.sh file> Run the command /path_to_file/*.sh --install Remote Installation through Kaspersky Security Center: Create installation package based on the kud file. Create remote installation task and assign it to the Linux VMs with Kaspersky Linux Light Agent 5.2 installed. The version of Kaspersky Linux Light Agent will be changed to the version specified in the name of the cumulative patch for Kaspersky Linux Light Agent 5.2.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. This article might be useful in the following cases: If you want to configure multi-vendor security on endpoints, keeping both Kaspersky and Microsoft technologies; If you don't know how to properly configure a Microsoft solution after installing KES; If you're having some issues with the product and the OS after configuring KES and Defender. The differences between the Defender products There are three different products: Windows Defender: an anti-malware solution for Windows 8, 8.1 and Server systems based on it. For details, see here. Microsoft Defender Antivirus: an anti-malware solution for Windows 10, 11 and Server systems based on it. For details, see here. Defender for Endpoint: an EDR solution for Windows 10, 11 that might be used together with Microsoft Defender Antivirus or a third-party solution (from the Microsoft point of view, of course). For details, see here. KES installation specifics During the installation of KES, the Defender solution status is verified and disabled automatically. After that, KES notifies the operating system about a new AV and FW feature (if the KES Firewall component is going to be installed). Please note that even if Defender is replaced with the AV in the system, the Defender service might still run, and this is an expected behavior. There is no need to disable this service explicitly, and it also might be harmful in certain scenarios. For example, if Defender is disabled by GPO, it may result in the KES installation failure since the installer might not be able to get access to the desired setting. Configuring systems to use both KES and Defender solutions Here you can find the article with the details on how to configure a Microsoft solution to properly coexist with third-party AV vendors (and KES is a third-party from the Microsoft point of view). No special actions should be taken from the KES side, at least at this moment. The information will be updated in case of finding any issues. Repairing KES registration in WSC This option available only for KES versions prior to the 11.11. KES registration within Windows Security Center might be affected. For example, when WMI repository getting corrupted, Windows is just restoring it back to defaults. In such cases KES and Defender might be both actively scan files and cause performance issues. The workaround to restore KES registration is: Disable KES Self-defense Open registry key Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\KasperskyLab\protected\KES\Data Find value "IsRegisteredInSecurityCenter" and set it to zero. Restart KES service or the whole host. Unfortunately, there is no possibility to restore KES registration by using some WMI scripts because they're breaking product integration and does not allow to update product statuses in a way the product does.

There're only two known errors during KSMG installation. First one: ksmg.celeryd.service failed because a timeout was exceeded Above error means that DNS and/or DHCP servers are not accessible. Please reinstall and make sure that DNS and/or DHCP is configured properly. Second error: with error code=1 and msg=initdb: error: directory "/var/opt/kaspersky/ksmg/postgresql" exists but is not empty if you want to create a new database system, either remove or empty the directory "/var/opt/kaspersky/ksmg/postgresql" or run initdb with an argument other than "/var/opt/kaspersky/ksmg/postgresql" To fix the error just delete created VM and create a new one.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. NAgent upgrade failure because the old agent was installed from a different .msi package than the new NAgent's .msi package. The below logs describe the root cause. KLNAG_INS_MSI: CheckInstalledMsiName: installed name 'KasperskyNetworkAgent', installed ext '.msi' MSI_UTILS: CAGetProperty(OriginalDatabase) called... KLNAG_INS_MSI: CheckInstalledMsiName: installing name 'Kaspersky Network Agent', installing ext '.msi' KLNAG_INS_MSI: CheckInstalledMsiName: names are NOT equal Solution 1. Copy the installation package of the new NA version from the shared folder and place it on the Desktop, for example. 2. Change the name of the .msi package related to the new version of NA to match the name of the installed .msi package. 3. Create "Installation package for specified exec file" 4. Browse the .msi package that you have edited to match the old NAgent .msi package name. 5. In the properties of the installation package insert the below command: msiexec /i "KasperskyNetworkAgent.msi" /qn /l*vx c:\windows\temp\nag_inst4.log EULA=1 PRIVACYPOLICY=1 SERVERADDRESS=<server address> REINSTALL=ALL REINSTALLMODE=vomus 6. Install the created package remotely on the impacted machines.