All Activity

Problem: When deploy the SVM of KSV LA on the vSphere 6.5, the following error may occur: Reason： This issue occurs because vCenter Server cannot detect any vSAN storage provider. There is no way to detect vSAN storage provider if no hosts are available when vCenter Server starts. Note: vSAN storage provider cannot be recognized automatically even after host start working properly. Workaround: This is a known issue affecting vCenter Server. To workaround this issue, you have the following options: 1. Initiate synchronizing vSAN storage provider by clicking icon for synchronization in the page: vCenter Server -> Configure -> Storage Providers 2. Make sure at least one host is working when starting vCenter Server.

Вот поэтому и хочется прояснения ситуации от официального лица компании Касперский. Потому что в таком случае я могу тоже таких вопросов сомнений много начать задавать.

Download KES distributive Unpack to the folder Copy patch .msp file (i.e. pf1794.msp) to the same folder In KSC create Installation package using the files from this folder Install

How to connect to KWTS via SSH or receive the files via SCP? Below are the examples of using Putty and WinSCP tools. In the puttygen utility (from the Putty package): Type of the key to generate: RSA. Generate the key. Protect the key with a password (key passphrase). Save the private key. Copy the public key from the field "Public key for pasting into OpenSSH authorized_keys file" In the KWTS web interface: Paste the copied public key into the SSH key field https://support.kaspersky.com/KWTS/6.1/en-US/183526.htm In Putty: Specify the KWTS address for connection. In the "Category" field on the left, open: Connection - SSH - Auth. Click "Browse" and select the .ppk file of the private key. Connect to the KWTS node. Specify root user account. Enter the password for the key from step 1. In WinSCP: Specify the KWTS address for connection. In the "Advanced..." drop-down list, select Advanced. In the left frame, select Authentication in the "SSH" section. In the "Authentication parameters» section, specify the .ppk of the private key in the "Private key file" field. Click OK. Connect to the KWTS node. Specify root user account. Enter the password for the key from step 1.

KSO365 is a cloud solution. It does not work in the cloud by itself but together with Microsoft Exchange Online (EOL) and its anti-spam and anti-virus protection. In more than 95% of cases, Microsoft Forefront (Ff) performs the spam and virus scans first, due to Microsoft's cloud architecture. Thus, if Ff has identified an email as spam, virus, phishing, etc., and has done with it any action (according to the settings) except “Skip”, we do not check this email and do nothing with it. We cannot change the verdicts given by other applications. If an email went to the user's box without Ff detects or with the “Skip” action, KSO365 comes into play. It performs all the scans that the user has enabled, gives its verdicts and performs the actions configured by the user. Special mention should be made of the SCL parameter, which is necessary when working with spam detection. This is the only general letter parameter that KSO365 can change but only upwards.

To install the solution in the silent mode, run the command line with administrator rights and execute the following command: msiexec /i "<PATH_TO_MSI>" /qn ADDLOCAL="<FEATURES>" SQL_SERVER_NAME="<SQL_SERVER_NAME>" BACKUP_DATABASE_NAME="<DATABASE_NAME>" SQL_ACCOUNT_DLG_USER_TYPE="UserAccount" SQL_ACCOUNT_DLG_USER="<UserName>" SQL_ACCOUNT_DLG_PASSWORD="<Password>" SERVICE_ACCOUNT_DLG_USER_TYPE="UserAccount" SERVICE_ACCOUNT_DLG_USER="<UserName>" SERVICE_ACCOUNT_DLG_PASSWORD="<Password>" INSTALLDIR="<INSTALLATION_DIRECTORY>" DATADIR="<DATA_DIRECTORY>" /l*vx "<LOG_FILE_PATH>" <PATH_TO_MSI> - path to the installer msi file. For example, "c:\temp\kse80_en_us.msi" <FEATURES> - list of components. Examples: All components: Anti-Spam, Anti-Virus for hub, Anti-Virus for mailbox, DLP, Administration console: "Antispam,AvVsapi,Antivirus,AdminConsole,Service,Feature.Complete" Console only: "AdminConsole,Feature.Complete" Anti-Spam only: "Antispam,Service,Feature.Complete" Only Anti-Virus on Hub: "Antivirus,Service,Feature.Complete" Only Anti-Virus on Mailbox: "AvVsapi,Service,Feature.Complete" The Feature.Complete component must always be incuded. The Service component must be included in all cases except for Console only installation. <SQL_SERVER_NAME> - MS SQL SERVER name. For example, MYSERVER\SQLEXPRESS. It is not possible to use a dot to specify a current server. <DATABASE_NAME> - name of the database. For example, "SecurityForExchange". Parameters SQL_ACCOUNT_DLG_USER_TYPE, SQL_ACCOUNT_DLG_USER and SQL_ACCOUNT_DLG_PASSWORD are used for specifying a user account for accessing the SQL Server. If they are not specified, the application will use the parameters of the account under which installation is performed. Example: SQL_ACCOUNT_DLG_USER_TYPE="UserAccount" SQL_ACCOUNT_DLG_USER="Domain\Username" SQL_ACCOUNT_DLG_PASSWORD="Password" Parameters SERVICE_ACCOUNT_DLG_USER_TYPE, SERVICE_ACCOUNT_DLG_USER and SERVICE_ACCOUNT_DLG_PASSWORD are used for specifying a user account under which the application service will run. If they are not specified, the service will run under the Local System account. Example: SERVICE_ACCOUNT_DLG_USER_TYPE="UserAccount" SERVICE_ACCOUNT_DLG_USER="Domain\Username" SERVICE_ACCOUNT_DLG_PASSWORD="Password" <INSTALLATION_DIRECTORY> - path to the installation folder, by default: %ProgramFiles(x86)%. <DATA_DIRECTORY> - path to the data folder. By default it is located in the installation folder. <LOG_FILE_PATH> - path to log files, for example, "c:\temp\kseinstall.log"

Description When installing or upgrading KSE, you may encounter various issues when installing or starting our service. If a user has repeated the installation many times and changed many settings manually, we recommend to remove KSE completely using the instructions below. Cause There are files that remain in the system from a previous KSE installation, so a new installation cannot be successful. Solution Delete the remaining KSE files from the Exchange server manually. Follow the instructions below. 1. Delete all the remaining KSE agents. To do so, start Exchange Management Shell and run the following command: Get-TransportAgent -TransportService FrontEnd If the KSE agent is on the list, run the command: Uninstall-TransportAgent -TransportService FrontEnd -Identity "Kaspersky Security antispam Frontend Cas agent" 2. Run the following command: Get-TransportAgent See what KSE agents are on the list. Run the command below for every KSE agent. For example: Uninstall-TransportAgent “Kaspersky Security routing antispam filter agent” Uninstall-TransportAgent “Kaspersky Security antispam filter agent” Uninstall-TransportAgent “Kaspersky Security antivirus filter agent” Insert the names of KSE agents from your list. 3. Restart the Transport Agent service using the command: Restart-Service "MSExchangeTransport" 4. To make sure that there are no more KSE agents, run the following commands again: Get-TransportAgent -TransportService FrontEnd and Get-TransportAgent 5. Set Disabled for Kaspersky Security For Microsoft Exchange Servers service startup and stop our service. 6. Import the removeregkeys.zip archive to the registry. 7. Restart the MSExchangeIS service: restart-Service MSExchangeIS 8. Remove the folder where KSE was installed. If possible, restart the server.

Description When trying to deliver any message from Backup, the following error occurs: Facade::DeliverMessage failed. [0xeceb0013] Details: Cannot create temporary file, code: 0xeceb0013. Solution Add to the /usr/lib/tmpfiles.d/tmp.conf file the following exclusions: x /tmp/klms* x /tmp/klmstmp/ x /tmp/klms_filter/ x /tmp/klmstmp/* x /tmp/klms_filter/* Restart the klms service. If the issue persists, send a screenshot of the information from the web interface to Kaspersky Support. Click System information - Create and take a screenshot.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. When troubleshooting typical KSC issues, you will likely need to check the availability of TCP port 13000 on the KSC Server. Both telnet and akconnect tools can be used to achieve this. Syntax is very simple: akconnect host port Examples: akconnect.exe 192.168.1.19 13000 >akconnectoutput.txt telnet 192.168.1.19 13000 >telnetoutput.txt Where 192.168.1.19 is the IP address or DNS name of the KSC Server and 13000 is the port number. Results will be logged to .txt files that should be sent to Kaspersky support for verification. Please be advised that telnet is not installed by default in the recent versions of Windows. You can add it using the appwiz.cpl→Add feature. You can download the akconnect utility here.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. If two different update agents on a PC are assigned in different ways: To an administration group. Based on a network location. Which one will have a higher priority for the PC? Among the update agents assigned to administration groups, the one assigned to the administration group, that is closest to the target host in the group hierarchy, has the higher priority. If the update agents are assigned to the same group, they have an equal priority. The priority of update agents assigned based on the network location is equal to the priority of the nearest update agent in the group hierarchy. If two update agents have the same priority, the one, the route to which is closer in the number of passed routers, is selected. If two update agents have the same priority and the network distance to them is the same, the agent is selected randomly.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Dynamic hosts require more KSC resources than regular hosts. When a new host is connected to KSC (and the dynamic host is considered new), an icon and a new entry in the database are created, full synchronization with the agent is performed, and the host moved to a group. When the host is deleted, all information about it is deleted as well. These operations consume a lot of KSC resources, while static hosts require them to be performed only once. Recommended sizing (no more than 20 000 VDI hosts) may not be fully and correctly loaded. In industrial use, for each icon the following network lists are created: - hardware - installed software - detected vulnerabilities - events and lists of executable files of the Application control component. Size of these lists directly affects KSC performance as well as SQL server performance when performing internal procedures, and the load may grow in the non-linear way. If the use of the solution with your policy settings, environment and virtual desktop properties shows moderate consumption of resources during standard operations, then the number of managed VDI hosts can be increased up to the limit of resources available in the current configuration. Consumption of 80% of memory and 75-80% of available cores is considered moderate.

Problem After "Nessus" vulnerability scanning on Central node 4.0 servers, you may see the following: Ports: 22-tcp Description: The remote SSH server is configured to allow key exchange algorithms which are considered weak. This is based on the IETF draft document Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH) draft-ietf-curdle-ssh-kex-sha2-20. Section 4 lists guidance on key exchange algorithms that SHOULD NOT and MUST NOT be enabled. This includes: diffie-hellman-group-exchange-sha1 diffie-hellman-group1-sha1 gss-gex-sha1-* gss-group1-sha1-* gss-group14-sha1-* rsa1024-sha1 This is about a IETF proposed standard (formerly a draft) introduced in January 2022 after KATA 4.0 release. These IETF recommendations are addressed in KATA version 5.0. Solution Disclaimer This security hardening procedure is done "at your own risk", at the present moment we don't suggest to apply it preemptively. KATA 4.0 has OpenSSH_7.4p1, OpenSSL 1.0.2k-fips. This version supports newer Key Exchange (KEx) algorithms, so disabling weaker ones doesn't pose a problem. However, the list of key exchange algorithms that are accepted by GSSAPI key exchange for this version have only the ones that are named weak by the IETF draft, man SSHD_CONFIG(5) says: GSSAPIKexAlgorithms The list of key exchange algorithms that are accepted by GSSAPI key exchange. Possible values are gss-gex-sha1-, gss-group1-sha1-, gss-group14-sha1- Therefore, the only option to remove these in OpenSSH_7.4p1, is to disable GSSAPI key exchange. GSSAPI however is used by Kerberos authentification, so the possible impact is that Kerberos integration may be affected after these changes. So, in order to achieve the desired result: Open /etc/ssh/shh_config #vi /etc/ssh/shh_config Locate the line GSSAPIAuthentication yes Change it to "no": GSSAPIAuthentication no Add (or uncomment) the line GSSAPIKeyExchange no Add the line defining the KEX algorithms to be used. These are all the algorithms supported by existing version of OpenSSL except the weak ones: KexAlgorithms diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,curve25519-sha256,curve25519-sha256@libssh.org Exit vi and save :wq! Restart sshd #systemctl restart sshd Confirm applied changes by listing the loaded gssapi settings and KEX algorithms. # sshd -T | grep kex # sshd -T | grep gssapi

Access to the Microsoft quarantine is carried out immediately after the issuance of the consent. Additional quarantine access accounts, that were subject to the MFA restriction in the previous versions, are no longer required for quarantine access. The connection is carried out using the application to which the consent is issued.

Why are emails detected by Microsoft Exchange Online not being detected by KS365? Because "first come, first served"? Yes. In more than 95% of cases, Microsoft Exchange anti-malware and anti-spam filters are processing all objects before KS4O365. That being said, all the detections performed by our application are actually detections of mail flow that has already been scanned by Microsoft filters if they are not disabled. If some email was already scanned and quarantined by Microsoft, then we do not receive it for scanning, as it was already done on the Microsoft side.

If multiple e-mails are selected in Security for Microsoft Office 365, they cannot be saved to disk. You can only save them one by one.

If anti-spam detects an e-mail as not definitely categorized as clean, it moves the e-mail to the "Temporary Quarantine" for 50 minutes to re-scan it with updated anti-spam databases. If upon after this 50 minutes' time the e-mail is not defined as spam, it is released automatically without any interaction with the user. The administrator has an option to manually release such e-mails from "Temporary Quarantine" before the 50 minute period ends. At the same time, the e-mail will remain in quarantine with the status "Released".

Is there any capacity limit of mails in the Quarantine zone? If any, can we modify it? Unfortunately, there is no possibility to customize this setting per user, it is hardcoded in the product (30 days for objects in the backup and 92 days for statistics). Is there any limit on the number of emails that can be stored in the Quarantine? On the KS4O365 side, there isn't a limit to the number of emails that can be saved in the backup. KS4O365 stores only metadata information about the emails in the backup, which is quite small in comparison to the email itself. Whereas the backup emails themselves are stored in the mailbox (in a hidden folder) on the Exchange online server that hosts mailboxes. When the object is restored from the Quarantine, the email from a hidden folder is simply moved to the inbox. That being said, the only limit that can be identified in the said scenario is the one from the Exchange online itself (the size of the mailbox for a particular user). I.e. if the total amount of emails in the inbox + emails in the backup will hit the limit of the free space in the Exchange Online mailbox, then the you will need to increase the size of the mailbox or remove the exceeding emails, etc. The emails from quarantine can be deleted from the Quarantine tab of the console, there you can also sort by date to delete the old ones.

Scenario: Phishing links are detected but some emails are allowed through, even though the selected Action is Move to Junk Email folder . Solution: The original e-mail was already located in the Junk folder when our product started to scan it. The "Allow through" action was performed, in this case it means that we've added the phishing tag to the e-mail and left it in the Junk folder. Most likely this e-mail was detected by some third-party anti-malware/phishing solution (Microsoft anti-malware filters in EWS, for example) and was moved to Junk, then we've scanned it and there was nothing to do with it except adding the tag to it.

In order to send messages from backup with headings without saving them, please navigate to:

Version: Kaspersky Security for Exchange 9.5.10000.64, 9.6.96 Scenario In Kaspersky Security 9.0 for Microsoft Exchange Servers there's the following error event: "AM Error Kernel: The Anti-Virus (Anti-Spam) module has been switched to limited scan mode for next 30 minutes. Some objects may be skipped without being scanned." The same error message appears on the KSE console: Solution Sometimes Exchange tries to give KSE more emails to check than KSE is able to to check. In order to prevent delays in mail delivery, the anti-virus or/and anti-spam engine switches to a special mode of operation called "Limited scan mode". This mode lasts for 30 minutes. During this period, some emails may be skipped for checking. The transition to normal mode is carried out automatically after the time specified above. You can find out about this mode of operation in our Online Help: https://support.kaspersky.com/KS4Exchange/9.6/en-US/28854.htm https://support.kaspersky.com/KS4Exchange/9.6/en-US/99915.htm https://support.kaspersky.com/KS4Exchange/9.6/en-US/28871.htm

Scenario Kaspersky Security for Exchange installation failed with the following error: "Failed to grant rights to run under a different name (impersonation) for Kse Watchdog Service". Solution If you get the error message about impersonation, execute the following command in PowerShell: Add-PsSnapin Microsoft.Exchange.Management.PowerShell.E2010 Remove-ManagementRoleAssignment KSE_IMPERSONATION -Confirm:$False Press the Retry button.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Version: Kaspersky Security for Exchange 9.0 MR5 (9.5.10000.64) Scenario The following error message appears: "Access denied. To manage application features, the user's account must be added to one of the following Active Directory groups: KSE Administrators KSE AV Security Officers KSE AV Operators KSE Security Officers." Solution This error means that the account under which the KSE management console is running is not part of any of the KSE management groups listed above in the error text. The user needs to decide what role the user’s account will perform and include this account in the corresponding KSE group created in their Active Directory (AD). You can learn more about the roles in our Online Help: https://support.kaspersky.com/help/KS4Exchange/9.5/en-US/81511.htm

Version: KSE for Microsoft Exchange Server versions 9.5.10000.64, 9.6.96. Scenario: We have established a workaround to a problem with invalid SQL server parameters during its installation. An error about invalid SQL server parameters occurred during the installation: "The server was not found or was not accessible. Verify that the instance name is correct, and that SQL Server is configured to allow remote connections. Error 26 - Error Locating Server/Instance Specified". We have found the following information from installation log: Installation log showed the SQL server "CRATER\SQLEXPRESS" was used for the installation: We found that the configuration file "BackendDatabaseConfiguration*.config" which was used for configuring the SQL server was using the server name "CRATER". Solution: If you're sure that "CRATER\SQLEXPRESS" is the real name of the SQL server, replace "CRATER" in the SQL server name by "CRATER\SQLEXPRESS" in the following objects: 1. "X:\%KSE_Folder%\Configuration\BackendDatabaseConfiguration*.config" file. If there are several such files in this folder, do it for all of them. 2. In the system registry "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Kaspersky Lab\Kaspersky Security for Microsoft Exchange Server". Parameter is BackendSqlServerName. Start the upgrade again.

In most cases the issue is related to processing downloaded bases on the server drive. Databases are downloaded from our sites successfully, but the problem appears during compiling and copying the downloaded bases locally on the KSE server. Such behavior may be caused by the following: Not configured exclusions for KSE in Kaspersky Security for Windows Server or Kaspersky Endpoint Security. Other utilities (backup, for example), that may interfere with the file processing. Incorrect operation of the delete function on high-speed drives, for example, SSD drives. Solution: 1. Configure Kaspersky Security for Windows Server or Kaspersky Endpoint Security for correct simultaneous work with KSE. Completely exclude the KSE folder, all subfolders and KSE processes from the scan scope: Kavscmesrv.exe Antiphishing.OutprocScanner.exe Antispam.OutprocScanner.exe Antivirus.OutprocScanner.exe Kse.Ksn.exe Kse.Licensing.exe Kse.Updater.exe 2. Set the startup type of KSE service to manual. 3. Stop the KSE service. 4. If issue is related to corrupted AS bases, delete all contents from the folders: C:\Program Files (x86)\Kaspersky Lab\Kaspersky Security for Microsoft Exchange Servers\data\bases\as\bases C:\Program Files (x86)\Kaspersky Lab\Kaspersky Security for Microsoft Exchange Servers\data\bases\ap\bases C:\Program Files (x86)\Kaspersky Lab\Kaspersky Security for Microsoft Exchange Servers\data\bases\ap\cache If issue is related to corrupted AV bases, delete all contents from the folders: C:\Program Files (x86)\Kaspersky Lab\Kaspersky Security for Microsoft Exchange Servers\data\bases\av\bases C:\Program Files (x86)\Kaspersky Lab\Kaspersky Security for Microsoft Exchange Servers\data\bases\av\cache If issue is related to corrupted AS and AV bases, delete all contents from the all folders: C:\Program Files (x86)\Kaspersky Lab\Kaspersky Security for Microsoft Exchange Servers\data\bases\as\bases C:\Program Files (x86)\Kaspersky Lab\Kaspersky Security for Microsoft Exchange Servers\data\bases\ap\bases C:\Program Files (x86)\Kaspersky Lab\Kaspersky Security for Microsoft Exchange Servers\data\bases\ap\cache C:\Program Files (x86)\Kaspersky Lab\Kaspersky Security for Microsoft Exchange Servers\data\bases\av\bases C:\Program Files (x86)\Kaspersky Lab\Kaspersky Security for Microsoft Exchange Servers\data\bases\av\cache 5. Set the startup type of KSE service back to automatic/ automatic (Delayed Start), as it was before adjustment at step 2. 6. Start the KSE service. 7. Update anti-spam or/and anti-virus bases manually through KSE Management Console. 8. If the issue persists, contact Kaspersky Support.

Вы самолично наблюдали за процессом связывания? Решили уже путем смены драйвера в настройках. По крайней мере, так гласит инструкция. С чего они должны что-то делать еще - неясно.