We rise up for the things we believe in over and over again


Лечение сети. Как уже ранее было написано, первое - это серверы. Их еще три. Впрочем, это уже намного меньше, чем в начале вакханалии. Основная проблема кроется даже не в самой процедуре лечения, не в том, что нужно еще найти, как убивать вредоноса. Нет, проблема в пользователях. Самое парадоксальное - их и винить не в чем, в конце концов, тот факт, что блокировка учетных записей идет почти непрерывно - всецело "заслуга" IT отдела. Поэтому приходится из двух зол выбирать то, что меньше буянит - то есть отключение блокировки учеток. Данная мера снижает безопасность сети в целом, но о какой безопасности может идти речь в такой ситуации. Пароли административных записей сменены, нужно обеспечить работу предприятия в целом.
Итак - как это сделать. Снова уже до боли знакомые нам групповые политики.
Создать новую, прицепить ее к корню домена. Областью действия назначить Authentificated users (в русской версии - Прошедшие проверку). Далее настройка самой политики:
Computer Configuration - Windows Settings - Security Settings - Account Policies - Account Lockout Policies.
Параметр Account Lockout Threshold выставить в 0. Два оставшихся держим как Not Applicable (Не задано)
После чего - ждем полтора часа. Это время, в течение которого политика применяется к клиентским компьютерам. В течение этого промежутка времени блокировки еще будут проходить.
С блокировками более мене понятно, после этих мер по крайней мере не будут отвлекать от работы. Остается другая проблема - безумная активность сети. Небольшой факт - за пару минут червь способен заблокировать более 70 учетных записей при минимальном количестве включенных компьютеров (относительно дневного времени, конечно). Соответственно, проблема в медленной работе сети в целом. Можете себе представить, каково приходится контроллерам домена, которые вынуждены обрабатывать лавину запросов. Нужно это как-то остановить. Если сеть большая, и поражена немалая ее часть - спасает только массовая проверка в режиме максимальной злобности. Если же есть уверенность, что точек заражения немного, то можно очень быстро их локализовать. В этом нам помогут политики контроллеров домена.
Работа в домене имеет одну особенность - практически любая активность пользователя порождает событие, которое контроллер может зафиксировать у себя в журнале. В случае борьбы с Kido - незаменимый инструмент. Критерием отбора пораженных машин будет постоянный поток сообщений о непройденной регистрации в домене. Нужно лишь включить регистрацию подобных событий. Как сделать:
Новая политика контроллеров домена - Computer Configuration - Windows Settings - Security Settings - Local Policies - Audit Policy
Включить параметр Audit Account Logon Events, Failure
Включить параметр Audit Logon Events, Failure
Применить политику к контроллерам домена, после чего ждать 5 минут. В течение этого времени политика применяется ко всем контроллерам.
После того, как политика будет применена, нужные нам сведения можно будет отыскать в Журнале Событий контроллера домена в журнале Безопасности. Там все будет достаточно прозрачным.
Ну и последнее на сегодня. Между моментом создания политики отмены блокировки учетных записей и моментом ее применения проходит весьма значительный промежуток времени, за который в домене могут снова появиться заблокированные пользователи. Как от таких избавиться? Искать их руками занятие бессмысленное. Гораздо проще воспользоваться скриптом, которых находит в домене все заблокированные учетные записи и сбрасывает с них флаг блокировки. Сам сценарий выглядит вот так: Unblock Users in Domain.vbs
Я искренне надеюсь, что никому его не придется применять. Борьба с Kido - вещь все же выматывающая.
Процесс можно ускорить - просто перезагрузив все компьютеры домена, или выполнить на всех gpupdate /force. Но это не всегда возможно )