Изоляция Служб В Windows

Как известно, службы Windows являются одним из самых популярных мест для атак на операционную систему.

В худшем случае (для нас, конечно) злоумышленник получает возможность действовать на атакуемом компьютере в контексте учетной записи, под которой запущен скомпрометированный сервис.

А если эта учетная запись имеет права администратора, то злоумышленник фактически получает полный контроль над компьютером.

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

Хотелось бы вкратце рассмотреть, что принципиально изменилось в этом направлении за последние несколько лет. Первые существенные изменения в механизмах защиты служб появились в Windows XP Service Pack 2. Сейчас трудно представить, но до выхода SP2 все службы самой операционной системы запускались в контексте встроенной учетной записи Local System, который имел наиболее полные административные права на компьютере.

В SP2 добавлены еще две записи: Local Service и Network Service. Принципиальные различия между тремя перечисленными статьями можно найти в табл.

1.

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

Маркер доступа также содержит идентификаторы SID групп «Все» и «Прошедшие проверку».

Таблица 1 Соответственно, начиная с Windows XP SP2, администратор мог настроить запуск службы в контексте одной из встроенных учетных записей, локальной или доменной.

Однако большинство служб Windows по-прежнему работают в контексте локальной системы.

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

взломан сервисный аккаунт. В Windows Vista представлено несколько механизмов повышения изоляции служб.

Я остановлюсь на двух.

Первый механизм — это уникальный идентификатор безопасности службы (Service SID).

Этот SID генерируется для каждой службы путем хеширования имени службы с использованием алгоритма SHA-1. К результату добавляется префикс S-1-5-80-.

Посмотреть SID службы можно с помощью команды sc showsid, указав имя службы в качестве параметра (см.

рис.

1).



Изоляция служб в Windows

Рис.

1 Вы можете поэкспериментировать, например, с сервисом W32Time. Для любой папки на NTFS в настройках разрешений нужно только ввести имя пользователя в формате NT SERVICE\ , в нашем случае NT SERVICE\w32time (см.

рис.

2).



Изоляция служб в Windows

Рис.

2 Нажимаем «Проверить имена», затем «ОК» и видим пользователя (см.

рис.

3), которому можно назначить права.



Изоляция служб в Windows

Рис.

3 Позвольте мне еще раз подчеркнуть, что w32time не является пользовательским объектом.

Это SID, но раз он таков, его можно использовать в ACL как в графическом интерфейсе, так и в командной строке и программно.

Более того, SID служб можно использовать в настройках брандмауэра Windows, применяя определенные правила к конкретной службе, а точнее к конкретному Service SID. Второе изменение, появившееся в Vista, — это новый тип идентификатора безопасности — Write Restricted SID. Если сервис помечен типом Write Restricted SID, то его SID добавляется в собственном токене доступа в специальный список — Restricted SID list. Когда такой сервис пытается что-то записать в файл, алгоритм проверки прав доступа немного меняется.

А именно, служба сможет записывать в файл только в том случае, если разрешение на запись явно предоставлено SID этой службы или группе «Все».

Например, ServiceAccount1 некоторой службы Service1 является членом Group1. Группа1 и только она имеет разрешение на запись в папку1. Что произойдет, если служба попытается изменить что-то в папке Folder1? В обычной ситуации ServiceAccount1 сможет осуществлять запись в папку благодаря своему членству в Group1. Но если Service1 помечен SID с ограниченной записью, то ее токен доступа обрабатывается по-другому, и она не сможет ничего записывать в папку, поскольку ей явно не предоставлено разрешение на запись, и это право не предоставлено всем.

Посмотреть тип SID можно с помощью команды sc qsidtype (см.

рис.

4).



Изоляция служб в Windows

Рис.

4 В частности, на рис.

4 вы видите, что служба брандмауэра Windows относится именно к упомянутому типу.

Естественно, этот тип был введен для того, чтобы еще больше ограничить возможности сервиса (возможность стереть или перезаписать что-либо) в случае его успешного взлома.

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

Если бы они только могли этим воспользоваться.

В Windows 7 и Windows Server 2008 R2 работа над изоляцией служб продолжалась.

Появились виртуальные учетные записи и управляемые сервисные учетные записи.

в чем именно проблема?: Нам необходимо изолировать сервисы — создадим необходимое количество локальных (или доменных) учетных записей пользователей.

Каждая критическая служба имеет свою собственную учетную запись.

Да, это решение.

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

А также периодически обновлять их вручную.

Ну раз уж мы за безопасность.

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

Это неудобно.

Но настоящей проблемой становится неудобство, когда сервис не может запуститься из-за истекшего пароля.

А админ просто забыл сменить для него пароль.

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

Виртуальная учетная запись используется только для запуска определенной службы или, скорее, для создания контекста безопасности для конкретной службы.

Вы не найдете эту запись среди пользователей в разделе «Управление компьютером».

И еще, это учетная запись, со своим уникальным SID, со своим профилем пользователя.

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

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

Мы изолируем нужные нам сервисы, и нам не нужно беспокоиться о паролях.

Для создания виртуальной учетной записи необходимо в настройках службы в качестве учетной записи указать: NT SERVICE\ (см.

рисунок 5)

Изоляция служб в Windows

Рис.

5 После запуска службы виртуальная учетная запись появится в консоли «Службы» (рис.

6), а в папке «Пользователи» вы заметите появление нового профиля пользователя.



Изоляция служб в Windows

Рис.

6 Формат очень похож на SID службы.

Но подчеркну, что это не просто дополнительный уникальный SID для сервиса как в Висте, это отдельная учетная запись и соответственно другой уровень изоляции.

По умолчанию виртуальные учетные записи используются, например, для пулов приложений в IIS 7.5 в Windows Server 2008 R2. Необходимо иметь в виду, что виртуальные учетные записи предназначены для локального использования.

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

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

Однако с ними связано больше тонкостей, и их рассмотрение выходит за рамки данного поста.

Более подробно Вы можете ознакомиться с MSA Здесь .

Перечисленные мною механизмы изоляции сервисов на этом не заканчиваются.

Вы также можете упомянуть изоляцию нулевых сеансов, уровни целостности и механизм DEP. Я остановился на тех, которые, как мне кажется, менее известны, но в то же время имеют весьма практическое значение для администратора.

И конечно, работа над улучшением безопасности сервисов в будущих версиях Windows продолжится.

Теги: #Windows 7 #Windows XP #Windows Vista

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.