Antipova Anna

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