Antipova Anna

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. You need a Mac device with macOS 14+ to supervise iOS device log via Apple Configurator Your iOS device will be reset to factory settings during supervising Download Apple configurator via App Store. Run Apple Configurator. Connect your iOS device. Unlock the device and tap Trust. Select your device and click on the Prepare button Select 'Manual Configuration'. Check 'Supervise devices' and 'Allow devices to pair with other computers' (if you want to allow it). Click on the Next button. Leave it on "Do not enroll in MDM" and click on the Next button Click on the Skip button Enter information about your organization (only 'Name' filed is mandatory'). Click on the Next button. Select 'Generate a new supervision identity'. Click on the Next button. In the next window you should choose which steps will be presented to the user in Setup Assistant. You can choose 'Show all steps', 'Do not show any of these steps' and 'Show only some' steps - in this options you must select the steps. Click on Prepare button. Enter password for your macOS account Click on Erase button. Your device will be reset to factory settings. Wait while your device will be prepared When your device will be turned on, you should see that your device is supervised and managed by your organization in device settings Now you can install iOS MDM profile to this device and apply iOS MDM policy with options for supervised devices.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Problem Description, Symptoms & Impact KES File Threat Protection sometimes can't check Microsoft office documents from mounted Google Drive shares, therefore generating Processing error events. This issue is caused by an incompatibility between Google Drive VFS driver and KES. There are no plans on making KES compatible with Google Drive. Workaround & Solution As a workaround, add files with Office extensions stored on the share to exclusions, this shouldn't lower protection, because Office creates a temporary copy of a document when it is opened, which will not be in the exclusion scope and will still be checked. Example for .xlsx files: Path\to\google\drive\folder\*.xlsx, where Path\to\google\drive\folder is replaced with an actual path.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. This article might be useful in the following cases: If you want to configure multi-vendor security on endpoints, keeping both Kaspersky and Microsoft technologies; If you don't know how to properly configure a Microsoft solution after installing KES; If you're having some issues with the product and the OS after configuring KES and Defender. The differences between the Defender products There are three different products: Windows Defender: an anti-malware solution for Windows 8, 8.1 and Server systems based on it. For details, see here. Microsoft Defender Antivirus: an anti-malware solution for Windows 10, 11 and Server systems based on it. For details, see here. Defender for Endpoint: an EDR solution for Windows 10, 11 that might be used together with Microsoft Defender Antivirus or a third-party solution (from the Microsoft point of view, of course). For details, see here. KES installation specifics During the installation of KES, the Defender solution status is verified and disabled automatically. After that, KES notifies the operating system about a new AV and FW feature (if the KES Firewall component is going to be installed). Please note that even if Defender is replaced with the AV in the system, the Defender service might still run, and this is an expected behavior. There is no need to disable this service explicitly, and it also might be harmful in certain scenarios. For example, if Defender is disabled by GPO, it may result in the KES installation failure since the installer might not be able to get access to the desired setting. Configuring systems to use both KES and Defender solutions Here you can find the article with the details on how to configure a Microsoft solution to properly coexist with third-party AV vendors (and KES is a third-party from the Microsoft point of view). No special actions should be taken from the KES side, at least at this moment. The information will be updated in case of finding any issues. Repairing KES registration in WSC This option available only for KES versions prior to the 11.11. KES registration within Windows Security Center might be affected. For example, when WMI repository getting corrupted, Windows is just restoring it back to defaults. In such cases KES and Defender might be both actively scan files and cause performance issues. The workaround to restore KES registration is: Disable KES Self-defense Open registry key Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\KasperskyLab\protected\KES\Data Find value "IsRegisteredInSecurityCenter" and set it to zero. Restart KES service or the whole host. Unfortunately, there is no possibility to restore KES registration by using some WMI scripts because they're breaking product integration and does not allow to update product statuses in a way the product does.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. There are multiple settings in both KES and KSC that allow to set notifications about various events. This article is based on example of setting complaint notification (message send to administrator if the users considers the blocking of the page to be mistaken). Let's review three main scenarios, when KES is connected to KSC (either constantly or intermittently) and when it is not connected. KES is always connected to KSC How to set To set address for email notifications go to Administration Server properties -> Notification delivery settings -> Notification and input email into Recipients filed. To enable email notifications do the following Open KES policy Navigate to KES policy -> Event notification -> Warning -> Web page access blockage message to administrator Press Properties Mark Notify by email checkbox What to expect Once the user will fill the form (way to change default complaint message will be covered later in this article) and press Send, Network agent will send event to KSC. Once KSC will receive it, email notification will be send to administrator. The default email will look like this: Event "%EVENT%" happened on computer %COMPUTER% in the domain %DOMAIN% on %RISE_TIME% %DESCR% %EVENT%, %COMPUTER%, %DOMAIN%, %RISE_TIME% are self explanatory, while %DESCR% may rise some questions. This part will be substituted the whole message that the user put in to the complaint form. You can change format of the email at Administration Server properties -> Notification delivery settings -> Notification. Note that it will affect all email notifications KES in not connected to KSC How to set Open KES GUI Navigate to Settings -> Endpoint control -> Web Control and press Templates Switch to Message to administrator tab Input address for notifications into To field Change Subject of the email and notification text if required. Open General Settings -> Interface -> Notifications Settings configure SMTP client connection settings in "Email notification settings" menu of Notifications. What to expect Once the user will fill the form (way to change default complaint message will be covered later in this article) and press Send, KES will send email to specified address. It will contain everything user put into the form. KES is connected to KSC from time to time How to set Follow the steps described in KES is always connected to KSC section. This will set KES for the time it has connection to KSC Do the same as described in KES is not connected to KSC with only difference – make changes to policy not KES local settings. This will set KES for the time when it is not connected to KSC: Open KES policy Navigate to Endpoint control -> Web Control and press Templates Set email address that will receive notifications when KES is not connected to KSC Change Subject of the email and notification text if required. What to expect When KES has connection to KSC you will receive message from KSC described in KES is always connected to KSC section. When KES has no connection to KSC you will receive email from KES described in KES is not connected to KSC section. The same goes for cases when out-of-policy is used. How it works As noted earlier, when you manage KES using Kaspersky Security Center you can specify two methods of email notification delivery, both of them could be configured in KES policy. KSC settings Open KES policy properties navigate to “Event configuration”, select event that you are interested in, mark “Notify by email” In this case, network agent transport will be used to deliver notification to KSC, then KSC will send an email to specified recipients. If you tracing KES activity, specialized information will be recorded in KES.version.date.time.PID.connector.log and KES.version.date.time.PID.SRV.log for each event sent by Nagent transport. KES settings Open KES policy, General Settings -> Interface -> Notifications Settings, leave tick marks in column "Notify by email" next to events that you are interested. Also you will have to configure SMTP client connection settings in "Email notification settings" menu of Notifications. In this case, KES will send emails using it’s own mail client, from computer where event was registered. KES actions will be recorded in KES.version.date.time.PID.SRV.log

Дисклеймер. Обязательно к прочтению перед использованием материалов базы знаний Форума. Описание Здесь мы расскажем, как установить KATA 6.0 AstraLinux в VK Cloud - https://support.kaspersky.ru/KATA/6.0/ru-RU/264697.htm Окружение, что используется: RHEL 9.3, VK Cloud, пакет qemu-img , KATA AstraLinux ISO образ (расположенный локально в ОС) - VK cloud поддерживает ТОЛЬКО AstraLinux версию. Инструкция по установке Для начала нужно подготовить образ AstraLinux для VK Cloud, он должен быть в .raw формате (VK Cloud поддерживает только этот формат) - необходимо конвертировать образ из .iso в .raw В данной статье мы используем RHEL 9.3, откройте терминал и установите пакет qemu-img yum -y install qemu-img После установки пакета выполните конвертацию qemu-img convert ~/Downloads/kata-cn-6.0.0-200-addon.x86_64_en-ru.iso ~/Downloads/kata6_astra.raw Залогиньтесь в свой аккаунт VK Cloud и перейдите в Cloud computing -> Images -> кликните Create -> выберите наш .raw образ и кликните Create image Теперь нужно создать основной диск для нашей инсталляции, перейдите в Cloud computing -> Disks -> Create disk -> выберите Source - Empty disk, Disk Type - High-IOPS SSD (high ops) -> Create disk Вернитесь в раздел Images - создайте ВМ из образа, как показано ниже Настройте ВМ согласно Калькулятор масштабирования (не обращайте внимания на наши настройки, это демо инсталляция) Вернитесь в раздел Disks и подключите ранее созданный нами диск к ВМ, как показано ниже В разделе Virtual machines кликните на ВМ и перейдите на вкладку Console -> начните инсталляцию Оказавшись в консоли, следуйте шагам инсталлятора На этом шаге выберите ИСКЛЮЧИТЕЛЬНО single режим (потому что VK Cloud поддерживает только этот тип инсталляции центральной ноды) После рестарта ВМ (вы попадете в окно выбора - снова установить КАТА или обновить версию 5.1) перейдите на вкладку General information и остановите ВМ, как показано ниже Выполните шаги, как показано ниже и выберите ранее созданный вручную диск (в нашем примере это kata6_astra_main 180 GB), дождитесь окончания выполнения операции замены диска. После этого либо сделайте диск non-bootable или удалите его, как показано ниже Включите ВМ заново Перейдите во вкладку Console и продолжите установку продукта, как мы обычно это делаем на VMware -> настройте подсети docker -> настройте сетевой адаптер (dhcp или static) > установите длину пароля и сам пароль -> настройте DNS сервера -> решите, включить ли захват трафика через SPAN или нет (y/n) > настройте NTP сервера На этом все, продукт КАТА установлен, теперь вы можете настроить его под УЗ admin и далее использовать на ваше усмотрение.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Description Here's how to install KATA 6.0 Ubuntu edition in KVM environment - https://support.kaspersky.ru/KATA/6.0/en-US/265697.htm In the example below we use RHEL 9.3, installed as VM in VMware Workstation Pro 17.0 Step-by-step guide First, you have to install QEMU/KVM , all steps are described HERE Then install from Software application Virtual Machine Manager, here it's 4.1.0 version. After successful installation just open up Virtual Machine Manager application, and click on the icon "Create a new virtual machine" Assuming, you have KATA Ubuntu ISO locally in OS, choose option below and click "Forward" Click "Browse" and "Forward" Click "Browse Local" Locate KATA Ubuntu ISO and click "Open" Next, do the steps as shown on picture below Click "Yes" Assign resources to VM according to THIS article (ignore our settings below, it's just a demo) and click "Forward" Configure a disk (ignore our settings below, it's just a demo) and click "Forward" Name your VM, select a network and click "Finish" Now you should see installation window, proceed like you usually do with standard KATA installation on VMware In this window select ONLY "single", cause KVM supports only this type of installation Select a disk and click "OK" Wait a bit and you should see that installation starts, and now you just have to wait for next step of installation/configuration Now select subnets (usually use default ones) by pressing Enter Choose network > assign IP (static or dhcp, in our example we use dhcp) > set password length and password itself > configure DNS servers Choose if you want capture traffic via SPAN (y or n) > configure NTP servers That's it, KATA installed Now you can login to web UI and configure server, in our example IP of server is 192.168.122.47, let's login to https://192.168.122.47:8443 and voila "Configure" and wait for completion

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Problem Sometimes it's necessary to check KATA detects, for example IDS, IOA, Sandbox detects. Step-by-step guide IDS detects (SPAN) To check IDS detects (SPAN) you can use tcpreplay utility on server configured to receive SPAN traffic. KATA 4.0/4.1 tcpreplay package for such versions could be found here https://rhel.pkgs.org/7/epel-x86_64/tcpreplay-4.4.4-1.el7.x86_64.rpm.html KATA 5.+ and tcpreplay tcpreplay package is not installed by default, so you should install it manually, using step-by-step guide below: 1) Download this package from HERE 2) Place downloaded file tcpreplay_4.3.2-1build1_amd64.deb to your KATA node. For example, use scp: [user@host]$ scp <your-path>/tcpreplay_4.3.2-1build1_amd64.deb admin@<kata-ip>:/tmp 3) Run installation on your KATA node with the next command: [admin@katahost]$ sudo dpkg -i /tmp/tcpreplay_4.3.2-1build1_amd64.deb Success! Now you can use tcpreplay on your KATA 5.+ or any other UBUNTU system! Before using tcpreplay you should enable tx capture for span: KATA 3.7.* In technical support mode from user root run following commands : systemctl stop apt-preprocessor.service systemctl stop suricata.service rmmod pf_ring Edit file /etc/modprobe.d/pf_ring.conf: change line: options pf_ring enable_tx_capture=0 min_num_slots=16384 # tx capture is disabled to: options pf_ring enable_tx_capture=1 min_num_slots=16384 # tx capture is enabled save file. Start pfring and related services back: modprobe pf_ring systemctl start suricata.service systemctl start apt-preprocessor.service KATA 4.0/4.1 Edit file /etc/modprobe.d/pf_ring.conf: change line: options pf_ring enable_tx_capture=0 min_num_slots=16384 # tx capture is disabled to: options pf_ring enable_tx_capture=1 min_num_slots=16384 # tx capture is enabled save file. In technical support mode from user root run following commands: systemctl stop docker rmmod pf_ring modprobe pf_ring systemctl start docker tx capture for span is now enabled KATA 5.0/5.1/6.0 - see https://forum.kaspersky.com/topic/how-to-enable-tx-capturing-in-kata-katakedre-37514/ Eicar traffic detect: Upload EICAR-Test-File_TCP.pcap sample to server with SPAN interface, then execute command from root shell: tcpreplay -i ens34 EICAR-Test-File_TCP.pcap # ens34 in this example is SPAN interface Nmap traffic detect: Scenario is the same as for Eicar detect, only .pcap file differs (# tcpreplay HackTool.Nmap.HTTP.C&C.pcap). After testing detects from span we strongly recommend to disable tx capture back again by the same way as described above for enabling. AM Engine Use EICAR's - https://www.eicar.com/ Email - send the EICAR via SMTP to KATA 25 port. (SMTP processing needs to be Enabled of course). ProTip: you may use local swaks mail client on CN to skip elaborate mail setups. swaks examples swaks --server 127.0.0.1 --port 25 --from antony@test.org --to cleopatra@test.org --attach eicar.com swaks --server 127.0.0.1 --port 25 --from antony@test.org --to cleopatra@test.org --body "link_to_EICAR_here" Endpoint - put an EICAR file to the endpoint and fetch it using GetFile task, queue for scanning. YARA detects By default, no YARA rules are supplied with the product. For test purposes one can use a test rule from YARA docs https://yara.readthedocs.io/en/v4.1.0/writingrules.html rule ExampleRule { strings: $my_text_string = "text here" $my_hex_string = { E2 34 A1 C8 23 FB } condition: $my_text_string or $my_hex_string } The rule will mark any analyzed object containing $my_text_string or $my_hex_string. IoA detects To check IoA detect (IoA detects can be checked only if you have KEDR license): Copy .bat file from attached archive Test_IOA.rar(not_infected) to any folder on host with installed EDR and start it. After some time(KATA need several minutes to transmit and process telemetry from EDR) check alerts in KATA. Alert should have type ioa_test_detect. For testing IoA detects on host more than once, .bat file should be placed to different locations on this host. On the host with installed KEA run command below in the cmd.exe shell: wmic.exe sfdguninstallkasperskyblabla There can be something else instead of sdfg and blabla, important part of command is uninstallkaspersky Command execution will fail with error, but it's not important. After some time new IoA detect should appear in KATA web-interface. IoC detects One can use the custom rule for testing - Ioctest.zip (infected123) - it is triggered for "c:\windows\system32\calc.exe" Automatic sandboxing in EDR To check automatic sandboxing: Unpack the archive with sample, use default password for samples: autosbtest.zip NB! Do not change MD5 of the sample. Run the sample on EDR-protected host and wait for automatic SB detect: Sandbox detect To check sandbox detect we can use file SA_sleep.exe from archive no_am_detection sample.rar. Password is inside text document in archive. Go to KATA senior security officer web-interface. Choose Storage → Upload and upload SA_sleep.exe from attached archive for KATA checking. Kata should enqueue it to sandbox , then a bit later verdict from SB should be Suspicious Activity. If SA_sleep.exe produces Not detected verdict then please use test_sb.bat from the test_sb.rar URL reputation Firstly, confirm K(P)SN is configured and works properly. MD5 used in this example should return UnTrusted status: Check KSN on KATA command for KATA 4.+ and 5.0: docker exec -it `docker ps | grep ksn_proxy| awk '{print $1}'` /opt/kaspersky/apt-ksn_proxy/sbin/ksn_client --ip 127.0.0.1 --hash 9C642C5B111EE85A6BCCFFC7AF896A51 for KATA 5.1: docker exec -it $(docker ps | grep ksn_proxy| awk '{print $1}') /opt/kaspersky/apt-ksn-proxy/sbin/ksn_client --ip 127.0.0.1 --hash 9C642C5B111EE85A6BCCFFC7AF896A51 Secondly, For traffic: access http://bug.qainfo.ru/TesT/Aphish_w/index For email (SMTP processing needs to be Enabled), send the link above via e-mail. For quick and dirty test: swaks examples swaks --server 127.0.0.1 --port 25 --from fisherman@test.org --to cleopatra@test.org --body "http://bug.qainfo.ru/TesT/Aphish_w/index"

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Problem Description, Symptoms & Impact When downloading large collects (sandbox-debug-report) exceeding 1Gb in size, download suddenly fails above 1Gb (at ~1 05x xxx KB). Diagnostics Reproducible in all browsers, is not bound to download speed, dowloaded part size is roughly 1Gb Workaround & Solution Workaround: download sandbox-debug-report using SCP and CLI, see https://forum.kaspersky.com/topic/how-to-gather-sandbox-debug-report-from-terminal-katakedre-36851/ Solution: From root, add directive uwsgi_max_temp_file_size 0; to the file /etc/nginx/conf.d/sandbox-ram-frontend.conf on sandbox, as follows: /etc/nginx/conf.d/sandbox-ram-frontend.conf location ~ ^/api/(.*) { rewrite ^/api/(.*)$ $1 break; uwsgi_pass ram_backend; uwsgi_read_timeout 900; client_max_body_size 2048m; include uwsgi_params; uwsgi_max_temp_file_size 0; <---add this line } Apply the changes by reloading nginx configuration: nginx -s reload RCA uwsgi built-in temp file size limit of 1Gb is applied unless other limit is specified directly.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. 1. Pre-requisites The file must contain the certificate itself and a private encryption key for the connection. The file must be in PEM format. The application does not support other formats of certificates. If you have prepared a certificate in a different format, you must convert it to the PEM format. The private key length must be 2,048 bits or longer. Please delete all Endpoint Agent host isolation rules. Connection with the isolated hosts and control over them will be lost. 2. Certificate creation and Configuration steps: To create a Certificate Signing Request file using the openssl utility: 1. Prepare a file named sandbox.config with the following contents: [req] default_bits=2048 prompt=no default_md=sha256 req_extensions=req_ext distinguished_name=dn [dn] C=AE ST=North L=Dubai O=ABC LAB OU=IT Security emailAddress=security@abc.lab CN=katacn.abc.lab [req_ext] subjectAltName=@alt_names [alt_names] DNS.1=katacn.abc.lab 2. Create a private RSA key with the PEM extension (without a passphrase): #openssl genrsa -out cn.key 2048 3. Create a Certificate Signing Request using the following command: #openssl req -new -sha256 -key cn.key -out cn.csr -config cn.config 4. Generate the certificate (as Web Server certificate) from Internal CA in Base 64 encoded with certificate chain. Access your internal CA from Domain Controller using https://dc.abc.lab/certsrv and follow the instructions as below screenshots. 5. Get the certificate from the certificate Authority in P7B format 6. Open the certificate, Export in the format of Service/Server/Root (names given for identification only) per the below screenshot. 7. While exporting the certificates, select the encoding as base64 8. Concatenate/Combine the Certificate in one file as below and save it in .CRT format. If you don’t have server certificate then you can add service and root only On TOP - Service Middle - Server Bottom - Root 9. To make a .PEM format you need to have the private key (get from where you have created the CSR) 10. Run the below command using Openssl in Windows or Linux to make it in a .PEM format #openssl pkcs12 -export -in cn.crt -inkey hsotname.key -out cn.p12 #openssl pkcs12 -in cn.p12 -nodes -out cn.pem 11. Once you have the certificate cn.pem format then upload it to the Central Node Web UI as per the below steps. Upload the TLS certificate in the web interface of the PCN or SCN server to which you want to upload the certificate. To upload an independently prepared TLS certificate using the Kaspersky Anti Targeted Attack Platform web interface: Sign in to the Kaspersky Anti Targeted Attack Platform web interface with the administrator In the window of the application web interface, select the Settings section, Certificates subsection. In the Server certificate section, click This opens the file selection window. Select a TLS certificate file to download and click the Open button. This closes the file selection window. Communication with the mail sensors, the Sandbox component, and the Kaspersky Endpoint Agent application is interrupted until reauthorization. The TLS certificate is added to the Kaspersky Anti Targeted Attack Platform 12. After replacing the certificate don't forget to replace it in KES Policy→ Detection and Response → Endpoint Detection and Response (KATA) → Server Connection Settings → Delete existing certificate and Select new Server TLS certificate (not the Add Client certificate). 13. The certificate you specify here needs to be in CRT Format. You can get it by "Downloading" the Certificate from CN → Settings → Certificates → Server certificate and click Export. 14. Open the KATA CN Web UI using the hostname in a new tab/window and verify the certificate.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. 1.1. Scenario: KATA/EDR CN is deployed on site, and there are some remote users that cannot connect to the internal network, and you want to receive the EDR telemetry from those endpoints and laptops when they are outside the network (considering that you don't have any VPN functionality). You don't want to expose the CN on the internet, so you'd like to use the sensor to relay the telemetry to the CN and have visibility on the endpoints. 1.2. Pre-requisites and configuration steps: To achieve the above scenario, we can deploy the KATA Network Sensor in the DMZ and publish it on the internet for remote and roaming users. The Network Sensor will be integrated with the CN and public IP/FQDN will be used to send the traffic from the internet to the sensor using port 443. Two KES policies (Active/Out of Office) will be configured, The Active policy will have the KATA CN internal IP and the Out-of-Office policy will have the public IP/FQDN for KATA Sensor. Connection profiling can be used to switch between the policies (similar to the connection gateway for KSC). The below steps need to be performed for the successful deployment and integration. Deploy the KATA Network Sensor in the DMZ Configure to integrate with CN, and accept the request on the CN side. When using the KEDR license, the Accept button might not be available, integration of the KATA sensor requires a KATA license, or the latest KATA patch should be applied on the CN to fix this issue. Export the certificate from the KATA Sensor using WinScp and copy it to the local computer or KSC server. Note: you might need to allow the connection using WinSCP: Location of the certificate = /etc/pki/tls/certs/ File name = kata.crt Copy the kata.crt to /tmp/ and change the permissions to download the file. Configure the destination NAT from Firewall towards KATA sensor internal IP for port 443. Configure the KES (Out-of-office) policy and add the Public FQDN/IP in the connection settings along with the sensor certificate. Apply the KES (Out-of-office) policy to a test laptop. Disconnect the Laptop from the network and wait for the connection to be established from the internet with KATA Sensor. Verify the Endpoint status on the Central Node and check for the recent events.

Hello Studynx! If you want to install KWTS, please refer to our Online Help https://support.kaspersky.com/kwts/6.1/en-US/166243.htm.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. To create a Certificate Signing Request file using the openssl utility: 1. Prepare a file named sandbox.config with the following contents: [req] default_bits=2048 prompt=no default_md=sha256 req_extensions=req_ext distinguished_name=dn [dn] C=AE ST=North L=Dubai O=ABC LAB OU=IT Security emailAddress=security@abc.lab CN=katasb.abc.lab [req_ext] subjectAltName=@alt_names [alt_names] DNS.1=katasb.abc.lab 2. Create a private RSA key with the PEM extension (without a passphrase): #openssl genrsa -out sandbox.key 2048 3. Create a Certificate Signing Request using the following command: #openssl req -new -sha256 -key sandbox.key -out sandbox.csr -config sandbox.config 4. Generate the certificate (as Web Server certificate) from Internal CA in Base 64 encoded and copy the certificate and key to the KATA SB Server Note: you might need to allow the connection using WinSCP (https://forum.kaspersky.com/topic/how-to-copy-files-tofrom-kata-katakedre-37146/ section 1.2). Access your internal CA from Domain Controller using https://dc.abc.lab/certsrv and follow the instructions as below screenshots. 5. To convert the DER encoded PKCS#7 file, use the following command: #openssl x509 -inform PEM -in sandbox.cer -out sandbox.crt 6. On the Sandbox server in SSH mode, Create a backup of original files both the private key and the certificate with same rights as it was before. #cp -p /etc/nginx/ssl/server.crt /etc/nginx/ssl/server.crt.orig #cp -p /etc/nginx/ssl/server.key /etc/nginx/ssl/server.key.orig 7. Replace the original files with your files #cat my_cert.crt > /etc/nginx/ssl/server.crt #cat my_cert.key > /etc/nginx/ssl/server.key 8. Rights and owner of the files should be same #ll /etc/nginx/ssl -rw-r----- 1 root klusers 2008 Feb 8 15:51 server.crt -rw------- 1 root root 1732 Feb 8 15:51 server.key 9. If the rights are different for the new files, then use the below command to change the rights and ownership #chmod 640 server.crt #chown root:klusers server.crt #chmod 600 server.key #chown root:root server.key 10. Restart nginx service #systemctl restart nginx.service 11. Open the KATA SB Web UI using the hostname and verify the certificate.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Description and cautions This article may be useful in certain cases, when you see that virtual machines running on the KATA Sandbox can not access internet using the properly configured malware interface. One can notice the issue based on several symptoms, such as VM activation errors, samples sent to Sandbox for processing not accessing internet, etc... We recommend to use the following article to check if the malware channel works properly on the KATA Sandbox server or not: Details In case if the tests listed above indeed show that malware channel fails to connect to the internet, we recommend to do the following checks among others: Run the following command on the sandbox server to check the currently configured network settings for the Sandbox: # /opt/kaspersky/sandbox/bin/sbnetworking all show check in the command's output if the malware interface is configured properly, i.e. it's intended IP, subnet, gateway, etc. Example of such output below: Correct values if they are misconfigured somehow from the web interface and don't forget to apply the settings afterwards and restart the host, to propagate those (prompt for restart will pop-up in the Sandbox web interface after applying those). Run the following command to check the system log on the Sandbox server if there are certain errors related to networking in general and malware interface in particular: # journalctl -u network # journalctl -u sandbox-networking.service In case if all checks listed above were passed, and there are no misconfigurations found and/or no specific errors were found in system journal, then try checking if routing is properly configured for the malware channel, i.e. run the following command: # ip route show table 701 Expected output below: if the output will be missing the default route entry via configured gateway for the malware interface, then add it manually like so: # ip route add default via <gateway's IP> table 701 after adding the route, double check that it indeed exists: # ip route show table 701 then restart the sandbox-networking service manually or the Sandbox server itself: # systemctl restart sandbox-networking.service Please note, that restarting sandbox-networking service may take a while especially on production servers that are processing a lot of samples at the moment and/or have a lot of worker slots. Thus it is highly recommended to detach this Sandbox server from KATA for the time of restart and expect 40 minutes - several hours downtime to complete the procedure. after restarting the sandbox-networking service check if you can ping public locations successfully from internet interface's namespace: # /opt/kaspersky/sandbox/bin/ns_exec /var/run/netns/dom1 /bin/ping -c 3 8.8.8.8

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Don't forget to install 6.0.1 patch, which fixes some bugs in ICAP integration. Description and cautions Since we have new ICAP working modes, presented in KATA 6.0 - https://support.kaspersky.ru/KATA/6.0/en-US/247269.htm , we would like to show you, how to configure such integration on example of squid proxy server. Added ICAP integration with feedback. ICAP integration with feedback can work in two modes: Standard scan. In standard scan mode, the object is scanned by all supported technologies. While being scanned by the Sandbox component, the object remains available. If a threat is detected, the object is blocked. Advanced scan. In the advanced scan mode, objects are scanned by all supported technologies. While being scanned by the Sandbox component, the object is not available. If a threat is detected, the object is blocked. Details Reminder - this is just an example, but working one:) Squid configuration part Assuming you already have squid installed with default configuration (of course, yours could be different according to your infrastructure), add following lines in the end of /etc/squid/squid.conf (surely, change the IP address to yours) icap_enable on adaptation_send_username on adaptation_send_client_ip on icap_service kata_req reqmod_precache icap://10.68.56.219:1344/av/reqmod icap_service kata_resp respmod_precache icap://10.68.56.219:1344/av/respmod adaptation_access kata_req allow all adaptation_access kata_resp allow all icap_service_failure_limit -1 The only thing we changed here as well is at the start of squid.conf - source subnet, in order to adapt server to our Lab # # Recommended minimum configuration: # # Example rule allowing access from your local networks. # Adapt to list your (internal) IP networks from where browsing # should be allowed acl localnet src 10.68.56.0/23 We also recommend to add these lines below as well, so you would be able to analyze ICAP logs logformat icap_squid %tl %6tr %rm %ru %rp %6icap::tr %>a %icap::to/%03icap::Hs %icap::rm %icap::ru %un %icap::<A %icap::<st %icap::>st %icap::<bs %icap::>h %icap::<h %icap::tr %icap::tio icap_log /var/log/squid/icap.log icap_squid ICAP logs are located at /var/log/squid/icap.log and look like So the whole picture should look like this Testing part If standard scan mode is enabled, let's check on KATA side, how it looks like in /var/log/kaspersky/services/preprocessor_icap/preprocessor_icap.log grep --color 'blocking_simple mode' | grep 'verdict' In this example we can see that from URL file was scanned with verdict: clean (whitelist) 09:41:46.697 INF 137781 server/source/file_handler_respmod.cpp:435 [sid: 0x0000004d] RESPMOD: Finish processing file in blocking_simple mode (request url: 'r3.o.lencr.org', size: 503, filename: 'baf664a8a7841e1d057f5ab0da58bcf0', uuid: 5cc2d18781924f98b6e4961494125616, md5: baf664a8a7841e1d057f5ab0da58bcf0, format: GeneralBin), processing time: 0.147ms, verdict: clean (whitelist) File from URL with verdict: clean (cached) 09:40:14.476 INF 137778 server/source/file_handler_respmod.cpp:435 [sid: 0x0000004a] RESPMOD: Finish processing file in blocking_simple mode (request url: 'detectportal.firefox.com/success.txt?ipv6', size: 8, filename: 'success.txt', uuid: 25f155a67eff4a4a90b33dbbb4f3367c, md5: ae780585f49b94ce1444eb7d28906123, format: GeneralTxt), processing time: 0.124ms, verdict: clean (cached) URL with verdict: good (KSN) 09:42:37.334 INF 137780 server/source/file_handler_reqmod.cpp:187 [sid: 0x0000004c] REQMOD: Finish processing url in blocking_simple mode ('box.kaspersky.com'), processing time: 3ms, verdict: good (KSN) File from URL verdict: clean (scanned) 09:35:14.691 INF 137770 server/source/file_handler_respmod.cpp:435 [sid: 0x00000042] RESPMOD: Finish processing file in blocking_simple mode (request url: 'detectportal.firefox.com/success.txt?ipv4', size: 8, filename: 'success.txt', uuid: 4c87c81cf3d543ceb6694d917329d2b8, md5: ae780585f49b94ce1444eb7d28906123, format: GeneralTxt), processing time: 124.894ms, verdict: clean (scanned) URL with verdict: bad (KSN) 10:05:18.354 INF 137802 server/source/file_handler_reqmod.cpp:187 [sid: 0x00000062] REQMOD: Finish processing url in blocking_simple mode ('kaspersky.com/test/wmuf'), processing time: 146ms, verdict: bad (KSN) If advanced scan mode is enabled, let's check on KATA side, how it looks like in /var/log/kaspersky/services/preprocessor_icap/preprocessor_icap.log grep --color 'blocking_advanced mode' | grep 'verdict' Picture is pretty the same, but from browser side you will see that object is blocked/inaccessible 10:54:01.341 INF 139635 server/source/file_handler_reqmod.cpp:187 [sid: 0x0000000e] REQMOD: Finish processing url in blocking_advanced mode ('bug.qainfo.ru/test_cloud/wmuf'), processing time: 27ms, verdict: bad (KSN) 10:54:20.467 INF 139635 server/source/file_handler_reqmod.cpp:187 [sid: 0x0000000e] REQMOD: Finish processing url in blocking_advanced mode ('secure.eicar.org:443'), processing time: 0ms, verdict: good (KSN) 10:50:45.303 INF 139632 server/source/file_handler_respmod.cpp:435 [sid: 0x0000000b] RESPMOD: Finish processing file in blocking_advanced mode (request url: 'ocsp2.globalsign.com/gsorganizationvalsha2g3', size: 1461, filename: 'gsorganizationvalsha2g3', uuid: f88dd52252da4fdf8aaabc3aafdbdb0a, md5: 9a3ec48893b2952f013e03311b878e18, format: GeneralBin), processing time: 0.346ms, verdict: clean (whitelist) During tests at KATA web UI you should see activity on ICAP dashboard and under Security office we can see two alerts, generated after our tests (10.68.56.227 is squid IP address) In real world, of course, you will see other detects as well, for instance, on infected objects and malicious URLs.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Problem description: After generating the client certificate on central node and upload it to KES policy, you can get the below error: Enter a crypto-container password to use the certificate. Note: If you are using KEA as a standalone product with KEA policy, you can upload the client certificate properly. Root cause: By default, the cryptographic container is not password-protected. The cryptographic container contains only the certificate file, but not the private key file. KES policy does not apply certificate without password (only KEA does). Solution: Access the central node SSH under root account 1) Export you current certificate to a passwordless pem type: #openssl pkcs12 -in mycert.pfx -out tmpmycert.pem -nodes Enter Import Password: <Enter no password> MAC verified OK 2) Convert the passwordless pem to a new pfx file with password: #openssl pkcs12 -export -out mycert2.pfx -in tmpmycert.pem Enter Export Password: <Enter password here> Verifying - Enter Export Password: <Enter password here> Now you can use the new mycert2.pfx file with your new password.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Description Error looks like this: You can't download trace log. But there is free space on the disk: Cause You will see this error if free disk space less than 10G. KWTS is not in sizing 200 GB of hard drive space, which includes: 25 GB for temporary file storage 25 GB for log file storage How to solve a problem Bring disk sizing to minimum hardware requirements

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Description After generating a trace log and then attempting to download it via the KWTS 6.1 web interface, it fails with an error if the trace log is more than 1GB (one gigabyte). The error is duplicated on different devices in different browsers: Mozilla, Chrome, Edge. In Mozilla, the download stops with "Failed to download file" Chrome goes into an endless download attempt, the download is interrupted at 1GB, after which the speed drops to 0kb/s and the download starts all over again. How to solve To resolve the problem with downloading a large trace log, follow this procedure: 1) Connect to the Kaspersky Web Traffic Security node via SSH to access the technical support mode. If SSH access has not been previously configured, you must first log into the web interface as a local administrator and configure access by uploading the SSH public key. 2) Go to the /etc/nginx/conf.d directory, make a backup copy of the kwts_webapi.conf and kwts_controlapi.conf files if you have not done so before: cd /etc/nginx/conf.d cp -p kwts_webapi.conf kwts_webapi.conf.backup cp -p kwts_controlapi.conf kwts_controlapi.conf.backup 3) Open the /etc/nginx/conf.d/kwts_webapi.conf file for editing and add the line marked below in green to the location /web/api block: location /web/api { ... uwsgi_max_temp_file_size 0; include uwsgi_params; ... } 4) Open the /etc/nginx/conf.d/kwts_controlapi.conf file for editing and add the line marked below in green to the location /ctl/v1 block: location /ctl/v1 { ... uwsgi_max_temp_file_size 0; include uwsgi_params; } 5) Restart nginx using the command systemctl restart nginx 6) Check the status of the nginx service, it should be running. systemctl status nginx The described steps must be repeated on each node of the Kaspersky Web Traffic Security cluster. After completing the procedure, restart your web browser and reconnect to the Kaspersky Web Traffic Security 6.1 web interface.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Description You can face an issue like this on Events page in KWTS: Sometimes the search on the Events page works correctly. Sometimes not.. If you collect har-file (HOW TO) from Events page with reproduced issue you will see an error also in it: Also you can find an error in diagnostic_info\logs\var\log\kaspersky\kwts\extra\webapi.log: celery.backends.base.SoftTimeLimitExceeded: SoftTimeLimitExceeded(True,) Then you should check Maximum event log size (https://support.kaspersky.com/KWTS/6.1/en-US/174773.htm) in settings here: diagnostic_info\klinfo\worker_settings.xml Maximum event log size set to 10 GB. How to solve a problem You should set it to 9 GB. The KWTS architecture is not designed for a large event database size.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Descriptrion You can see an issue like this: You can also find log entries like this in diagnostic_info\logs\var\log\kwts-traces.log Line 1538367: Jan 11 18:12:33 kwts2 KWTS Licenser[1154]: 1241 INF httpcli#011Req 0x7fecd003b9d0 CURL: Could not resolve host: activate.activation-v2.kaspersky.com Line 1538460: Jan 11 18:12:33 kwts2 KWTS EventLogger[1062]: 1102 DBG APP: void lms::event_logger::LoggerHelperProcFrontend::SendCommand(const lms::event_logger::HelperProcCommand&, const string&)message is: license error: Could not resolve host Or like this Line 4667143: Nov 18 16:02:12 32-vs-kwts02 KWTS Licenser[1675]: 35735 DBG APP: virtual result_t lms::licenser::utils::RequestCompleteEvent::OnRequestComplete(licensing::facade::product::ILicensing*, licensing::facade::product::activation_action::Type, const ActivationCode&, result_t, licensing::facade::product::IActivationContent*) actionType = 0, activationCode = AW65R-BZ8CG-KBQ18-ANNZ2, result = 0xa0430005 Line 4667349: Nov 18 16:02:12 32-vs-kwts02 KWTS EventLogger[1552]: 1592 DBG APP: void lms::event_logger::Journalist::Write(const lms::event_logger::JournalRecord&) JournalRecordData(dateTime.dt: 133132501328539280, type: 9, person: kluser, result: 1, description: license error: Could not resolve host, details: { "name": "LicenseErrorEvent", "data": {#012 "reason": -1608777683#012} }) How to solve a problem It means that the problematic node could not resolve activation service. Check an access to activation services from the problematic node curl -v https://activation-v2.kaspersky.com/ --cacert activation-v2.kaspersky.crt And if there is no success connection, open an access to https://activation-v2.kaspersky.com https://activation-v2.kaspersky.com/ActivationService/ActivationService.svc And check a page with configuring network access - https://support.kaspersky.com/KWTS/6.1/en-US/189764.htm

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Problem When installing KESS on Windows XP MSI installer service may stop working, and the msi.dll is reverted to version 3.1. The reason for such behavior is that the "Scan at operating system startup" task restores the "Last access time" attribute. The System Restore in turn restores the files with the modified attributes from the backup. Solution Prior to KESS installation create the following registry entry: [HKEY_LOCAL_MACHINE\SOFTWARE\KasperskyLab\ESS\2.3\Environment] "DontRestoreFileTimes"=dword:00000001 If the product is already installed and the problem already occurred, the solution will be as follows: Create the registry entry: [HKEY_LOCAL_MACHINE\SOFTWARE\KasperskyLab\ESS\2.3\Environment] "DontRestoreFileTimes"=dword:00000001 Install Windows Installer 4.5 https://support.microsoft.com/en-us/help/942288/windows-installer-4-5-is-available Reboot the host

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. There can be the following errors in the installation log: InstallDriversDeferred (4c8:0830) [11:20:58:793]: Failed to execute driver package 'DriverKlips.601'. Failed to add a catalog file. Error 0x80070426. InstallDriversDeferred (4c8:0830) [11:20:58:793]: Failed to add a catalog file. Error 0x80070426. The problems of installing a driver's cat-file usually mean that there are some problems with Cryptographic services and the system cat-base. Try the following workaround: 1. Re-create C:\Windows\System32\catroot2 according to the instruction from the article: https://answers.microsoft.com/en-us/windows/forum/windows_xp-performance/event-application-log-reports-multiple-event-id/5c13fd68-60b2-4f57-b4d9-3cfc83a4a618 2. Reboot the server 3. Retry the installation

The materials provided on the Advice and Solutions (Forum Knowledgebase) part of the Forum result from the work of the Kaspersky Customer Support team and Forum community members. They are shared here for ease of use of Kaspersky products, deploying and configuring them. Please remember that using commands or recommendations from the articles without a clear understanding of their purpose may result in errors or system inoperability. Please note that some materials presented are not official, so technical support may decline to support a specific unsupported configuration in some instances. Please also ensure to use the official documentation, found in this link.

Дисклеймер. Обязательно к прочтению перед использованием материалов базы знаний Форума. 1. Остановить сервис kics4net 2. Выполнить команду для "удаления" ТМ (имя точки мониторинга в этом примере "span"): sudo -u kics4net-postgresql /opt/kaspersky/kics4net-postgresql/libexec/postgresql/psql -h /var/run/kics4net-postgresql -p 5433 -d kics -c "UPDATE monitoring_point SET timestamp_deleted=CURRENT_TIMESTAMP WHERE name='span'" 3. Запустить сервис kics4net

Дисклеймер. Обязательно к прочтению перед использованием материалов базы знаний Форума. Description and cautions Статья описывает настройку функциональности взаимодействия программы KICS for Network с решением Kaspersky Security Center (KSC) в части получения обновлений антивирусных баз продукта, но при условии отсутствия DNS в сети. Использование IP в качестве адреса KSC не достаточно для настройки взаимодействия. Проблема актуальна для Astra Linux, на CentOS получить воспроизведение проблемы не удалось. Без внесения изменений в конфигурацию ОС подключение к KSC может завершаться ошибкой "Возникла ошибка на Сервере", а попытка обновить АВ базы всегда прерываться ошибкой "Установка обновлений не завершена из-за ошибки прервавшей процесс." Ошибка настройки взаимодействия с KSC: Задача обновления АВ баз: Details Требуется убрать алиас базы данных "dns" для поиска имен и добавить"myhostname": Открыть на редактирование конфигурационный файл модуля NSS: $ sudo nano /etc/nsswitch.conf Удалить значение из строки "hosts" удалить значение "dns": hosts: files dns На его место вписать новое "myhostname": hosts: files myhostname Сохранить изменённый файл нажатием CTRL+X и подтвердить сохранение Y. Перезагрузить ОС. Повторить попытку обновления АВ баз из источника KSC. Успешное обновление: Troubleshooting Если сохраняется ошибка "Установка обновлений не завершена из-за ошибки прервавшей процесс.", вероятно, хранилище АВ баз KSC не содержит баз KICS for Networks. Проверьте установлен ли плагин продукта, попробуйте выполнить очистку хранилища и повторить загрузку баз задачей на KSC. Related Information "Обновление баз и программных модулей": https://support.kaspersky.ru/kics-for-networks/4.0/167050 "Плагины управления программами для Kaspersky Security Center и Web Console": https://support.kaspersky.ru/ksc14/settings/host/9333 "Ошибка при обновлении программ в Kaspersky Security Center": https://support.kaspersky.ru/ksc13/troubleshooting/update/9307

Дисклеймер. Обязательно к прочтению перед использованием материалов базы знаний Форума. Description and cautions Статья описывает настройку узлов с ролями Сервер или Сенсор комплекса KICS for Networks в качестве Точек распространения (DP) с ролью Шлюза соединений (CGW) для управляемых устройств Kaspersky Security Center (KSC). На практике схема с DP может применяться в классическом виде для оптимизации передаваемого трафика обновлений между объектами в паре с правилами ограничений трафика для IP-диапазонов в KSC. Роль CGW может обеспечить сетевую связанность посредством узлов KICS, когда они являются единственным звеном выхода из изолированной сети объекта для подключения конечных устройств к общему KSC. Схема подключения проста, поскольку в состав Серверов KICS входит Агент администрирования KSC при наличии установленной функциональности взаимодействия программы KICS for Network с решением KSC. На Сенсоры KICS Агент администрирования KSC может быть доставлен из пакета отдельно. При использовании Серверов KICS есть определённые моменты, которые требуется учесть при организации подключения, именно о них будет пояснено в инструкции. Details Предварительные требования: Если CGW организуется на Сервере KICS, то настройку необходимо выполнять только после активации интеграции с KSC в разделе WebUI Сервера "Взаимодействие с Kaspersky Security Center". Активация взаимодействия с KSC сбрасывает параметры работы Агента администрирования KSC на Сервере KICS, роль CGW исчезнет. Для DP это не критично, но в инструкции основная тема узел KICS как CGW. Если CGW организуется на Сенсоре KICS, то следует установить пакет Агента администрирования KSC for Linux, поскольку в состав Сенсора Агент KSC не входит. Дистрибутив находится в пакете KICS, например: kics4net-4.0.0.388.pf3.zip\linux-centos\klnagent64-14.0.0-4490.x86_64.rpm Когда условия на узлах выполнены, следует разрешить входящие и исходящие подключения на Firewall узлов и перечитать параметры сервиса: firewalld на CentOS $ sudo firewall-cmd --permanent --add-port=13000/tcp $ sudo firewall-cmd --permanent --add-port=13295/tcp $ sudo firewall-cmd --reload UFW на Astra Linux: $ sudo ufw allow 13000/tcp $ sudo ufw allow 13295/tcp $ sudo systemctl restart ufw Приступить к конфигурированию Агента администрирования KSC на узле KICS: Если ранее узел уже был CGW, то повторное конфигурирование обновит ранее выданный от KSC сертификат для CGW и все подключенные через него устройства отключатся без возможности восстановления. Возобновить подключение удастся только через переустановку Агента администрирования KSC на конечных устройствах с повторной настройкой использования CGW на каждом потерянном в управлении устройстве. Выполнить конфигурирование Агента KSC на узле KICS командой: /opt/kaspersky/klnagent64/lib/bin/setup/postinstall.pl На последнем шаге мастера указать пункт "4) Use as connection gateway", поскольку узел требуется сделать CGW. Первые пару минут после конфигурирования Агент администрирования KSC перезапускается и применяет новые параметры. Поэтому после небольшой паузы следует выполнить команду диагностики Агента администрирования KSC и убедиться в корректности заданных параметров: /opt/kaspersky/klnagent64/bin/klnagchk Следующая строка подтверждает, что данный Агент администрирования KSC на узле является CGW и DP, параметры на последнем шаге мастера были заданы корректно: "This host was installed as a connection gateway, but not yet registered on server" Наличие буквенно-циферного значения ID в строке указывает, что Агент KSC успешно зарегистрирован на Сервере KSC: HostId: 6da79ad4-6ba4-45af-a853-8309d9f7d898 Connecting to server...OK Connecting to the Administration Agent...OK До момента добавления информации о новом CGW на стороне KSC, CGW не будет выполнять функцию шлюза соединений. В Свойствах Сервера KSC требуется добавить новые Точки распространения с ролью Шлюза соединений в DMZ с указанием Группы администрирования на какие устройства будет применяться CGW. Когда Точка распространения с ролью Шлюза соединений успешно зарегистрирована на Сервере KSC, в Свойствах объекта узла KICS появится установленная галка "Не разрывать соединение с сервером администрирования", её не следует снимать и устанавливать вручную для настройки CGW. После успешной регистрации DP/CGW на KSC на узле KICS утилита klnagchk будет выводить подтверждение успешной работы ролей Агента администрирования KSC: Host is a connection gateway Host is a distribution point <...> Connection with server: active CG connection with server: active Важно не удалять Агент администрирования KSC с узлов комплекса KICS for Networks, которые являются Точками распространения с ролью Шлюза соединений, поскольку будет утерян ранее выданный KSC сертификат для Агента администрирования KSC, который используют конечные устройства, подключенные к CGW. При повторной установке будет выдан уже новый сертификат для CGW и конечные управляемые устройства потребуется подключать повторно. То есть удалять на них Агент администрирования KSC и устанавливать снова с режимом работы через Шлюз соединений. Переключение через команду klmover не применимо к сценариям со Шлюзом соединений, помогает только переустановка Агентов администрирования KSC. Related Information Использованные при реализации задачи статьи справки KSC: "Подключение устройства под управлением Linux в качестве шлюза в демилитаризованной зоне": https://support.kaspersky.com/KSC/14.2/ru-RU/203996.htm "Добавление шлюза соединения в демилитаризованной зоне в качестве точки распространения": https://support.kaspersky.com/KSC/14.2/ru-RU/204253.htm "Назначение устройства точкой распространения вручную": https://support.kaspersky.com/help/KSC/14.2/ru-RU/3420.htm "Об обновлении баз, программных модулей и программ "Лаборатории Касперского"" (блок "Использование задачи Загрузка обновлений в хранилище Сервера администрирования"): https://support.kaspersky.com/KSC/14.2/ru-RU/46875.htm "Типовая конфигурация точек распространения: множество небольших удаленных офисов": https://support.kaspersky.com/KSC/14.2/ru-RU/92431.htm "Об использовании точки распространения в качестве шлюза соединений": https://support.kaspersky.com/KSC/14.2/ru-RU/45902.htm "Сценарий: Подключение автономных устройств через шлюз соединения": https://support.kaspersky.com/KSC/14.2/ru-RU/204219.htm "Сервер администрирования и два устройства в демилитаризованной зоне: шлюз соединений и клиентское устройство": https://support.kaspersky.com/KSC/14.2/ru-RU/158534.htm "Сервер администрирования внутри локальной сети (LAN), управляемые устройства в интернете; использование шлюза соединения https://support.kaspersky.com/KSC/14.2/ru-RU/183058.htm