Overview

Проблема При попытке подключиться к песочнице через SFTP, соединение закрывается сразу после ввода пароля Решение В Technical Support Mode отредактировать файл /etc/ssh/sshd_config Строку ForceCommand /usr/bin/apt-restricted-ssh заменить на #ForceCommand /usr/bin/apt-restricted-ssh Строку Subsystem sftp /usr/libexec/openssh/sftp-server заменить на Subsystem sftp /usr/lib/openssh/sftp-server Сохранить файл (Ctrl+S, Ctrl+X) и перезапустить сервис sshd sudo systemctl restart sshd После чего можно загружать файлы через SFTP в /tmp

The article is applicable to KEA 3.x (any cf) as part of [KATA+]EDR solution. 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: Log Name: System Source: Schannel Event ID: 36871 Level: Error Description: A fatal error occurred while creating a TLS client credential. The internal error state is 10013. In KEA traces you should be able to find the following lines: SSL Error: WINHTTP_CALLBACK_STATUS_FLAG_SECURITY_CHANNEL_ERROR internal error kata.compression=true kata.sync_period=300 kata.certificate=[...] kata.servers=10.231.132.146:0; syslog.enable=false syslog.type=CEF syslog.server=: 0 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 Alternative cause Recently it was found out that the problem persists on desktops (Win 10) with all the TLS1.2 keys and ciphers in place, when there is "CryptoPRO CSP" software installed, specifically following versions: CryptoPRO CSP - 4.0.9944 CryptoPRO CSP - 4.0.9958 1.3. Solution For KEA 3.11 and older - Upgrade KEA to the latest version. Ensure "КриптоПро CSP" is not listed in installed applications For Windows 2012R2 - install KB2919355 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 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 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; 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/ Reboot for the settings to take effect - !Restart required!

1.1. Scenario: 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. 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. 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/ Location of the certificate = /etc/pki/tls/certs/ File name = kata.crt Copy the kata.crt to /tmp/ and change the permissions to download the file. Configure the destination NAT from Firewall towards KATA sensor internal IP for port 443. Configure the KES (Out-of-office) policy and add the Public FQDN/IP in the connection settings along with the sensor certificate. 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.

Description and cautions 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: 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). 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

Collect script output is a must for most KATA-related issues and questions. Which information? Which file? How to find/interpret? Example КАТА version and role: CN/PCN/SCN/Sensor /config/apt-va File contains the version and role in human-readable form. Also, you can see if the node was upgraded from previous KATA versions in 'migrate' line Primary CN [product] name=kata-cn title=Kaspersky Anti Targeted Attack Platform version=3.5.0-1269 release=release master = yes sensor = yes timestamp = 1568700994 migrate = cn_role = pcn Standalone CN [product] name=kata-cn title=Kaspersky Anti Targeted Attack Platform version=3.6.1-713 release=release master = yes sensor = yes timestamp =1572445307.01 migrate = cn_role = cn Sensor node [product] name=kata-cn title=Kaspersky Anti Targeted Attack Platform version=3.6.1-713 release=release master = no sensor = yes timestamp =1583845362.98 migrate = cn_role = Virtual or hardware? /environment/dmesg.txt OR /var/log/messages OR /var/log/boot.log Search for "DMI" entries in the file. Physical server [ 0.000000] DMI: HPE ProLiant DL560 Gen10/ProLiant DL560 Gen10, BIOS U34 06/20/2018 Virtual server [ 0.000000] DMI: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016 CPU /environment/cpuinfo.txt Scroll to the bottom of the file. Each "processor" listed is not a physical core, but virtual "thread", so, i.e. 8-physical core CPU with hyper-threading will have 16 CPUs in the file. Keep in mind that CPUs are counted from 0, so for 16-thread CPU last entry will have number 15. processor : 15 vendor_id : GenuineIntel cpu family : 6 model : 79 model name : Intel(R) Xeon(R) Platinum 8158 CPU @ 3.00GHz stepping : 0 microcode : 0x2000050 cpu MHz : 2992.968 cache size : 25344 KB physical id : 0 siblings : 16 core id : 15 cpu cores : 16 apicid : 15 initial apicid : 15 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch ibrs ibpb stibp fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 invpcid rtm rdseed adx smap xsaveopt arat spec_ctrl intel_stibp arch_capabilities bogomips : 5985.93 clflush size : 64 cache_alignment : 64 address sizes : 43 bits physical, 48 bits virtual power management: RAM /environment/memory.txt File shows free command output. Values are in megabytes, pay attention to 'total' and 'available' columns. NB! Ignore 'free' column: despite of it's name, it doesn't actually show free RAM, 'available' column does it. total used free shared buff/cache available Mem: 197308 63869 3634 6738 129804 125558 Swap: 0 0 0 HDD /environment/hdd.txt Pay attention to partitions /dev/sda* and /dev/sdb*. If /dev/sdb* partition is present, you are dealing with two-disk installation, otherwise, it's one-disk installation. NB! Always check HDD partitions size and available free space! KATA needs a LOT of disk space to work correctly. Most important partitions are: /dev/sda4 1.2T 894G 224G 80% /data ← Used for processing queues and quarantine, main partition for KATA /dev/sdb1 2.7T 1.4T 1.3T 52% /data/var/lib/kaspersky/storage ← Used for EDR data: (telemetry from Endpoint Sensors) Filesystem Size Used Avail Use% Mounted on /dev/sda3 367G 14G 335G 4% / devtmpfs 126G 0 126G 0% /dev tmpfs 126G 252K 126G 1% /dev/shm tmpfs 126G 4.1G 122G 4% /run tmpfs 126G 0 126G 0% /sys/fs/cgroup /dev/sda2 232M 32M 189M 15% /boot /dev/sda1 237M 5.5M 232M 3% /boot/efi /dev/sda4 1.5T 435G 955G 32% /data /dev/sdb1 2.7T 1.4T 1.3T 52% /data/var/lib/kaspersky/storage tmpfs 26G 0 26G 0% /run/user/998 tmpfs 26G 0 26G 0% /run/user/1002 tmpfs 26G 0 26G 0% /run/user/1001 DNS name /environment/hostname.txt File contains exactly the hostname of the machine. kata-cn IP address /environment/ipa.txt /environment/ifconfig.txt Both files contain info about network interfaces and assigned IP addresses. ifconfig command is considered obsolete by community, but it can be useful: it helps to recognize SPAN interfaces. SPAN interfaces usually don't have IP address assigned, but have a lot of traffic. Also, SPAN interfaces always are in promiscuous mode: <UP,BROADCAST,RUNNING,PROMISC,MULTICAST> ipa.txt 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:50:56:9f:0e:77 brd ff:ff:ff:ff:ff:ff inet 10.200.178.85/23 brd 10.200.179.255 scope global ens192 valid_lft forever preferred_lft forever inet6 fe80::250:56ff:fe9f:e77/64 scope link valid_lft forever preferred_lft forever 3: ens224: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:50:56:9f:db:4d brd ff:ff:ff:ff:ff:ff inet6 fe80::250:56ff:fe9f:db4d/64 scope link valid_lft forever preferred_lft forever ifconfig.txt ens192: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.200.178.85 netmask 255.255.254.0 broadcast 10.200.179.255 inet6 fe80::250:56ff:fe9f:e77 prefixlen 64 scopeid 0x20<link> ether 00:50:56:9f:0e:77 txqueuelen 1000 (Ethernet) RX packets 604911116 bytes 747444631331 (696.1 GiB) RX errors 0 dropped 26 overruns 0 frame 0 TX packets 368814032 bytes 353073760300 (328.8 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ens224: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet6 fe80::250:56ff:fe9f:db4d prefixlen 64 scopeid 0x20<link> ether 00:50:56:9f:db:4d txqueuelen 1000 (Ethernet) RX packets 437 bytes 135823 (132.6 KiB) RX errors 0 dropped 1125 overruns 0 frame 0 TX packets 8 bytes 656 (656.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 19418334689 bytes 12053991732736 (10.9 TiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 19418334689 bytes 12053991732736 (10.9 TiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 SPAN interface eno2: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST> mtu 1500 inet6 fe80::42f2:e9ff:fecc:4343 prefixlen 64 scopeid 0x20<link> ether 40:f2:e9:cc:43:43 txqueuelen 1000 (Ethernet) RX packets 122540697216 bytes 104768065608116 (95.2 TiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 7 bytes 586 (586.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device memory 0xbd5a0000-bd5bffff Sandbox server information /config/apt-agents-id Bottom part of the file contains info about connected sandbox nodes: IP addresses, cert fingerprints and states: Sandbox may be connected, but disabled. [sandbox_node.sandbox1] host = 172.16.0.151 enable = yes fingerprint = C0:15:18:C8:11:46:11:BC:23:50:16:95:10:2D:FF:FA:4E:06:21:90:20:AA:CC:36:53:27:B8:BF:CF:5A:1A:9C Enabled integrations(SPAN, ICAP, etc) /config/preprocessor.conf Preprocessor is the component responsible for main KATA integrations: SPAN, SMTP, ICAP, POP3. You should look for corresponding section in preprocessor.conf: SPAN: [traffic] SMTP: [smtp_proxy] ICAP: [icap] POP3: [pop3] For each section, there's a line defining whether this integration is enabled: enable=yes/no Other integrations like KSMG/KLMS/API aren't easy to check by collect script output Only SPAN is enabled [app] use_syslog=no trace_level=ERR cache_socket=localhost:6379 collector_url=http://centralnode:8081/apt/collector license_remote=no #this section applicable for sections: pop3, smtp_proxy and for traffic section but only for smtp preprocessor [mail] extract_urls=yes #file extensions of attachments which format recognizer is not used for file_extensions=dll,exe,com,java,js,jse,wsf,wsh,vbs,vbe,msi,deb,rpm,apk,zip,7z,rar,iso,cab,jar,bz2,gz,tgz,ace,arj,dmg,xsr,rtf,pdf,msg,eml,vsd,vdx,xps,xsn,odt,ods,odp,sxw,doc,dot,docx,docb,dotx,docm,dotm,xls,xlt,xlm,xla,xll,xlw,xlsx,xltx,xlsm,xltm,xlam,xlsb,ppt,pot,pps,ppam,sldx,sldm,thmx,pptx,potx,pptm,potm,ppsx,ppsm,pub,html,htm,hta,swf,jpg,jpeg,gif,png,tiff,chm,mht,cpl,ocx,pif,scr,bat,cmd,ps1,lnk,reg,msu,msp,z [traffic] enable=yes network_interfaces=ens6f0,ens6f1,ens5f1,ens5f0,ens5f3,ens5f2,eno1,ens3f1,ens3f0 pcap_snaplen=1600 pcap_cores= pcap_filter= checksum_validation=no buffer_size_limit=4096 tcp_threads_number=16 enable_dns=yes enable_http=yes enable_ftp=yes enable_ssl=yes enable_smtp=yes ftp_data_expired_timeout_in_seconds=60 ftp_data_supposed_max_size_in_bytes=10485760 [ksn] enable=yes #possible values of type are KSN or KPSN type=KSN timeout=500 non_dl_formats=GeneralHtml,GeneralTxt,ExecutableJs,ImageGif,ImageJpeg,ImagePng,ArchiveCab ksn_adapter_interfaces= # Change cache entries only you know what are doing. # 0 - disables cache cache_entries=3600100 request_threads=4 [snmp] enable=yes master_agent_address=tcp:localhost:705 ping_interval_in_seconds=15 [icap] enable=no listen_interfaces=ens3f3:1344,ens3f2:1344,eno2:1344 allow204=yes max_connections=5000 respmod_url=av/respmod header_client_ip=X-Client-IP header_client_port=X-Client-Port extract_user=no header_username=X-Authenticated-User base64_decode_username=yes [filter] file_size_limit=100000000 dns_lookup_enable=yes dns_timeout=500 html_filter=/var/opt/kaspersky/apt/update/bases/htmlre.txt [snort] enable=yes alerts_socket=/var/log/kaspersky/snort/snort_alert [pop3] enable=no server= port= user= password= cipher_list=ALL:!aNULL:!eNULL:!LOW:!EXP:!MD5:!DSS:!KRB5:!PSK:!RC4:!SRP:!CAMELLIA:!IDEA:!SEED:!3DES:@STRENGTH:!kDH:!kECDH encrypted=yes check_interval_in_seconds=2 accept_any_certificates=no accept_untrusted_self_signed_certificate=yes process_msgs_per_session=3000 request_timeout_in_seconds=60 [smtp_proxy] enable=no max_threads=20 socket_in=inet:10025@127.0.0.1 #RFC 1123 suggests 10 min timeout_in_seconds=600 [stat_engine] enable=yes db=kafka:centralnode:9092?topic=network oltp_bulk_size=1000 subnets= taa_skip_header_proxy_auth=status-code: 407 oltp_raw_data_limit=0 [proxy] enable=no bypass_local_addresses=yes host= port= user= password= Connected Endpoint Sensors /config/aapt_info You can find the beginning of Endpoint Sensors list by searching for 'Agent Status'. To find the number of connected sensors, you need to calculate lines; but it's not easy to automate it as the lines don't have obvious unique grep-able attribute. However, using 'Microsoft Windows' will give you enough precision(it will give a few extra matches from last detections info). Sample entry for 1 agent ae5290b1-c490-404b-beec-ee553d5d64ee | DXB00079395.*.corp | 2019-09-24 08:41:51.579011 | 10.56.14.170 | 3.5.435.0 | 2019-09-23 03:21:26.883616 | 2019-09-24 03:15:28.642816 | t | Microsoft Windows 10 | | | 2346c7a2-a395-4dc4-bc5c-ea99fa488386 | 6 | 568b01b8-4497-decf-7f8c-671bbf8ad8cc KSN/KPSN connection /config/preprocessor.conf From collect script, you can only determine whether KATA is set up to receive verdicts from the cloud, and understand which sort of cloud it is - global KSN or private KPSN. Look for [ksn] section in preprocessor.conf, it's pretty self-explanatory. Keep in mind that you have a tool which allows you to check KSN availability https://forum.kaspersky.com/blogs/entry/86-how-to-check-ksn-availability-on-kata-cn-katakedre/ [ksn] enable=yes #possible values of type are KSN or KPSN type=KSN

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

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

To create a Certificate Signing Request file using the openssl utility: 1. Prepare a file named sandbox.config with the following contents: [req] default_bits=2048 prompt=no default_md=sha256 req_extensions=req_ext distinguished_name=dn [dn] C=AE ST=North L=Dubai O=ABC LAB OU=IT Security emailAddress=security@abc.lab CN=katasb.abc.lab [req_ext] subjectAltName=@alt_names [alt_names] DNS.1=katasb.abc.lab 2. Create a private RSA key with the PEM extension (without a passphrase): #openssl genrsa -out sandbox.key 2048 3. Create a Certificate Signing Request using the following command: #openssl req -new -sha256 -key sandbox.key -out sandbox.csr -config sandbox.config 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 Note: you might need to allow the connection using WinSCP (https://forum.kaspersky.com/topic/how-to-copy-files-tofrom-kata-katakedre-37146/ section 1.2). 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: #openssl x509 -inform PEM -in sandbox.cer -out sandbox.crt 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. #cp -p /etc/nginx/ssl/server.crt /etc/nginx/ssl/server.crt.orig #cp -p /etc/nginx/ssl/server.key /etc/nginx/ssl/server.key.orig 7. Replace the original files with your files #cat my_cert.crt > /etc/nginx/ssl/server.crt #cat my_cert.key > /etc/nginx/ssl/server.key 8. Rights and owner of the files should be same #ll /etc/nginx/ssl -rw-r----- 1 root klusers 2008 Feb 8 15:51 server.crt -rw------- 1 root root 1732 Feb 8 15:51 server.key 9. If the rights are different for the new files, then use the below command to change the rights and ownership #chmod 640 server.crt #chown root:klusers server.crt #chmod 600 server.key #chown root:root server.key 10. Restart nginx service #systemctl restart nginx.service 11. Open the KATA SB Web UI using the hostname and verify the certificate.

Don't forget to install 6.0.1 and 6.0.2 patch, which fixes some bugs in ICAP integration. Description and cautions Since we have new ICAP working modes, presented in KATA 6.0 - https://support.kaspersky.ru/KATA/6.0/en-US/247269.htm , we would like to show you, how to configure such integration on example of squid proxy server. Added ICAP integration with feedback. ICAP integration with feedback can work in two modes: Standard scan. In standard scan mode, the object is scanned by all supported technologies. While being scanned by the Sandbox component, the object remains available. If a threat is detected, the object is blocked. Advanced scan. In the advanced scan mode, objects are scanned by all supported technologies. While being scanned by the Sandbox component, the object is not available. If a threat is detected, the object is blocked. Details Reminder - this is just an example, but working one:) Squid configuration part Assuming you already have squid installed with default configuration (of course, yours could be different according to your infrastructure), add following lines in the end of /etc/squid/squid.conf (surely, change the IP address to yours) icap_enable on adaptation_send_username on adaptation_send_client_ip on icap_service kata_req reqmod_precache icap://10.68.56.219:1344/av/reqmod icap_service kata_resp respmod_precache icap://10.68.56.219:1344/av/respmod adaptation_access kata_req allow all adaptation_access kata_resp allow all icap_service_failure_limit -1 The only thing we changed here as well is at the start of squid.conf - source subnet, in order to adapt server to our Lab # # Recommended minimum configuration: # # Example rule allowing access from your local networks. # Adapt to list your (internal) IP networks from where browsing # should be allowed acl localnet src 10.68.56.0/23 We also recommend to add these lines below as well, so you would be able to analyze ICAP logs logformat icap_squid %tl %6tr %rm %ru %rp %6icap::tr %>a %icap::to/%03icap::Hs %icap::rm %icap::ru %un %icap::<A %icap::<st %icap::>st %icap::<bs %icap::>h %icap::<h %icap::tr %icap::tio icap_log /var/log/squid/icap.log icap_squid ICAP logs are located at /var/log/squid/icap.log and look like So the whole picture should look like this Testing part If standard scan mode is enabled, let's check on KATA side, how it looks like in /var/log/kaspersky/services/preprocessor_icap/preprocessor_icap.log grep --color 'blocking_simple mode' | grep 'verdict' In this example we can see that from URL file was scanned with verdict: clean (whitelist) 09:41:46.697 INF 137781 server/source/file_handler_respmod.cpp:435 [sid: 0x0000004d] RESPMOD: Finish processing file in blocking_simple mode (request url: 'r3.o.lencr.org', size: 503, filename: 'baf664a8a7841e1d057f5ab0da58bcf0', uuid: 5cc2d18781924f98b6e4961494125616, md5: baf664a8a7841e1d057f5ab0da58bcf0, format: GeneralBin), processing time: 0.147ms, verdict: clean (whitelist) File from URL with verdict: clean (cached) 09:40:14.476 INF 137778 server/source/file_handler_respmod.cpp:435 [sid: 0x0000004a] RESPMOD: Finish processing file in blocking_simple mode (request url: 'detectportal.firefox.com/success.txt?ipv6', size: 8, filename: 'success.txt', uuid: 25f155a67eff4a4a90b33dbbb4f3367c, md5: ae780585f49b94ce1444eb7d28906123, format: GeneralTxt), processing time: 0.124ms, verdict: clean (cached) URL with verdict: good (KSN) 09:42:37.334 INF 137780 server/source/file_handler_reqmod.cpp:187 [sid: 0x0000004c] REQMOD: Finish processing url in blocking_simple mode ('box.kaspersky.com'), processing time: 3ms, verdict: good (KSN) File from URL verdict: clean (scanned) 09:35:14.691 INF 137770 server/source/file_handler_respmod.cpp:435 [sid: 0x00000042] RESPMOD: Finish processing file in blocking_simple mode (request url: 'detectportal.firefox.com/success.txt?ipv4', size: 8, filename: 'success.txt', uuid: 4c87c81cf3d543ceb6694d917329d2b8, md5: ae780585f49b94ce1444eb7d28906123, format: GeneralTxt), processing time: 124.894ms, verdict: clean (scanned) URL with verdict: bad (KSN) 10:05:18.354 INF 137802 server/source/file_handler_reqmod.cpp:187 [sid: 0x00000062] REQMOD: Finish processing url in blocking_simple mode ('kaspersky.com/test/wmuf'), processing time: 146ms, verdict: bad (KSN) If advanced scan mode is enabled, let's check on KATA side, how it looks like in /var/log/kaspersky/services/preprocessor_icap/preprocessor_icap.log grep --color 'blocking_advanced mode' | grep 'verdict' Picture is pretty the same, but from browser side you will see that object is blocked/inaccessible 10:54:01.341 INF 139635 server/source/file_handler_reqmod.cpp:187 [sid: 0x0000000e] REQMOD: Finish processing url in blocking_advanced mode ('bug.qainfo.ru/test_cloud/wmuf'), processing time: 27ms, verdict: bad (KSN) 10:54:20.467 INF 139635 server/source/file_handler_reqmod.cpp:187 [sid: 0x0000000e] REQMOD: Finish processing url in blocking_advanced mode ('secure.eicar.org:443'), processing time: 0ms, verdict: good (KSN) 10:50:45.303 INF 139632 server/source/file_handler_respmod.cpp:435 [sid: 0x0000000b] RESPMOD: Finish processing file in blocking_advanced mode (request url: 'ocsp2.globalsign.com/gsorganizationvalsha2g3', size: 1461, filename: 'gsorganizationvalsha2g3', uuid: f88dd52252da4fdf8aaabc3aafdbdb0a, md5: 9a3ec48893b2952f013e03311b878e18, format: GeneralBin), processing time: 0.346ms, verdict: clean (whitelist) During tests at KATA web UI you should see activity on ICAP dashboard and under Security office we can see two alerts, generated after our tests (10.68.56.227 is squid IP address) In real world, of course, you will see other detects as well, for instance, on infected objects and malicious URLs.

Versions Applicable to versions above 5: 5.0, 5.1, 6.0, 6.0.1, etc. 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. basename -a /data/volumes/s3proxy/log-history/2024* 2024-01-01-13-55-03 2024-01-17-12-00-14 2024-01-17-12-05-14 To access these logs, use the respective zless; zgrep; zcat tools. For example: zcat /data/volumes/s3proxy/log-history/2024-01-17-12-05-14 2024-01-17 12:00:59.924639 info apt-history: New IDS alert: {id: 63, importance: High, hidden: False, rule_id: 51310592, excluded rule: False, src: 18.156.136.240:80, dest: 10.63.100.252:2198, bases_version: 202401170033} Bonus: you can also use these tools to read rotated logs of kataservices in /var/log/kaspersky/services/: zgrep "FileNotFoundError" /var/log/kaspersky/services/web_backend/web_backend.log.1

Versions Applicable to versions later than 5.0, 5.1, 6.0, 6.0.1, etc. 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: sudo su console-settings-updater get /deploy/deployment_api/nodes | python3 -m json.tool > /tmp/nodes Open the saved file for editing: vim /tmp/nodes Locate the desired network_settings, ifaces node, change the values tat you need to change: { "cc2cx0fltsjmxolid99p5loen": { "id": 1, "hostname": "1.srv.node1.node.dyn.kata", ... "network_settings": { "ifaces": [ { "iface_name": "ens160", "configuration_type": "static", "span": false, "address": "10.68.56.215", "netmask": "255.255.254.0", "gateway": "10.68.56.1", "mac": "00:50:56:a5:39:f6" }, { "iface_name": "ens192", "configuration_type": "static", "address": "100.100.100.100", "netmask": "255.255.255.0", "gateway": "100.100.100.1", "mac": "00:50:56:a2:5a:f6" } ] } } } Save your changes and exit Vim. Verify that the JSON structure is valid (the command returns no errors): cat /tmp/nodes | python3 -m json.tool Import the modified settings back: console-settings-updater set /deploy/deployment_api/nodes @/tmp/nodes

Description 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

Scenario: 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.

Description and cautions One may need to change the admin account's password (the account used for SSH login). KATA 5.0 For KATA 5.0 this article is not applicable. No option to change Local Administrator/ Cluster Administrator in pseudo-graphic menu available by default in 5.0 See https://forum.kaspersky.com/topic/how-to-reset-kata-web-administrator-password-in-kata-50-katakedre-36844/ Details In case of standalone Central node: Login to the web-interface of the CN. Enter admin credentials (used for SSH login). Go to admin account > change password as per below In case of Distributed deployment (PCN and SCN): Login to the web-interface of PCN. Enter admin credentials (used for SSH login). Go to admin account -> change password Login to SCN via SSH and change using the pseudographic menu ("Change cluster admin password..." option)

Problem 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. Error root@1.srv.node1.node.dyn.kata:/home/admin# mount -t nfs 10.225.62.41:/mnt/NFS/KXDR /mnt/nfs mount: /mnt/nfs: bad option; for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program. Solution Install packages manually via dpkg in the following order to add NFS support: dpkg -i /home/admin/libtirpc-common_1.2.5-1_all.deb dpkg -i /home/admin/libtirpc3_1.2.5-1_amd64.deb dpkg -i /home/admin/keyutils_1.6-6ubuntu1_amd64.deb dpkg -i /home/admin/libnfsidmap2_0.25-5.1ubuntu1_amd64.deb dpkg -i /home/admin/rpcbind_1.2.5-8_amd64.deb dpkg -i /home/admin/nfs-common_1.3.4-2.5ubuntu3.5_amd64.deb

Problem description: 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: Settings section #console-settings-updater get /kata/configuration/product/preprocessor_span | python3 -m json.tool | grep \"traffic\" -A 23 "traffic": { "buffer_size_limit": 4096, "checksum_validation": false, "enable": true, "enable_dns": true, "enable_ftp": true, "enable_http": true, "enable_smtp": false, "enable_ssl": true, "ftp_data_expired_timeout": "PT60S", "ftp_data_supposed_max_size_bytes": 10485760, "iface_groups": [ { "ifaces": [ "ens192" ], "core_id": null } ], "pcap_filter": "", "pcap_snaplen": 1600, "pcap_timeout": 10, "tcp_threads_number": 16 }, Example disable SMTP, enable the rest #console-settings-updater set --merge /kata/configuration/product/preprocessor_span '{"traffic": {"enable_dns": true, "enable_ftp": true, "enable_http": true, "enable_smtp": false}}' Example change #console-settings-updater get /kata/configuration/product/preprocessor_span | python3 -m json.tool > /tmp/preprocessor_span.json #vim /tmp/preprocessor_span.json #console-settings-updater set /kata/configuration/product/preprocessor_span @/tmp/preprocessor_span.json

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

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

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

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

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

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

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

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