aehrlich

Multiple (although not all and not even majority of) computers have suddenly, in last couple of days, fallen into the “Security application is not installed” state. KES 11.2.0.2254cf1 is installed on the computers according to “Application registry” but the “Applications” tab shows only Network Agent being installed and running. Network agent 11.0.0.1131b is running ok against KSC 10.5.1781. The affected machines connect remotely over VPN (the crisis and quarantine, you know) so I cannot even get diagnostics from them. WTHIGO? Has anybody encountered anything similar?

#metoo 8-D

Отчет klnagent с последней машины: Starting utility 'klnagchk'... Checking command line options...OK Initializing basic libraries...OK Current device is 'gateway.docker.internal' Network Agent version is '11.0.0.1131 (b)' Reading the settings...OK Verifying the settings...OK Network Agent settings: Administration Server address: '(SERVERNAME.DOMAINNAME)' Use SSL: 1 Compress traffic: 1 Numbers of the Administration Server SSL ports: '13000' Numbers of the Administration Server ports: '14000' Use proxy server: 0 Administration Server certificate: available Open UDP port: 1 Numbers of UDP ports: '15000' Synchronization interval (min): 15 Connection timeout (in seconds): 30 Send / receive timeout (in seconds): 180 Device ID: 90bfa82e-cca1-4b61-9228-2191a719b937 Attempting to connect to Administration Server...OK Attempting to connect to Network Agent...OK Network Agent is running. Receiving the Network Agent statistical data...OK Network Agent statistical data: Total number of synchronization requests: 288 The number of successful synchronization requests: 288 Total number of synchronizations: 1 The number of successful synchronizations: 1 Date/time of the last request for synchronization:25.02.2020 07:40:55 GMT (25.02.2020 09:40:55) Deinitializing basic libraries...OK

Прекрасная новая картинка. Один и тот же лаптоп с разными именами LAP-RAITL и LAP-RAITL~~15328, одним и тем же IP 10.31.1.56. У лаптопа с тильдами в именах агент “обнаружил” доменное имя gateway.docker.internal, видимо, именно поэтому создал дубликат.

I’ve encountered this “untrusted certificate” error messages if the remote site was actually inaccessible; I guess “error setting up tls with remote site for _any_ reason” results into such an error page presented by Kaspersky, too.

Маки, схожим образом (хотя это все же другая проблема), имеют тенденцию приобретать имя вида “computername.local” вместо или вдобавок к “computername.правильное-имя-сети”. Часто образуя дубликаты. Это один и тот же лаптоп, подключавшийся к нашей локальной сети “двумя разными способами” , поэтому у него разные IP.

> как именно в этот момент резолвится имя хоста в DNS? В каком именно DNS? В доступном KSC? В локальном-для-докера на проблемной машине? В DNS удаленной подключенной по VPN сети? Они все разные и имена там тоже все разные. В доступном KSC (обслуживающем локальную сеть) “как положено”: netbios-имя + доменное имя локальной сети (LAP-RAITL.icefire в примере). В DNS-для-докера (автомагически поднимаемом средствами виртуализации hyper-v/virtualbox при запуске контейнера) как, очевидно, gateway.docker.internal. В удаленном DNS партнерской сети по VPN как что-нибудь вроде netbios-имя.remote-lan-name (без конкретных примеров, извините). > Пожалуйста, приложите также отчет утилиты klnagchk “Ну вот, началось!” (с) Разработчикам установить _локально_ докер и запустить какой-нить контейнер, воспроизвести и отлаживать локально же...

Т.е. не то чтобы оно совсем случайное, какой-то из сетевых адаптеров машины имеет такое имя, в случае с докером, очевидно, он (локальный клиент в собственной докер-сети), в случае с VPN-клиентами -- получается что-то вроде имя_машины.удаленный-по-vpn-домен (обычно “нормальное” “netbios-имя”, для примера со скриншота “lap-raitl”). Надо просто из всех возможных имен выбор делать осознанно.

В разное время -- разные компьютеры. Сейчас один; время вечернее, уже “disconnected”.

В KSC компьютеры с несколькими сетевыми адаптерами могут показываться со случайным именем. Например, если установлен и запущен docker, то бывает, показывается “нормальное” имя, а бывает и нет. NetBIOS name: LAP-RAITL DNS name: gateway.docker.internal IP address: 10.31.1.56 (Hyper-V Virtual Ethernet Adapter) В DNS, обслуживающем локальную сеть, имя “gateway.docker.internal”, разумеется, не регистрируется, т.е. это “имя” приходит от klnagent. Похожая ситуация случается с компьютерами, на которых устанавливаются/запускаются VPN-клиенты к сторонним организациям (Cisco Anyconnect и т.д.). Воспроизводится и с последним klnagent 11.0.0.1131b. Собственно, вопрос: доколе?

@Katbert “Патч В для Kaspersky Security Center 11 выпущен 26 сентября 2019 года”, так что даже в “обновленном” от 29 июля как-то сомнительно наличие интегрированного патча. Не знаю, стянул lite-версию, она подписана 25. ‎aprill ‎2019 14:06:22 (ru), 25. ‎aprill ‎2019 14:06:14 (en)… может, у нас интернет такой разный :) гео-CDN или еще какой роскомнадзор...

@DemiadВ теории -- да. На практике, если я скачиваю https://support.kaspersky.en/ksc11#downloads дистрибутив с якобы интегрированным патчем b, то он (дистрибутив) бинарно тот же, что ksc_11_11.0.0.1131_lite_en.exe от февраля 2019, т.е. без патча. О чем и плач. Но за инструкцию по внедрению патча спасибо.

Нет, это патчи отдельно. А мне бы агента с интегрированным патчем. Или, на крайний случай, ководство, как патч интегрировать в изначальный 11.0.0.1131 пакет, чтобы устанавливать сразу с патчем, а не “сначала непатченый агент, потом патч поверх”.

Где взять klnagent 11.0.0.1131b с интегрированным патчем b (в идеале англоязычную версию)? Статья “Коммерческий релиз Kaspersky Security Center 11 (версия 11.0.0.1131) патч B” (https://support.kaspersky.ru/15293#block1) говорит “Вы также можете скачать дистрибутив с интегрированным патчем B на странице загрузки”, но отсылает на общую страницу https://support.kaspersky.com/ksc11#downloads , где “скачать” предлагается только старую версию от 07.02.19, да и то лишь в составе минимально KSC lite (152 Mb).

Минск, и как полет?

Если отключить политику и попытаться установить автопатч вручную (обновление - принять - бла-бла), то автопатч этот тоже не устанавливается. Молча. Если попытаться установить полную инсталляшку 11.2 поверх 11.1 (где-то в KSC было видно, что тип установки этого патча “full”), то установка подвисает. Если закрыть (Exit) KES (пробовал с 11.1), вот тогда установка проходит. На всех проблемных KSC-управляемых машинах есть нюанс (с): включена Password Protection в KES. Не она ли виновата? На аналогичной машине, развернутой из того же win-образа, но еще не подключенной к KSC (и, соответственно, без парольной защиты) автообновление накатилось нормально.

Не устанавливается автопатч на Win10. Задача обновления KSC10, которая после установки плагина решила, что она относится к KES 11.2.0, выдает результат Event type: Patch installation failed Result: Patch installation failed Object: C:\ProgramData\Kaspersky Lab\KES\Patches\kes11\kes11_2\aes256\en\kes_win.msi Object\Path: C:\ProgramData\Kaspersky Lab\KES\Patches\kes11\kes11_2\aes256\en\ Object\Name: kes_win.msi Кто в курсе, к чему бы это?

"Как жить, дядь Мить?!" Can we expect some development to resolve the issue in next patch levels or at least versions, at least in the simplest form of "provide a way to turn _off_ the too-smart-machine-self-thinking"?

Четкой последовательности действий нет, но не исключено, что BSOD связан с work docked/sleep/work undocked/sleep/work docked действиями.

https://drive.google.com/file/d/1_R9QYTJLSNfHJcOp297ywD5WHT-t0npv/view?usp=sharing

https://drive.google.com/file/d/1AlMk54FoVamh2UL2I9hblnfHz9S7GdRd/view?usp=sharing

Yes we can learn from the support article that some changes (network adapter change, presence of hosts with the same names in different domains, among others) can cause this. The question is what we can do to avoid this in the real world -- where, for example, ugly vpn clients are being used, modifying visible host domains, or developers running lots of dockers on their machines with different technology? There is some machineId (that is being reset by the "dupfix" option of klmover). Can we have a patch/checkbox like "dear klnagent, keep machine id, do not play with it in spite of all the networking changes"? I have tens of laptops in my 100+ network exhibiting such problems from time to time...

Что-то у меня тоже на свежеустановленной W10 1903 стабильно вылезает SYSTEM_SERVICE_EXCEPTION (3b) на klflt.sys. Вылетает, правда, с попыткой обратиться к адресу 0, как я понимаю: Arguments: Arg1: 00000000c0000005, Exception code that caused the bugcheck Arg2: fffff8032b1e6a80, Address of the instruction which caused the bugcheck Arg3: fffff10531cee550, Address of the context record for the exception that caused the bugcheck Arg4: 0000000000000000, zero. fffff105`31ceef48 fffff803`2b1e5ea9 : ffffbe81`82640601 fffff803`2b1d6bbb ffffbe81`82640040 ffffbe81`82640000 : klflt!EvReferenceObjectSafe+0xb40 fffff105`31ceef50 fffff803`2b2026cf : ffffbe81`82640040 ffffbe81`827adde0 ffffbe81`82640650 ffffbe81`827addd8 : klflt!PstDereferenceProcess+0x29 fffff105`31ceef90 fffff803`2b1d4719 : ffffbe81`827add70 ffffbe81`827add70 ffffbe81`81f5def0 ffffbe81`821f60b0 : klflt!EvUnregisterNonPermanentFiltersClient+0x6f fffff105`31ceefc0 fffff803`364574cb : ffffbe81`821f6090 ffffbe81`80242d68 ffffbe81`81f5def0 ffffbe81`748fdef0 : klflt!EvTeardownConnection+0x59 fffff105`31ceeff0 fffff803`36457877 : ffffbe81`802428a0 ffffbe81`8209e670 ffffffff`80002318 ffffbe81`744979f0 : klif+0xa74cb fffff105`31cef040 fffff803`3649a0f0 : ffffbe81`81f5def0 ffffbe81`8209e670 ffffbe81`81f5df40 ffffbe81`81f5ebe0 : klif+0xa7877 fffff105`31cef080 fffff803`363c665c : ffffbe81`81f5def0 00000000`00000000 ffffd502`cf4075d0 fffff803`25c4c1d0 : klif+0xea0f0 fffff105`31cef0b0 fffff803`3649a18c : ffffbe81`81f5def0 ffffbe81`8209e670 00000000`0000137c fffff105`00000000 : klif+0x1665c fffff105`31cef0e0 fffff803`363ca762 : ffffbe81`748fdef0 fffff803`363c6630 00000000`0000137c fffff803`26067940 : klif+0xea18c fffff105`31cef130 fffff803`363b8984 : ffffbe81`7f7b7a40 00000000`0507eccc 0000015a`00000010 00000000`00000000 : klif+0x1a762 fffff105`31cef160 fffff803`3645762e : ffffbe81`81f5ccf0 ffffbe81`7f7b7a40 00000000`0507eccc 00000000`00000010 : klif+0x8984 fffff105`31cef4d0 fffff803`3649a608 : ffffbe81`81f5ccf0 ffffbe81`82088d70 00000000`0507eccc 00000000`00000010 : klif+0xa762e fffff105`31cef520 fffff803`29eccd8b : ffffbe81`81f5ccf0 00000000`0507eccc 00000000`00000010 00000000`00000000 : klif+0xea608 fffff105`31cef590 fffff803`29efbf18 : fffff105`31cef6a0 00000000`00000001 ffffbe81`86cfb230 fffff105`31cef9ff : FLTMGR!FltpFilterMessage+0xdb fffff105`31cef5f0 fffff803`29efbfd6 : ffffbe81`86cfb300 00000000`0507eccc 00000000`00000000 ffffbe81`00000000 : FLTMGR!FltpMsgDeviceControl+0x128 fffff105`31cef650 fffff803`29ec3f4f : ffffbe81`719379f0 00000000`00000002 00000000`00000000 fffff803`261eff85 : FLTMGR!FltpMsgDispatch+0xa2 fffff105`31cef6c0 fffff803`25c31f39 : ffffbe81`86cfb230 00000000`00000000 00000000`00000003 00000000`00000010 : FLTMGR!FltpDispatch+0xef fffff105`31cef720 fffff803`261e8345 : ffffbe81`86cfb230 00000000`00000000 00000000`00000000 ffffbe81`82058360 : nt!IofCallDriver+0x59 fffff105`31cef760 fffff803`261e8150 : 00000000`00000000 00000000`00000000 ffffbe81`82058360 fffff105`31cefa80 : nt!IopSynchronousServiceTail+0x1a5 fffff105`31cef800 fffff803`261e7526 : 00000000`00000000 00000000`00000000 00000000`00000001 00000000`00000000 : nt!IopXxxControlFile+0xc10 fffff105`31cef920 fffff803`25dd2915 : 00000000`00004b88 ffffbe81`7bc4ebd0 00000000`00000000 fffff105`31cef900 : nt!NtDeviceIoControlFile+0x56 fffff105`31cef990 00000000`772a1cbc : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x25 00000000`04f7eb38 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x772a1cbc