Antipova Anna
-
Posts
352 -
Joined
-
Last visited
Posts posted by Antipova Anna
-
-
Дисклеймер. Обязательно к прочтению перед использованием материалов базы знаний Форума.
Сценарий
- В Контроле устройств включено блокирование флэш-накопителей.
- Флэш-накопитель подключен к хосту.
В результате KES показывает всплывающее окно о том, что USB-накопитель заблокирован компонентом Контроль устройств, однако пользователь может открыть флэш-накопитель и прочитать/изменить его содержимое.
Основная причина проблемы
На хосте установлена программа SecretDisk5.
Решение
У производителя (Alladin) есть решение этой проблемы.
-
Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.
You may wonder which product detection should create incident card, and which should not. Here's the answer.
ProductComponentKES WebAV, MailAV, OAS/ODS, SystemWatcher, HIPS KSWS OAS, ODS, TrafficSecurity KSV LA WebAV, MailAV, OAS/ODS, SystemWatcher, HIPS -
Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.
Problem
Using EDR, you may encounter an issue where you're unable to view incident card regarding a detection in KSC Web Console. It looks like this:
Here we will discuss known causes of such behavior (several products are involved, so causes may be different).
Possible causes and solutions
MDR
In MDR, incidents are to be viewed using the dedicated MDR Console, and KSC version 13 and newer with configured MDR plug-in. KSC 12.* Web Console will not receive the data; this is expected behavior.
KES+KEA
If you first install KES without EA component, and then a standalone KEA package, KES EDRO integration will be disabled and killchain will not work.
Here is a quick way to determine if KEA was installed as a component of KES. Open regedit, then navigate to:
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\KasperskyLab\protected\KES\Installer\features]
"AntiAPTFeature" = "1"If the value is
0, proceed to the workaround to enable the component as described below.To fix this, we ran Change application components task on the host, enabling Endpoint Agent in KES.
If KES/KEA integration is configured correctly, we can find the following in KES traces:
12:08:37.4260x2a18INF edr_etw Start processing detect = http://www.virusanalyst.com/eicar.zip//eicar/eicar.com, recordId = 6, taskId = 1128, result = 012:08:37.4260x2a18INF edr_etw Start processing actions = http://www.virusanalyst.com/eicar.zip//eicar/eicar.com, action = 4, recordId = 6, taskId = 1128, edrAction = 3489660999, result = 012:08:37.4420x2a18INF edr_etw Killchain is enabled!12:08:37.4420x2a18INF edr_etw SystemWatcher is running!12:08:37.4420x2a18INF edr_etw product::component::edr::`anonymous-namespace'::IsSystemWatcherDetect begin12:08:37.4420x2a18INF edr_etw product::component::edr::`anonymous-namespace'::IsSystemWatcherDetect end12:08:37.4420x2a18INF edr_etw product::component::edr::`anonymous-namespace'::InvestigateProcessIds begin12:08:37.4420x2a18INF edr_etw product::component::edr::`anonymous-namespace'::InvestigateProcessIds end12:08:37.4420x2a18INF edr_etw Finish processing detect = http://www.virusanalyst.com/eicar.zip//eicar/eicar.com threat status = 1, recordId = 6, taskId = 1128,result = 012:08:37.4580x1f18INF edr_etw Finish processing AV detect result =0Searching for ThreatID in KEA traces:
12:08:37.4260x2a18INF amfcd ThreatsProcessingEventsLogic::OnTreatActionImpl: ctx:0x23d68510[TI0x1b8dd490: id =0x6, : tdid = {7F620459-6C51-9E46-9A5D-689A9B0D0098}, name = http://www.virusanalyst.com/eicar.zip//eicar/eicar.com, add info: <none>, 0x0] 0x4 0x0KES+KEA (upgrade from KESB to EDR Optimum)
EDR Optimum requires KSC 12.1 or newer to work. This includes the Network Agent, which is a part of KSC, and is generally installed on the host alongside KES.
Using an outdated version of Network Agent (10.5, 11, etc.) will lead to the mentioned error when opening incident cards. If Network Agents were not upgraded along KSC, it's better upgrading them for EDR Optimum.
KES 11.7+
Check that EDR Optimum feature is enabled in registry (GSI > Registry > HKLM_Software_Wow6432Node_KasperskyLab.reg.txt ).
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\KasperskyLab\protected\KES\Installer\features]
EdrOptimumFeature = 1
If value is 0, run Change application components task on the host, enabling EDR Optimum in KES.
Also in traces (*.SRV.log) you can search for sentence bundles::InstalledFeaturesProvider::InstalledFeaturesProvider and check that EDROptimumFeature is there, for instance in example below such component is missing
KES.21.9.6.465_05.18_14.00_3952.SRV.log11:00:36.897 0x26a0 INF bundles::InstalledFeaturesProvider::InstalledFeaturesProvider{ 3 (AVScannerAndCoreFeature) 28 (AdaptiveAnomaliesControlFeature) 0 (AdminKitConnectorFeature) 24 (AdvancedThreatProtectionFeature) 27 (AmsiFeature) 7 (ApplicationControlFeature) 17 (BehaviorDetectionFeature) 30 (CloudControlFeature) 4 (CriticalScanTask) 6 (DeviceControlFeature) 23 (EssentialThreatProtectionFeature) 11 (ExploitPreventionFeature) 8 (FileThreatProtectionFeature) 19 (FirewallFeature) 5 (FullScanTask) 2 (HostIntrusionPreventionFeature) 16 (MailThreatProtectionFeature) 14 (NetworkThreatProtectionFeature) 12 (RemediationEngineFeature) 25 (SecurityControlsFeature) 18 (UpdaterTask) 21 (WebControlFeature) 20 (WebThreatProtectionFeature) 22 (WholeProductFeature) }KSWS+KEA
The same rule applies: KEA component needs to be installed in KSWS. KSWS does not have a "Change application components" task in KSC, so this has to be taken into account during KSWS deployment.
Here is a quick way to determine if KEA was installed as a component of KSWS. Open regedit, then navigate to:
[HKEY_LOCAL_MACHINE\Software\Wow6432Node\KasperskyLab\\WSEE\11.0\Install]
"Features"="AntiCryptorNAS=0;AntiCryptor=0;AntiExploit=0;AppCtrl=0;AVProtection=0;DevCtrl=0;Fim=0;Firewall=0;ICAPProt=0;IDS=0;Ksn=0;LogInspector=0;Oas=0;Ods=0;RamDisk=0;RPCProt=0;ScriptChecker=0;Soyuz=0;WebGW=0"
(Soyuzneeds to be set to1)If
Soyuzis set to0, apply workaround to enable it. KSWS allows to change its components locally or via cli.Here is the example of how to set Soyuz=1 when KEA was installed not as a component of KSWS:
1. Locate ks4ws_x64.msi or ks4ws.msi (depends on OS architecture)
2. Create custom installation package based on ks4ws_x64.msi or ks4ws.msi from p.1 with parameters as per screenshot (add UNLOCK_PASSWORD= if KSWS is protected by password in policy)
3. Deploy package on problematic servers with KSWS and KEA, then check registry that Soyuz=1
4. Check host's properties at KSC side - EDRO should be in Running state in KEA
If KSWS/KEA integration is configured correctly, we can find the following in KSWS traces:
19:57:04.5777a81310info [edr] Published ThreadDetected:VerdictName : HEUR:Win32.Generic.Suspicious.AccessRecordId :0DatabaseTime :18446744073709551615ThreatId : {ffb58079-6d8d-4a62-8ab0-021ff4ed61c5}IsSilent :falseTechnology :3489661023ProcessingMode :3489660948ObjectType :3489660934ObjectName : C:\Windows\System32\wbem\WmiPrvSE.exeMd5 : e1bce838cd2695999ab34215bf94b501Sha256 : 1d7b11c9deddad4f77e5b7f01dddda04f3747e512e0aa23d39e4226854d26ca2UniquepProcessId:0xf7c807730e051a0dNativePid :3360CommandLine :AmsiScanType :AmsiScanBlob :FileCreationTime:1601-01-06T23:09:56.075520800ZSearching for ThreatID in KEA traces:
19:57:05.5837049b0 debug [bl] ThreatsHandler: detect v2verdictName: HEUR:Win32.Generic.Suspicious.AccessdetectTechnology:0xd000005fprocessingMode:0xd0000014objectType:0xd0000006objectName: C:\Windows\System32\wbem\WmiPrvSE.exenativePid:3360uniquePid:17854528913448180237nativePidTelemetry:3360uniquePidTelemetry:17854528913448180237downloaderUniqueFileId: <none>downloadUrl: <none>isSilentDetect:falsethreatId: ffb58079-6d8d-4a62-8ab0-021ff4ed61c519:57:05.583704650info [evtstt] NetworkConnectionHandler statistics: queueSize=0, received=59675, processed=59675, dropped=0, queueBytes=19119:57:05.583704650info [evtstt] NetworkConnectionHandler statistics: queueSize=0, received=59676, processed=59676, dropped=0, queueBytes=13219:57:05.583704650info [evtstt] NetworkConnectionHandler statistics: queueSize=0, received=59677, processed=59677, dropped=0, queueBytes=37119:57:05.5837049b0 debug [bl] Threats Handler: event processed, id =219:57:05.5847041fc debug [killchain] Message discarded: name = ThreatDetectThe verdict is Message discarded, this means the detection won't trigger killchain generation.
No such entries can be found in traces, which might mean that EPP integration is not configured correctly (EDR component is disabled in KSWS).
Check killchain presence on the host
If all pre-requisites are met, it's worth checking if killchain files are actually created on the host. To check that, run
cmd.exeasAdministratorand check the c:\ProgramData\Kaspersky Lab\Endpoint Agent\4.0\Data\killchain\detectsfolder contents. Archives with <threat_id>.zip names should be present in the folder:C:\WINDOWS\system32>dir"c:\ProgramData\Kaspersky Lab\Endpoint Agent\4.0\Data\killchain\detects"Volume in drive C has no label.Volume Serial Number is8010-ADC0Directory of c:\ProgramData\Kaspersky Lab\Endpoint Agent\4.0\Data\killchain\detects08/16/202112:20PM <DIR> .08/16/202112:20PM <DIR> ..08/16/202109:34AM6360349c190-4ac3-4da4-9b64-07835298660f.zip//this is an archive with killchain info08/16/202112:18PM6961d306aa7-f37f-4ab2-969e-d337d398a995.zip08/16/202109:34AM63723a5dc93-5776-43c8-b949-79c102aa1184.zip08/16/202112:19PM69127bc9ea3-200b-49d2-b8b0-df7954cd428a.zip08/16/202112:19PM68340673c70-9e8e-420f-b5ce-65b406862b94.zip08/16/202112:19PM688590b6e30-4509-4b25-bdb0-062f89b7e062.zip08/16/202112:20PM69367993612-dc82-45a2-9e5b-74756adc46eb.zip08/16/202112:20PM6856a892bd1-f452-42d0-80b0-cb953cd7fc26.zip08/16/202112:19PM686a63fbafa-fcef-46f7-935f-42be4392a172.zip08/16/202112:19PM699d9d4f5eb-42b2-4460-8f8a-eb63bbef8791.zip08/16/202112:19PM686f6042624-9840-4a6e-9b30-9270cce22236.zip11File(s)7,480bytes2Dir(s)240,763,092,992bytes free -
Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.
How to monitor KATA system health such as CPU, HDD, Memory usage, services status and etc? How to output this information？
Locally, monitoring product operation and component health can be done in KATA dashboard. CPU, memory or similar metrics can be viewed using built-in Linux tools in support mode. Available remote monitoring options are:
- Using SNMP
- Hearbeats in SIEM integration
- Email notifications about alerts and system health.
-
For Sandbox component - only SSL probing option is available
echo "Q" |openssl s_client -connect sandbox:443
-
Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.
Problem Description, Symptoms & Impact
When trying to activate KES with valid License for KATA EDR (License contains Licensing object 184), Activation Task results in error "Internal data incompatible with this application".
Cause
The KATA Built-In KES component EDR (KATA) responsible for integration is not installed on target machine.
Diagnostics
-
In KSC -> Application properties, Endpoint Detection and Response (KATA) component version is listed as <N/A>, "Not installed" may be masked with "Not supported by license".
-
In registry,
[HKEY_LOCAL_MACHINE\Software\Wow6432Node\KasperskyLab\\protected\KES.21.13\Installer\features]
Key "AntiAPTFeature"=dword:00000001 is missing -
In logs:
in *.SRV.log (trace file) line forbundles::BundlesControllerImpl::GetNotInstalledFeaturesbundles::InstalledFeaturesProvider::InstalledFeaturesProviderline09:58:42.239 0x2bf4 INF bundles bundles::BundlesControllerImpl::GetNotInstalledFeatures Not installed features (1): 1
09:54:03.788 0x2050 INF bundles::InstalledFeaturesProvider::InstalledFeaturesProvider{ 3 (AVScannerAndCoreFeature) 0 (AdminKitConnectorFeature) 24 (AdvancedThreatProtectionFeature) 27 (AmsiFeature) 7 (ApplicationControlFeature) 17 (BehaviorDetectionFeature) 4 (CriticalScanTask) 23 (EssentialThreatProtectionFeature) 11 (ExploitPreventionFeature) 8 (FileThreatProtectionFeature) 19 (FirewallFeature) 5 (FullScanTask) 14 (NetworkThreatProtectionFeature) 12 (RemediationEngineFeature) 25 (SecurityControlsFeature) 18 (UpdaterTask) 22 (WholeProductFeature) }in *.SRV.log (trace file) for good machine bundles::InstalledFeaturesProvider::InstalledFeaturesProvider will list
1 (AntiAPTFeature)08:14:31.733 0x1e30 INF bundles::InstalledFeaturesProvider::InstalledFeaturesProvider{ 3 (AVScannerAndCoreFeature) 0 (AdminKitConnectorFeature) 24 (AdvancedThreatProtectionFeature) 1 (AntiAPTFeature) 7 (ApplicationControlFeature) 15 (BadUSBAttackPreventionFeature) 17 (BehaviorDetectionFeature) 4 (CriticalScanTask) 6 (DeviceControlFeature) 23 (EssentialThreatProtectionFeature) 11 (ExploitPreventionFeature) 8 (FileThreatProtectionFeature) 5 (FullScanTask) 16 (MailThreatProtectionFeature) 14 (NetworkThreatProtectionFeature) 12 (RemediationEngineFeature) 25 (SecurityControlsFeature) 18 (UpdaterTask) 21 (WebControlFeature) 20 (WebThreatProtectionFeature) 22 (WholeProductFeature) }
Solution
NB!
EDR Optimum, EDR Expert and EDR (KATA) components are not compatible with each other. Only one can be installed.
- Create Change Components Task for affected machines
- Execute Task
- Verify the component is installed.
How to check that KES 'KATA' component is enabled, up and running
1) Let's check that component is enabled first
In GSI > Registry > HKLM_Software_Wow6432Node_KasperskyLab.reg.txt > [HKEY_LOCAL_MACHINE\Software\Wow6432Node\KasperskyLab\\protected\KES.21.13\Installer\features] > "AntiAPTFeature"=dword:00000001 (should be like this)
2) Search in *.SRV.log (trace file) for bundles::InstalledFeaturesProvider::InstalledFeaturesProvider
08:14:31.733 0x1e30 INF bundles::InstalledFeaturesProvider::InstalledFeaturesProvider{ 3 (AVScannerAndCoreFeature) 0 (AdminKitConnectorFeature) 24 (AdvancedThreatProtectionFeature) 1 (AntiAPTFeature) 7 (ApplicationControlFeature) 15 (BadUSBAttackPreventionFeature) 17 (BehaviorDetectionFeature) 4 (CriticalScanTask) 6 (DeviceControlFeature) 23 (EssentialThreatProtectionFeature) 11 (ExploitPreventionFeature) 8 (FileThreatProtectionFeature) 5 (FullScanTask) 16 (MailThreatProtectionFeature) 14 (NetworkThreatProtectionFeature) 12 (RemediationEngineFeature) 25 (SecurityControlsFeature) 18 (UpdaterTask) 21 (WebControlFeature) 20 (WebThreatProtectionFeature) 22 (WholeProductFeature) }
-
In KSC -> Application properties, Endpoint Detection and Response (KATA) component version is listed as <N/A>, "Not installed" may be masked with "Not supported by license".
-
Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.
You may want to have full certificate chain for KATA Web UI. Here's how to do it.
Step-by-step guide
Preparing the certificate chain for use in nginx_gateway configuration
We start with full certificate chain in familiar form. Please note that certificate chain should contain desired intermediate authorities' public keys. Do not add private key to the chain.
First of all, we transfer it to the Central Node. It's recommended to do all further actions on Central Node, as in different *nix environments further steps may give different result.
To use it for product configuration, we should convert it to format, used by etcd.
Note that certificate is in one line, and that line breaks (CRLF) are replaced by \n symbols. So that's what we should do with our certifciate:
-
add \n to the end of each line:
sed's/$/\\n/'< cert.json > cert_n.json -
Remove line breaks:
tr -d'\n'< cert_n.json > cert_oneline.json
Now, certificate chain is ready to be used in nginx_gateway configuration.
Importing the prepared certificate chain to nginx_gateway
The most convenient way is to first export nginx_gateway configuration to JSON format:
apt-settings-manager get /configuration/nginx_gateway | python -m json.tool > /tmp/nginx_gatewayNow, find the place where certificate is located and replace it with created certificate chain.
Import the configuration back:
apt-settings-manager set /configuration/nginx_gateway @/tmp/nginx_gatewayAnd that's it, now browsers will receive full certificate chain for KATA Web UI.
-
-
Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.
Article applies to KSC13-14.2
Consider the following scenario:
- Open KSC MMC console;
- Go to Kaspersky licenses;
- Select KSC license.
Devices on which the license key is active is zero regardless of fact that this key is assigned as active on KSC Server:
Explanation
In older versions of Kaspersky applications, several license key files were provided to activate different products - one for KSC - 1 license unit and another for workstations and servers (Kaspersky Security for WS and FS) - in this example, 150 license units.
In this example, 151 license units.
In newer versions of Kaspersky applications, an activation code is provided (activation 2.0 format). When you activate an application with this activation code, total number of license unit is 150, this is 1 fewer than 151 because KSC Server consumed 1 license.
Solution
The license for KSC server is not counted. This applies only to activations codes.
- Re-configure Report on usage of license keys to display all summary fields;
-
Re-generate the report - it will display KSC license as active on KSC Server:
- Open the properties of KSC server→License keys to make sure it is activated with a valid license.
-
1
-
Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.
Product: Any KSC version
Problem Description, Symptoms & Impact
Network Agent local installation errors: "Setup Wizard cannot process the command line", "Setup wizard cannot process the internal error."
Diagnostics
Error can be found on the screenshots or in the installation log.
Workaround & Solution
Some leftover registry records should be deleted, but there are too many different cases to describe them all.
Collect detailed information about the error, GSI (https://support.kaspersky.com/common/diagnostics/3632) with Windows Event Log and following registry hives export, and create a case in https://companyaccount.kaspersky.com for further investigation by Kaspersky Experts.
Registry hives to export:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\
HKEY_CLASSES_ROOT\Installer\ProductsThis article describes how to export registry keys:
https://support.kaspersky.com/common/diagnostics/8576#block2
RCA
Leftovers of previously installed Network Agent.
-
Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.
Sometimes it's not clear how KSC assigns Distribution Point (DP) for Managed groups or NLA subnets, and how clients choose DP.
Automatic assignment of distribution points is enabled in Kaspersky Security Center by default. The Administration Server automatically selects the scopes for distribution points, and assigns one or multiple distribution points to each scope depending on how many client computers it includes.
The Administration Server first considers how many managed computers it has in total. If there are fewer than 300, the Administration Server does not assign distribution points automatically. If there were more than 300 but later they decreased to fewer than 300, the server does not stop automatic assignment. Automatic assignment stops only if the total number of managed computers becomes fewer than 200. Then all (remaining) automatically assigned distribution points become ordinary managed computers.
If automatic assignment is active (not just enabled but the number of endpoints is also above the threshold), the KSC Server selects which scopes to assign to distribution points, and then selects one or multiple distribution points for each scope depending on the number of managed computers in the scope.
Kaspersky Security Center can assign distribution points to three types of scopes:
- Administration groups
- Broadcast domains
- Network locations
Administration groups and network locations are structures defined in the Kaspersky Security Center Console. A broadcast domain is a logical division of a computer network in which all endpoints can exchange data by broadcasting at the data link layer of the OSI network model.
Kaspersky Security Center can automatically assign distribution points either to groups or to broadcast domains. An administrator can manually assign a distribution point to a group or network location.
The Administration Server attempts to define broadcast domains for all endpoints of the network. This is an automatic process that is performed in the background and takes multiple hours depending on the network’s specifics. Until the KSC Server defines a broadcast domain for 70% of endpoints in the network, it assigns distribution points to groups. As soon as the percentage of endpoints whose broadcast domain is known exceeds 70%, the KSC Server begins to assign distribution points to broadcast domains. The type of scope changes only once and is irreversible.
Regardless of the currently used scope type, the Administration Server looks at the number of endpoints in each scope (in a group without taking its subgroups into account, or in a broadcast domain), and assigns distribution points depending on the number of endpoints in the scope:
- If there are fewer than 10 endpoints in a scope, a distribution point is not assigned.
- If there are more than 10 but fewer than 20 endpoints, one distribution point is assigned.
- If there are more than 20 but fewer than 300 endpoints, two distribution points are assigned.
- If there are more than 300 but fewer than 600 endpoints, 3 distribution points are assigned.
- For larger numbers, if there are more than 300 * N endpoints but fewer than 300×(N+1), then N+2 distribution points are assigned.
If there are already distribution points in a scope but the number of endpoints has decreased, the KSC Server reduces the number of distribution points in the scope. However, it uses other threshold values:
- The last distribution point disappears only after fewer than 6 endpoints remain in the scope.
- One distribution point remains when the number of endpoints in a scope drops below 15.
- Two distribution points remain when the number of endpoints in a scope drops below 200.
- Three distribution points remain when the number of endpoints in a scope drops below 400.
- For larger numbers, N-1 distribution points remain when the number of endpoints in a scope drops below 200×(N-2).
This mechanism in which a second distribution point is added after reaching 20 endpoints in a scope but is removed when the number of endpoints drops below 15 is designed to protect against over-frequent reassignment of distribution points.
The KSC Server reviews scopes and could potentially assign or unassign a distribution point every hour.
How to monitor auto-assignment of Distribution Points:
- You can create Report on activity of Distribution Points.
- You can use Search: in Network activity tab select YES for the "This device is a distribution point" condition.
-
Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.
Second part of this article is also applicable to KSB 2.0, details about it below.
It's rather hard to understand if malware channel works on KATA Sandbox or not. Here's a simple and reliable way of doing it.
Step-by-step guide
-
Create a .bat script with commands that you would normally execute in console to check internet connection - like
pingortracert, - and redirect commands output to file. Here's the example of such script. -
Upload this script to Storage and wait for it to be scanned:
- After the scan completes, download debug info with scan results.
- Unpack scan results using the password 'infected' without quotes.
-
In folder
task0or foldertask1, rename the fileinternal_tracing_reporttointernal_tracing_report.zipand unpack it.
-
Open the file
files.listwith notepad and note the name of file that you used for commands output redirection (results.txtin our example script)
-
Open the file with notepad to see the command results:
-
Done! You will see the output of
ping/tracertcommands. In our example,pingcommand succeeded, buttracertfailed with DNS problems, which means malware channel does not work properly and detection rate will be significantly decreased.
How to test DNS on malware channel
There is also an option to test DNS without running samples in Sandbox. Sandbox server uses core DNS servers in the wild web, not the ones specified in WebUI. DNS servers are accessed by VMs via local
unboundserver, which attempts to run DNS queries via internet interface.Interface namespace may be different, so in order to identify yours execute (after identifying proper dom* name execute command above):
cd /var/run/netnsllExample:
First, you need to jump to internet interface's namespace:
/opt/kaspersky/sandbox/bin/ns_exec /var/run/netns/dom1 /bin/bashThen, test name resolution via local DNS server:
dig@127.0.0.1google.comExample:
You can also test pings same way:
/opt/kaspersky/sandbox/bin/ns_exec /var/run/netns/dom1 /bin/ping -c38.8.8.8Do not forget to exit the namespace viaexitcommand! -
Create a .bat script with commands that you would normally execute in console to check internet connection - like
-
Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.
Product: KSC 11 and more recent versions
Consider the following problematic scenario:
You use a caching proxy server to download updates for the KSC Server, for example, Squid. KSC is configured to download updates via https (default config).
$up2date-1103-eka.log analysis
KL uses the HTTP public key pinning mechanism to verify update server authenticity; a certificate used for authentication is self-signed by KL. A certificate revocation list is also implemented.
More information about the certification revocation process is available here:
https://learn.microsoft.com/en-us/archive/blogs/ieinternals/understanding-certificate-revocation-checks
https://technet.microsoft.com/en-us/library/ee619754(WS.10).aspxA recent update of CRL was performed at the end of July 2023. CRL is available on this link: http://crl.kaspersky.com/cdp/KasperskyLabPublicServicesRootCertificationAuthority.crl
Old CLR was valid till 23.7.2023 and is expired now.
When KSC requests the CRL file, the proxy server sends back to KSC the cached version of it and the CRL verification fails.
The details can be found in the $up2date-1103-eka.log to identify the issue precisely.
04:01:48.817 0x326c INF httpcli cert_revoke 0x70e2908 Got error: 0xa0010019 (http_client::eCrlHasExpired)
04:01:48.817 0x326c INF httpcli Req 0x70e2908 <- HttpsErrorOccurs: Revocation Error [0xa0010019 (http_client::eCrlHasExpired)04:01:48.892 0x1d0c INF updater core: ========= Downloading primary index result TLS error =========
Troubleshooting steps
To solve the problem, an administrator of the proxy server should turn off caching of the http://crl.kaspersky.com/cdp/KasperskyLabPublicServicesRootCertificationAuthority.crl file. It is recommended to turn off caching for all files downloaded from public update servers using this mask:
*.kaspersky.com
*.kaspersky-labs.com
An alternative workaround:-
Set a server flag for KSC using the following commands:
klscflag.exe -fset -pv klserver -s Updater -n DisableKLHttps -t d -v1Also, set a server flag for Update Agents (Distribution Points) that get updates from the Internet, if any:
klscflag.exe -fset -pv klnagent -s Updater -n DisableKLHttps -t d -v1 - Explicitly set an update task to use HTTP sources for URLs, for example, http://p00.upd.kaspersky.com. The full list of HTTP-enabled sources can be found in the <insecure_sites_list> parameter at http://dnl-05.geo.kaspersky.com/updates/upd/updcfg2.xml
-
-
Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.
When running security analyzers on KSC server you may occasionally get warnings about outdated OpenSSL libraries. Normally these vulnerabilities can not be exploited as the OpenSSL library is used in a very specific way.
If vulnerable OpenSSL libraries were found in
C:\Program Files (x86)\Kaspersky Lab\NetworkAgent\protcompthen there is actually no way to exploit it. Due to this fact this library is usually updated with major releases of KSC.What is protcomp
Protcomp is a common code used by the following KSC components.
- vapm: searches for vulnerabilities, local service, does not establish connections (all information transferred to the server via NAgent traffic);
- up2date: does not work with SSL;
- klfc: application categorization, local service, does not establish connections;
- ksnproxy: establishes network connection, but does not use Open SSL;
- cm_um: encryption, local encryption service, does not establish connections.
Why OpenSSL is used
Open SSL has non-networking functions like randomizer and encryption.
-
Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.
Product: KATA
Found In: 5.0
Description and cautions
This article describes how to configure a custom TAA (IOA) exclusion rule in KATA 5.x.
Such exclusions may be needed in cases when a certain TAA (IOA) rule generates a lot of false-positives in the environment. Rather than disabling the rule completely one can add a custom exclusion rule, that will allow to prevent excessive alerts from being generated based on the typical activity in the particular environment.Hopefully this article will give a better understanding on how the current rules are working and how to both configure and troubleshoot the already created TAA (IOA) rule exclusions.
Details
-
Log into KATA web-console as a user with senior security officer role and locate the specific detections, that generates false-positives, that we want to modify (Alerts → Alert to edit the TAA rule for → Click on the name of TAA rule). Please, note, that in our example we are investigating the false positive for the TAA rule named attempt_to_uninstall_av_via_wmi_input, it might be different in your specific case. Click on the name of the TAA rule. to see it's description:
-
Copy the IOA id to the clipboard, we will need it for the further steps.
-
Let's check what exactly triggers this particular rule on enriched events, in order to do so login using SSH to KATA server and run the following query:
# psql -h 127.0.0.1 -U postgres hunts_database -c "select * from hunt where hunt_id = 'fd4ec101-4022-c91f-4228-48a41816c5a4';"
Please, note, that in our example we assume that IOA id from the step 2 is equal to fd4ec101-4022-c91f-4228-48a41816c5a4. Please change the command above accordingly to match the particular IOA id in your specific case.
-
Check in the provided output the exact query, that raises the said TAA (IOA) alert on the events received by the KATA server. Creating TAA (IOA) exclusion rules in KATA web interface is basically altering this query in a way to minimize the possible false positives for a particular case.
-
Return to the KATA web-interface and open the list of events, that had triggered the alert in question (Alerts → Alert to edit the TAA rule for → All events related to the alert) in a new tab.
-
Switch to the Web Developer Tools mode in your browser (Ctrl + Shift + I for Mozilla Firefox / F12 for Google Chrome, etc.) and click on the event you want to inspect, to see its details.
-
Review the event, that had triggered the TAA (IOA) rule in Web Developer Tools. It will contain all the Raw data from the original event in JSON format.
It is recommended to use the Web Developer Tools, as web interface does not show all the available fields with the correlating values, that might be used regardless for the custom TAA (IOA) exclusion rules. -
Return back to the KATA web-interface tab, that we've left open in step 2 of this instruction. Press the Add to exclusions button, to open the Add TAA (IOA) rule to exclusions tab.
-
Select the Based on conditions Exclude rule value and press the Configure additional conditions hyperlink.
-
Now, configure the conditions of exclusion to the rule we are working with. Here we can use all the data that we've extracted from the underlying event on the step 7. In our example let's exclude all the events with interactive input starting with substring "wmic aaauninstallbbbkasperskyc" and FileFullName matching exactly C:\Windows\System32\cmd.exe, as was listed in the original event.
Pay attention to the field names and the values in the original event and the filters, that you are configuring here. Some values may contain spaces in unexpected locations of the string, that may affect the query logic if missed, also pay attention to the operators and how they works.
For example if the original event do contain the following key-value pair:
"FileName" : "rundll32.exe "
then the following criteria will match the value above:
FileName STARTS "rundll32.exe"
but the following 3 will not:FileName CONTAINS "rundll32.exe"
CONTAINS operator expects at least one character before and after the substring defined "rundll32.exe" for the rule to match. In our example we do not have any characters before the 1st letter r in rundll32.exe, thus criteria mismatch.
FileName ENDS "rundll32.exe"
ENDS operator expects at least one character before the substring "rundll32.exe" for the rule to match, whereas we do not have one. Also in our example we have a space character after the rundll32.exe, thus criteria mismatch.
FileName = "rundll32.exe"= operator expects exact match of the string values, whereas here space in the end is missing.
-
When the exclusions are configured you can double-check them in the Add TAA (IOA) rule to exclusions tab, before saving the exclusion. If the query was configured properly save the rule, by pressing the Add button.
-
Check how the TAA rule query was altered in accordance to the changes, that were made in KATA web-console on the previous step:
# psql -h 127.0.0.1 -U postgres hunts_database -c "select query from hunt where hunt_id = 'fd4ec101-4022-c91f-4228-48a41816c5a4';"
Please, note, that in our example we assume that IOA id from the step 2 is equal to fd4ec101-4022-c91f-4228-48a41816c5a4. Please change the command above accordingly to match the particular IOA id in your specific case.
The changes might take a few seconds to be applied accordingly, please re-run the query above a few times, if the changes does not replicate immediately.
If the query is not being changed for quite a while (1-2 minutes) even after the changes in web interface were saved successfully, try checking the hunts_database_synchronizer.log:# less /var/log/kaspersky/services/hunts_database_synchronizer/hunts_database_synchronizer.log
Search there for the entries mentioning IOA id, that we are editing. Most common error here is Attribute is not supported:
This errors means, that there are some specific attributes (like InputType in our example) that can not be used for this particular TAA rule. This usually happens for "older" TAA rules, that were created for earlier KEA version, that had quite a limited amount of supported TAA fields. In such case re-write the exclusion TAA (IOA) exclusion rule, without using this particular attribute/field name. -
If you have confirmed on the previous step, that the changes were replicated, then now you can try to check if the configured exclusions are working correctly. Do this by triggering the underlying event, generating the TAA alert, if this can be done on demand.
-
Log into KATA web-console as a user with senior security officer role and locate the specific detections, that generates false-positives, that we want to modify (Alerts → Alert to edit the TAA rule for → Click on the name of TAA rule). Please, note, that in our example we are investigating the false positive for the TAA rule named attempt_to_uninstall_av_via_wmi_input, it might be different in your specific case. Click on the name of the TAA rule. to see it's description:
-
Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.
KATA 4.0/4.1 is compatible with KSMG 2.0, KSMG 1 and KLMS 8.0.3.
Second thing to notice is that KSMG integration has a few bugs on KATA side. Thankfully, all known issues are fixed in a PF, which is recommended for all who integrate KSMG/KLMS and KATA4.
KATA4.0
Step-by-step guide
Download container with fix.
file_name : kata_scanner_35f8753e6d.tar.gz
md5 : 2adb09c0bd13dfc03c6a5c8980dde4ff
container_name: kata_scanner
container_version: kata_scanner:35f8753e6d
service_name: kataedr_main_1_kata_scannerCopy file
kata_scanner_35f8753e6d.tar.gzto KATA CN-
check md5:
md5sum /var/opt/kaspersky/apt/files/kata_scanner_35f8753e6d.tar.gz -
MD5 should be
2adb09c0bd13dfc03c6a5c8980dde4ff, after that import the container, no need to decompress:docker load < /var/opt/kaspersky/apt/files/kata_scanner_35f8753e6d.tar.gzIf the load is successful, the result would be the the container version, like
kaspersky/kata/kata_scanner:35f8753e6d -
Change container tag in
/etc/opt/kaspersky/apt-swarm/image_versions.jsonto the new version (kata_scanner:bb3be18444 -> kata_scanner:35f8753e6d)"kata_scanner":"kaspersky/kata/kata_scanner:35f8753e6d", -
Update the image used for service kata_scanner by running the command:
docker service update kataedr_main_1_kata_scanner --image"kaspersky/kata/kata_scanner:35f8753e6d" -
To verify that kata_scanner service runs new container, run:
docker service ls | grep kata_scannerSample output, note container version4up6sm5yetnj kataedr_main_1_kata_scanner replicated1/1kaspersky/kata/kata_scanner:35f8753e6d *:8081-8082->8081-8082/tcp
КАТА 4.1
Fixing mail processing Step-by-step guide
Download container with fix.
file_name : kata_scanner_66e20ed.tar.gz
md5 : 288ddb650ed9c08ca1fe57e188c41c67
container_name: kata_scanner
container_version: 66e20ed
service_name: kataedr_main_1_kata_scannerStep-by-step: kata_scanner-
Download a container.
-
Copy the file
kata_scanner_66e20ed.tar.gzto KATA CN. -
Check md5:
md5sum /var/opt/kaspersky/apt/files/kata_scanner_66e20ed.tar.gz -
MD5 should be
288ddb650ed9c08ca1fe57e188c41c67. After that, load the container, no need to decompress:docker load < /var/opt/kaspersky/apt/files/kata_scanner_66e20ed.tar.gzIf the load is successful, the result would be the container version, like
Loaded image: kaspersky/kata/kata_scanner:66e20ed -
Use it to change the container version in
/etc/opt/kaspersky/apt-swarm/image_versions.json.Set the correct version:"kata_scanner":"kaspersky/kata/kata_scanner:66e20ed", -
Confirm that the changes are correct and are not breaking anything:
cat /etc/opt/kaspersky/apt-swarm/image_versions.json | python -m json.tool | grep"kata_scanner:" -
Update the image used for the kata_scanner service with the new version of the container that we have just added:
docker service update kataedr_main_1_kata_scanner --image"kaspersky/kata/kata_scanner:66e20ed" -
Verify that the
kataedr_main_1_kata_scannerservice runs the new container by running:docker service ls | grep kata_scanner -
Confirm the new version tag 66e20ed:
Sample output, note container versionmtgzlqu3beny kataedr_main_1_kata_scanner replicated1/1kaspersky/kata/kata_scanner:66e20ed *:8081-8082->8081-8082/tcp
Fixing autoprevention rules for composite objects step-by-step guide
Download container with fix.
file_name : hunts-fixed-prevs.tar.gz
md5 : 604d0918ddcb8b91cac694a15d96d501
container_name: hunts_event_processor
container_version: 2610c63
service_name: kataedr_main_1_hunts_event_processor-
Copy file
hunts-fixed-prevs.tar.gzto KATA CN (e.g via scp) -
check md5:
md5sum /var/opt/kaspersky/apt/files/hunts-fixed-prevs.tar.gz -
MD5 should be 604d0918ddcb8b91cac694a15d96d501, after that import the container, no need to decompress:
docker load < /var/opt/kaspersky/apt/files/hunts-fixed-prevs.tar.gzIf the load is successful, the result would be the the container version, like
kaspersky/kata/hunts_event_processor:2610c63 -
Change container tag in
/etc/opt/kaspersky/apt-swarm/image_versions.jsonto the new version (hunts_event_processor:0e5fabb -> hunts_event_processor:2610c63)"hunts_event_processor":"kaspersky/kata/hunts_event_processor:2610c63", -
Check that json is changed and valid (outputs the string from previous step if all is ok):
cat /etc/opt/kaspersky/apt-swarm/image_versions.json | python -m json.tool | grep 2610c63 -
Update the image used for service kata_scanner by running the command:
docker service update kataedr_main_1_hunts_event_processor --image"kaspersky/kata/hunts_event_processor:2610c63"Expected output "verify: Service converged"
-
To verify that kata_scanner service runs new container, run:
docker service ls | grep hunts_event_processorSample output, note container versionr8m0jcrtkiu0 kataedr_main_1_hunts_event_processor replicated1/1kaspersky/kata/hunts_event_processor:2610c63
Fixing dashboards step-by-step guide
For dashboards, two containers should be replaced:
web_backendandclickhouse_metrics_importer.Service nameContainer nameDownload linkkataedr_main_1_web_backend kaspersky/kata/management/management_ui/web_backend:4e30ad8 https://box.kaspersky.com/f/d66c6aa3ebe1483c9558/?dl=1 kataedr_main_1_clickhouse_metrics_importer kaspersky/kata/clickhouse_metrics_importer:0e5fabc https://box.kaspersky.com/f/fe0e562798fe4d1e9730/ Please replace them both as per instructions above.
file_name: web_backend_4e30ad8.tar.gz
md5: 9aa87ce646c28cc30f5002f837d10104
container_name: web_backend
container_version: "kaspersky/kata/management/management_ui/web_backend:4e30ad8"
service_name: kataedr_main_1_web_backendStep-by-step: web_backendDownload a container. Check md5:
md5sum /var/opt/kaspersky/apt/files/web_backend_4e30ad8.tar.gzMD5 should be
9aa87ce646c28cc30f5002f837d10104.After that, load the container:docker load < /var/opt/kaspersky/apt/files/web_backend_4e30ad8.tar.gzIf the load is successful, the result would be the container version, like
Loaded image: kaspersky/kata/management/management_ui/web_backend:4e30ad8Use it to change the container version in
/etc/opt/kaspersky/apt-swarm/image_versions.json.Set the correct version:"web_backend":"kaspersky/kata/management/management_ui/web_backend:4e30ad8",Confirm that the changes are correct and are not breaking anything:
cat /etc/opt/kaspersky/apt-swarm/image_versions.json | python -m json.tool | grep"web_backend:"Reload the docker service with the new version of the container that we have just added:
docker service update kataedr_main_1_web_backend --image"kaspersky/kata/management/management_ui/web_backend:4e30ad8"Verify that the
kataedr_main_1_web_backendservice runs the new container by running:docker service ls | grep kataedr_main_1_web_backendConfirm the new version tag 4e30ad8:
Sample output, note container version5nb5ghavmtl5 kataedr_main_1_web_backend replicated1/1kaspersky/kata/management/management_ui/web_backend:4e30ad8KSMG
You should add vacuum command to the crontab and run it every 6 hours
Cron scheduler should be added similar to this (under root):
For KSMG 2.0.1 there is no need to add this command to cron.
KSMG 2.0
$ sudo -i# crontab -e
# Run at minute 0 past every 6th hour:
0 */6 * * * /opt/kaspersky/ksmg/libexec/postgresql/psql -h /var/run/ksmg -U kluser -d kata_quarantine -c 'vacuum full;'
KSMG 1.1.2.30
$ sudo -i
# crontab -e
# Run at minute 0 past every 6th hour:
0 */6 * * * /opt/kaspersky/klms/libexec/postgresql/psql -h /var/run/klms -U kluser -d kata_quarantine -c 'vacuum full;'
-
-
Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.
KSC installer generates default passwords for service accounts (automatically created to run KSC service), KIPxeUser and KIScSvc.
Those passwords have 16 characters length, characters are taken randomly so that the password contain 3 out of 4 of the following groups of characters:
- Lowercase characters (a – z)
- Uppercase characters (A – Z)
- Numbers (0-9)
- Symbols (~ ! @ # $ % ^ & * - _ + = [ ] { } | \ : ' , . ? / ` ~ " < > ( )
- Also the password cannot contain a dot character '.' immediately preceding the '@' symbol.
-
Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.
Product: KSC 11+
Applies also to the update utility version 4.1 and more recent.
Consider the following problematic scenarios:
- You have installed KSWS on the KSC server and enabled Traffic Security component and Traffic Security uses MITM mechanism to analyze traffic.
- You use a 3rd party software or hardware appliance for traffic filtering and this appliance disrupts connections to HTTPS-enabled public update servers. It can be a hardware appliance like BlueCoat or F5, FortiGate SSL Deep Inspection, or a software proxy like Squid that uses ICAP to redirect traffic to another security application for scanning.
KL uses HTTP public key pinning mechanism to verify update server authenticity; certificate used for authentication is self-signed by KL. Using any MITM-based solutions for SSL traffic inspection will lead to failures in establishing connection between KSC and a HTTPS-enabled KL update source. It happens because any MITM traffic inspection will forward a wrong certificate to KSC after inspection and KSC11 will break the connection.
The following string can be found in up2date trace:
self signed certificate in certificate chain
The following trace files are required for accurate diagnostic: $up2date-1103.*, $up2date-1103-eka.*
Please bear in mind that Kaspersky Support needs KSC traces mentioned above to be collected BEFORE you apply any of the workarounds listed in this post.
Troubleshooting steps
-
If you have KSWS blocking traffic, add
Up2Date.exeprocess or the update source certificate to trusted in Traffic Security settings. - If you use a 3rd party appliance to filter traffic, you can explicitly allow traffic signed by KL certificate.
-
Otherwise you can use HTTP to download updates. There are two ways to make KSC use HTTP:
-
Set a server flag on KSC using following commands:
klscflag.exe -fset -pv klserver -s Updater -n DisableKLHttps -t d -v1and on Update Agents (Distribution Points) getting updates from the internet, if any:
klscflag.exe -fset -pv klnagent -s Updater -n DisableKLHttps -t d -v1 - Explicitly set update task to use HTTP sources URLs, for example http://p00.upd.kaspersky.com. Full list of HTTP-enable sources can be found in <insecure_sites_list> parameter in http://dnl-05.geo.kaspersky.com/updates/upd/updcfg2.xml
-
- Download updates using update utility 4.0. More recent version of update utility uses https.
-
Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.
You can receive vulnerability CVE-2016-2183 alerts while scanning Central Node v4.0 with the following insecure cipher suites:
* TLS 1.2 ciphers: * TLS_RSA_WITH_3DES_EDE_CBC_SHA
Clarifications:
Here are more details on CVE-2016-2183.
Fix:
Fix download link.
1) docker load < /path/to/container/nginx_gateway-4.0-pf12) Change container's version in /etc/opt/kaspersky/apt-swarm/image_versions.json
put:
"nginx_gateway": "registry.kata.avp.ru:5000/kaspersky/kata/web/nginx_gateway:aa48c91",3) Load new container:
docker service update kataedr_main_1_nginx_gateway --image "registry.kata.avp.ru:5000/kaspersky/kata/web/nginx_gateway:aa48c91" -
Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.
1) Go to Programs and features and find WebConsole
2) Press Change/uninstall
3) Choose Upgrade mode
4) Follow the wizard and you will be able to change port and list of trusted servers.
-
Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.
Problem
After "Nessus" vulnerability scanning on Central node 4.0 servers, you may see the following:
Ports:22-tcpDescription: 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 RecommendationsforSecure Shell (SSH) draft-ietf-curdle-ssh-kex-sha2-20. Section4lists guidance on key exchange algorithms that SHOULD NOT and MUST NOT be enabled. This includes:diffie-hellman-group-exchange-sha1diffie-hellman-group1-sha1gss-gex-sha1-*gss-group1-sha1-*gss-group14-sha1-*rsa1024-sha1This 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:GSSAPIKexAlgorithmsThe list of key exchange algorithms that are accepted by GSSAPI key exchange. Possible values aregss-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 yesChange 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
-
-
Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.
Most of the problems with installing images in Sandbox are caused by incorrect VMWare/VM configuration. Please only proceed according to this article after it has been established that each of the specified requirements from Sandbox sizing calculator has been met.
Problem
Sometimes images would not install on a correctly deployed Sandbox even though all the system requirements were met.
Solution
The culprit of this issue was found to be the ESXi version 6.7.0-8169922.
To resolve this, it is necessary to install the latest patch for ESXi.
The file itself can be downloaded here:
https://my.vmware.com/group/vmware/patch
update-from-esxi6.7-6.7_update03
Product:ESXi (Embedded and Installable) 6.7.0
Download Size:454.6 MB
08/20/2019
14320388Then follow the steps to install it:
-
Log in as root over
ssh; -
Create updates directory:
/vmfs/volumes/XXXXXXXXXXXXXXX/ESXI/updates
(where XXXXXXXXXXXXXXX is the volume name); - Copy the patch to updates directory;
- Start patch installation.
A more detailed instruction on installing the patch from VMWare can be found here:
-
Log in as root over
-
Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.
There is an example of a step-by-step instruction to configure Single-Sign-On (SSO) for KATA 4.1/5.0 into HOME.LAB domain.
Prerequisites
-
Deployed Central Node Server Name should be FQDN. (In current case FQDN name of Central Node - kata-cn.home.lab)
It can be checked via Settings/Network Settings of Central Node.
- A and PTR record should be set for Central Node in DNS.
- Domain User Account should be created to set up Kerberos authentication by means of keytab file (in current case Domain User Account is kata-sign-on).
- AES256-SHA1 encryption algorithm should be enabled into created Domain User Account.
Step-by-step guide to create keytab file
On Domain Controller:
- Launch CMD As Administrator
-
Execute the following command to create keytab file
C:\Windows\system32\ktpass.exe -princ HTTP/kata-cn.home.lab@HOME.LAB -mapuser kata-sing-on@HOME.LAB -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass * +dumpsalt -out C:\TEMP\kata-sgn-on.keytab
The utility requests thekata-sign-onuser password when executing the command.
The SPN of the selected server is added to the created keytab file. The generated salt is displayed on the screen: Hashing password with salt "<hash value>"
For multiple Central Node servers you need to save "<hash value>" of hashing password to add an SPN for each subsequent Central Node servers further using ktpass.exe utility.
On Central Node Web Interface
- Move to Settings/Users/Active Directory Integration
-
Add the created keytab file:
- Keytab file status section contains File which contains SPN for this server
- The file contains section HTTP/*****@*****.tld
- Under Users tab click Add and select Domain user account.
- Set domain user as <username>@<domain>
On client machine
Host should be joined to the same domain. Domain user should be logged in with account added into the Central Node.
- Open Control Panel/Internet Options
- Click on Security and select Local Intranet
- Click on Sites and then on Advanced
- Add FQDN of central node - kata-cn.home.lab
- Close windows:
Launch Web Browser and access to Web Interface of the Central Node https://kata-cn.home.lab:8443 and it should be opened without asking any Login/Password.
-
Deployed Central Node Server Name should be FQDN. (In current case FQDN name of Central Node - kata-cn.home.lab)
-
Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.
KATA / EDR is using only one certificate for all connections (like WebServer and Client Connections). When you plan to replace it, do it in an early stage of deployment.
If you want to replace the TLS certificate, you will need to:
- Reauthorize mail sensors (KSMG, KLMS) on Central Node.
- Reconfigure connection of Central Node, PCN and SCN to Sandbox.
- Reconfigure Endpoint Agent traffic redirection to Sensor and trusted connection with Endpoint Agent.
- Upload a new certificate in Active Directory (if you use it in Active Directory).
Prepared TLS certificate must satisfy the following requirements:
- The file must contain the certificate itself and a private encryption key for the connection. To generate a pem from your PKI PFX you can use the following command:
openssl pkcs12 -in mySecureCertificate.pfx -out kata.pem -nodes- The file must be in PEM format.
- The private key length must be 2048 bits or longer.
After replacing the certificate don't forget to replace it in KEA Policy → KATA Integration → KATA Integration Settings → Add new TLS certificate (not the Add Client certificate).
The certificate you specify needs to be in CRT Format. You can get it by "Downloading" the Certificate from CN → Settings → General Settings → Download.
-
Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.
This works an all KATA CN versions from 3.6.1 to 5.1
You can execute the queries below with Curl to get the text representation of agent status. SSO login and password must be used, limit of 200 entries is used in the example query.
JSONs with agent statuscurl -s --output /dev/null-c ./cookie -k -X POST -H'Content-Type: application/json'-d'{"username":"SSO","password":"MYPASSWORD","local":false}'https://KATACN:8443/apt/api/userLogin && curl -s -b ./cookie -k -X POST -H 'Content-Type: application/json' -H 'Referer: https://KATACN:8443/katap/' -d '{"limit":200,"offset":0}' https://KATACN:8443/apt/api/hostsAgentActivity | python -m json.toolThis query can be customized further to get lists of hostnames, IPs etc:
List of unique agents hostnamescurl -s --output /dev/null-c ./cookie -k -X POST -H'Content-Type: application/json'-d'{"username":"SSO","password":"MYPASSWORD","local":false}'https://KATACN:8443/apt/api/userLogin && curl -s -b ./cookie -k -X POST -H 'Content-Type: application/json' -H 'Referer: https://KATACN:8443/katap/' -d '{"limit":200,"offset":0}' https://KATACN:8443/apt/api/hostsAgentActivity | python -m json.tool | grep hostname | awk -F\" '{print $4}' | sort | uniqList of unique agents hostnamescurl -s --output /dev/null-c ./cookie -k -X POST -H'Content-Type: application/json'-d'{"username":"SSO","password":"MYPASSWORD","local":false}'https://KATACN:8443/apt/api/userLogin && curl -s -b ./cookie -k -X POST -H 'Content-Type: application/json' -H 'Referer: https://KATACN:8443/katap/' -d '{"limit":200,"offset":0}' https://KATACN:8443/apt/api/hostsAgentActivity | python -m json.tool | grep \"ip\" | awk -F\" '{print $4}' | sort -n | uniq -
Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials.
What is the default synchronization period between KEA and CN?
Sync period (which is every X minutes) for KEA is configurable in KEA policy. Default synchronization period is 300 sec (5 min). The same period applies to LENA.What is the isolation workflow?
- In KATA CN creates task for host isolation.
- KEA receives an 'isolate' command from the Central Node during synchronization .
- An agent turns on host isolation with exclusions configured in KEA policy.
- At the next sync time (after X minutes) the agent sends the results of isolation to the Central Node .
- When isolation is turned on isolated host connected to the Central Node, you can view the telemetry from this host and execute other tasks.
Is it OK that isolation takes up to 10 minutes?
Yes, see previous two sentences for explanation. It takes up to 5 minutes to sync a task with the host when default settings are applied. To sync the status back to CN we need another 5 minutes.What will happen if the IOC scan didn't finish within Maximum scan duration. Will it resume next time or it will terminate?
IOC scan task starts as scheduled and then terminates upon reaching the Maximum scan duration even if it hasn'tt finished yet. The next scheduled time the scan task starts from the beginning.How to determine whether the specified time is enough to complete the scan?
Experimentally.The default scan is a full scan, are there any options to set a custom scan?
IOC scan task is not configurable in KATA, thus there is no way to set a custom scan.
Дисклеймер. Обязательно к прочтению перед использованием материалов базы знаний форума.
in Советы и решения по Kaspersky Endpoint Security для бизнеса
Posted
Материалы, представленные в разделе Форума "Советы и решения" (База знаний Форума), являются результатом работы сотрудников Службы поддержки клиентов Лаборатории Касперского и участников сообщества Форума. Они размещены здесь для удобства использования, развертывания и настройки продуктов Касперского.
Пожалуйста, помните, что использование команд или рекомендаций из статей без четкого понимания их назначения может привести к ошибкам или сбоям в работе системы. Обращаем ваше внимание на то, что некоторые из представленных материалов не являются официальными, поэтому в ряде случаев техническая поддержка может отказать в поддержке конкретной неподдерживаемой конфигурации.
Также просим обязательно использовать официальную документацию, представленную по этой ссылке.