All Activity

Scenario You're using a firewall that is using SSL interception. All required ports were opened as per http://support.kaspersky.com/13326 . On the corporate network, activation fails with "error 6". Off the network, activation is successful. Solution The reason this might not work is that your SSL-intercepting firewall (3rd party) might be attempting to check the validity of the SSL certificate that protects Kaspersky's activation server (activation-v2.kaspersky.com, TCP port 443). In particular, the firewall might be trying to check whether the certificate is revoked. Checking a certificate's status can be done through an older protocol called CRL or a newer protocol called OCSP. The fix is to configure firewall to not perform SSL interception relating to TCP port 443 of activate.activation-v2.kaspersky.com.

Officially exclusions from protection against external encryption are written on this page https://support.kaspersky.com/KSVLA/5.2/en-US/175626.htm Starting from 07/06/2022 it is possible to add exclusions from protection against external encryption using "Exclusions" tab under "Exclusions and trusted applications" settings. Steps: Go to "Exclusions and trusted applications" settings and move to "Exclusions" tab Add folder/filename (masks are supported) specifying SystemWatcher application component. Apply the policy The tested exclusions: <Drive>:\<Folder>\ <Drive>:\<Folder>\*.enc <Drive>:\<Folder>\*\*.enc Example:

Windows Unpack the archive (add_category.rar) on any device that has access to the Administration Console port of the Administration Server. Create a text file with needed hashes, by default the script expects it to be sha256.txt in script's working directory. Edit add_category.cmd with specified KSC username, password, server address, name of the text file with hashes (file should be saved in UTF-8 encoding) If a category with the specified name already exists, it keeps unique SHA256 hashes in the category. List of arguments: /Server Server address, 127.0.0.1 by default /User Username, current user by default /Pass Password /File Path to the file with hashes, input.txt by default. File should be saved in UTF-8 /Category Category name, New custom category by default Linux/macOS/Windows custom_script_add_category.zip - OpenApi python script. To use it the customer should install Python 3.12 or newer and additional libraries - urllib3, keyring, KlAkOAPI https://support.kaspersky.com/ksclinux/14.2/en-US/211453.htm -ksc_user - this parameter should be specified in internal KSC user is used to login to KSC. -category - name of the category -expressions_type - defines the array of the rules - "inclusions" or "exclusions" -file - name of the file with hashes. -full_replace - with this parameter specified all existing condtions will be overwritten ( by default script adds new conditions to the category without overwriting existing conditions)

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Scenario: When login to KSC Web Console, it shows the following error: Administration Server uses an untrusted self-signed certificate. Please modify the application configuration by specifying a valid certificate for Administration Server. Alternative wording (for older KSC versions): Administration Server has untrusted self signed certificate. Please, reconfigure the application with correct certificate for Administration Server. Reason: KSC certificate is set when Web Console is installing. If there are any changes/errors with the certificate after the installation, KSC Web Console will show this error, e.g. you installed Web Console with KSC together, then restore a KSC backup. Solution and Source: Change certificate in KSC. Specifying certificates for trusted Administration Servers - guide on specifying a new certificate

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. You're using KSC as WSUS server and moving the Windows Update folder to another drive so it won't occupy space on the C drive. However, when you're downloading Windows updates to KSC, the “C:\ProgramData\KasperskyLab\adminkit\1093\.working\FTServer” folder is increasing its size up to 15.5 GB. Solution Here is the procedure: Make a backup copy of KSC. Stop KSC service Copy folder “C:\ProgramData\KasperskyLab\adminkit\1093\.working\FTServer” to its new location, for example “E:\ProgramData\KasperskyLab\adminkit\1093\.working\FTServer” Rename old FTServer folder, for example “C:\ProgramData\KasperskyLab\adminkit\1093\.working\FTServer_old” Create a symbolic link for FTServer folder that points to new FTServer folder location using this command (run in elevated command prompt, replace link target with path to your new FTServer folder location): mklink /D “C:\ProgramData\KasperskyLab\adminkit\1093\.working\FTServer” “E:\ProgramData\KasperskyLab\adminkit\1093\.working\FTServer” Start KSC service.

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;'