Versions

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.

Problem

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

Solution

Become root, save the nodes settings:

Open the saved file for editing:

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

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

Import the modified settings back:

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

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

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

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

Problem

You may encounter issues with KEA that may include:

• Excessive resource consumption
• Freezes, crashes
• etc.

Solution

Install the latest available core patch.

To install patch using KSC or locally use the following keys, /qn can be added for silent install as usual

When installing on servers it is advisable to use additional SERVERPROFILE=1 key for optimized performance (works for core patches starting from CF8 for KEA 3.12 and newer)

For password-protected installations additional key is needed:

For detailed info see article https://forum.kaspersky.com/topic/how-to-install-patches-on-password-protected-kea-kaspersky-endpoint-agent-38148/

Things to keep in mind:

• All Core patches are cumulative; That means all previous fixes are included.
• Newer KEA versions include fixes done in previous versions.
• It's not always necessary to keep KEA at latest core, but it's worth starting your troubleshooting with installing the latest one.

About

This article contains the best way of upgrading KEA 3.9 to the last KEA version avoiding possible known issues.

Procedure

• Disable Password-protection and Self-Defense in KEA policy, lock the settings. Ensure that policy is applied on all devices.
• Upgrade KEA plug-in on the KSC side. Recreate KEA policy.
• Prepare installation package:
   - copy KEA distributive to KSC;
   - copy KEA Core-patch into the same folder;
   - copy KEA3.9_upgrade_script.zip into the same folder;
  
   - modify the last part of the script specifying the correct patch name (optional). Uncomment the last string if you want to install the patch right after KEA installation:
  
• Create an installation package on KSC
    →  → 
• Create and start "Install Application Remotely" task from KSC;
• Wait for successful completion;
• Enable Password-protection and Self-Defense in KEA policy after the upgrade is done.

Upgrade Script:KEA3.9_upgrade_script.zip

This scenario helps to avoid possible known issues with KEA 3.9 upgrade.

Rarely, even the script doesn't work.
The cause of it - KEA 3.9 Self-Defense. The files and services are marked for deletion but can't be deleted.
So, if the script doesn't help you - the only possible way to complete the upgrade, unfortunately, is the reboot.

The scenario is applicable for KEA version 3.10 and above.

There is no built-in feature to perform Yara-scan using KATA/EDR Expert 3.7.2. But if necessary, it's possible to perform it using KEA 3.10 and above.

Yara-scan using the Command line

Requirements:

• KEA 3.10 (and above) installed
• Files with Yara-rules (*.yara; *.yar)

Scenario:

1. Ensure that KEA is installed and running;

2. Run the Yara-scan

   "C:\Program Files (x86)\Kaspersky Lab\Endpoint Agent\agent.exe" --scan-yara --path c:\rules --folder c:\files --scan-files yes

   Syntax

   --path [PATH] - the location of yara-files
   --folder [PATH] - the scope of scanning (e.g. C:\ to scan all files on the C drive and subfolders)

3. Results will be listed on the CLI

Yara-scan using KATA/EDR Web-UI

Alternatively you can perform the commend using "Run program" EDR task from Central Node.

Yara-scan using KSC

If KEA is installed and managed from KSC server, you can start the command by *.bat file using Remote installation task.

Requirements:

• KEA 3.10 (and above) installed
• Files with Yara-rules (*.yara; *.yar)
• Shared folder with READ ALL access
• Shared folder with WRITE ALL access

Follow these steps:

1. Prepare the batch file
2. Prepare Shared folders: one with READ and one with WRITE access for everyone
3. Create installation package on KSC using *.bat file (see example below)
4. Create and start "Install application remotely" task

Example:

The script will start Yara scanning using KEA: all files at C:\ will be scanned using all rules from \\SHARE\YaraRules\, results will be saved into \\SHARE\YaraScanRusults\ folder.

\\SHARE\YaraRules\ folder should be available for READ
\\SHARE\YaraScanRusults\ folder should be available for WRITE

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.

This article applies to Endpoint Agent for Linux. To collect LENA debug or ANY traces, please follow this guide.

Default traces location is '/var/log/kaspersky/epagent/'.

Default dumps location is '/tmp/agentdumps'

Public collect.sh script was updated to collect LENA-related information and gather these folder as well.

How to: enable LENA ANY traces

For KATA-EDR (on-premises) customers to tune LENA performance by exclusions, ANY level logs are required. To enable ANY logging:

1. Become root

   sudo su -

2. Use one-liner to enable ANY tracing level: 

   sed -i 's/LENA_TRACE_LEVEL=none/LENA_TRACE_LEVEL=any/g' /etc/opt/kaspersky/epagent/service.conf && systemctl restart epagent

   1. Modify the config file /etc/opt/kaspersky/epagent/service.conf

      /etc/opt/kaspersky/epagent/service.conf

      KESL_FIFO_PATH=/run/log/kesl-messages AUDIT_FIFO_PATH=/run/log/audit-messages LENA_TRACE_LEVEL=none <-- set any here instead of none LENA_DUMPS=yes

   2. Save the modided value.

      Careful, CaSe sensitive values!

      LENA_TRACE_LEVEL=any  ← correct

      LENA_TRACE_LEVEL=none  ← correct

      LENA_TRACE_LEVEL=ANY ← wrong

      LENA_TRACE_LEVEL=None   ← wrong

   3. To apply changes, restart epagent service

      systemctl restart epagent

3. Wait until the problematic behavior is reproduced;

4. Stop traces

   /opt/kaspersky/epagent/sbin/lenactl --traces --off

5. Double-check that produced traces indeed contain ANY-level information use this command:

   grep -q ANY /var/log/kaspersky/epagent/lena*; if [[ $? == 0 ]]; then echo "ANY logs"; else echo "Not ANY :("; fi

6. As an addition you can check for how long ANY traces were gathered like 

   grep -h ANY /var/log/kaspersky/epagent/lena* | awk '{print $1}' | cut -d '.' -f 1 | uniq

7. And as final accord you can check whether you gathered enough ANY traces to be analyzed and sneak-peek what processes are producing excess load

   grep -ha "from auditd" /var/log/kaspersky/epagent/lena* | grep -oE "\"exe\"\:\[\"[^\"]+\"" | sort | uniq -c | sort -nr | sed -e 's/$/\]/' | grep -E "[0-9]{3,}\s+\""

8. Collect the produced logs and system information in one go using collect.sh script

How to: enable LENA debug traces

Debug traces take less space and are suitable for troubleshooting issues not-related to Performance or 3rd party compatibility.

1. Enable debug traces:

   /opt/kaspersky/epagent/sbin/lenactl --traces --on

   This method is not suitable for ANY traces and will override ANY traces level set previously by DEBUG value

2. Wait for a while until the problematic behavior is reproduced;

3. Disable traces:

   /opt/kaspersky/epagent/sbin/lenactl --traces --off

4. Collect the produced logs and system information in one go using collect.sh script

How to: enable LENA log rotation

1. To add log rotation, add to /etc/opt/kaspersky/epagent/service.conf following strings:

   /etc/opt/kaspersky/epagent/service.conf

   LENA_ROTATION_COUNT=10         <--  set max number of log files LENA_ROTATION_FILE_SIZE=100m    <--  set the size of each file

2. To apply changes, restart epagent service

   systemctl restart epagent

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

1. In the Administration Console, go to Advanced → Remote installation → Installation packages;
2. In the right frame, click Create installation package;
3. Select Create installation package for specified executable file;
4. Enter the name for the package and click Next;
5. 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;

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

7. Click Next→ Finish;
8. Create a remote installation task with this installation package for a device or a group of devices;
9. Run the task to remove the patch.

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:

1. EULA is not accepted;
2. KEA installation is protected with a password.

This guide addresses both of these issues.

Step-by-step guide

The following options need to be provided to the installer:

This instructs the installer to accept the EULA. 

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:

Remote installation

The same options can be used when deploying remotely via KSC. Specify them as follows:

How to upgrade previously installed password protected KEA using KSC remote installation task.

Step-by-step guide

1. Edit attached file install_props.json, put there your password for already installed KEA;
2. Put this file to folder on KSC containing files for creation of remote installation package for new KEA version as per screenshots below;
3. Create on KSC package for remote installation;

4. Start remote installation task on KSC.

   

    

   

Problem

If you install standalone Kaspersky Endpoint Agent, both KSC installation package and local installer provide option to choose, which KEA components to install:

However, when KEA is installed in built-in scenario, bundled with KES or KSWS, you don't get to choose and KEA is installed in default configuration, with all the components.

There's a way to select installed KEA components even for built-in scenarios.

Using install_props.json for changing installed components

As KEA section of Online Help states, it is possible to configure installation options via install_props.json. EDR Optimum help even describes how to use it for built-in scenario. However, installer options for components selection are not covered by Online Help.

Directives and values

ADDLOCAL directive defines, which components of KEA will be installed.

REMOVE directive defines which components will not be installed.

There are five possible values for directives in KEA now:

Example

This example will install Endpoint Agent with KATA integration, but without Kaspersky Sandbox integration:

How to use the file

File (example) with options should be placed next to the Kaspersky Endpoint Agent installer, endpointagent.msi.

For the remote installation via KSC, location should be similar to

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:

Sometimes, you may want to have Kaspersky Endpoint Agent traces which start from its very cradle. This guide is applicable to local installation.

Step-by-step guide

1. Place the attached JSON file next to endpointagent.msi file. Feel free to modify patch to traces folder inside.

2. Install Endpoint Agent using GUI or command line:

   msiexec /i endpointagent.msi /qn

Traces will appear as soon as the services start, even before the installation completes.

Description and cautions

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

Details

In case of standalone Central node:

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

In case of Distributed deployment (PCN and SCN):

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

Issue

1. "Databases and modules update task" is configured for hosts with LENA 3.12 installed.
2. Task is executed via KSC.

Diagnostics

1. "Activate KEA" task is configured for the hosts with LENA or has been configured and deleted in the past.
2. An update is executed locally, using lenactl works.
3. KLNagent successfully synchronizes with the server. Other installed applications (e.g. KESL) display no synchronization issues.

Workaround

To fix the issue:

1. Remove the "Activate KEA" task or any other configured KEA tasks except for "Databases and modules update task" for hosts with LENA installed.
2. If necessary, move hosts with LENA to a separate group or configure other desired KEA tasks using a selection for Windows hosts only.
3. Ensure there are no tasks except for "Databases and modules update task" remaining for hosts with LENA installed in KSC.
4. Option A. Reinstall LENA on hosts to get rid of cached activation tasks.
5. Option B. Remove the problematic cached tasks locally:
   1. Stop LENA:
      # systemctl stop epagent
   2. Remove the cached tasks:
      # rm -rf /var/opt/kaspersky/epagent/tasks/*
   3. Start LENA
      # systemctl start epagent
   4. Force synchronization with the host, e.g. by calling klnagchk.
      # /opt/kaspersky/klnagent64/bin/klnagchk
   5. Ensure one task is recieved.
      # ll /var/opt/kaspersky/epagent/tasks/
6. Execute "Databases and modules update task" on KSC. Ensure it finishes successfully.
7. Double check locally that the bases are updated.

RCA

1. LENA connector that receives the product tasks from KLNagent is only configured to accept valid tasks ant halt synchronization if an invalid task is received.
2. Only "Databases and modules update task" is considered to be valid for certified LENA version.
3. "Activate KEA" task is received or cached first. Connector halts synchronization once it is processed.
4. An update task is never received by the product.

When creating an IoC scan task, only the following registry branches are scanned.

<field name="predefined_keypaths" type="wstring" multi-valued="yes" default-value=
               '{
                  LR"(HKEY_CLASSES_ROOT\htafile)",
                  LR"(HKEY_CLASSES_ROOT\batfile)",
                  LR"(HKEY_CLASSES_ROOT\exefile)",
                  LR"(HKEY_CLASSES_ROOT\comfile)",
                  LR"(HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa)",
                  LR"(HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Monitors)",
                  LR"(HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider)",
                  LR"(HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Class)",
                  LR"(HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders)",
                  LR"(HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server)",
                  LR"(HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager)",
                  LR"(HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services)",
                  LR"(HKEY_LOCAL_MACHINE\Software\Classes\piffile)",
                  LR"(HKEY_LOCAL_MACHINE\Software\Classes\htafile)",
                  LR"(HKEY_LOCAL_MACHINE\Software\Classes\exefile)",
                  LR"(HKEY_LOCAL_MACHINE\Software\Classes\comfile)",
                  LR"(HKEY_LOCAL_MACHINE\Software\Classes\CLSID)",
                  LR"(HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run)",
                  LR"(HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ShellServiceObjectDelayLoad)",
                  LR"(HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer)",
                  LR"(HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run)",
                  LR"((HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components)",
                  LR"(HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows)",
                  LR"(HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options)",
                  LR"(HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Aedebug)",
                  LR"(HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon)"
                }'
             tag-id="2" tag-name="PredefinedKeyPaths"/>

IoC tasks that are configured to scan other branches of the registry will not return any results.

Problem

Some users may face a rather unclear and not self-explanatory error when attempting to remotely install KEA for Linux:

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

To disable SELinux, in file /etc/selinux/config set

1.1. Problem

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

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

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

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

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

1.2. Cause

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

1.3. Solution

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

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

   Script to enable all the keys from the article 

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

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

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

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

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

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

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

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

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

Problem

You need to install KEA on a host running MS Exhange 2013, 2016, 2019 server, and ensure compatibilty.

Solution

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

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

KEA writes in its event logs numeric task states. 

Solution

In EDR Security officer can create a hash-based prevention rule for workstation. Here's the list of activities to which prevention rules apply:

Agent should control and prevent read access of the following file formats by the following apps:

Agent should prevent script started by following interpreters:

• cmd.exe
• reg.exe
• regedit.exe
• regedt32.exe
• cscript.exe
• wscript.exe
• mmc.exe
• msiexec.exe
• mshta.exe
• rundll32.exe
• runlegacycplelevated.exe
• control.exe
• explorer.exe
• regsvr32.exe
• wwahost.exe
• powershell.exe
• perl.exe ( * )
• hh.exe ( * )
• msbuild.exe ( * )
• python.exe ( * )
• InstallUtil.exe
• RegSvcs.exe
• RegAsm.exe
• ruby.exe
• rubyw.exe
• autoit.exe
• AutoHotkey.exe
• AutoHotkeyU32.exe
• AutoHotkeyA32.exe
• AutoHotkeyU64.exe
• AutoHotkeyA64.exe

You may have purchased both the KATA and KWTS(Kaspersky Web Traffic Security) products. Since KWTS has built-in KATA integration, you may want to integrate KATA and KWTS.

Problems after integration

Shortly after integration you may notice that on KWTS side, there is an error about sending objects to KATA, and dashboards look similar to this:

Resolution

KATA side

To clean tasks, stuck in 'processing' state, do the following:

1) Find out KWTS ID:

On KATA4:

Name and IP of KWTS will be the same as in Administrator Web UI, External Systems section.

Then, clean up tasks that may be stuck in 'processing state':

On KATA4:

This command is safe to execute, it will do no harm even if there are no stuck tasks.

To view all active tasks from KSMG/KLMS/KWTS/Other external systems without modifying their states, run the command:

KWTS side

On KWTS side, it is important to exclude certain type of objects from being scanned in KATA:

In file /var/opt/kaspersky/kwts/kata-filters.json remove the lines, containing keywords:

After applying changes, restart kwts service:

After these changes, KWTS and KATA integration is expected to work normally further on.