Earlier versions of KATA Platform provided KATA functionality, which is intended to protect the perimeter of an organization by analyzing the external traffic for attacks, intrusions, and malicious objects/emails/URL links.

NDR expands the above functionality and allows you to protect the corporate LAN.
Specifically, KATA is more for north-south traffic (flowing into and out of an organization), and NDR is more for east-west traffic (flowing among devices within an organization).
NDR can analyze data from the following sources: network traffic (SPAN traffic from Sensors) and network events from Endpoint Agents (so called "NDR telemetry").

In case of network traffic, NDR obtains it from Sensors (SPAN) and scans it for indicators of attacks, malicious activity, anomalies, and the use of hack tools.

On the Endpoint Agents' side, NDR collects information about endpoint protection (EPP) detections, network events, user accounts, and executable files.

To use NDR features in Endpoint Agents, KES 12.7 or KESL 12.2 or later versions must be used.
A built-in NDR component in KES sends NDR telemetry to Integration Servers. To add an Integration server, you need a working Sensor. You can use a built-in sensor on the Central Node (Embedded sensor) or an external Sensor for this purpose.

The procedure for adding an Integration Server is simple and described in the documentation.

In case of KES for windows, make sure that "Network Detection and Response (KATA)" component is installed and enabled in KES policy.

You need to select the NDR component in KESW installation package properties in KSC. You can also use "Change application components" task to add NDR to an existing KES installation.

In the case of KES for Linux, you don't need to explicitly select the NDR component, since KESL installs all protection components by default.

The next step is to connect the NDR component with the Integration Server (IS). For this you need to obtain Integration Server's certificate by clicking on "Get communication data package for clients" button in Integration Server properties

Then you need to add the IS certificate in KESW/KESL policy and also specify its IP address

To use NDR to scan traffic, you need to activate the Central Node with a "KATA+NDR" license.
To use integration with Endpoint Agents (KES), an "NDR Add-on" license must also be added to KES (for example, via KSC).

Please note that NDR functionality can be used independently from KEDR.

NDR presents its detections in the form of Alerts and Network traffic events.
If malicious activity is detected in traffic, an Alert will be shown in the Alerts section, showing "NDR: IDS" in the technology column. Aggregated alerts and alerts based on the information received from external systems are shown as "NDR: EA" alerts.

If you open an NDR alert and then click Show related -> Events, it will open the "Network traffic events" section and show you NDR events that correspond to the alert.

The "Network traffic events" section is where NDR stores its events with detailed information on each event: malicious/suspicious activity (triggered rule), source and destination IP and MAC addresses, network protocol, severity level, registration technology, etc.

Other new useful features of NDR are Network interactions map and Network sessions monitoring.
NDR analyzes network packets, discovers interactions between devices and draws a network map showing the devices and links between them.

More detailed information about network interactions of devices is presented in the "Network sessions" tab.
Here you can review detailed information on discovered network sessions: devices names, IP/MAC addresses, transport and application protocols, port numbers, speed, number of packers, etc. You can also download traffic for the selected network sessions.

Other new features include Risks monitoring and NDR Reports.
Asset management is also new in KATA 7 and specifically with NDR license 4 additional tabs appear inside "Assets" section: Executable files monitoring, Users monitoring, Address spaces, and Active polling jobs.

1.1. Problem

Some hosts (usually server, eg. Windows Server 2012 R2) will not appear in CN dashboard after being configured using correct settings, including a valid TLS certificate. In the known case, such Endpoint Agents were configured locally using the command line, not via policy; however, we were able to verify that the same configuration led to successful connection on most hosts.

During troubleshooting, you should be able to find the following events in WEL, Schannel errors are present:

In KEA traces  you should be able to find the following lines:

The connection port is displayed as 0. This persists even though the port used by default is 443 (as it is on non-affected hosts), or if we specify the port in the configuration string like this:

C:\Program Files (x86)\Kaspersky Lab\Endpoint Agent\agent.exe" --message-broker=enable --type=kata --servers=<servername>:443 --tls=yes --pinned-certificate=”%~dp0kata.crt

1.2. Cause

• Most common cause - TLS 1.2 is disabled (usually for Server OSes)
• Some of the ciphers are missing

1.3. Solution

1. For KEA 3.11 and older - Upgrade KEA to the latest version.
2. Ensure "КриптоПро CSP" is not listed in installed applications
3. For Windows 2012R2  - install KB2919355 

4. Enable TLS 1.2. Exhaustive article in Russian https://winitpro.ru/index.php/2022/04/19/vklyuchit-protokol-tls-1-2-windows/

   Script to enable all the keys from the article 

   @echo off reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled /t REG_DWORD /d 1 /f reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v DisabledByDefault /t REG_DWORD /d 0 /f reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v Enabled /t REG_DWORD /d 1 /f reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHTTP" /v DefaultSecureProtocols /t REG_DWORD /d 2720 /REG:32 /f   reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" /v SchUseStrongCrypto /t REG_DWORD /d 1 /REG:32 /f reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /REG:32 /f reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /f reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto /t REG_DWORD /d 1 /REG:32 /f reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /REG:32 /f

5. Ensure the following registry keys for TLS 1.2 are present (it is possible to check using GSI6 report):

   Windows Registry Editor Version 5.00   [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001   [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001

6. Ensure the following registry value for WinHttp API:
   32-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp
   64-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp
   "DefaultSecureProtocols" = dword:00000AA0
   
   0x0000AA0 — allow TLS 1.1 and TLS 1.2 in addition to SSL 3.0 and TLS 1.0;

7. Allow following ciphers on the server in order to match KATA CN (old and outdated are not allowed from security point of view) -

   For Windows 2012 R2 it is necessary to add and enable  TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 
   One can do this via MS documentation like this - https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-server-2022:

   ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-ECDSA-AES256-SHA384 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-ECDSA-AES128-SHA256

   Ciphers can be enabled using tool called IISCrypto, it can be used to tweak TLS/SSL, cipehrs and Schannel with GUI - https://www.nartac.com/Products/IISCrypto/

8. Reboot for the settings to take effect - !Restart required!

KATA/EDR CN is deployed on site, and there are some remote users that cannot connect to the internal network, and you want to receive the EDR telemetry from those endpoints and laptops when they are outside the network (considering that you don't have any VPN functionality).

You don't want to expose the CN on the internet, so you'd like to use the sensor to relay the telemetry to the CN and have visibility on the endpoints.

1.2. Warning

Sensor that is published (port 443 TCP) to wild internet for endpoint agent integration will not be a reason for denial of technical support.

We regularly close known vulnerabilities (including those reported by customers) with private fixes and workarounds.

However, for this functionality you must consider that KATA EDR allows SoC users (security officers) to execute arbitrary code on workstations with agents deployed.
Such capability is also present for example in KSC <-> Network Agent. But in KSC <-> Network Agent it is recommended to publish only a connection gateway, in which case connection gateway can be automatically updated via bases with fixes for SSL vulnerabilities.
Currently there is no such functionality with automatic fixes installation for SSL vulnerabilities via bases updates in KATA Sensor.
Also KATA EDR stores and processes much deeper data than KSC. 

Considering above the following is recommended:

1) Allocate a dedicated and isolated central node which would not process data from corporate network where data has a different class of confidentiality. 
Meaning that even if you publish only a sensor, it is not recommended to connect that sensor to the same central node that processes agents installed on domain controllers.

2) Published sensor should not process any data from corporate network. For example, no SPAN or other integrations from corporate network, no agents connecting from inside corporate network.

3) Configure telemetry storage in such way so that only several days of telemetry is stored on central node to which published sensor is connected.

4) If possible limit IP range from where published port is accessible. For example, using some geoip database.

5) Enable validation of client certificate: https://support.kaspersky.com/help/KATA/7.1/en-US/247876.htm .

1.3. Pre-requisites and configuration steps:

To achieve the above scenario, we can deploy the KATA Network Sensor in the DMZ and publish it on the internet for remote and roaming users. The Network Sensor will be integrated with the CN and public IP/FQDN will be used to send the traffic from the internet to the sensor using port 443.

Two KES policies (Active/Out of Office) will be configured, The Active policy will have the KATA CN internal IP and the Out-of-Office policy will have the public IP/FQDN for KATA Sensor.

Connection profiling can be used to switch between the policies (similar to the connection gateway for KSC).

The below steps need to be performed for the successful deployment and integration.

• Deploy the KATA Network Sensor in the DMZ
• Configure to integrate with CN, and accept the request on the CN side.
  1. When using the KEDR license, the Accept button might not be available, integration of the KATA sensor requires a KATA license, or the latest KATA patch should be applied on the CN to fix this issue.
• Export the certificate from the KATA Sensor using WinScp and copy it to the local computer or KSC server.

Note: you might need to allow the connection using WinSCP:

https://forum.kaspersky.com/blogs/entry/100-how-to-copy-files-tofrom-kata-katakedre/

Copy the kata-current.crt with WinSCP.

• Apply the KES (Out-of-office) policy to a test laptop.
• Disconnect the Laptop from the network and wait for the connection to be established from the internet with KATA Sensor.
• Verify the Endpoint status on the Central Node and check for the recent events.

This article may be useful in certain cases, when you see that virtual machines running on the KATA Sandbox can not access internet using the properly configured malware interface. One can notice the issue based on several symptoms, such as VM activation errors, samples sent to Sandbox for processing not accessing internet, etc... We recommend to use the following article to check if the malware channel works properly on the KATA Sandbox server or not:

https://forum.kaspersky.com/blogs/entry/162-how-to-test-malware-interface-on-kata-sandbox-katakedre/

Details

In case if the tests listed above indeed show that malware channel fails to connect to the internet, we recommend to do the following checks among others:

1. Run the following command on the sandbox server to check the currently configured network settings for the Sandbox:
   
   # /opt/kaspersky/sandbox/bin/sbnetworking all show 
   
   check in the command's output if the malware interface is configured properly, i.e. it's intended IP, subnet, gateway, etc.
   
   Example of such output below:
   
   
   
   Correct values if they are misconfigured somehow from the web interface and don't forget to apply the settings afterwards and restart the host, to propagate those (prompt for restart will pop-up in the Sandbox web interface after applying those).
2. Run the following command to check the system log on the Sandbox server if there are certain errors related to networking in general and malware interface in particular:
   
   # journalctl -u network
   
   # journalctl -u sandbox-networking.service
   
   In case if all checks listed above were passed, and there are no misconfigurations found and/or no specific errors were found in system journal, then try checking if routing is properly configured for the malware channel, i.e. run the following command:
   
   # ip route show table 701
   
   Expected output below:
   
   
   
   if the output will be missing the default route entry via configured gateway for the malware interface, then add it manually like so:
   
   # ip route add default via <gateway's IP> table 701
   
   after adding the route, double check that it indeed exists:
   
   # ip route show table 701
   
   then restart the sandbox-networking service manually or the Sandbox server itself:
   
   # systemctl restart sandbox-networking.service
    
   Please note, that restarting sandbox-networking service may take a while especially on production servers that are processing a lot of samples at the moment and/or have a lot of worker slots. Thus it is highly recommended to detach this Sandbox server from KATA for the time of restart and expect 40 minutes - several hours downtime to complete the procedure.
   
   after restarting the sandbox-networking service check if you can ping public locations successfully from internet interface's namespace:
   
   # /opt/kaspersky/sandbox/bin/ns_exec /var/run/netns/dom1 /bin/ping -c 3 8.8.8.8
   

Problem Description

A PCN connection request got stuck in the "Waiting" status and doesn't result in failure. The reboot doesn't help. It can happen if, for example, a SCN IP was specified instead of PCN.

Solution

1. Run the following commands as root:

   Cancel PCN connection request

   # console-settings-updater get /ipsec > /home/admin/ipsec.orig.json && chmod 777 /home/admin/ipsec.orig.json # console-settings-updater set /ipsec "{}"

2. Clear the browser cache. Reload the page. Alternatively, force the reload (Ctrl+F5 in FF).
3. The server status will revert to the Standalone solution.
4. Select the Distributed solution, specify the correct IP of PCN and retry to connect.

To restore config in case of error:

• CPU: 15 cores, 2.1 GHz or higher
• RAM: 32 GB
• HDD volume: 300 GB
• Two network adapters with 1 Gbit/s data transfer rate

Virtual machine settings: 

1. Only VMware ESXi hypervisor is fully supported.
2. Nested virtualization is enabled
3. Supported VMware ESXi versions 6.5, 6.7U3 or 7.0 hypervisor. 
4. Entire CPU clock rate reserved. For a minimum CPU clock this means 12*2100=25200 MHz reserved. For a clock rate higher than 2.21Hz, use the following formula to calculate the entire CPU clock rate: 12 * <clock rate in MHz>.
5. Entire RAM reserved (32 GB).
6. Expose hardware assisted virtualization to the guest OS check box selected.
7. Latency Sensitivity option set to High.
8. No Secure Boot.
9. The maximum number of simultaneously running virtual machines set to 12.

Please note, these cannot be checked from a debug report or from inside of the VM, as these settings are configured in a hypervisor.

Checking VMX file

Obtain a .vmx file of the respective sandbox VM. Demo video showing how to locate a .vmx file. Note, that in this video the goal is to modify the .vmx, and we only need to access it for reading, therefore, there is no need to unregister a VM from inventory as done in video. All the following lines in .vmx file must match exactly with the following two exceptions: 

• For sched.cpu.min, the value can be higher than 25200, see formula above.
• Line uefi.secureBoot.enabled might be absent, which is OK.

Checking number of slots

• In the Sandbox web interface window, select the Administration section.
• In the Guest virtual machines group of settings, in the Maximum simultaneous VMs field, number of simultaneously running virtual machines must equal 12.

1. Prepare a file named sandbox.config with the following contents:

2. Create a private RSA key with the PEM extension (without a passphrase):

3. Create a Certificate Signing Request using the following command:

4. Generate the certificate (as Web Server certificate) from Internal CA in Base 64 encoded and copy the certificate and key to the KATA SB Server

Access your internal CA from Domain Controller using https://dc.abc.lab/certsrv and follow the instructions as below screenshots.

5. To convert the DER encoded PKCS#7 file, use the following command:

6. On the Sandbox server in SSH mode, Create a backup of original files both the private key and the certificate with same rights as it was before.

7. Replace the original files with your files

8. Rights and owner of the files should be same

9. If the rights are different for the new files, then use the below command to change the rights and ownership

10. Restart nginx service

11. Open the KATA SB Web UI using the hostname and verify the certificate.

Versions

You can fancy access log-history logs (former apt-history) directly for convenience purposes or if the kata-collect-siem-logs tool is malfunctioning for some reason.

These logs are in gzip, sorted by dates, as files with names in format: /data/volumes/s3proxy/log-history/YYYY-MM-DD-HH-MM-SS, where YYYY-MM-DD-HH-MM-SS is the datetime.

 To access these logs, use the respective zless; zgrep; zcat tools. For example:

Bonus: you can also use these tools to read rotated logs of kataservices in /var/log/kaspersky/services/:

Versions

Problem

There are several cases where the standard method of changing interface network settings via the Web UI is not available, e.g. the Web UI is inaccessible.

Solution

Become root, save the nodes settings:

Open the saved file for editing:

Locate the desired network_settings, ifaces node, change the values tat you need to change:

Save your changes and exit Vim. Verify that the JSON structure is valid (the command returns no errors):

Import the modified settings back:

Here's how to install KATA 6.0 Ubuntu edition in KVM environment - https://support.kaspersky.ru/KATA/6.0/en-US/265697.htm

In the example below we use RHEL 9.3, installed as VM in VMware Workstation Pro 17.0

Step-by-step guide

• First, you have to install QEMU/KVM , all steps are described HERE
• Then install from Software application Virtual Machine Manager, here it's 4.1.0 version.

• After successful installation just open up Virtual Machine Manager application, and click on the icon "Create a new virtual machine"

• Assuming, you have KATA Ubuntu ISO locally in OS, choose option below and click "Forward"

• Click "Browse" and "Forward"

• Click "Browse Local"

• Locate KATA Ubuntu ISO and click "Open"

• Next, do the steps as shown on picture below

• Click "Yes"

• Assign resources to VM according to THIS article (ignore our settings below, it's just a demo) and click "Forward"

• Configure a disk (ignore our settings below, it's just a demo) and click "Forward" 

• Name your VM, select a network and click "Finish"

• Now you should see installation window, proceed like you usually do with standard KATA installation on VMware

• In this window select ONLY "single", cause KVM supports only this type of installation

• Select a disk and click "OK"

• Wait a bit and you should see that installation starts, and now you just have to wait for next step of installation/configuration

• Now select subnets (usually use default ones) by pressing Enter

• Choose network > assign IP (static or dhcp, in our example we use dhcp) > set password length and password itself > configure DNS servers 

• Choose if you want capture traffic via SPAN (y or n) > configure NTP servers 

• That's it, KATA installed

• Now you can login to web UI and configure server, in our example IP of server is 192.168.122.47, let's login to https://192.168.122.47:8443

        and voila  "Configure" and wait for completion 

KATA/EDR CN is integrated with the KPSN server, and you want to enrich the KPSN reputation database with the detections from the sandbox server. You can integrate a KATA Platform Central node with the KPSN reputation database and automatically populate it with information about the files that the sandbox technology finds to be dangerous and highly important.

Pre-requisites:

To configure sending checksums of the files detected by the sandbox technology to KPSN, you will need a certificate of a KPSN user account entitled to use KPSN API.

Download the certificate (both parts, public and private) of a KPSN user who has permission to use KPSN API from the user’s profile in the KPSN web console. The KPSN administrator has the required permissions, but a pair of encryption keys of any user allowed to access the KPSN API will do as well. and key from the user’s profile from the KPSN web interface.

You can provide the API access to the required user from KPSN Web UI → Users → and the API option should be enabled under permissions.

To send the sandbox detections to KPSN:

• In the central node administrator’s console, open Settings | KPSN reputation database and specify:
  • HOST – IP address of the KPSN server where the local KPSN reputation database is stored;
  • TLS Certificate – a certificate for the user authentication in KPSN;
  • TLS encryption key – private encryption key;

There are two or more servers with different roles in a typical KPSN installation. A KPSN server can have several roles. Specify the IP address of the KPSN server that has the Monitoring Service role.

In the Central node console of a senior security office, open Settings | KPSN reputation database and select the checkbox to Assign the ‘Untrusted’ status to objects.

You can upload the test file to the KATA Central node for scanning, once the file is detected by Sandbox component, the checksum of the detected file will be published in the KPSN local reputation database.

The KPSN administrator can manually create records in the KPSN reputation database. A record added by KATA/EDR has the KATA tag in the description. You cannot delete the KATA records, but you can disable them.

Below screenshot display the samples hashes added in the KPSN Reputation database from the KATA server.

One may need to change the admin account's password (the account used for SSH login).

Details

In case of standalone Central node:

1. Login to the web-interface of the CN.
2. Enter admin credentials (used for SSH login).
3. Go to admin account > change password as per below

In case of Distributed deployment (PCN and SCN):

1. Login to the web-interface of PCN.
2. Enter admin credentials (used for SSH login).
3. Go to admin account -> change password
4. Login to SCN via SSH and change using the pseudographic menu ("Change cluster admin password..." option)

In previous versions of KATA it was possible to mount an NFS share to copy backups to. In KATA 5.x only CIFS share mounts are available out-of the box.

Solution

Install packages manually via dpkg in the following order to add NFS support:

After generating the client certificate on central node and upload it to KES policy, you can get the below error:

Enter a crypto-container password to use the certificate.

Note: If you are using KEA as a standalone product with KEA policy, you can upload the client certificate properly.

Root cause:

By default, the cryptographic container is not password-protected. The cryptographic container contains only the certificate file, but not the private key file. KES policy does not apply certificate without password (only KEA does).

Solution:

Access the central node SSH under root account

1) Export you current certificate to a passwordless pem type:

#openssl pkcs12 -in mycert.pfx -out tmpmycert.pem -nodes

Enter Import Password: <Enter no password>
MAC verified OK

2) Convert the passwordless pem to a new pfx file with password:

#openssl pkcs12 -export -out mycert2.pfx -in tmpmycert.pem

Enter Export Password: <Enter password here>
Verifying - Enter Export Password: <Enter password here>

Now you can use the new mycert2.pfx file with your new password.

Issue

In KATA 4.1, when Central Node was used as Sensor, it was possible to access Traffic Capture and disable protocol, e.g SMTP.

CN-Sensor - https://support.kaspersky.com/help/KATA/4.1/en-US/199500.htm
Standalone Sensor - https://support.kaspersky.com/help/KATA/4.1/en-US/199500_1.htm

In KATA 5.0, this possibility is missing from docs and from CN and only available on Standalone Sensor:

Solution

Workaround is to use CLI and access predecessor configuration directly:

Problem Description, Symptoms & Impact

It is not possible to use a proxy server for KATA 5.0 and/or KATA 5.1 CN on TCP ports 8080, 8090 or 8091. If you will configure in KATA 5.0/5.1 proxy server connection settings using one of those ports, then such configuration will result in KATA update task failure and KSN connection errors right after those settings will be applied.

This happens due to the fact, that KATA uses ports 8080, 8090 and 8091 for it's internal services and there are preconfigured default iptable rules that prevent incoming and outgoing connection on those ports for external hosts outside of the KATA cluster, which in turn results in connection errors if those ports are also used by the product for outgoing connections to a proxy server.

Diagnostics

It can be easily confirmed if a KATA server will be facing those updater and KSN issues, by either checking the current proxy server configuration in the product's web interface:

if either of the listed ports 8080, 8090 or 8091 is used, then the KATA server is probably facing the issue.

Or alternatively you can run the iptables -nvL DOCKER-USER command and check if the number of the rejected packages in the corresponding rules for ports 8080, 8090 and 8091 steadily increases upon running update task in KATA:

Workaround & Solution

To avoid this issue use one of the following 2 options:

1. Do not use proxy server for KATA connections, configure direct internet connection for KATA CN nodes.
2. Use a proxy server on a different port, for example port 3128 is quite standard option in such cases.

Create backup of original files with same rights as it was before (you can check them with ll /etc/nginx/ssl command)

• Replace original files

• Restart nginx service

• Rights and owner of files should be the same

Problem Description, Symptoms & Impact

When trying to activate KES with valid License for KATA EDR (License contains Licensing object 184), Activation Task results in error "Internal data incompatible with this application".

Cause

The KATA Built-In KES component EDR (KATA) responsible for integration is not installed on target machine.

Diagnostics

1. In KSC -> Application properties, Endpoint Detection and Response (KATA) component version is listed as <N/A>, "Not installed" may be masked with "Not supported by license".
   
2. In registry, [HKEY_LOCAL_MACHINE\Software\Wow6432Node\KasperskyLab\\protected\KES.21.13\Installer\features]
   Key "AntiAPTFeature"=dword:00000001 is missing

3. In logs:
   in *.SRV.log (trace file) line for bundles::BundlesControllerImpl::GetNotInstalledFeatures lists  (1) and 1 is missing from bundles::InstalledFeaturesProvider::InstalledFeaturesProvider line

   09:58:42.239    0x2bf4    INF    bundles    bundles::BundlesControllerImpl::GetNotInstalledFeatures Not installed features (1): 1
09:54:03.788    0x2050    INF    bundles::InstalledFeaturesProvider::InstalledFeaturesProvider{ 3 (AVScannerAndCoreFeature)  0 (AdminKitConnectorFeature)  24 (AdvancedThreatProtectionFeature)  27 (AmsiFeature)  7 (ApplicationControlFeature)  17 (BehaviorDetectionFeature)  4 (CriticalScanTask)  23 (EssentialThreatProtectionFeature)  11 (ExploitPreventionFeature)  8 (FileThreatProtectionFeature)  19 (FirewallFeature)  5 (FullScanTask)  14 (NetworkThreatProtectionFeature)  12 (RemediationEngineFeature)  25 (SecurityControlsFeature)  18 (UpdaterTask)  22 (WholeProductFeature) }

   in *.SRV.log (trace file) for good machine bundles::InstalledFeaturesProvider::InstalledFeaturesProvider will list  1 (AntiAPTFeature)

   08:14:31.733    0x1e30    INF    bundles::InstalledFeaturesProvider::InstalledFeaturesProvider{ 3 (AVScannerAndCoreFeature)  0 (AdminKitConnectorFeature)  24 (AdvancedThreatProtectionFeature)  1 (AntiAPTFeature)  7 (ApplicationControlFeature)  15 (BadUSBAttackPreventionFeature)  17 (BehaviorDetectionFeature)  4 (CriticalScanTask)  6 (DeviceControlFeature)  23 (EssentialThreatProtectionFeature)  11 (ExploitPreventionFeature)  8 (FileThreatProtectionFeature)  5 (FullScanTask)  16 (MailThreatProtectionFeature)  14 (NetworkThreatProtectionFeature)  12 (RemediationEngineFeature)  25 (SecurityControlsFeature)  18 (UpdaterTask)  21 (WebControlFeature)  20 (WebThreatProtectionFeature)  22 (WholeProductFeature) }

Solution

1. Create Change Components Task for affected machines
2. Execute Task
3. Verify the component is installed.

Problem Description

A PCN connection request got stuck in the "Waiting" status and doesn't result in failure. The reboot doesn't help. It can happen if, for example, a SCN IP was specified instead of PCN.

Solution

1. Run the following commands as root:

   Cancel PCN connection request

   # console-settings-updater get /ipsec > /home/admin/ipsec.orig.json && chmod 777 /home/admin/ipsec.orig.json # console-settings-updater set /ipsec "{}"

2. Clear the browser cache. Reload the page. Alternatively, force the reload (Ctrl+F5 in FF).
3. The server status will revert to the Standalone solution.
4. Select the Distributed solution, specify the correct IP of PCN and retry to connect.

To restore config in case of error:

• CPU: 15 cores, 2.1 GHz or higher
• RAM: 32 GB
• HDD volume: 300 GB
• Two network adapters with 1 Gbit/s data transfer rate

Virtual machine settings: 

1. Only VMware ESXi hypervisor is fully supported.
2. Nested virtualization is enabled
3. Supported VMware ESXi versions 6.5, 6.7U3 or 7.0 hypervisor. 
4. Entire CPU clock rate reserved. For a minimum CPU clock this means 12*2100=25200 MHz reserved. For a clock rate higher than 2.21Hz, use the following formula to calculate the entire CPU clock rate: 12 * <clock rate in MHz>.
5. Entire RAM reserved (32 GB).
6. Expose hardware assisted virtualization to the guest OS check box selected.
7. Latency Sensitivity option set to High.
8. No Secure Boot.
9. The maximum number of simultaneously running virtual machines set to 12.

Please note, these cannot be checked from a debug report or from inside of the VM, as these settings are configured in a hypervisor.

Checking VMX file

Obtain a .vmx file of the respective sandbox VM. Demo video showing how to locate a .vmx file. Note, that in this video the goal is to modify the .vmx, and we only need to access it for reading, therefore, there is no need to unregister a VM from inventory as done in video. All the following lines in .vmx file must match exactly with the following two exceptions: 

• For sched.cpu.min, the value can be higher than 25200, see formula above.
• Line uefi.secureBoot.enabled might be absent, which is OK.

Checking number of slots

• In the Sandbox web interface window, select the Administration section.
• In the Guest virtual machines group of settings, in the Maximum simultaneous VMs field, number of simultaneously running virtual machines must equal 12.

This is short article about how to burn KATA ISO on USB drive.

For KATA 4.0/4.1 you need 8Gb USD drive, for 5.0/5.1 - 16Gb at least.

Details

1. Download latest Rufus release or Ventoy, how to use Ventoy described here or Balena http:// https://etcher.balena.io/
2. [Rufus part] Open it and select respective KATA ISO.
3. KATA 4.0/4.1 Rufus config should be like on screenshot below (Partition scheme GPT, Target system UEFI)

For KATA 5.0/5.1 (Partition scheme MBR, Target system BIOS or UEFI)

No option to change Local Administrator/Cluster Administrator in pseudo-graphic menu available by default .

Solution

a) Upgrade to 5.1

b) Follow steps:

1. Download an archive with WHL packets.

2. Upload it to KATA CN to /tmp/change_password.zip

3. Extract (we have no unzip shipped by default):

   echo -e "import zipfile\nwith zipfile.ZipFile('/tmp/change_password.zip', 'r') as z:\n  z.extractall('/tmp/')" | python3

4. Become root:

   sudo su

5. Confirm this is a right node:

   docker ps | grep  kedr_database_server

6. Install installer patch:

   installer-1.0-py3-none-any.whl

   pip3 install --ignore-installed --no-deps /tmp/installer-1.0-py3-none-any.whl

7. Install docker_utils patch:

   docker_utils-1.0-py3-none-any.whl

   pip3 install --ignore-installed --no-deps /tmp/docker_utils-1.0-py3-none-any.whl

8. Restrict changing password to root: 

   which kata-web-admin-change-password | xargs chmod 754

9. Change password by running:

   kata-web-admin-change-password

10. Enter new password in the prompt, no confirmations or validation will be given

KSN connection error on KATA web may appear.

Details

1. It could be fixed unless you don't have permanent KSN errors, you have to check it in ksn_proxy.log DEBUG level. Key word is ErrCount. If you don't see Errcount: 0 in log, then you don't have access to our KSN servers which are: 

• *.ksn.kaspersky-labs.com
• ksn-*.kaspersky-labs.com
• ds.kaspersky.com

       2. In order to fix this web error do as below

For KATA 4.0/4.1

           Under root at CN execute:

            * PT1.5S means 1,5 seconds, don't increase it more

          Then let's increase "errors_increase_threshold": 100 (actually you have to check ksn_proxy debug log in order to understand how much KSN connection errors you have and adjust this parameter accordingly)

              vim /etc/opt/kaspersky/apt-swarm/swarm_config.json

 "ksn": {

                "non_dl_formats": [ Numbered list

                    "GeneralHtml",

                    "GeneralTxt",

                    "ExecutableJs",

                    "ImageGif",

                    "ImageJpeg",

                    "ImagePng",

                    "ArchiveCab"

                ],

                "request_threads": 4,

                "timeout": "PT0.5S"  <<<<< set 1.5S

           Find

"ksn_proxy": {

                    "errors_increase_threshold": 2, <<<<< set 100

                    "errors_window_period": "10m",

                    "scraping_alert_for_interval": "1m",

                    "scraping_evaluation_interval": "30s"

For KATA 5.+/6.+

Use one line:

• console-settings-updater set --merge /kata/configuration/product/monitoring_prometheus '{"alert_settings": {"ksn_proxy": {"errors_increase_threshold": 100}}}'

   if value 100 doesn't help you may increase it to 150-200.

Or use long way: 

• Under root at CN execute 

  console-settings-updater get /kata/configuration/product/monitoring_prometheus | python3 -m json.tool > /tmp/monitoring_prometheus

• Make changes in /tmp/monitoring_prometheus (via vim or nano) by finding following block

"ksn_proxy": {
            "errors_increase_threshold": 100, <<<<<< put here value 100 instead of default 2

• Save file (ESC:wq!)
• Put changes back to container 

• console-settings-updater set /kata/configuration/product/monitoring_prometheus @/tmp/monitoring_prometheus

    If value 100 doesn't help you may increase it to 150-200.