[SSH certificate import error during the "Install application remotely" task in KSC [KES for Linux]]

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

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

[Linux programs remote execution using "Install application remotely" task in KSC [KES for Linux]]

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

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:

executable_package.kpd

[Setup]

Executable=script.sh

DontWrap=1

Params=

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

exec\executable_package.kpd

[Setup]

Executable=script.sh

DontWrap=1

Params=

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

[How to configure KESL to use non-default folders [KES for Linux]]

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

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

If you encounter "Fatal error: Invalid permissions. Check /, /opt, /opt/kaspersky, /var, /var/opt, /var/opt/kaspersky. Only root user should have write access to these directories." while running the post install script, make sure root is owner of all subfolders in the path to kesl executable.

/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"

[kesl-supervisor.service: Control process exited, code=exited status=203 [KES for Linux]]

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

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.

[File Threat Protection does not start due to driver interceptor error [KES for Linux]]

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

Problem

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

en

File Threat Protection:                     Unavailable due to file interceptor driver 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:

sudo /opt/kaspersky/kesl/bin/fanotify-checker && echo fanotify: supported || echo fanotify: unsupported

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: 

yum install kernel-headers-`uname -r` kernel-devel-`uname -r`

for Debian based OS: 

apt install linux-headers-`uname -r`

Reboot the system;

Run the post-install script: 

/opt/kaspersky/kesl/bin/kesl-setup.pl --build | tee /tmp/buildLog

And reboot the service: 

systemctl restart kesl-supervisor.service

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

[KESL rejects connection from kesl-control, gui or nagent due to non-root write permissions [KES for Linux]]

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

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:

chown root:root /path/to/folder chmod g-w,o-w /path/to/folder

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:

# ls -ld / /var /var/opt /opt /opt/kaspersky /bin /usr /usr/lib /usr/lib64 | egrep -v '^d.{4}-.{2}-.*root root'

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:

# cat /proc/$(pidof -s klnagent)/maps | awk '{print $6}' | grep ^/ | grep -v 'kaspersky' | sort | uniq # cat /proc/$(pidof kesl)/maps | awk '{print $6}' | grep ^/ | grep -v 'kaspersky' | sort | uniq

[nft utility errors "XT target TPROXY not found" caused by WTP/NTP task [KES for Linux]]

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

Problem

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

# nft list ruleset XT target TPROXY not found XT target TPROXY not found XT target TPROXY not found XT target TPROXY not found

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

[How to enable TX capturing in KATA [KATA/KEDRE]]

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

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.

[How to check in the registry if the KSWS component is installed or not [Kaspersky Security for Windows Server]]

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

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.

[How to check if critical fix is installed for KSWS [Kaspersky Security for Windows Server]]

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

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

 

[KSWS spawns a lot of PR*.tmp files [Kaspersky Security for Windows Server]]

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

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:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\KasperskyLab\WSEE\10.1\Environment] "ProcessingTempPath"="d:\\Temp\\"

[How to add domain\site name in exclusions of KSWS Traffic Security component [Kaspersky Security for Windows Server]]

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

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

 

Important

Besides required domain names, we recommend to add the following default list of names to avoid breaking of Windows Updates and KSWS activation functionality:

*.data.microsoft.com
*.update.microsoft.com
*.kaspersky.com
*.rds.amazonaws.com
*.s3.amazonaws.com
*.blob.core.windows.net
*.database.windows.net

[How to collect KSWS dumps [Kaspersky Security for Windows Server]]

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

Some issues with KSWS/KESS/KICS4Nodes may require a process dump to analyze. It is fairly easy to collect. 

Crash dumps

KSWS/KESS/KICS4Nodes does not create crash dumps by default. It should be enabled before reproducing the issue.

Using KSC console

1. Open KSC console and navigate to the affected server.
2. Open its properties.
3. Switch to the Applications tab.
4. Open KSWS properties.
5. In the new window navigate to the Malfunction diagnosis tab.
6. Mark Create dump file checkbox.
7. Specify Dump file folder.

Using KSWS command line

1. Start elevated command prompt.

2. Execute KAVSHELL DUMP command. More info about the syntax is here https://support.kaspersky.com/KSWS/11/en-US/146721.htm.

   Example where automatic dumps will be saved to C:\Dumps

   KAVSHELL DUMP /ON /F:"C:\Dumps"

Manual dumps

Manual dump files are usually required when the process does not crash, just hangs or consumes a large amount of CPU time. There are two ways to collect manual dumps. Keep in mind that there are multiple executables, and we need all dumps from all of them. There are always one kavfs.exe and at least one kavfswp.exe (number depends on load and settings).

Using Windows Task Manager

1. Start Task Manager
2. Switch to the Details tab
3. Right-click on the image name
4. Select Create dump file
5. Repeat for every running KSWS/KESS/KICS4Nodes process

Using KSWS command line

1. Start an elevated command prompt.

2. Execute KAVSHELL DUMP command. More info about the syntax is here https://support.kaspersky.com/KSWS/11/en-US/146721.htm.

   Example where process with ID 1234 is dumped to C:\Dumps

   KAVSHELL DUMP /SNAPSHOT /F:C:\Dumps /P:1234

[How to use wildcard in KSWS/KESS exclusions [Kaspersky Security for Windows Server]]

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

KSWS/KESS use * as a wildcard character. There are multiple ways to use it.

Examples

Masks without paths

1. *.exe - all files with extension *.exe
2. test - all files with name test

Masks with absolute paths

1. C:\dir\*.* - all files in folder C:\dir\ and its subfolders
2. C:\dir\*.exe - all files with mask *.exe in folder C:\dir\ and its subfolders
3. C:\dir\test - all files named test in folder C:\dir\ and its subfolders
4. C:\dir\ - all files in folder C:\dir\ and its subfolders

Masks with relative paths

1. dir\*.* - all files in all folders named dir and their subfolders
2. dir\*.exe - all files with mask *.exe in all folders named dir and their subfolders
3. dir\test - all files named test in all folders named dir and their subfolders
4. dir\test*.* - all files which name begins with test and has extention in all folders named dir and their subfolders (for example, C:temp\dir\sub\test2.exe will be excluded )
5. dir\ - all files in all folders named dir and their subfolders

dir\ and dir\* have the same result.

Combinations such as dir\*\ are not used. The product will ignore them.

Masks acceptable while adding trusted processes:

c:\dir1\dir2\fil?.exe

c:\dir1\dir?\fil?.exe

c:\dir1\dir2\*.exe

c:\dir1\*\some_file.exe

[Error: Please go to the Control Panel to install and configure system components [Kaspersky Security for Windows Server]]

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

Product version/Environment

• KSWS 10.1/11.X
• Windows Server Requirements for the server on which Kaspersky Security for Windows Server is deployed

Description of Error

Run installation of the application or the console with the setup file. Error "Please go to the Control Panel to install and configure system components" pops up and installation doesn't run.

Solution

• Unpack the installation file and run the .msi file inside instead of the setup:
• *\ksws_11.0.1.897_en\client\ks4wstools*.msi for the console
• *\ksws_11.0.1.897_en\server\ks4ws*.msi for the application

[Task's stop settings are not available in KSWS database update and scan tasks [Kaspersky Security for Windows Server]]

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

Consider the following scenario:

Open update or scan KSWS task. 

Go to Schedule->Advanced→Task stop settings:

Solution

Task's stop settings are greyed out and cannot be changed. This is by design behaviour:

1. Task stop settings can be changed only for real-time tasks  - Real-Time File Protection and Script Monitoring. These tasks can be configured in KSWS policy to pause the execution at certain time not to interfere with 3d apps or speed up heavy operations. 

2. Task stop settings cannot be changed for Updater and On Demand Scan tasks. These tasks should be executed without pausing them. 

[KSWS corrupt installation [Kaspersky Security for Windows Server]]

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

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.

[Report Folder consumes disk space more than 1 GB [Kaspersky Security for Windows Server]]

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

Environment/Preconditions
KSC - 12
KSWS - 11.0.1.897

You may find a massive increase in disk usage from the folder report under the Kaspersky folder. The size of the report folder will increase from around 2GB to 12GB, the files in the report folder have random name (like 340a13d9-2a50-4c4e-94d6-82a79d80da4b), which rapidly grows and consumes disk space.

The file can be deleted to resolve the disk space full issue, which itself can cause many issues (can't log in to the server, KSWS stop, etc)

To delete the file:

1. Stop KSWS.
2. Add permission/owner for the login account.
3. Right-click and delete file.

This issue is caused by the Task log setting under Log and Notification tab in the KSWS policy. 

To avoid the detailed events issue:

1. Ensure that there are no Informational events in the Importance level option in each Component. 
2. Remove task logs older than (days) is selected.

In case you do the above step and the random file is still keep growing rapidly (100 MB per hour), it may be causes by the flooding event. 

You can check the event flooding by using "DB Browser for SQLite". 

For example, the log above is generated by the Application launch control component. You may solve this issue by disabling Application launch control log.

[Errors with removing KSWS and running GSI because of the Application Control [Kaspersky Security for Windows Server]]

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

Problem

KSWS10 and KSWS11 may have two issues because of the Application Control component:

1. Can't uninstall KSWS with the error "There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run"
   
2. Can't run GSI with this error "Unable to unpack the critical file. GsiSharp.bin"
   

Solution

Disable Application Control and retry uninstallation.

Сollect GSI, if necessary. 

[Update task completes successfully but bases remain outdated [Kaspersky Security for Windows Server]]

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

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.

[How to generate application blocking rules based on SHA256 file without source file [Kaspersky Security for Windows Server]]

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

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

1. Create a text file containing the sha256 you want to block.

2. Use the AppRulesGenerator.exe app to generate an xml file:

   

3. Import the generated .xml file into the KSWS policy:

   

AppRulesGenerator.exe can be downloaded here.

[About Disk I/O usage optimization option [Kaspersky Security for Windows Server]]

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

In KSWS/KESS/KICS there is an option in update task to Lower the load on the disk I/O.

It is important to understand that when this option is enabled the task does not use HDD resources at all. Updater will not only place current updates to RAM. Update temp and cache files will also be placed there.

Incorrect expectation: The task uses dedicated amount of RAM, in case if dedicated RAM is not enough for all update files including temp and cache task will continues through HDD.

Actual product behavior : The task uses dedicated amount of RAM, in case if dedicated RAM is not enough for all update files including temp and cache then task fails with the error:

Failed to update. Reason: insufficient drive space. 

[How to mount an NFS share for backups storage in KATA 5.x [KATA/KEDRE]]

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

Problem

In previous versions of KATA it was possible to mount an NFS share to copy backups to. In KATA 5.x only CIFS share mounts are available out-of the box.

Error

root@1.srv.node1.node.dyn.kata:/home/admin# mount -t nfs 10.225.62.41:/mnt/NFS/KXDR /mnt/nfs mount: /mnt/nfs: bad option; for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program.

Solution

Install packages manually via dpkg in the following order to add NFS support:

dpkg -i /home/admin/libtirpc-common_1.2.5-1_all.deb dpkg -i /home/admin/libtirpc3_1.2.5-1_amd64.deb dpkg -i /home/admin/keyutils_1.6-6ubuntu1_amd64.deb dpkg -i /home/admin/libnfsidmap2_0.25-5.1ubuntu1_amd64.deb dpkg -i /home/admin/rpcbind_1.2.5-8_amd64.deb dpkg -i /home/admin/nfs-common_1.3.4-2.5ubuntu3.5_amd64.deb

[How to use FQDN as a display name [KSC for Windows]]

It is the same as setting up flag in the registry: 

[HKEY_LOCAL_MACHINE\SOFTWARE\KasperskyLab\Components\34\1093\1.0.0.0\ServerFlags]
"SrvUseFqdnAsDisplayNames"=dword:00000001

Both ways are acceptable. Thank you!

[How to analyze KATA collect script output [KATA/KEDRE]]

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

Collect script output is a must for most KATA-related issues and questions.

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