Jump to content

aehrlich

Members
  • Content Count

    383
  • Joined

  • Last visited

About aehrlich

  • Rank
    Cadet

Recent Profile Visitors

1,518 profile views
  1. Не понял. Отключение KSN влияет -- этого что, недостаточно? Что-то куда-то отослать пытается, невзирая на системные power-события и не ожидая от них прерывания работы. Чем нам отключение компонент-то поможет типа USBAttack или даже File Threat Protection??
  2. Однако отключение использования KSN решает эту проблему.
  3. Прилагаю и GSI Нет, не прилагаю, файл размером 2 845 613 байт добавить не получается.
  4. KES 11.0.1.90. Windows x64 1803, 1809. Dell Latitude 7480, 7490, 7390. При отправке лаптопа в sleep происходит раздражающая задержка секунд на 30-40. В Windows Event Log (прилагается) позже видим ошибки Service Control Manager: event id 7023: The Kaspersky Status Send Service terminated with the following error: System call failed. event id 7011: A timeout (30000 milliseconds) was reached while waiting for a transaction response from the AVP service. Если из Касперского "выйти" и вдобавок остановить-убить сервисы, похожие на генерального прокурора AVP, то задержка при входе в sleep изчезает, лаптопы засыпают за 3-4 секунды. avp-on-sleep-2.7z
  5. Just curious: are network agents crashing (i.e. are there [fresh] dumps in "C:\Program Files (x86)\Kaspersky Lab\NetworkAgent\~dumps\" present)? Or are they "just" not running? Some years ago I ran into a situation where service was crashing massively and then unable to restart as it was busy writing its dump file at the moment of restart attempt. Since then I make sure KSC Network Agent has "Restart service after 3 minutes" set instead of default "0"; it has helped a lot.
  6. I have the same issue on 1803 with firewall state reporting when KES firewall is turned off and MS one working -- in case you need alternate GSIs.
  7. Да, при добавлении путей в групповую задачу KES11 и ее выполнении статус клиента также меняется на зеленый.
  8. Добавил пути %systemroot%* в локальную стандартную (создаваемую при standalone-установке KES11) задачу Critical Areas Scan для KES11, прогнал -- клиент действительно позеленел. Попробую добавить пути в групповую задачу. НО. Когда KES11 устанавливается, эти пути в "Critical Areas Scan" не добавляются. При этом сколько-то дней после добавления клиента в KSC он все еще зеленый "по инерции". И в мастере создания задач сканирования такие пути не предлагаются (т.е. ручками, только ручками, когда знаешь, что именно надо добавить).
  9. KSC 10.5.1781 Имею схожие политики и расписания для 4 версий KES. Для версий 10.3.0.6294, 10.3.3.139 (агент 10.4.343) состояние клиента "зеленое". Для версий 11.0.0.6499, 10.2.6.3733 (агент 10.5.1781) состояние клиента (через несколько дней после добавления в KSC и под политику) становится "Virus Scan has not been performed in a long time" (а ведь сразу после добавления свежеобновленного KES было зеленым) и таким и остается. Созданы (кастомизированные) групповые задачи "Quick Virus Scan - xxx" с настройками: Scheduled start: After application update Files scanned by format Security level: Custom Scan scope: KES10sp1: System Memory, Startup Objects, Disk boot sectors, System Backup Storage KES10sp2: Kernel Memory, Running processes and Startup Objects, Disk boot sectors, %systemroot%\, %systemroot%\system\, %systemroot%\system32\, %systemroot%\system32\drivers\, %systemroot%\syswow64\, %systemroot%\syswow64\drivers\ KES11: Kernel Memory, Running processes and Startup Objects, Disk boot sectors Разумеется, проверено, что групповые задачи ходят, например, на одном проблемном KES11: 19.09.2018 05:14:43 Running, 19.09.2018 05:16:28 Completed Вопрос: куда копать?
  10. Не вижу системы в "работает -- не работает". Сегодня один и тот же лаптоп не работал, после перезагрузки по-прежнему не работал, через 10 минут заработал и до сих пор работает. Единственный подозрительный факт -- во время "не работал" зарегистрировано событие "KSN servers unavailable", более-менее во время "заработал" зарегистрировано событие "KSN servers available" на лаптопе.
  11. Не на Windows до сих пор проблем не было. Но и не использует никто Касперского на линуксе; на маках тоже практически не использует. На серверах касперский тоже не стоит. > Есть ли сервера или рабочие станции с KSWS 10 где проблема повторяется ? Есть. Но "повторяется", это такое слово... вот после недели паники (и моего досрочного по этому поводу прерывания отпуска) оно взяло и заработало все "само", на всех машинах -- KES SP2 mr2 и mr3_beta. И ломалось тоже поэтапно -- сначала на одной версии Windows 10 (вроде бы 1803), потом Fall Creators, а у пользователей Win81 был праздник. Потом сломался и Win81. Начался на некоторых машинах снос Касперского, на большинстве -- отключение компонентов политиками. Потом, как я и говорил, "заработало". Где-то потом добавились KES11, на них тоже работало. Через какое-то время на каких-то машинах опять сломалось. Потом опять починилось. Сейчас снова этап "начало ломаться". Два делловских лаптопа, даже модель одна (E7470), установлена Win10 1803 с одного образа практически одновременно. На одном VPN сегодня утром вис, пока не отключили Firewall, на другом сегодня вечером работает с теми же настройками Firewall. Что я могу сказать, кроме того, что попробую их же завтра утром? Один (висячий), правда, под политикой KSC, другой -- еще даже без установленного агента. И в логах Касперского ничего нет. Каким бубном изгонять "20 пинг-пакетов проходит, потом -- амба"? Я помню, много лет назад было горе, Касперский убивал -- по своему внутреннему таймауту -- tcp-сессии (telnet/ssh, например, или подключения к Oracle); я приблизительно понимаю по аналогии с iptables, как это могло быть устроено, и рецепты решения проблемы tcp timeout публиковались. Тоже "неочевидные внутренние действия". Привязка по времени суток -- вот такое мне поискать в голову не приходило...
  12. Получил ответ в рамках инцидента: "подтвердить или опровергнуть ваши предположения, что что-то меняется в базах, не можем, нет данных". При этом на каких-то Win10 машинах (в т.ч. с KES11) OpenVPN работает, на каких-то нет. А потом начинает на всех работать. Само. А через неделю-две опять катастрофа-неработа -- для нашей компании OpenVPN является критической инфраструктурой (намного более критичной, чем любой антивирус). С билдом Windows вроде как тоже не связать. Счастье админа. KSN отрубить, что ли?
  13. TAP не в состоянии сделать dhcp release при disconnect, например. И отключиться. .OpenVPN bridged connection. с конфигурационным файлом и всем прочим.
×
×
  • Create New...

Important Information

We use cookies to make your experience of our websites better. By using and further navigating this website you accept this. Detailed information about the use of cookies on this website is available by clicking on more information.