Заметки о Windows и других программных продуктах Microsoft...

Защищаем учетную запись локального администратора

Защищаем учетную запись локального администратора

В каждой операционной системе Windows по умолчанию присутствует встроенная (built-in) учетная запись администратора. Эта учетная запись имеет неограниченные права и при ее компрометации злоумышленник получает полный контроль над системой. Чтобы этого не произошло, встроенную учетную запись администратора необходимо защитить.

Существует множество различных способов защиты и сегодня мы рассмотрим некоторые из них.

Отключение и переименование

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

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

В производственной среде сделать это проще всего с помощью групповых политик. Нужные нам параметры находятся в разделе Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options.

объект групповой политики, раздел опций безопасности

 

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

За переименование отвечает параметр политики с именем Accounts: Rename administrator account. Надо открыть его, отметить чекбокс ″Define this policy settings″ и задать новое имя пользователя. Имя может быть любое, насколько хватит фантазии. Как вариант, можно переименовать администратора в гостя (Guest), а гостя в администратора. Поскольку у гостевой учетной записи практически нулевые права в системе, то взломав ее злоумышленник будет неприятно удивлен 🙂

переименование учетной записи администратора

 

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

Поэтому более эффективным способом защиты учетной записи администратора является ее отключение. Для отключения используется параметр политики с названием Accounts: Administrator account status. Надо открыть его, отметить чекбок ″Define this policy settings″ и поставить переключатель в положение Disabled.

отключение учетной записи администратора

 

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

отключенный переименованный пользователь

 

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

Запрет на вход

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

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

Примечание. Права входа (Logon Rights) определяют способы входа в систему, доступные для пользователя.

В разделе Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment находятся следующие параметры:

Deny log on locally — запретить локальный вход в систему;
Deny log on through Remote Desktop Service — запретить доступ с помощью службы удаленных рабочих столов;
Deny access to this computer from the network — запретить доступ к компьютеру по сети. Доступ по сети используется при удаленном доступе к файловой системе или приложениям;
Deny log on as a service — запретить пользователю регистрироваться в качестве службы. Это право обеспечивает работу служб Windows в фоновом режиме;
Deny log on as a batch job — запретить пользователю регистрацию в качестве пакетного задания. Это право используется планировщиком заданий (Task Scheduler) и некоторыми другими службами.

политики безопасности для локальных пользователей

 

Для активации параметра политики надо надо открыть его, отметить чекбок ″Define this policy settings″ и указать пользователей или группы, для которого эта политика будет применяться. В нашем случае надо указать имя Administrator.

пример включения параметра групповой политики

 

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

результат настройки

 

После применения запрещающих политик надо проверить их работу. Для проверки запрета на вход по RDP попробуем зайти на сервер с помощью RDP клиента, и если все получилось, то получим примерно такое сообщение.

ошибка при попытке подключения по RDP

 

Проверить запрет на доступ по сети несколько сложнее. Для проверки надо зайти на сервер локально, запустить от имени администратора командную консоль и выполнить команду net use. Например:

net use \\SRV2\C$

Если политика отработала корректно, то вместо ответа будет выдана ошибка с номером 1385.

ошибка при попытке удаленного подключения по сети

 

Для проверки запрета на запуск в виде сервиса надо открыть оснастку Services, выбрать любой некритичный сервис, например сервис печати (Print spooler), и попробовать запустить его от имени локального администратора.

настройка сервиса

 

В результате должна получиться следующая ошибка.

ошибка при запуске сервиса от имени администратора

 

Ну и проверить запрет на запуск в виде пакетного задания можно с помощью планировщика заданий (Task scheduler). Для этого создадим в планировщике задание и укажем его запуск от имени учетной записи локального администратора.

настройка задания в планировщике

 

В случае успеха при сохранении задания мы получим ошибку.

ошибка при сохранении задания

Заключение

В заключение некоторые важные моменты, о которых необходимо помнить:

• Если вы решили отключить встроенную учетную запись администратора, то не забудьте создать на компьютере хотя бы одного пользователя с административными правами;
• Не рекомендуется применять вышеописанные политики к контроллерам домена. Дело в том, что на контроллерах домена нет локальных учетных записей и политики применяться к учетной записи DSRM администратора. При недоступности этой учетной записи вы не сможете зайти на контроллер домена в режиме восстановления Active Directory;
• При отключении политики переименования учетной записи администратора имя пользователя может не измениться на исходное. В этом случае потребуется в политике прописать стандартное имя, подождать пока она применится, и только потом ее отключать.

 
 
Комментарии

Если учетная запись админа отключена, то нужно ли дополнительно отключать права на вход? Я думал, что отключение записи админа автоматически не позволяет входить ему в ОС никаким способом.

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

Ответить