Контрмеры

Паразиты класса Rootkit опаснее угроз вчерашнего дня

В 2001 г. главными факторами устрашения были черви Nimda и Code Red. Сегодня они почти безобидные пустячки по сравнению с такими вредоносными программами, как руткиты.

Что же делал Code Red, некогда так пугавший ИТ-администраторов? Всего лишь портил домашние страницы Web-сайтов. Даже Nimda - для своего времени весьма деструктивный червь - бледнеет на фоне руткитов, главной сегодняшней угрозы ИТ-администраторов и менеджеров по безопасности. Если восстановление бизнеса после налета Nimda и Code Red можно было сравнить с очисткой дома, который забросали яйцами хулиганистые соседские дети, то последствия успешной атаки руткита подобны ситуации, когда забравшийся в дом вор перерыл все ваше добро, украл ваши документы, поставил в комнатах и на телефоне "жучки" .

Как должны себя вести ИТ-менеджеры, обнаружившие, что руткит превратил их системы в собственный "центр развлечений"? К сожалению, наилучший выход зачастую сводится к рекомендации, которую получила фирма, фигурировавшая в обзоре eWeek Labs "Anatomy of a rootkit hack" (http://www.eweek.com/article2/ 0,1759,1776615,00.asp), - надо все "снести". Иными словами, следует демонтировать систему, в которую внедрился руткит, и построить ее с нуля. (Неудивительно, что компания, о которой шла речь в обзоре, пожелала не упоминать своего названия.)

Шаг Четвертый:контрмеры

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

Когда "выдергивать штепсельную вилку"

Для большинства системных инфекций первый шаг после обнаружения проблемы состоит буквально в том, чтобы "выдернуть штепсельную вилку". Это совершенно правильно, если затронута лишь одна система, однако как выдернуть ее, когда дело касается сети? Если рассматриваемая сеть является внутрикорпоративным сегментом, надо "выдергивать вилку" для всего сегмента. Хотя это и вызовет протесты пользователей, отключение пораженных систем от Интернета - абсолютно необходимая мера.  

Что же касается ресурсов и сегментов сети, которые отключать нельзя (к ним относятся, например, Web-серверы, серверы баз данных и приложений), то для них может понадобиться мера, предпринятая компанией из нашей статьи "Anatomy of a rootkit hack", а именно умышленная порча собственных DNS-таблиц. Это собьет с толку руткит при поиске зараженных систем.

После изоляции всех потенциально инфицированных систем необходимо найти и удалить сам руткит. Тут помогут и стандартные приложения - скажем, антивирусное ПО. Однако против руткитов целесообразно задействовать специальные программы, в частности Sysinternals RootkitRevealer для Microsoft Windows, использующие для нахождения изменений в системе, вызванных действиями руткита, методы обнаружения коррелирующих признаков.

На этом этапе крайне важно выявить все без исключения процессы, связанные с инфекцией руткита, для чего необходимо мобилизовать весь ИТ-персонал компании. Надо проверить все, что находилось в прямом или косвенном контакте с инфицированными системами, и изучить все процессы, выполнявшиеся этими системами с момента внедрения руткита.

Sysinternals RootkitRevealer сканирует Windows-системы на предмет обнаружения

потенциальных следов инфекции руткитами

Именно эти действия предприняло руководство ИТ-отдела фирмы из нашего очерка "Anatomy of a rootkit hack", которое, к своему прискорбию, обнаружило, что один из ИТ-специалистов использовал имя и пароль администратора домена на системе, уже инфицированной руткитом и клавиатурным шпионом. Этот промах предоставил атакующим ключи практически ко всем закоулкам ИТ-инфраструктуры компании.

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

Если у вас были планы по обновлению ваших инфраструктур безопасности, сети и серверов, то есть повод осуществить и их. Все это большая работа, однако если у злоумышленников останется хотя бы один действующий пароль, вам так или иначе придется ее проделать.

На заключительном этапе надо попытаться предотвратить повторение такой неприятности в будущем.

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

Инфекции руткитов и тяжелая работа по их устранению дают хороший повод еще раз напомнить о важности четкого соблюдения правил безопасности. Очевидно, нужно дополнительно подучить ваш ИТ-персонал. Но по большому счету в работе над безопасностью не должно быть места передышкам.

Жертвы инфекции руткитов, как и люди, у которых украли документы, никогда не смогут быть стопроцентно уверены, что все поправилось, что нигде не затаилась маленькая троянская программка или другой руткит, ожидающие момента для нового удара, когда ИТ-персонал ослабит свой контроль.

Постоянная бдительность - это единственно эффективная ответная реакция.