All Activity

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.

In order to upgrade KATA from 3.7.2 to 4.0 > 4.1 > 5.0 > 5.1 > 6.0 please follow the manual below. Step-by-step guide Prior to PCN upgrade you have to disconnect all Sensors, SCNs and Sandboxes. After upgrade Sandboxes and Sensors must be reinstalled, disconnected SCNs – upgrade to 4.0 and 4.1 and then reconnect them to PCN. Upgrade order described here - https://support.kaspersky.com/KATA/4.0/en-US/198801.htm Information which is kept during upgrade - https://support.kaspersky.com/KATA/4.0/en-US/227848.htm Contents of backup - https://support.kaspersky.com/KATA/4.0/en-US/198854.htm NB! Events database is not being transferred if you want to restore backup to new installation (e.g. new physical or virtual server). System requirements are the same for 3.7.2 and 4.0/4.1, so if 3.7.2 installation matches the requirements, you can upgrade keeping the same hardware/VM configuration - https://support.kaspersky.com/KATA/4.0/en-US/194861.htm For upgrade you don’t need .ktgz archives, only the ISO file. Pre-upgrade recommendations This recommendation is optional for vanilla 3.7.2, and it's a must for 3.7.2 PF1 Before upgrading KATA 3.7.2 to KATA4, copy and run this script. Run it as root: python /var/opt/kaspersky/apt/files/kata4-preupgrade-checker.py Expected result for vanilla 3.7.2: In case any issues arise, please contact Kaspersky support, and provide script output as shown on screenshot above and this script log, the script shows log location upon completion: /data/kata4-preupgrade-checker.log Upgrade order Create backup of CN and do the manual backup of /var/opt/kaspersky/apt-preprocessor/preprocessor.conf (from CN and sensors, especially if tuning was made at sensors). Mount installation ISO to KATA VM or boot from drive with ISO, if a server is physical. Select Install Kaspersky Anti Targeted Attack Platform. Select Disk marked as [upgrade] and press Enter. Select Upgrade and press Enter Select Upgrade again and press Enter Wait for the completion and check at WEB UI, that there are no errors / issues / etc. Storage migration is a lengthy procedure and may take many hours, depending on the installation. No visual indication of progress is provided, but it's not frozen. Perform a backup of 4.0 The upgrade procedure from 4.0 up to 4.1 is pretty much the same, you have to map ISO and boot from it, select disk marked as [upgrade], proceed, make a backup of 4.1 Upgrade procedure from 4.1 to 5.0 is described here. Before updating the product from version 4.1 to version 5.0, check which boot mode is used on the server (BIOS or UEFI). If UEFI is used, the update will fail. To avoid this, you need to update from a special KATA 5.0 image which can be provided by Kaspersky Support. Before upgrade DISABLE NTP on 4.1 Information which is kept during upgrade. 1) You can obtain file upgrade_preparation-1.0-py3-none-any.whl in kata-cn-5.0.0-5201-inst.x86_64_en-ru.iso, just mount it in Windows, go to support folder, copy this file and put it to /tmp via WinSCP to your KATA 4.1. 2) Proceed with steps described in Online help After mounting ISO and running from it you will be prompted to say y + ENTER to upgrade Then press ENTER, read EULA and select "I accept" Then you have two options: leave cluster and bridge/overlay subnets by default (just by pressing ENTER in windows below) or you can change them as you want (especially if these subnets crossover with your infrastructure subnets) Upgrade procedure can take a while, after that you'll be prompted to choose management interface, enter it's details again Enter password for admin Configure DNS servers and press ENTER Enable SPAN capturing by typing y or skip this step as n and press ENTER (you can do it later after upgrade). Don't forget to read this article, kindly pay attention to section "Special considerations for upgrading Kaspersky Anti Targeted Attack Platform from version 4.1 to version 5.0" After upgrade you have to perform initial configuration of KATA via web interface using admin (with Local administrator checkbox) credentials being set up during upgrade, please refer to https://support.kaspersky.com/KATA/5.0/en-US/242580.htm and https://support.kaspersky.com/KATA/5.0/en-US/240726.htm Once the configuration is completed, it's possible to log in to Web UI as regular local admin: use Administrator/Administrator login and password, "Local administrator" checkbox must be enabled, too. Change the password for Administrator user and proceed with adding license, creating users etc. Upgrade procedure from 5.0 to 5.1 is described here. Step-by-step guide of upgrade is here. Information kept during upgrade is here. According to KB you have to upload upgrade.tar.gz to /data/upgrade But first, you have to create this directory and set permissions to it to be able to upload upgrade package via WinSCP (in this example we use chmod 777 as an ultimate set of rights, you can use another set) mkdir /data/upgrade chmod 777 /data/upgrade After that upload upgrade.tar.gz to /data/upgrade via WinSCP and unarchive it cd /data/upgrade tar xvf upgrade.tar.gz Give executive permissions to script install_kata_upgrade.sh and install pre-upgrade package Execute as root chmod +x /data/upgrade/install_kata_upgrade.sh sh install_kata_upgrade.sh You'll see this And finally run upgrade (use admin user credentials which you use for ssh) kata-upgrade --data-dir /data/upgrade --user admin --password 'passw@rd' In a while you should receive message about successful upgrade . Upgrade procedure from 5.1 Ubuntu to 6.0 Ubuntu is described HERE Step-by-step guide of upgrade is HERE Information kept during upgrade is HERE Upload kata-cn-ubuntu-upgrade-6.0.0-200-x86_64_en-ru.tar.gz via WinSCP to /home/admin Unpack it to /data by command tar xvf /home/admin/kata-cn-ubuntu-upgrade-6.0.0-200-x86_64_en-ru.tar.gz -C /data/ Install the upgrade package by running the following commands cd /data/upgrade/ chmod +x ./install_kata_upgrade.sh ./install_kata_upgrade.sh Install the upgrade by running the following commands source /tmp/upgrade-venv/venv/bin/activate kata-upgrade --data-dir /data/upgrade/ --password <password specified during component installation> If the password contains special characters, the password variable must be specified in the following format: --password '<password>' Mount the iso image of Kaspersky Anti Targeted Attack Platform version 6.0 and restart the server In the GRUB menu, select Upgrade KATA 5.1 Accept EULA Confirm upgrade Wait for completion, don't forget to remove ISO or ensure that after reboot KATA boots from local disk. Done. Known problem: during upgrade to 6.0 upgrade script may fail With the following error: 2024-10-21 10:56:16,664.664 [kata_upgrade.tasks.upgrade_base_task][ERROR] Upgrade task " (UpdateDeploymentServices)" completed with an error, elapsed time: 191.07 sec Traceback (most recent call last): File "/tmp/upgrade-venv/venv/lib/python3.11/site-packages/etcd3/client.py", line 46, in handler return f(*args, **kwargs) ^^^^^^^^^^^^^^^^^^ File "/tmp/upgrade-venv/venv/lib/python3.11/site-packages/etcd3/client.py", line 257, in get_response return self.kvstub.Range( ^^^^^^^^^^^^^^^^^^ File "/tmp/upgrade-venv/venv/lib/python3.11/site-packages/grpc/_channel.py", line 1161, in __call__ return _end_unary_response_blocking(state, call, False, None) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/tmp/upgrade-venv/venv/lib/python3.11/site-packages/grpc/_channel.py", line 1004, in _end_unary_response_blocking raise _InactiveRpcError(state) # pytype: disable=not-instantiable ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with: status = StatusCode.UNAVAILABLE details = "DNS resolution failed for etcd.dyn.kata:2379: C-ares status is not ARES_SUCCESS qtype=A name=etcd.dyn.kata is_balancer=0: Timeout while contacting DNS servers" debug_error_string = "UNKNOWN:DNS resolution failed for etcd.dyn.kata:2379: C-ares status is not ARES_SUCCESS qtype=A name=etcd.dyn.kata is_balancer=0: Timeout while contacting DNS servers {grpc_status:14, created_time:"2024-10-21T10:56:16.663456976+00:00"}" > After which web interface is not be accessible with Administrator credentials. Solution: Login to web interface using admin credentials (not Administrator) If current sizing by Endpoint Agents is not 0 then remember current value and set it to 0. If this setting cannot be applied because there are 0s for other integrations then set mail to 1. For example: Would be changed to Apply this configuration, login back with admin credentials and configure original values back: The point is to zero out any single of the integrations and then configure it back to original value, so depending on original configuration you may need to zero out other integration instead of Endpoint Agents. After this login to web interface with Administrator should work. Do that and wait till all errors in dashboard are cleared. Now you can restart upgrade script from step 5: sudo -i cd /data/upgrade/ ./install_kata_upgrade.sh source /tmp/upgrade-venv/venv/bin/activate kata-upgrade --data-dir /data/upgrade/ --password ... --current-task-index 5 Known problem: during upgrade to 6.0 when booting to iso an error is displayed: File /mnt/debconf_menu_answers.ini not found Possible causes: Upgrade script that was running before reboot did not finish successfully. Check logs in /var/log/kaspersky/installation/. It is safe to boot not from iso at this point to check that log. In case script failed (but not like above) escalate incident. Wrong partitioning of /dev/sda, where there is sda4 instead of sda3. Check output of lsblk -o NAME /dev/sda Correct output: # lsblk -o NAME /dev/sda NAME sda ├─sda1 ├─sda2 └─sda3 Wrong output: # lsblk -o NAME /dev/sda NAME sda ├─sda1 ├─sda2 └─sda4 Solution: $ sudo -i 1) Create partition table backup # sfdisk -d /dev/sda > sda.bkp # cp sda.bkp sda.new 2) Edit partition table file # vi sda.new 3) Enter edit mode by pressing "i" and change /dev/sda4 to /dev/sda3 For example if you have Change the number 4 to 3. Nothing else should be changed in the file! To save press ESC then :wq! and Enter. Apply new partition table # sfdisk --no-reread -f /dev/sda < sda.new Now you can boot from iso and continue upgrade. Upgrade procedure from 5.1 Ubuntu to 6.0 Astra is described below Installation is described here https://support.kaspersky.ru/KATA/6.0/en-US/243480.htm But, we have some differences here Upload kata-cn-astra-upgrade-6.0.0-200-x86_64_en-ru.tar.gz to /data Then move to *****@*****.tld:~# cd /data Execute tar xvf /data/kata-cn-astra-upgrade-6.0.0-200-x86_64_en-ru.tar.gz -C /data/ Execute cd /data/upgrade/ chmod +x ./install_kata_upgrade.sh source /tmp/upgrade-venv/venv/bin/activate kata-upgrade --data-dir /data/upgrade/ --password <password of the 'admin' user> Mount the iso image of Kaspersky Anti Targeted Attack Platform version 6.0 and restart the server. You have to start server from mounted ISO and select "Upgrade KATA 5.1 server" Proceed That's it, you've upgraded your 5.1 Ubuntu to 6.0 Astra Upgrade procedure from 6.0 to 6.1 is below https://support.kaspersky.com/help/KATA/6.1/en-US/246850.htm It considers upgrade from 6.0 or 6.0.1 directly to 6.0.2 - https://support.kaspersky.com/KATA/6.0/en-US/271957.htm, to 6.0.3, and finally to 6.1 - https://support.kaspersky.com/help/KATA/6.1/en-US/243480.htm 6.0 > 6.0.1 Upload upgrade.tar.gz to /home/admin directory Execute following commands below root@1.srv.node1.node.dyn.kata:~# mv /home/admin/upgrade.tar.gz /data/ root@1.srv.node1.node.dyn.kata:~# tar xvf /data/upgrade.tar.gz -C /data/ upgrade/ upgrade/images.tar.gz upgrade/install_kata_upgrade.sh upgrade/kata_license-1.0-py3-none-any.whl upgrade/kata_upgrade-1.0-py3-none-any.whl upgrade/ubuntu_image_versions.json upgrade/updates/ upgrade/updates/Packages.gz upgrade/updates/glibc_2.35-0ubuntu3.6.debian.tar.xz upgrade/updates/glibc_2.35-0ubuntu3.6.dsc upgrade/updates/glibc_2.35.orig.tar.xz upgrade/updates/glibc_2.35.orig.tar.xz.asc upgrade/updates/libc-bin_2.35-0ubuntu3.6_amd64.deb upgrade/updates/libc-dev-bin_2.35-0ubuntu3.6_amd64.deb upgrade/updates/libc-devtools_2.35-0ubuntu3.6_amd64.deb upgrade/updates/libc6-dev_2.35-0ubuntu3.6_amd64.deb upgrade/updates/libc6_2.35-0ubuntu3.6_amd64.deb root@1.srv.node1.node.dyn.kata:~# cd /data/upgrade/ root@1.srv.node1.node.dyn.kata:/data/upgrade# chmod +x ./install_kata_upgrade.sh root@1.srv.node1.node.dyn.kata:/data/upgrade# ./install_kata_upgrade.sh Processing ./kata_license-1.0-py3-none-any.whl Installing collected packages: kata-license Attempting uninstall: kata-license Found existing installation: kata-license 1.0 Uninstalling kata-license-1.0: Successfully uninstalled kata-license-1.0 Successfully installed kata-license-1.0 WARNING: There was an error checking the latest version of pip. Processing ./kata_upgrade-1.0-py3-none-any.whl Installing collected packages: kata-upgrade Successfully installed kata-upgrade-1.0 WARNING: There was an error checking the latest version of pip. Installation was successful! Then execute and wait until completion kata-upgrade --data-dir /data/upgrade/ --password <password of the 'admin' user> <<<<<<<< use ' ' symbols if special symbols are presented in password ............................................................................................................................................................ 2024-09-10 15:46:02,038.38 [kata_upgrade.context.ssh_execution_context][INFO] manager.cluster.dyn.kata: Closed ssh session 2024-09-10 15:46:02,038.38 [kata_upgrade.tasks.upgrade_base_task][INFO] Upgrade task "Update product stack sizing via management api (UpdateSizing)" completed successfully, elapsed time: 896.77 sec 2024-09-10 15:46:02,039.39 [kata_upgrade.updater.updater][INFO] WARNING: Please close all current user sessions to complete the upgrade process. Patch 6.0.1 is installed, you can check it at web UI 6.0.1 > 6.0.2 Upload kata-cn-upgrade-6.0.2-x86_64_en-ru.tar.gz to /home/admin directory Execute following commands below root@1.srv.node1.node.dyn.kata:/data/upgrade# mv /home/admin/kata-cn-upgrade-6.0.2-x86_64_en-ru.tar.gz /data/ root@1.srv.node1.node.dyn.kata:/data/upgrade# tar xvf /data/kata-cn-upgrade-6.0.2-x86_64_en-ru.tar.gz -C /data/ upgrade/ upgrade/images.tar.gz upgrade/install_kata_upgrade.sh upgrade/kata_license-1.0-py3-none-any.whl upgrade/kata_upgrade-1.0-py3-none-any.whl upgrade/ubuntu_image_versions.json upgrade/updates/ upgrade/updates/Packages.gz upgrade/updates/glibc_2.35-0ubuntu3.6.debian.tar.xz upgrade/updates/glibc_2.35-0ubuntu3.6.dsc upgrade/updates/glibc_2.35.orig.tar.xz upgrade/updates/glibc_2.35.orig.tar.xz.asc upgrade/updates/libc-bin_2.35-0ubuntu3.6_amd64.deb upgrade/updates/libc-dev-bin_2.35-0ubuntu3.6_amd64.deb upgrade/updates/libc-devtools_2.35-0ubuntu3.6_amd64.deb upgrade/updates/libc6-dev_2.35-0ubuntu3.6_amd64.deb upgrade/updates/libc6_2.35-0ubuntu3.6_amd64.deb root@1.srv.node1.node.dyn.kata:/data/upgrade# cd /data/upgrade/ root@1.srv.node1.node.dyn.kata:/data/upgrade# chmod +x ./install_kata_upgrade.sh root@1.srv.node1.node.dyn.kata:/data/upgrade# ./install_kata_upgrade.sh Processing ./kata_license-1.0-py3-none-any.whl Installing collected packages: kata-license Attempting uninstall: kata-license Found existing installation: kata-license 1.0 Uninstalling kata-license-1.0: Successfully uninstalled kata-license-1.0 Successfully installed kata-license-1.0 WARNING: There was an error checking the latest version of pip. Processing ./kata_upgrade-1.0-py3-none-any.whl Installing collected packages: kata-upgrade Attempting uninstall: kata-upgrade Found existing installation: kata-upgrade 1.0 Uninstalling kata-upgrade-1.0: Successfully uninstalled kata-upgrade-1.0 Successfully installed kata-upgrade-1.0 WARNING: There was an error checking the latest version of pip. Installation was successful! Then execute and wait until completion kata-upgrade --data-dir /data/upgrade/ --password <password of the 'admin' user> <<<<<<<< use ' ' symbols if special symbols are presented in password ............................................................................................................................................................ 2024-09-10 16:47:24,839.839 [kata_upgrade.context.ssh_execution_context][INFO] manager.cluster.dyn.kata: Closed ssh session 2024-09-10 16:47:24,839.839 [kata_upgrade.tasks.upgrade_base_task][INFO] Upgrade task "Update product stack sizing via management api (UpdateSizing)" completed successfully, elapsed time: 902.25 sec 2024-09-10 16:47:24,840.840 [kata_upgrade.updater.updater][INFO] WARNING: Please close all current user sessions to complete the upgrade process. Patch 6.0.2 is installed, you can check it at web UI 6.0.2 > 6.0.3 https://support.kaspersky.com/KATA/6.0/en-US/286625.htm Upload kata-cn-upgrade-6.0.3.sh to /home/admin Execute following commands below root@1.srv.node1.node.dyn.kata:/data/upgrade# chmod +x /home/admin/kata-cn-upgrade-6.0.3.sh root@1.srv.node1.node.dyn.kata:/data/upgrade# cd /home/admin/ root@1.srv.node1.node.dyn.kata:/home/admin# sh kata-cn-upgrade-6.0.3.sh Check that there are no errors like this root@1.srv.node1.node.dyn.kata:/home/admin# cat /tmp/ks_check_klava_patch.log before total 1016 -rwxr-xr-x 1 root root 561 Nov 15 2023 check_aapt -rwxr-xr-x 1 root root 306 Nov 16 2023 check_aptfr -rwxr-xr-x 1 root root 1592 Nov 15 2023 check_aptfs -rwxr-xr-x 1 root root 1860 Nov 15 2023 check_aptsn -rwxr-xr-x 1 kluser klusers 1011432 Oct 20 2023 check_hips2 -rwxr-xr-x 1 root root 287 Nov 16 2023 check_ksn -rwxr-xr-x 1 root root 409 Nov 15 2023 dispatcher -rwxr-xr-x 1 root root 1315 Nov 16 2023 validate_ioa_rules after total 1016 -rwxr-xr-x 1 root root 561 Nov 15 2023 check_aapt -rwxr-xr-x 1 root root 306 Nov 16 2023 check_aptfr -rwxr-xr-x 1 root root 1592 Nov 15 2023 check_aptfs -rwxr-xr-x 1 root root 1860 Nov 15 2023 check_aptsn -rwxr-xr-x 1 kluser klusers 1011432 Oct 20 2023 check_hips2 lrwxrwxrwx 1 root root 50 Sep 10 16:56 check_klava -> /opt/kaspersky/apt-scan-server/libexec/check_klava -rwxr-xr-x 1 root root 287 Nov 16 2023 check_ksn -rwxr-xr-x 1 root root 409 Nov 15 2023 dispatcher -rwxr-xr-x 1 root root 1315 Nov 16 2023 validate_ioa_rules Patch 6.0.3 is installed, it doesn't change version of product at web UI 6.0.3 > 6.1 Please follow https://support.kaspersky.com/help/KATA/6.1/en-US/243480.htm Known problem: after upgrade to 6.1 kata-collect is not found This is related not only to kata-collect console utility but also other internal console utilities Solution: $ sudo -i Edit /etc/bash.bashrc file # vi /etc/bash.bashrc Enter edit mode by pressing "i" and insert the following line in the very beginning: source /opt/venv/bin/activate Like so: To save press ESC then :wq! and Enter. After that reconnect to server via SSH. Known problem: no space on / at 6.1 sensor nodes after installation Cause: If you do not select any network interface as SPAN then suricata crashes constantly generating core files. To prevent this select at least one network interface for SPAN on sensor nodes. Solution if the problem already occured: Reinstall. Select at least one network interface for SPAN (Program settings → Configure traffic capture → Setup capture interfaces → Mark at least one network interface) If reinstallation is difficult and / is already full and you cannot get into preprocessor_span container to check its / content then: Select at least one network interface for SPAN. Change dir to docker container MergedDir *****@*****.tldr:~# cd $(docker inspect $(docker ps | grep preprocessor_span | awk '{print $1}') | grep Merged | awk -F\" '{print $4}') *****@*****.tldr:/var/lib/docker/overlay2/c3028dde07229aa8fc6f37b7ac2e04b454765b1b015ec9303ac1a35c38ffda38/merged# Check listing, it should contain a lot of core files *****@*****.tldr:/var/lib/docker/overlay2/c3028dde07229aa8fc6f37b7ac2e04b454765b1b015ec9303ac1a35c38ffda38/merged# ls -la | head -20 total 60596 drwxr-xr-x 2 root root 4096 May 18 09:36 drwxr-xr-x 1 root root 4096 Oct 24 11:12 . drwx--x--- 5 root root 4096 Oct 22 14:21 .. drwxr-xr-x 1 root root 4096 Oct 22 14:58 application lrwxrwxrwx 1 root root 7 Apr 25 2023 bin -> usr/bin drwxr-xr-x 2 root root 4096 Apr 18 2022 boot -rw------- 1 root root 11939840 Oct 24 11:10 core.103983 -rw------- 1 root root 11939840 Oct 24 11:10 core.103985 -rw------- 1 root root 11939840 Oct 24 11:10 core.103987 -rw------- 1 root root 11939840 Oct 24 11:10 core.103989 -rw------- 1 root root 11939840 Oct 24 11:10 core.103991 -rw------- 1 root root 11939840 Oct 24 11:10 core.103993 -rw------- 1 root root 11939840 Oct 24 11:10 core.104001 -rw------- 1 root root 11939840 Oct 24 11:10 core.104008 -rw------- 1 root root 11939840 Oct 24 11:10 core.104010 -rw------- 1 root root 11939840 Oct 24 11:10 core.104017 -rw------- 1 root root 11939840 Oct 24 11:10 core.104025 -rw------- 1 root root 11939840 Oct 24 11:11 core.104027 -rw------- 1 root root 11939840 Oct 24 11:11 core.104033 Remove them like so (make sure no unnecessary spaces are in the rm command) *****@*****.tldr:/var/lib/docker/overlay2/c3028dde07229aa8fc6f37b7ac2e04b454765b1b015ec9303ac1a35c38ffda38/merged# rm -f ./core.[0-9]* Reboot

Environment/Preconditions KSC - 12 KSWS - 11.0.1.897 You may find a massive increase in disk usage from the folder report under the Kaspersky folder. The size of the report folder will increase from around 2GB to 12GB, the files in the report folder have random name (like 340a13d9-2a50-4c4e-94d6-82a79d80da4b), which rapidly grows and consumes disk space. The file can be deleted to resolve the disk space full issue, which itself can cause many issues (can't log in to the server, KSWS stop, etc) To delete the file: Stop KSWS. Add permission/owner for the login account. Right-click and delete file. This issue is caused by the Task log setting under Log and Notification tab in the KSWS policy. To avoid the detailed events issue: Ensure that there are no Informational events in the Importance level option in each Component. Remove task logs older than (days) is selected. In case you do the above step and the random file is still keep growing rapidly (100 MB per hour), it may be causes by the flooding event. You can check the event flooding by using product local console. Install and launch KSWS tools and under Logs and Notifications node observe Task logs, System audit log and Security log in local UI. Check which event is generated in excessive amounts.

Странно, что раньше не было AdGuard в несовместимых - давно пора было ее добавить.

Second part of this article is also applicable to KSB 2.0, details about it below. It's rather hard to understand if malware channel works on KATA Sandbox or not. Here's a simple and reliable way of doing it. Step-by-step guide Create a .bat script with commands that you would normally execute in console to check internet connection - like ping or tracert, - and redirect commands output to file. Here's the example of such script. Upload this script to Storage and wait for it to be scanned: After the scan completes, download debug info with scan results. Unpack scan results using the password 'infected' without quotes. In folder task0 or folder task1, rename the file internal_tracing_report to internal_tracing_report.zip and unpack it. Open the file files.list with notepad and note the name of file that you used for commands output redirection (results.txt in our example script) Open the file with notepad to see the command results: Done! You will see the output of ping/tracert commands. In our example, ping command succeeded, but tracert failed with DNS problems, which means malware channel does not work properly and detection rate will be significantly decreased. How to test DNS on malware channel There is also an option to test DNS without running samples in Sandbox. Sandbox server uses core DNS servers in the wild web, not the ones specified in WebUI. DNS servers are accessed by VMs via local unbound server, which attempts to run DNS queries via internet interface. Interface namespace may be different, so in order to identify yours execute (after identifying proper dom* name execute command above): cd /var/run/netns ll Example: First, you need to jump to internet interface's namespace: /opt/kaspersky/sandbox/bin/ns_exec /var/run/netns/dom1 /bin/bash Then, test name resolution via local DNS server: dig @127.0.0.1 google.com Example: You can also test pings same way: /opt/kaspersky/sandbox/bin/ns_exec /var/run/netns/dom1 /bin/ping -c 3 8.8.8.8 Do not forget to exit the namespace via exit command!

Information in this article can be used when there are disk space limitations imposed on the folders used by KESL: /var/opt/kaspersky - default KESL installation folder /tmp - default folder used to store temporary files during the scan /var/opt/kaspersky To move files located in this directory you can create a symbolic link to another folder before installation. Use the following steps: Before installing KESL: mkdir /new/kesl/folder/ ln -s /new/kesl/folder/ /var/opt/kaspersky #root has to be the owner of all kesl subfolders below / chmod go-w,a-t /new Install KESL If you encounter "Fatal error: Invalid permissions. Check /, /opt, /opt/kaspersky, /var, /var/opt, /var/opt/kaspersky. Only root user should have write access to these directories." while running the post install script, make sure root is owner of all subfolders in the path to kesl executable. /tmp You can declare a new temporary folder for KESL by following these steps: Execute this: systemctl edit kesl Add the following: [Service] Environment="TMP=/new/temp/folder"

Consider the following scenario: Open update or scan KSWS task. Go to Schedule->Advanced→Task stop settings: Solution Task's stop settings are greyed out and cannot be changed. This is by design behaviour: Task stop settings can be changed only for real-time tasks - Real-Time File Protection and Script Monitoring. These tasks can be configured in KSWS policy to pause the execution at certain time not to interfere with 3d apps or speed up heavy operations. Task stop settings cannot be changed for Updater and On Demand Scan tasks. These tasks should be executed without pausing them.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. OS restart will be requested If you upgrading KEA above 3.11 version. About This article contains the best way of upgrading KEA 3.9 to the last KEA version avoiding possible known issues. Procedure Disable Password-protection and Self-Defense in KEA policy, lock the settings. Ensure that policy is applied on all devices. Upgrade KEA plug-in on the KSC side. Recreate KEA policy. Prepare installation package: - copy KEA distributive to KSC; - copy KEA Core-patch into the same folder; - copy KEA3.9_upgrade_script.zip into the same folder; - modify the last part of the script specifying the correct patch name (optional). Uncomment the last string if you want to install the patch right after KEA installation: Create an installation package on KSC → → Create and start "Install Application Remotely" task from KSC; Wait for successful completion; Enable Password-protection and Self-Defense in KEA policy after the upgrade is done. Upgrade Script:KEA3.9_upgrade_script.zip This scenario helps to avoid possible known issues with KEA 3.9 upgrade. Rarely, even the script doesn't work. The cause of it - KEA 3.9 Self-Defense. The files and services are marked for deletion but can't be deleted. So, if the script doesn't help you - the only possible way to complete the upgrade, unfortunately, is the reboot.

The scenario is applicable for KEA version 3.10 and above. There is no built-in feature to perform Yara-scan using KATA/EDR Expert 3.7.2. But if necessary, it's possible to perform it using KEA 3.10 and above. Yara-scan using the Command line Requirements: KEA 3.10 (and above) installed Files with Yara-rules (*.yara; *.yar) Scenario: Ensure that KEA is installed and running; Run the Yara-scan "C:\Program Files (x86)\Kaspersky Lab\Endpoint Agent\agent.exe" --scan-yara --path c:\rules --folder c:\files --scan-files yes Syntax --path [PATH] - the location of yara-files --folder [PATH] - the scope of scanning (e.g. C:\ to scan all files on the C drive and subfolders) Results will be listed on the CLI Yara-scan using KATA/EDR Web-UI Alternatively you can perform the commend using "Run program" EDR task from Central Node. Yara-scan using KSC If KEA is installed and managed from KSC server, you can start the command by *.bat file using Remote installation task. Requirements: KEA 3.10 (and above) installed Files with Yara-rules (*.yara; *.yar) Shared folder with READ ALL access Shared folder with WRITE ALL access Follow these steps: Prepare the batch file Prepare Shared folders: one with READ and one with WRITE access for everyone Create installation package on KSC using *.bat file (see example below) Create and start "Install application remotely" task Example: *.bat file example @echo off "C:\Program Files (x86)\Kaspersky Lab\Endpoint Agent\agent.exe" --scan-yara --path \\SHARE\YaraRules\ --folder C:\ --scan-files yes >> C:\Windows\Temp\yara-scan-results.txt copy C:\Windows\Temp\yara-scan-results.txt \\SHARE\YaraScanRusults\%computername%_results.txt The script will start Yara scanning using KEA: all files at C:\ will be scanned using all rules from \\SHARE\YaraRules\, results will be saved into \\SHARE\YaraScanRusults\ folder. \\SHARE\YaraRules\ folder should be available for READ \\SHARE\YaraScanRusults\ folder should be available for WRITE

Problem KEA writes in its event logs numeric task states. Solution Number Meaning 0 Unknown 1 PreparedToStart 2 Starting 3 Started 4 Stopping 5 Stopped 6 Reloading 7 Recovering 8 Failed 9 Completed

Problem KSWS10 and KSWS11 may have two issues because of the Application Control component: Can't uninstall KSWS with the error "There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run" Can't run GSI with this error "Unable to unpack the critical file. GsiSharp.bin" Solution Disable Application Control and retry uninstallation. Сollect GSI, if necessary.

This article is fully applicable to KSB 2.0 server as well You may want to gather KATA Sandbox diagnostics via SSH, without accessing Web UI. Here's how to do it. Step-by-step guide Login to Sandbox via SSH and become root. Then, execute the command: Produce collect sb-logs --create '/tmp' '-7' chmod 777 /tmp/sandbox-debug-report* sandbox-debug-report%timestamp%.tar.gz archive will be created in /tmp directory. Its name will be printed in the output, .e.g /tmp/sandbox-debug-report.2022-12-13.2022-12-20.tar.gz Use this full path as input for local scp to download it: Retrieve using scp scp admin@SB_IP:/tmp/path/to/sandbox-debug-report

Problem This error appears when newest MDR Configuration files that are above 1MB in size are uploaded into KATA WebUI following the integration scenario either to establish the integration or to replace the outdated config: https://support.kaspersky.com/KATA/3.7.2/en-US/201839.htm Solution Extend zip-archive file size limit from 1MB to 2MB: Become root: sudo su Open the file for modification: /opt/kaspersky/apt-request-utils/lib/request_utils/zip_checker.py Find the line in the file: def verify_zip(file_to_check, files=(), max_size=(1024 * 1024)) Change the max_size value to (1024 * 2048) def verify_zip(file_to_check, files=(), max_size=(1024 * 2048)) Save the changes. Restart uwsgi: systemctl restart uwsgi Clear the browser cache, reload page and check if issue is now fixed.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. In this scenario we will create an internal user "test-user" on KSC who has permission on admin group "Virtualized" only, while couldn't view nor manage admin groups "servers" and "workstations". Step-by-step guide 1. Take a backup from KSC admin server in order to make sure that incorrect changes will not impact your KSC. 2. Login to KSC admin server using admin account and go to KSC admin server → Monitoring → Administration server → Configure functionality displayed in user interface → check the box Display security settings section. 3. Close KSC admin console and re-open it again in order to apply the feature. 4. Go to KSC admin server → server properties → security → + internal user. 5. Don't assign Roles to the created user and only assign Rights. 6. The assigned Rights should be allow-all except Management of administration groups as per below. 7. Go to Managed devices → properties → security → uncheck inherit settings → assign the right to the user as per below. 8. For admin groups that the user will not manage (e.g. servers in this scenario). 9. For admin group that the user will manage (e.g. virtualized in this scenario). 10. Disconnect from KSC admin server and login to KSC console using the created user and you will find that he has access to only virtualized admin group as per below.

The symptoms of the issue are: Installation/upgrade of KSV LA 5.2 vSphere Virtual Machine is unresponsive after KSV LA 5.2 installation Based on the investigation results the problem related to NSX Introspection Drivers coming with VMware Tools. There is the article about it: https://kb.vmware.com/s/article/78016 Solution: The best option is to uninstall NSX File Introspection and NSX Network Introspection by modifying VMware Tools on a virtual machine. Try to upgrade VMware Tools up to the latest supported by vSphere version.

KATA doesn't have auto removal for inactive agents, and also it doesn't have support for VDI scenarios yet. So if you have many VDI clients in use, they will quickly fill up the license. Step-by-step guide KATA 3.7.2 You can set up cron task to remove clients periodically, for example, this code will remove clients older than 3 days sudo -u kluser psql antiapt -c "delete from agent_status where last_packet_time < (NOW() - INTERVAL '3 days');" KATA 4.0/4.1/5.0 docker exec -it `docker ps | grep kedr_database_server | awk '{print $1}'` psql -U kluser antiapt -c "delete from agent_status where last_packet_time < (now() - interval '2 weeks');" It will delete 2 weeks old inactive agents.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. This article is about Kaspersky Endpoint Security for Windows (KES for Windows) Problem "Removable disk" Encryption is enabled and the policy applied to the machines, but nothing happens when the client connects USB drive. Solution Encryption of the removable drives supports two modes: Encrypt entire removable drive: based on Kaspersky Full Disk Encryption (FDE), the entire disk including the file system is encrypted using klfde.sys. Encrypt all files or new files only: based on Kaspersky File Level Encryption (FLE), files on a removable drive are encrypted using klfle.sys and file system remains unchanged Encryption of removable drives (kaspersky.com). If you have collected GSI from an affected device, check file KL_Drivers_Versions_****.txt: If klfde.sys module is installed on the machine → there should be klfde.sys in KL_Drivers_Versions_****.txt file in GSI. If klfle.sys module is installed on the machine → there should be klfle.sys in KL_Drivers_Versions_****.txt file in GSI. If there's no GSI from an affected device, check: klfde.sys module is installed on the machine (in case of Encrypt entire removable hard drive) → path C:\Program Files (x86)\Kaspersky Lab\Kaspersky Endpoint Security for Windows\klfde_x64 klfle.sys module is installed on the machine (in case of Encrypt all files or new files only on removable hard drive) → C:\Program Files (x86)\Kaspersky Lab\Kaspersky Endpoint Security for Windows\klfle_x64 If none of the above exists, the related component as per Change application components (kaspersky.com) should be installed. Portable mode (which allows access to data outside the corporate network and allows encrypted data to be accessed on computers that do not have KES installed) is only available for File Level Encryption (FLE). It is not possible to enable portable mode support for Full Disk Encryption (FDE).

Please note that Kaspersky Light Agent 5.2 has been passed basic test scenarios on Windows Server 2022 and Windows 11. Currently KSV LA 5.2 supports installation on Windows Server 2022 and Windows 11.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Sometimes EDR agents generate more telemetry than anticipated. There's an option to tune telemetry collection via KEA bases, and in order to do it, telemetry profile, aka "topic-dump", is needed in ready-to-use format. In order to collect telemetry, do the following: Please do not run apt-sedr-reset before collecting topic dumps. Execute the following command and wait till it finishes (it may take significant time to finish, depending on the telemetry flow): KATA 3.7: docker exec -it $(sudo docker ps | grep kafka1 | awk '{printf $1}') kafka-console-consumer.sh --bootstrap-server 127.0.0.1:9092 --from-beginning --property print.key=true --property key.separator="~" --max-messages 2000000 --timeout-ms 200000 --topic EndpointEnrichedEventsTopic | head -n -1 | gzip > /tmp/topic-dump.gz KATA 4.0/4.1/5.0/5.1: docker exec -it $(sudo docker ps | grep kafka\: | awk '{printf $1}') kafka-console-consumer.sh --bootstrap-server 127.0.0.1:9092 --from-beginning --property print.key=true --property key.separator="~" --max-messages 2000000 --timeout-ms 200000 --topic EndpointEnrichedEventsTopic | head -n -1 | gzip > /tmp/topic-dump.gz Collect and provide to Kaspersky Support /tmp/topic-dump.gz