All Activity

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

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

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

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

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

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

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

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

Problem KSWS detects certain exploit or malware frequently with N/A as an action in KSC reports. Solution 1. Download the latest patch for our product on the machine which detects the issue. 2. Download the latest Windows security updates on the machine to cover the potential vulnerabilities. 3. Make sure that the product has the latest updates from KLABs servers. 4. Check the events on the impacted server as sometimes KSC report shows "detection events" only with action N/A while KSWS already takes the action. i. If you find a blocking event, it’s probably N/A on the report (Cause the blocking event appears in the next warning event at the same moment). ii. If you couldn’t find a blocking event: a. Enable KSWS traces https://support.kaspersky.com/15618 b. In case the exploit or malware impacts system memory or the object path is .exe, download and run ProcMon (Process Monitor) https://support.kaspersky.com/common/diagnostics/10935 c. Restart the product’s agent. d. Simulate the issue and wait till correlated event being generated. e. Stop product’s traces and ProcMon. f. Collect export from server's events and GSI report including event logs and AVZ. https://support.kaspersky.com/common/diagnostics/3632#block7 g. Get KSWS reports if exists {c:\ProgramData\Kaspersky Lab\Kaspersky Security for Windows Server\11.0\Reports} i. Submit an issue to Kaspersky Support.

Problem After importing a custom certificate instead of a default self-signed one for accessing KSC 13 Web Console, you cannot reach Web Console. When using the default certificate, there is now issue with Web Console. Solution There are several causes and solutions for this issue: You might be using Internet Explorer or any other unsupported browser to access Web Console. So first we need to check if the browser is supported by KSC. Ref : https://support.kaspersky.com/KSC/13.1/en-US/96255.htm. You may use unsupported certificate's format. KSC Web Console can only work with PEM, not PFX format - https://support.kaspersky.com/KSC/13/en-US/191451.htm. If you use incorrect format, try to convert the certificate like described here: https://support.kaspersky.com/KSC/13/en-US/201428.htm. After converting the certificate you should be having 2 file formats ready: .crt and .pem. If you use correct browser and certificate, follow these steps: Run the Web Console installation package (KSCWebConsoleInstaller.12.0.<build number>.exe) again and follow the instruction here to upload the certificate and the key https://support.kaspersky.com/KSC/13/en-US/184363.htm. During the procedure when setting up the Trusted Administration Servers, you would be requested to provide the path for the trusted KSC's Administration Server certificate. Do note that this is a different certificate from the Web Console's certificate. By default, the Administration Server certificate file is stored in the ALLUSERSPROFILE%\Application Data\KasperskyLab\adminkit\1093\cert folder (ensure you correctly identify the path and also that the path is accessible). Once done, open the browser -> clear cache, cookies & history -> exit browser -> Open again. This should solve the problem.

This article applies to KEA 3.10+ Problem You need to install KEA on a host running MS Exhange 2013, 2016, 2019 server, and ensure compatibilty. Solution Add the following values into registry (should be done with "Local System" rights): [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\KasperskyLab\SOYUZ\4.0\Environment] "EnablePorts"=dword:00000001 "EnableSignatureLevel"=dword:00000001 "ServerProfile"=dword:0000000a In KEA policy, add the following telemetry exclusions: We highly recommend NOT to exclude UmWorkerProcess.exe. C:\Program Files\Microsoft\Exchange Server\V15\Bin\ComplianceAuditService.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\EdgeTransport.exe C:\Program Files\Microsoft\Exchange Server\V15\FIP-FS\Bin\fms.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\HostController\hostcontrollerservice.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\Microsoft.Exchange.AntispamUpdateSvc.exe C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\agents\HygieneMicrosoft.Exchange.ContentFilter.Wrapper.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\Microsoft.Exchange.Diagnostics.Service.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\Microsoft.Exchange.Directory.TopologyService.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\Microsoft.Exchange.EdgeCredentialSvc.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\Microsoft.Exchange.EdgeSyncSvc.exe C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\PopImap\Microsoft.Exchange.Imap4.exe C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\PopImap\Microsoft.Exchange.Imap4service.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\Microsoft.Exchange.Notifications.Broker.exe C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\PopImap\Microsoft.Exchange.Pop3.exe C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\PopImap\Microsoft.Exchange.Pop3service.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\Microsoft.Exchange.ProtectedServiceHost.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\Microsoft.Exchange.RPCClientAccess.Service.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\Microsoft.Exchange.Search.Service.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\Microsoft.Exchange.Servicehost.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\Microsoft.Exchange.Store.Service.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\Microsoft.Exchange.Store.Worker.exe C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\CallRouter\Microsoft.Exchange.UM.CallRouter.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\MSExchangeCompliance.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\MSExchangeDagMgmt.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\MSExchangeDelivery.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\MSExchangeFrontendTransport.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\MSExchangeHMHost.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\MSExchangeHMWorker.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\MSExchangeMailboxAssistants.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\MSExchangeMailboxReplication.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\MSExchangeRepl.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\MSExchangeSubmission.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\MSExchangeTransport.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\MSExchangeTransportLogSearch.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\MSExchangeThrottling.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Runtime\1.0\Noderunner.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\OleConverter.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\ParserServer\ParserServer.exe C:\Program Files\Microsoft\Exchange Server\V15\FIP-FS\Bin\ScanEngineTest.exe C:\Program Files\Microsoft\Exchange Server\V15\FIP-FS\Bin\ScanningProcess.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\UmService.exe C:\Program Files\Microsoft\Exchange Server\V15\FIP-FS\Bin\UpdateService.exe C:\Program Files\Microsoft\Exchange Server\V15\Bin\wsbexchange.exe

Problem If you found out that KSWS installations are somehow corrupted, and you're not able to remove it using conventional means (using misexec and/or appwiz.cpl), please do not use kavremover and/or mszap tools. Do not attempt removing the product manually as our goal is to determine the root cause of the product moving to this inconsistent state. Solution Please provide Kaspersky Support with the pertinent GSI log of the affected host and KSWS msi installer logs containing all the previous installations/modifications of the product that have led it to its current state. Locate and copy all msi files from the windows temp folder and the user temp folders: %systemroot%\Temp :\Users\<username>\AppData\Local\Temp Or simply collect all files from those folders from the affected machine. Also, clarify the exact timestamp when the issue have started to occur, or an approximate date and time when you have noticed the problem on the affected host for the first time, and when the last time was when the product was working just fine on the said host as well. Based on this data it will be potentially possible to provide an automated msiexec string to repair and/or removing the product automatically, and more importantly it will give us a better chance of determining the root cause.

If you are writing your own rules for YARA engine on Central Node, you may need available modules in YARA and engine version. Engine version is 3.7-3.11 in KATA 3.7.x Engine version is 4.10 in KATA 4.1 and KATA 5.0 Here's the list of modules: tests pe elf math time pe_utils magic hash dotnet dex For more info on modules, please refer to YARA documentation.

Problem How to configure KEA exclusions required for KEA installed on AD controllers to prevent its slowdown and high hardware resources consumption. Step-by-step guide Add the following registry key to affected AD controller registry: [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\KasperskyLab\SOYUZ\4.0\Environment] "EnablePorts"=dword:00000001 "EnableSignatureLevel"=dword:00000001 "ServerProfile"=dword:0000000a This operation should be done as Local System account (either locally via psexec or via .bat script (attached) deployed via KSC and Network Agent). Please restart Endpoint Agent service after this change. This option will make KEA exclude the ports: Exclusions WinRM Exclution DHCP Exclude DNS Exclude SSDP Exclude mDNS Exclude LLMNR Exclusions RPC/NetBios Exclude LDAP Exclude Kerberos Networking and RabbitMQ Exclude Delivery Optimization for Windows 10[244] Exclusions Microsoft SQL Server database management system (MSSQL) server Exclusions In Windows Server 2008 (and Windows Vista), the dynamic port range is 49152-65535, for both TCP and UDP.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Make sure the network agent of KSCCC has already been implemented: Download the Network agent installer of KSCCC from the web console. Click the installer and confirm that it has already has been installed and click OK. Finding the HDS site which is used by this NA： Run the klnagchk utility within C:\Program Files (x86)\Kaspersky Lab\NetworkAgent to check the network connection. By running the utility klnagchk you find that the server address received from HDS is e009.ksc.kaspersky.com Regarding the HDS:Hosted Discovery Service please refer to the online guide here: https://support.kaspersky.com/KSC/CloudConsole/en-US/200848.htm If Request timed out appears while using ping, then that means that the KSCCC server is not accepting incoming ICMP traffic. And the PSPing utility from MS KB: https://docs.microsoft.com/zh-cn/sysinternals/downloads/pstools also has the same output: We recommend to use PowerShell command Test-NetConnection Test-NetConnection e009.ksc.kaspersky.com -port 23100 Then if connection successfully established you will see the following response:

When administrator attempts to establish a connection between KS4O365 workspace and their Exchange online organization by doing the following in the administration console: Office 365 connection → Exchange Online connection → Grant Access → passes the consent validation algorithm but in the end gets the Error processing the request error: This error is usually triggered by the browser settings on the client host that is performing the consent validation. Upon executing consent validation algorithm we get the access token from Microsoft. Then we redirect browser to our web site's URL and attach access token as a cookie. Upon redirecting, cookie with access token is lost/blocked somehow, usually this is caused by one of the following reasons: Browser filters cookies on its own. For instance due to some extensions, browser settings, or due to some beta version of browser with paranoid default security settings. Some 3rd party program, for example a file anti-virus, is blocking access to the file with the browser's cookies on the local hard drive. Thus, the following action plan is suggested. Step-by-step guide Clear all history, cache and cookie in the web-browser, restart it and check the reproduction. If it doesn’t help, then please make sure that the same error occurs if you try to do the same operation in another web-browser supported by the product (https://support.kaspersky.com/KS4MO365/1.2/en-US/141858.htm) or in incognito mode of the browser. Also, temporarily disabling anti-malware solutions or any 3-rd party products that might be blocking/locking/inspecting browser's cookie files is called for. If the issue will persist, then please do the following: 1. Open Google Chrome web-browser. 2. Press F12 keyboard button. 3. Enable Preserve log option in Network tab. 4. Reproduce the whole scenario from the begging (log into business hub account) and the issue itself. 5. Make an error screenshot with time stamp. 6. Export Network debugging results to HAR-file. 7. Provide HAR-file + screenshot to the Kaspersky Support. Also we will be interested in the URL that will be shown when the error will pop-up in the browser.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. This article is about Kaspersky Endpoint Security for Windows (KES for Windows) This problem has been observed in KES 11.5, but may apply to other versions as well. Problem Sometimes the KES tray icon behaves unexpectedly: it appears twice or does not appear at all (the icon next to the Windows clock). Solution Reset the tray icons: Open regedit; Go to HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\TrayNotify; In the right pane, backup & delete the IconStreams Registry value; Now backup & delete the PastIconsStream Registry value; Close Registry Editor; Open Task Manager Use File -> Run new task menu item in Task Manager; Type Explorer in the "Create New Task" dialog and press Enter to restore Desktop. This should fix tray icons issues. The Registry values above represent the notification area icon cache which stores the tray icons for all apps. If this cache is corrupted, it may also prevent system icons from appearing in the tray.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. This article is about Kaspersky Endpoint Security for Windows (KES for Windows) Sometimes it is required to unregister KES from context menu of Explorer. Follow these steps: Disable self-defense of KES; Open CMD shell as admin; Run commands: regsvr32 /u C:\Program Files (x86)\Kaspersky Lab\Kaspersky Endpoint Security for Windows\x64\shellex.dll regsvr32 /u C:\Program Files (x86)\Kaspersky Lab\Kaspersky Endpoint Security for Windows\shellex.dll Process troubleshooting. To re-enable it, run in admin CMD: regsvr32 "C:\Program Files (x86)\Kaspersky Lab\Kaspersky Endpoint Security for Windows\x64\shellex.dll" regsvr32 "C:\Program Files (x86)\Kaspersky Lab\Kaspersky Endpoint Security for Windows\shellex.dll"

How to upgrade previously installed password protected KEA using KSC remote installation task. Step-by-step guide Edit attached file install_props.json, put there your password for already installed KEA; Put this file to folder on KSC containing files for creation of remote installation package for new KEA version as per screenshots below; Create on KSC package for remote installation; Start remote installation task on KSC.

Most of the time KEA core patches are cumulative and it is sufficient to install the newer one on top of the previous in order to fix new issues. However, sometimes, for troubleshooting purposes or otherwise, you would need to remove an existing patch. This is how it's done. Step-by-step guide In the Administration Console, go to Advanced → Remote installation → Installation packages; In the right frame, click Create installation package; Select Create installation package for specified executable file; Enter the name for the package and click Next; Click Select and specify the path to the MSP file with the patch. The file must be located in the folder with MSP and MSI files of the major application version; In the Executable file command line field enter the following: /i <GUID KEA> MSIPATCHREMOVE={GUID of Core} /qn Example of the path to uninstall KEA 3.9 Core 11: /i {B310DC3B-8C5A-4C9D-A054-DFEEF8549B9B} MSIPATCHREMOVE={3891229E-A660-4416-B662-F5ED41B7B771} /qn GUIDs of KEA msi and Core msp files can be found into properties of these files under Details tab in the Revision Number line Click Next→ Finish; Create a remote installation task with this installation package for a device or a group of devices; Run the task to remove the patch.

Problem Some users may face a rather unclear and not self-explanatory error when attempting to remotely install KEA for Linux: Remote installation has been completed with an error on this device: Installation error Error in PREIN scriptlet in rpm package epagent Error: Transaction failed Solution This error is specific to RHEL-based distributives which have SELinux. KEA for Linux does not support Enforcing SELinux mode, and thus requires SELinux to be either disabled, or set to Permissive mode. To set SELinux to permissive mode for current session(until reboot): setenforce Permissive To disable SELinux, in file /etc/selinux/config set SELINUX=disabled

Problem In some cases, it is possible to run a database upgrade task on the KSWS/KICS/KESS host, but despite the upgrade task successfully completing, the databases are still out of date. Solution Most probably product operates in UpdateBlackListOnly mode. This happens in cases when product is activated with activation code and is unable to reach our activation servers. Thus KSWS fails to receive/refresh activation ticket and downloads updates only for Blacklist. Possible ways to solve the problem: 1. Activate with a key file; 2. In case KSWS needs to be activated with the code make sure that either KSWS server is able to reach our public activation servers directly or set up KSC to act as activation proxy and make sure that KSWS server is able to reach KSC on TCP17000.

As the first step of troubleshooting of KEA, we recommend installing the latest core patch. However, sometimes such installation will fail. There are two popular causes of this: EULA is not accepted; KEA installation is protected with a password. This guide addresses both of these issues. # in Password Symbol Due to limitations in KSC, when creating a custom package for remote deployment in KSC, or editing package configuration file (.kpd) directly, if password contains "#" symbol, it won't work. Examination of saved package shows everything afterwards and including # is lost from command line. This is because in (.kpd) configuration files # is a sign of a single string comment. Thus # is invalid symbol and cannot be used in command line. Behavior is expected from KSC side and cannot be changed. We recommend not to use # in password. Step-by-step guide The following options need to be provided to the installer: disclaimer=1 This instructs the installer to accept the EULA. UNLOCK_PASSWORD=password This is required if the installation of KEA is protected with a password. Replace "password" with the actual value of the password. Local installation The resulting line for local installation may look like this: msiexec /p critical_fix_core9(private).msp disclaimer=1 UNLOCK_PASSWORD=password Remote installation The same options can be used when deploying remotely via KSC. Specify them as follows:

Step-by-step guide KATA 3.7.2 Connect to central node/sensor node which processing SPAN traffic via ssh; Proceed to Technical support mode; Become root with command: Turn on wrapCopy as text # sudo -i Create file /etc/suricata/capture-filter.bpf with line containing traffic filtering conditions (syntax is the same as in tcpdump conditions), below you can see filter for example: Example: Turn on wrapCopy as text # cat /etc/suricata/capture-filter.bpf not ((src 10.21.68.247 and dst 10.21.60.155 or 10.21.60.14 or 10.21.60.15 or 10.21.60.80 or 10.21.60.212 or 10.20.72.48 and port 1433) or (src 10.21.65.113 or 10.20.75.142 and dst 212.250.153.80 or 212.250.153.81 or 194.72.254.216 or 194.72.254.217 and port 22)) Change owner/group for created file with command: Turn on wrapCopy as text # chown kluser:root /etc/suricata/capture-filter.bpf Edit file /usr/bin/apt-suri-start, find line: Turn on wrapCopy as text /sbin/suricata -c /etc/suricata/suricata.yaml $OPTIONS || { And change it to: Turn on wrapCopy as text /sbin/suricata -F /etc/suricata/capture-filter.bpf -c /etc/suricata/suricata.yaml $OPTIONS || { Restart suricata.service with command: Turn on wrapCopy as text # systemctl restart suricata.service Check absence of errors in system journal related to suricata service restart with commands: Turn on wrapCopy as text # systemctl status suricata.service # journalctl -u suricata.service Done! KATA 5+ Connect to central node/sensor node which processing SPAN traffic via ssh; Proceed to Technical support mode; Become root with command: Turn on wrapCopy as text sudo -i Run the following command, replacing it with your rule with your rule in tcpdump syntax, for example "not ((src 10.10.0.1 or src 10.10.0.13 or src 10.10.0.11 or src 10.10.0.14) and (dst 10.10.6.13 or dst 10.10.6.11 or dst 10.10.6.12))":n on wrapCopy as text console-settings-updater set --merge /kata/configuration/product/preprocessor_span '{"traffic": {"storage_settings": {"bpf_filter": "your rule"}}}'

Problem There are slight differences when connecting devices to the Wi-Fi network configured via Kaspersky Endpoint Security for Mobile in Android 10. The main difference is that the connection to the target Wi-Fi network is made automatically through the product installed on the device and can't be forced manually via device settings. Step-by-step description The following scenario demonstrates the correct way to connect the device to a Wi-Fi network, as well as what behavior is expected. Setting up the target Wi-Fi network in the Kaspersky Endpoint Security for Android as usual – navigate to Wi-Fi section and add new network by specifying network SSID, network protection type and password: Apply the configured policy to the target mobile device with KESM installed and Android 10 (sync the product with the Security Center); When the policy applies, "Allow suggested Wi-Fi networks" notification from Android System appears (unless the mobile phone is located in the target Wi-Fi access zone): The user should open this notification and tap on ‘Allow’ / 'Yes' link. It should be done only once, when a new one network is added through the product; Depending on the conditions: If the target mobile device is not connected to any Wi-Fi networks, then the connection to the expected network is made immediately automatically (no further actions are required from the user); If the target mobile device is already connected to another Wi-Fi network (and it was made manually by the device owner via native mobile phone network settings), then the connection to the expected network will not be made until the user manually disconnects his device from the current Wi-Fi network ('forgets' this network). As soon as this happens, the device will automatically connect to the desired network configured through the product. If everything works as expected, then you’ll find an inscription near the network: ‘Connected via Kaspersky Endpoint Security’: Please note that if the device is still connected to another Wi-Fi network (which was added manually before) and the client just tries to connect to the target network configured through the product on his own (navigates to the ‘Network and Internet’ section – finds there the target network and taps on ‘Connect’ link), then it will be not possible to do that: connection settings from the product's policy will not be pushed and the password will be still required (obviously, if this network is protected by password): The connection will be established automatically as soon as the device owner disconnects their mobile phone / tablet from the previously used network on his own (applicable to the networks that were connected manually via device settings).