Казалось бы, все хорошо. Пользователи работают в сети с минимальными привилегиями, не имеют возможности войти в сеть с чужой рабочей станции, на их компьютерах установлены только необходимые для работы программы. Системная политика предписывает пользователям менять пароль раз в две недели, что они послушно исполняют, причем слова, выбираемые ими в качестве пароля, напоминают кличку кота программиста или выходную последовательность генератора случайных чисел. Руководство обзавелось аппаратными средствами двухфакторной аутентификации, и администратора больше не беспокоит состояние Caps Lock на клавиатуре шефа. Но вдруг выясняется, что учетные записи пользователей переместились из группы Users в группу Administrators, и все компьютеры отдела маркетинга заражены свежим вирусом, а группа операторов открыла на полный доступ корневой раздел диска «C:\». Кто виноват во всех этих неприятностях?

Вспомним, что в операционных системах Windows 2000 по умолчанию создаются две учетные записи. Первая - это учетная запись для гостевого доступа Guest. Она заблокирована и имеет весьма ограниченные права. Вторая - учетная запись Administrator, которая имеет неограниченные полномочия на данном компьютере и является одним из основных объектов атак.

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

У вас нет возможности отключить эту учетную запись (данная возможность появилась в Windows XP). Пароль локального администратора обычно устанавливается техническим персоналом или самими пользователями. Возможность централизованного контроля пароля администратора отсутствует. Он может быть подобран по сети, поскольку политика блокировки на данную учетную запись не распространяется.

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

Необходимо определиться с тем, какая учетная запись будет использоваться при восстановлении систем: локальная учетная запись или учетная запись пользователя домена. Локальная учетная запись может применяться для восстановления системы даже в случае отсутствия связи с доменом. Использование доменной учетной записи позволяет усилить защиту от изменения пароля при физическом доступе к компьютеру, но снижает вероятность восстановления системы в случае проблем с сетевым взаимодействием.

Локальную учетную запись рекомендуется использовать на серверных системах, имеющих достаточную физическую защиту и требовательных к процедуре восстановления. В этом случае создается учетная запись, отличная от учетной записи локального администратора. Согласно рекомендациям Дэйва Клеймана (dave@netmedic.net), желательно применять в имени учетной записи специальные символы, к примеру, символ Alt-251. Как показывают его исследования, учетные записи, содержащие в своем имени подобные символы, не отображаются или неверно отображаются программами типа sid2user или showmbrs. Кроме того, такие имена затрудняют подбор паролей программой L0phtCrack и подобными утилитами. Полный список символов и подробный анализ их использования описан в статье Дэйва Клеймана «Defeating password cracking» (см. http://securityfocus.com/archive/88/312976/2003-03-24/2003-03-30/1 ).

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

Следующая задача - ограничение возможности изменения пути наследования групповых политик. В объекты групповой политики входит параметр Computer Settings\Administrative settings\System\Group Policy\User Group Policy loopback processing mode (см. статью Microsoft Q231287), который позволяет изменить способ вычисления результирующей групповой политики. Если этому параметру на локальном компьютере присвоено значение Replace и нет других политик, регламентирующих его значение, результирующая политика будет определяться только на основе того, в каком организационном подразделении находится данный компьютер, вне зависимости от того, кто из пользователей зарегистрировался в системе. Именно из-за него у локального администратора появляется возможность обхода ограничений групповой политики, таких, как запуск приложений, ограничение доступа к меню Start и других, применяемых обычно на уровне пользователя, для всех пользователей данного компьютера.

Чтобы избежать подобной ситуации, необходимо присвоить параметру User Group Policy loopback processing mode значение Disabled в политике уровня домена, имеющей статус No Override. В случае необходимости применения данной функции на определенных компьютерах нужно для их учетных записей запретить доступ к политике, отключающей эту возможность.

Следующим шагом является ограничение членства в группе локальных администраторов. Данный параметр тоже удобно конфигурировать через групповые политики. Свойство GPO Restricted Groups позволяет указывать, какие учетные записи должны быть членами той или иной группы. В группу локальных администраторов необходимо включить администраторов домена, а также группу, в которую входят учетные записи персонала, осуществляющего техническую поддержку компьютеров подразделения. Поскольку последний параметр может быть в каждом подразделении свой, целесообразно применять подобные политики на уровне организационного подразделения.

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

Далее имеет смысл произвести централизованную смену пароля локального администратора, а также локальной учетной записи, используемой для восстановления на компьютерах домена. Метод SetPassword объекта User позволяет изменять пароль пользователя как с данного компьютера, так и по сети (см. Листинг 1).

Использование для смены пароля локального администратора сценариев запуска компьютера (Startup Scripts) нецелесообразно с точки зрения безопасности, поскольку требует указывать пароль в тексте сценария. Утилита кодирования файлов сценариев Microsoft Script Encoder не обеспечивает должного уровня безопасности, поскольку результат ее работы может быть легко раскодирован. Более безопасный сценарий предполагает периодический запуск программы, осуществляющей смену пароля локального администратора на компьютерах в домене. Список компьютеров можно взять из файла, причем разным группам компьютеров может присваиваться свой пароль локального администратора. Пример сценария, выполняющего подобные функции, приведен в Листинге 2.

Приведем несколько примеров использования данного сценария. Для смены пароля локального администратора на локальном компьютере необходимо набрать команду:

cscript lapass.vbs -h . -p pass

Смена пароля локального администратора на компьютерах, чьи имена сохранены в файле hosts.txt, произойдет при вызове команды со следующими параметрами:

cscript lapass.vbs -f host.txt -p pass

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

Следующим шагом является запрет входа локального администратора с консоли компьютера или доступа к нему по сети. Необходимо понимать, что полный запрет доступа локального администратора к консоли в случае, если в системе отсутствует другой пользователь с административными привилегиями, может крайне затруднить процедуру восстановления системы после сбоя. В связи с этим запрещать локальный вход в систему администратору на серверах домена не рекомендуется, достаточно ограничить право на доступ по сети. Для того чтобы лишить администратора права на доступ к компьютеру по сети (см. статью Microsoft Q281140), достаточно в параметре Computer Settings\Windows Settings\Security Settings\Local Polices\User Right зAssigments\Deny access to this computer from the network указать учетную запись администратора. Второй параметр, регулирующий вход с консоли Deny logon locally, находится в том же разделе групповой политики.

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

Чтобы избежать подобной ситуации, можно использовать утилиту passprop из состава Windows NT Reskit, позволяющую включить блокировку учетной записи администратора при превышении счетчика попыток неудачной сетевой аутентификации. Количество попыток задается через параметр Computer Settings\Windows Settings\Security Settings\Local Polices\Account Lockout Policy\Account lockout threshold. Блокировка не распространяется на попытки входа администратора с консоли компьютера. Поскольку в системе могут присутствовать дополнительные локальные учетные записи, рекомендуется настраивать блокировку на короткий промежуток времени (10 мин) после двух-трех неудачных попыток. Эффективность данного метода может повысить периодическая смена паролей.

Приведенные методы позволяют усилить защиту от большинства типовых атак, нацеленных на получение в системе прав локального администратора и несанкционированное использование административных привилегий. Дополнительный уровень защиты дает возможность организовать предупреждение успешных попыток входа в систему с правами локального администратора. Для этого необходимо отслеживать события в журналах компьютеров домена с ID 528 и 540, в которых значение поля Domain совпадает с полем Workstation Name.

К сожалению, в состав Windows 2000 не входит система мониторинга и реагирования на события в режиме реального времени. Подобные функции выполняет ряд систем обнаружения атак уровня хоста и систем централизованного управления сетевой инфраструктурой. В качестве простого решения можно предложить использование Script.vbs - сценария загрузки компьютера для назначения локальным пользователям сценария регистрации в системе, извещающего администратора сети о регистрации пользователя (см. Листинг 3).

Данный сценарий определяет путь к системной папке Windows, после чего пытается создать в ней подпапку \Repl\Import\Scripts. Данная папка используется для сохранения сценариев пользователей и не создается по умолчанию на компьютерах, которые не являются контроллерами домена. Далее в папке создается файл Echo.vbs (см. Листинг 4), присваиваемый в качестве сценария регистрации локальным пользователям. Этот сценарий определяет, от имени локальной или доменной учетной записи производилась регистрация, и в первом случае отсылает уведомление на компьютер администратора.

Сценарий Script.vbs выполняется каждый раз при загрузке компьютеров и пересоздает сценарий Echo.vbs. Кроме того, он обновляет привязку сценариев регистрации пользователей к этому файлу. Сам файл Echo.vbs выполняется в случае регистрации в системе локального пользователя. Можно расширить функциональность сценария Script.vbs, чтобы он изменял сценарии регистрации в системе у всех локальных пользователей.

Приведенные методы не защищают систему от квалифицированных злоумышленников, которые могут подменить операционную систему на компьютере, но позволяют повысить степень защиты сети.

Дизайн и поддержка: Silicon Taiga

Обратиться по техническим вопросам