Управление безопасностью службы сервера с помощью групповой политики

Вы внимательно изучили свои серверные службы? Приняли ли вы соответствующие меры для защиты ключевых аспектов ваших услуг? Тебе следует!

Почему услуги должны быть защищены

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

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

• LSASS — это подсистема локального органа безопасности, которая отвечает за аутентификацию пользователей, как локальных, так и удаленных. LSASS также отвечает за контроль и соблюдение локальной политики безопасности.
  
• Диспетчер учетных записей безопасности — эта служба управляет локальным SAM, в котором хранятся локальные пользователи и группы. SAM является ключом к безопасности системы, так как он также хранит пароли для учетных записей пользователей и в случае взлома может позволить злоумышленнику получить доступ к компьютеру.
  
• Центр распространения ключей Kerberos — эта служба управляет созданием и распространением ключей проверки подлинности Kerberos для компьютеров и проверки подлинности пользователей в Active Directory.

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

Атака типа «отказ в обслуживании» обычно осуществляется, потому что служба работает на заданном порту или канале связи, который хорошо известен и задокументирован. Злоумышленник или злонамеренный кодировщик может использовать эти порты и каналы связи, чтобы попытаться «заблокировать» линии связи, чтобы помешать работе служб. Например, если служба центра распространения ключей Kerberos, работающая на контроллере домена Windows, перестанет функционировать, пользователи не смогут войти в систему или получить новые билеты Kerberos для аутентификации в сетевых ресурсах.

Это только службы по умолчанию, а как насчет дополнительных служб, которые устанавливаются после запуска сервера? Как и службы по умолчанию, дополнительные службы также могут представлять угрозу безопасности. Существуют службы, которые можно установить для запуска служб веб-хостинга, служб FTP, резервного копирования файлов и даже ключевых приложений на сервере. Когда эти службы предназначены для передачи и управления конфиденциальными данными и файлами операционной системы, они представляют собой потенциальные ворота для злоумышленника, чтобы получить доступ к этой информации.

В случае службы World Wide Publishing и службы FTP они работают на определенных портах. Эти порты использовались годами, что позволяло запускать вредоносный код и получать доступ к компьютеру через эти порты. В течение многих лет было обычной практикой не разрешать запуск этих служб на важных серверах, особенно на контроллерах домена.

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

Почему сервисные аккаунты должны быть защищены

Большинство пользовательских служб, устанавливаемых после операционной системы, должны иметь учетную запись службы, настроенную для работы вместе с ней. Учетная запись службы предназначена для выполнения задач, которые должна выполнять служба, как в локальной системе, так и на удаленных компьютерах. Обычно это требуется, поскольку действия, выполняемые службой, требуют проверки подлинности. Служба не может пройти аутентификацию, так как в Active Directory нет объекта, который может представлять эту службу. Вместо этого учетная запись службы действует от имени службы.

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

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

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

Использование групповой политики для защиты служб

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

Рисунок 1: Управление службами в объекте групповой политики по умолчанию

В стандартном объекте групповой политики вы можете управлять типом запуска службы и списком управления доступом (ACL) для службы. Тип запуска является ключевым, так как он определяет, как служба работает при запуске компьютера. Конечно, если вы имеете дело с контроллером домена и хотите, чтобы служба FTP не запускалась при загрузке компьютера, вы можете отключить тип запуска.

Для ACL вы можете указать, кто может управлять поведением службы после запуска сервера и службы. Когда вы настраиваете ACL для службы, вы можете указать, какой пользователь или группа могут запускать, останавливать или приостанавливать службу. Этот ACL не отображается из обычной консоли управления службами, поэтому это идеальный способ централизовать безопасность службы.

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

Рисунок 2: PolicyMaker позволяет контролировать учетную запись службы и пароль

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

Резюме

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