среда, 7 декабря 2011 г.

Еще раз о Kido

Интересная, вообще говоря, штука - Kido. Казалось бы, информация уже устарела, так как Касперский давно, вроде бы, проблему решил. Однако, всегда случается так, что она всплывает вновь и вновь. Причин для этого на нашем заводе оказалось всего две - пользователи по-прежнему заносят его откуда попало, а жесткие  меры контроля легко разбиваются об какую-нибудь служебку начальника отдела, подписанную аж генеральным директором - со списком пользователей, которым жутко необходимо для работы дать права локального администратора. Как ни ругайся, не понимают, приходится давать. Я вообще бы на уровне общероссийского законодательства запретил предоставлять такие права и вообще разрешать в России программное обеспечение, требующее для обычного пользователя компьютера непременно админских прав! А вторая причина - ребята из нашей техподдержки привыкли запускать KidoKiller без всяких опций, если компьютер поступает к ним на лечение. А без опций выполняется только проверка системных разделов, а не всех дисков вообще. Так что лежит себе кидошка где-нибудь в каталогах в пассивном виде, пока пользователь с локальными админскими правами туда не залезет - и все началось по-новой...
Воевать с некомпетентностью я устал и просто сделал обходное решение. А именно - скрипт, который копирует KidoKiller на диск пользователя и запускает его в режиме мониторинга. При этом сканируются потоки, сервисы и задания планировщика, если что-то вылезло - тут же запускается лечение. Таким образом, не обязательно постоянно лечить компьютеры, просто само распространение kido пресекается и пакостить он уже практически не может. Конечно, при этом отъедается от оперативной памяти несколько мегабайт - от 2 до 8, я наблюдал на разных рабочих станциях. Однако, может еще напугать, что с запущенным процессом KK.exe периодически диспетчер показывает, как будто этот процесс подскакивает до 20-50 процентов использования процессорного времени, но я при этом не заметил никакого ощутимого падения производительности или зависания других приложений, и потому сделал вывод, что скачки очень кратковренные, а видим мы их только из-за инерции отображения в диспетчере задач.
Скрип очень простой:

copy \\server\kklogs\kk.exe  %SYSTEMDRIVE%\  /Y  &&  %SYSTEMDRIVE%\kk.exe -m -s -l \\server\kklogs\%COMPUTERNAME%_kklog.txt


Опции вполне понятны - запуск в режиме мониторинга, тихий (то есть без открытия окна и уведомлений), лог файл пишется на сервер, чтобы централизованно отслеживать, где были срабатывания. Добавлю только, что скрипт не нужно запускать как скрипт автозапуска, потому что учетная запись SYSTEM не увидит общих папок на серверах, и скрипт не отработает. Я добавил его в логон-скрипты, то есть при входе пользователя в систему он запускается, а ресурс \\server\kklogs просто сделал доступным на запись пользователям домена - это не опасно в данном случае, так как логон информация не критична, она постоянно обновляется.
По этой информации в первый же день работы было выловлено 10 компьютеров, на которых было таки заражение, лечение запустилось автоматически, и на следующий день на этих компьютерах kido уже не светился. KidoKiller, оказалось, прекрасно отрабатывает под правами обычного пользователя. Причем, даже если пролечиваются только избранные источники кидо в отдельных каталогах, это не страшно, если где-то кидо еще лежит в пассивном виде у пользователя. Снова будет обнаружен и обезврежен при активации. А вот если компьютер такого пользователя пролечить полностью - то есть все жесткие диски, то это займет изрядное время, хотя загружается не оперативная память и процессор в основном, а система ввода-вывода HDD. Проблема решена с умеренными затратами при достаточной эффективности.