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.

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

   

2. Apply the configured policy to the target mobile device with KESM installed and Android 10 (sync the product with the Security Center);

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

   

4. 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;
5. Depending on the conditions:
   1. 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);
   2. 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’:

There are 2 methods of installing iOS MDM on the user's device:

• Via AppStore (iTunes Store);
• Via Manifest URL (with manual placement of the package).

How to install via AppStore

Installation via AppStore involves a special key named App ID.

This process is fully automatic and requires no actions from the KSC administrator. In KSC, you need to specify the application name (this name will be used in KSC event log) and the application ID.

The application ID can be learned from its URL.

To install an app on a device after the application's description has been published on the server, perform the corresponding command (Install application to device).

How to install via Manifest URL

Manual installation requires more actions from the company (in particular, from the KSC administrator).

To perform an installation, you need:

1. An application signed with a developer certificate. Depending on what certificate is used, you may need a provisioning profile with the corresponding UDID installed on the device.
2. Manifest for the application. Manifest is an XML file that contains information about the application, including its name, version, and the location of its installation package

Workflow:

1. The user fills out the manifest with the application details (icon, metadata, .ipa package location).
2. Next, the user needs to upload the manifest to the web server and create a new application in the iOS MDM server properties with a link to the created manifest. ATTENTION! The link must lead to the manifest, not the ipa file.
3. Selecting an application:
   
4. Selecting a device and installing the application on it:
   

Step-by-step guide

Download Apple configurator via App Store.

Run Apple Configurator.

Connect your iOS device.

Unlock the device and tap Trust.

Open the iOS device → Console.

Reproduce the issue.

Save the log in Apple configurator.

Send the collected log file to Kaspersky support for further analysis.

Problem

KSC and KS4Android are implemented but KSC is offline and could not access Internet. KUU can be used for updating KS for Android and distribute the update databases. But after running KUU (Kaspersky Update Utility), you cannot find actual KES for Android versions. 

Solution

AV bases for new KESM versions will appear in KUU UI after running KUU with empty application list. 

The KUU settings should look like the following (in order to update the list of supported applications, you need first to press 'Start' with a blank application list as follows):

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:

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.

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:

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:

Then, reboot the host and check the issue reproduction.

Intro

This instruction describes how to create an installation package (.pkg) for the MacOS operating system from the standalone installation package of Kaspersky Endpoint Security for Mac.

You may need to create such a package to automate the installation of Kaspersky Endpoint Security software via third-party systems (e.g. AirWatch).

Details

Files

Munki tool (with predefined files)

Prerequisites

• Kaspersky Security Center
• MacOS machine
• Python must be installed

Usage

• Create a standalone installation package for Kaspersky Endpoint Security for Mac (https://support.kaspersky.com/KSC/14/en-US/182663.htm)
• On a MacOS machine:

Unzip the file munki-munki-pkg-e018bf1.zip to Desktop.

Open Terminal and navigate to the directory munki-munki-pkg-e018bf1

Copy the built standalone installation package (kesmac11.2.1.145.sh) to the postinstall file in the kesmac/scripts/ directory:

Modify the code of the standalone installation package with the vim editor

Replace the section in the file  to the modified section (note that the line "#!/bin/sh" must be the first line in the file, there must be no empty lines before it):

Add the execution bit:

You can also change the metadata (if needed) in the nagent/build-info.plist file

Perform the assembly:

The built package will be available in the kesmac/build directory with the name <name of package from build-info.plist>.pkg

Important

Step-by-step guide

1. Install KSWS and make sure the Anti-Cryptor protection component running and its Work Mode is Active.

2. Install AESCrypt on a remote host.

3. Try to encrypt the files on a network share protected by KSWS.
    
   
4. Enter a password.
5. As encryption starts, Anti-Cryptor detects it and blocks remote user's session. In KSWS 11, by default, the application blocks a host's access to network file resources for 30 minutes.
6. The following attempts to access shared folder will fail. 

7. KSWS logs attempts to encrypt the data.
    

8. The attacker host appears in the Blocked host storage now.

Step-by-step guide

1. Open KSWS policy
2. Navigate to "User rights" section
3. Under "Configure application management section" press "Settings" button
4. In the "Permissions for Kaspersky Security" window press "Advanced" button
   
5. Select necessary user or group -> press "Edit" button -> press "Show advanced permissions"
6. In the "Permissions Entry for Kaspersky Security" window unselect "Uninstall Kaspersky Security", make sure that Type is set to "Allow"
   
7. Switch Type to "Deny" -> click "Clear all" button -> Select "Uninstall Kaspersky Security"
   
8. In the pop-up "Windows Security" window select "Yes"
   
9. If security administrator will try to uninstall KSWS he'll receive the following error message

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.

Security administrator can create KSWS Application Control rules based on Digital Certificate.

What does product actually checks and how it is related to the file itself?

First of all, product checks whether the file matches certificate. Secondly, whether certificate is valid. If any of verifications fail - launch of the file will be denied. And vice versa.

If signed file which execution was allowed by certificate has been modified, will execution of the file be allowed?

Altering the file signed by the certificate will cause its certificate to no longer confirm the integrity of this file. As a result "Allowing" rule will no longer be applied to the file.

How the control of the revoked certificates operates, if such a control exist?

Certificates revocation in the operation system is implemented through OS updates. When a certificate becomes revoked, it can no longer pass validation checks. Thus file execution will be blocked.

When both the subject of the certificate and its thumbprint verifications are selected, then product checks that the file is signed by an exact "version" of certificate. In other words, it will not be enough to make a self-signed certificate with the Subject field equal to "Redmont, Microsoft" - such a certificate does not coincide with the real thumbprint of Microsoft.

This error message means that KSWS KSN-Client was unable to reach KSN Cloud servers (in most cases if KSN Proxy is used).

Possible causes of the issue:

• Various transport-level issues
• KSC Server has been moved to another host with new DNS-name and IP-address

Troubleshooting steps:

1. Check that option "Bypass proxy for local addresses" is enabled (KSC server properties > Advanced > Configure Internet access)
2. Check that option "Use UDP port 15111" is disabled:
   2.1 Administration server properties -> KSN Proxy -> KSN Proxy settings
   2.2 Network Agent policy properties -> Distribution points -> KSN Proxy
3. Check that KSC server could successfully establish connection to KSN
   • KSN Proxy server statistics is updated
4. Check that in KES policy option "Use KSN servers when KSN Proxy is not available" is disabled. And KES is able to successfully establish connection with KSN and KSN statistic is populated correctly. Otherwise, KES might establish a direct connection to KSN, bypassing KSN Proxy.
5. Check that port 443, 13111 TCP used by KSN proxy are available on proxy or company's firewall. For more information about ports which KSC uses please use KB article.
6. Check that Port Control or Detect Protocol features are disabled on the corporate proxy servers, firewalls. Non-SSL traffic should be allowed on 443 port.
7. If you use Squid, upgrade to the latest version. We have a confirmation that older versions of Squid have some issues, which might lead to this problem.
8. On KSC open Advanced -> Remote installation -> right click on 'Installation packages' node -> Properties. Make sure that correct server address is specified. In the address is incorrect then specify the right one -> recreate Nagent package -> reinstall Nagent on client hosts using the new package.

While removing Kaspersky Security for Windows Server Console removal log may contain a message:

Error 1336. There was an error creating a temporary file that is needed to complete this installation.
Folder: C:\Program Files (x86)\Common Files\Kaspersky Lab\Kaspersky Security for Windows Server\.
System error code: 5

And if you launch removal process using an appwiz.cpl a popup will be displayed stating : 

“There was an error creating a temporary file that is needed to completed this installation”

This may happen because KES is installed in the system, so far the workaround is the following:

Disable self-defense in KES and perform removal one more time.

Problem

Sometimes Anti-Cryptor task in KESL won't be able to launch after the OS is started. This may happen because Anti-Cryptor needs all the protected network resources to be up before KESL service is started. In other words, Samba or NFS services should be started before KESL service. 

Solution

To resolve this problem you need to make sure that services start in the correct order.

For Systemd systems:

1. Create a file /etc/systemd/system/kesl.service.d/override.conf

2. Add the following to /etc/systemd/system/kesl.service.d/override.conf:

3. Reload services

For Sys V init systems: 

Rename Samba and NFS init files to make those services start earlier. E.g.

Where <smb_init_file> and <nfs_init_file> stand for current init files present in the system. NFS init file may have different name depending on your environment - nfs, nfs3 or nfs-server.

Problem

The "Install application remotely" task wizard presents an option to specify an SSH certificate as account credentials, if Linux package is selected for installation. 

The wizard does not accept certain certificates and fails to provide informative error messages why this happens.

Examples:

Failed to upload the certificate.

Failed to import the private key of the certificate.

Root cause

KSC 13.2 only accepts PEM certificates, they start with header line of the following format:

-----BEGIN RSA PRIVATE KEY-----

However, most modern Linux systems use openssh, which offers an ssh-keygen tool to generate certificates. Starting from ~2018 it generates certificates in its own openssh structure if used with default settings. The header looks as follows:

-----BEGIN OPENSSH PRIVATE KEY-----

Solution

As a workaround, generate a cetificate in the PEM/RSA format.

• Using ssh-keygen (newer versions): use -m flag to switch to the old PEM format.

# ssh-keygen -t rsa -m PEM

• Using PuTTYgen:

Generate the SSH-2 certificate, then navigate to Conversions → Export OpenSSH key (do not choose "force new file format").

Problem

Remote installation tasks finishes with uninformative errors:

Setup process error: Unknown error. (126)

Setup process error: Unknown error. (2)

Solution

1. Create 3rd party installation package (Create installation package -> Create an installation package for the specified executable file.)

2. Specify executable file, for example script.sh

3. Locate this package folder in KSC storage, by default %ProgramData%\KasperskyLab\adminkit\1093\.working\share\Packages\(package_name)

4. Edit .\(package_name)\executable_package.kpd: remove exec\ from Executable path, add DontWrap=1 option. Setup section should read the following:

5. Edit .\(package_name)\exec\executable_package.kpd: remove exec\ from Executable path, add DontWrap=1 option. Setup section should read the following:

6. Copy .\(package_name)\exec\script.sh to .\(package_name)\script.sh

7. Check that in package Settings, "Executable file" changed from exec\script.sh to script.sh

8. Use this package in "install application remotely" task

Information in this article can be used when there are disk space limitations imposed on the folders used by KESL:

• /var/opt/kaspersky - default KESL installation folder
• /tmp - default folder used to store temporary files during the scan

/var/opt/kaspersky

To move files located in this directory you can create a symbolic link to another folder before installation. Use the following steps:

1. Before installing KESL:

   mkdir /new/kesl/folder/ ln -s /new/kesl/folder/ /var/opt/kaspersky #root has to be the owner of all kesl subfolders below / chmod go-w,a-t /new

2. Install KESL

/tmp

You can declare a new temporary folder for KESL by following these steps:

1. Execute this:

   systemctl edit kesl

2. Add the following:

   [Service] Environment="TMP=/new/temp/folder"

Description

After successful installation kesl-supervisor.service may refuse to start with the following error:

Root cause

SElinux is enabled on the system and prohibits execution of the service.

Solution

You can check SELinux status by running: 

If SELinux is enabled, then use the dedicated online help article to disable, configure and re-enable it.

Problem

kesl-control --app-info outputs the following error:

One of the most common root causes is Fanotify is disabled (or KESL could not access it) and kernel module compilation also failed.

A special utility can  be used for this directly on the affected machine with KESL installed:

In case, an operating system does not support Fanotify technology, it is required to install some additional packages and build a kernel module for KESL.

A part of required packages may be found on the Hardware and software requirements section of the product documentation, for example for KESL 11.3; In addition to this, new packages kernel-headers-XXX and kernel-devel-XXX must be installed, where XXX - an operating system kernel version.

Use the following scenario to install those packages and build a kernel module for KESL:

for RHEL based OS: 

for Debian based OS: 

Reboot the system;

Run the post-install script: 

And reboot the service: 

In case of any further issues, please contact Kaspersky Support.

Problem

There are several problems with similar causes:

1) KESL postinstall script produces error.

Warning: Failed to set up KSN

2) KESL is installed and running. However, the kesl-control command outputs something like that:

kesl-control --app-info

Connection refused. Invalid user permissions for /var.

Only root user should have write access to this path.

kesl-control --app-info

Could not connect to Kaspersky Endpoint Security 11.2.2 for Linux

3) KESL is installed and running, kesl-control indicates no problems. However, kesl-gui shows the Application is currently unavailable error.

4) KESL is installed and running, nagent indicates no connectivity problems. However, KSC shows that KESL is stopped and can't be started.

Root cause

KESL service implements defensive internal logic which denies connections from not "trusted" processes. One of the causes is that the process executable file or some library it loads can be overwritten by a non-root user:

1) The Owner is not "root".

2) FS write permission is granted to "Group" or "Other".

Such errors often serve as indication of some erratic configuration. For example:

• You may have changed ACL for /opt or other folder (which is supposed to not be widely accessible) to 777;
• In Astra Linux, the owner of the /var directory is sometimes changed to the fly-dm service user due to an error in the fly-dm package. Astra developers confirmed this bug and released fix. If the issue reproduces with new fly-dm versions, address Astra support.
• LD_PRELOAD variable may be used to load arbitrary libraries for any given process including KESL. This is usually the case when you see non-root permissions errors for some third-party libraries.

Solution

To restore proper permissions, use the chown and/or chmod commands:

Please exercise caution when changing permissions for / and folders straight under /. It depends on the environment which files/folders are checked, thus a complete list cannot be provided.

In new kesl versions, kesl-control output suggests which path has incorrect permissions.

You can check what folders have incorrect permissions using this command:

To get a full list of files loaded by KESL or klnagent, you can read /proc/<pid>/maps. Use commands in the example below to filter out all application-specific files that are located in the folders listed above and to see what other files are used:

Problem

While WTP/NTP is enabled, nft utility produces errors (stderr) like

These errors are caused by a bug in nft utility and xt_TPROXY dynamic library. This effect does not indicate functionality issues.

This bug may be reported to netfilter.org developers.

Explanation

Whenever nft utility lists traffic rules, it dynamically loads extension libraries (for example, from /usr/lib/x86_64-linux-gnu/xtables in Debian OS) including TPROXY and CONNMARK.

When nft encounters first ipv4 rule, it sets global "family=ipv4" state via xtables_set_nfproto function, then loads libxt_TPROXY.so which has both ipv4 and ipv6 targets, but ipv6 are ignored due to the flag.

After that, nft processes ipv6 rules but there are no ipv6 targets for them. As a result, nft utility produces errors "XT target TPROXY not found".

This is a workaround and should be used if you can't check it the standard way.

1. Collect GSI 

2. Open this file (see screenshot) and press ctrl+f and search for the word, for example, Firewall. Immediately you'll get a line with the installed components.

In Compact Diagnostic Interface

Can be checked in "About the application" window.

In Kaspersky Security Console

Can be checked in Action -> Information about the application and available module updates...

Problem

You might notice that large files named like PR*.tmp appear in C:\Windows\Temp.

Cause

This is known and expected behavior. When the product scans an object it creates a temporary copy, names it like PR*.tmp and places it in the temp folder.Once the scan is complete, this temporary file gets deleted.

Large PR*.tmp files mean that some large objects are scanned by OAS (On-Access Scan) or ODS (On-Demand Scan).

Solution

In some cases there might be not enough space of drive to create large temporary file. Below are the possible solutions:

1. Exclude large objects from OAS and ODS;
2. In OAS and ODS settings, enable option 'Do not scan compound objects larger than' and specify required size in MB;
3. Change the folder where KSWS temporary files are created to a drive with higher capacity. In KSWS11 this can be achieved by editing Application settings → Scalability, interface and scan settings → Scan settings → 'Folder for temporary files created during scanning'. In KSWS10 use below registry entry:

Sometimes you may need to add a particular site\domain to an exclusions list of Traffic Security.

Unfortunately, at current moment KSWS console allows us to make exclusions ONLY for Ports, IP-addresses, and Processes:

But we have ability to make site and domain exclusions for Traffic Security via registry workaround.

To implement workaround, we need to create and fill following REG_MULTI_SZ key:

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\KasperskyLab\WSEE\11.0\Environment\ICAP\IgnoreDomains]

To make changes in this hive, you can add necessary permissions to your account OR you can run regedit in SYSTEM context (psexec -s -i regedit.exe).