All Activity

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).

Description As part of proactive security, you may wish to add sha256 to block the execution of application or malicious applications without having the original source files. This article explains how to perform this action. How To Create a text file containing the sha256 you want to block. Use the AppRulesGenerator.exe app to generate an xml file: Import the generated .xml file into the KSWS policy: AppRulesGenerator.exe can be downloaded here.

Description After successful installation kesl-supervisor.service may refuse to start with the following error: kesl-supervisor.service: Control process exited, code=exited status=203 journalctl -xe command provide more information related this error ***** kesl-supervisor.service: Failed to execute command: Permission denied kesl-supervisor.service: Failed at step EXEC spawning /var/opt/kaspersky/kesl/install-current/etc/init.d/kesl-supervisor: ***** kesl-supervisor.service: Control process exited, code=exited status=203 kesl-supervisor.service: Failed with result 'exit-code'. Failed to start kesl. Root cause SElinux is enabled on the system and prohibits execution of the service. Solution You can check SELinux status by running: $ sestatus If SELinux is enabled, then use the dedicated online help article to disable, configure and re-enable it.

Sometimes one may need to enable transmitted traffic capturing in KATA (in example, for local testing of Suricata detections). Here's how to do it. Instructions for KATA 3.7.* In file /etc/modprobe.d/pf_ring.conf set enable_tx_capture=1. File should look like this: options pf_ring enable_tx_capture=1 min_num_slots=16384 Stop apt-preprocessor and suricata services: systemctl stop apt-preprocessor.service systemctl stop suricata.service Reload pf_ring module: rmmod pf_ring modprobe pf_ring Start apt-preprocessor and suricata back systemctl start apt-preprocessor.service systemctl start suricata.service Instructions for KATA 4.0/4.1 In file /etc/modprobe.d/pf_ring.conf set enable_tx_capture=1. File should look like this: options pf_ring enable_tx_capture=1 min_num_slots=16384 Stop docker service: systemctl stop docker Reload pf_ring module: rmmod pf_ring modprobe pf_ring Start docker back systemctl start docker Instructions for KATA 5.0 In file /etc/pf_ring/pf_ring.conf set enable_tx_capture=1. File should look like this: options pf_ring enable_tx_capture=1 min_num_slots=16384 Stop docker service: systemctl stop docker Reload pf_ring module: rmmod pf_ring modprobe pf_ring Start docker back systemctl start docker With these changes, KATA will capture and process both incoming and outgoing traffic.

Problem Sometimes it is necessary to replace the KSN proxy address in products like KSWS, KESS or KES after restoring KSC from backup or when Server moved to new Hardware. Unfortunately, there are no settings in the policy for this. Solution The corresponding option can be found in the properties of Installation packages node in KSC. See the effects of changing this value: Note that after changing these settings, you must also rebuild the Network Agent installation packages, even if the change is propagated to connected clients.

Все равно ситуация очень и очень странная, раньше не выдавало и тут вдруг с новой версией стало выдавать. Тоже Adguard пользуюсь и ниразу проблем с Касперский не было. Тоже склоняюсь, что попытка продвинуть свой блокировщик, который откровенно говоря работает не очень. В подсказке в приложении выдает, что якобы какие-то функции защиты не будут доступны в такой связке. Вот тут и напрашивается какие именно???

Problem In some cases KESMac is not able to start protection components: Or, the status "Allow encrypted traffic to be inspected" is not changing: Solution 1) Please get acquainted with the article https://support.kaspersky.com/kis20mac/error/15031#block1; 2) If the article above did not help, try to remove the FireFox user's profiles directory via Terminal: rm -rf ~/Library/Application\ Support/Firefox/Profiles Removal of the Firefox profiles deletes the user's data stored in the browser, like saved logins and passwords, visited websites and other. Make backup if needed. Then, reboot the host and check the issue reproduction.

The KESMac 12 and the KESMac 11.3 patch C allows adding particular processes into the trusted section named Trusted Applications. The both filesystem and network activity of which can be ignored by the product increasing performance. Please, however, note that this could be potentially risky. https://support.kaspersky.com/KESMac/11.3_adminguide/en-US/194142.htm Problem This article will describe a few ways to configure KES for Mac to exclude some of the software from the scope of the product. Solution Trusted applications In order to have an ability to exсlude an application from scanning with KES, a function of Trusted Applications available in Kaspersky Endpoint Security for Mac can be used: The Trusted applications section as seen in the policy creation wizard. Naturally, it can be configured later by modifying the policy. Update the plugin to at least version 11.3.0.33 to get the new functionality. In some specific cases it might be required to put several binaries to Trusted Applications simultaneously in order to take effect. So, a final solution might include several path-based exclusions accompanied by a few BundleID-based ones. Trusted Applications are only available for configuration via KSC policy; i.e. it is currently impossible to add application to exclusions having no KSC installed. Additionally, an appropriate application control plug-in for KESMac must be downloaded and installed on the KSC prior to using Trusted Application functionality. It can be found on the corresponding download page. Common exclusions for developers It's suggested excluding the following paths: "/Library/Developer/CommandLineTools" and "/Library/Toolchains" for the standard developers' utilities, as well as the "/Applications/Xcode.app/*" for the XCode. At the same time, in case you use alternative tools, contact Kaspersky Support to get the exact paths for further exclusions. Excluding TCP 443 from port monitoring Additionally, in case of HTTPS-connectivity issues, unchecking port 443 in Monitored ports may also help: