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

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

Почему необходимо заботиться о безопасности служб

Знаете ли вы или нет, но после установки все ваши сервера Windows servers работают на основе служб. Служба (service) – это особое приложение, с помощью которого операционная система выполняет определенную задачу, или набор задач. Ваши сервера запускают различные службы сразу же после установки, потому что для правильной работы операционной системе необходимо много этих служб.

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

• LSASS – это локальная подсистема безопасности (Local Security Authority Sub System), которая отвечает за аутентификацию пользователей, как локальных, так и удаленных. Служба LSASS также отвечает за контроль и соблюдение локальной политики безопасности.
• Security Account Manager (менеджер безопасности учетной записей) – это служба контролирует локальный SAM, который содержит локальных пользователей и группы. SAM – это основа безопасности системы, т.к. он содержит пароли для учетных записей пользователей, и в случае его взлома злоумышленник может получить доступ к компьютеру.
• Kerberos Key Distribution Center (Центр распространения ключей керберос) – эта служба контролирует формирование и распространение ключей для аутентификации керберос (Kerberos authentication key) для аутентификации компьютеров и пользователей в Active Directory.

Достаточно ясно, что если кто-то сможет взломать эти службы, то у них появится возможность входа не только на сервер, но в домен. В большинстве случаев, служба не взламывается, а подвергается атаке типа отказ в обслуживании (denial of service attack).

Атака типа отказ в обслуживании обычно доводится до конца, т.к. определенная служба работает по определенному порту, и вся эта информация хорошо известна и документирована. Злоумышленник или взломщик может попробовать заблокировать эти порты и каналы, что службы перестали работать. Например, служба центра распространения ключей керберос (Kerberos Key Distribution Center service), которая работает на контроллере домена Windows Domain Controller, перестала работать, и тогда пользователи не смогут войти в сеть или получить новые билеты керберос (Kerberos tickets) для аутентификации на сетевых ресурсах.

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

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

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

Для чего необходимо заботиться о безопасности учетной записи службы

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

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

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

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

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

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

Рисунок 1: Контроль служб в объекте политики групп, созданного по умолчанию

С помощью стандартного объекта политики групп, вы можете контролировать тип запуска службы, и список для контроля доступ (Access Control List или ACL) для службы. Тип запуска здесь является основным, т.к. он контролирует, как будет вести себя служба при запуске компьютера. Конечно, если вы имеете дело с контроллером домена, и хотите гарантировать, что служба FTP не запуститься при загрузке компьютера, то вы можете установить тип запуска «отключено» (disabled).

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

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

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

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

Резюме

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