Изоляция служб в Windows / Блог компании Microsoft / Хабр
| Учетная запись | Локальные ресурсы | Сетевые ресурсы |
|---|---|---|
| Local System | Полный доступ ко всем ресурсам компьютера | Подключение к сетевым ресурсам в контексте учетной записи компьютера, на котором запущена |
| Local Service | Права стандартного пользователя + небольшой набор дополнительных привилегий | Анонимное подключение к сетевым ресурсам |
| Network Service | Права стандартного пользователя + небольшой набор дополнительных привилегий | Подключение к сетевым ресурсам в контексте учетной записи компьютера, на котором запущена. Маркер доступа также содержит SID групп Everyone и Authenticated Users |
Таблица 1 Соответственно, начиная с Windows XP SP2, администратор мог настраивать запуск службы в контексте одной из встроенных учетных записей, локальной или доменной учетной записи. Тем не менее, большая часть служб самой Windows по-прежнему запускается в контексте Local System. Но даже если абстрагироваться от этого, ситуация, когда несколько служб запускаются в контексте одной и той же учетной записи, приводит к тому, что успешный взлом одной службы, пусть даже без административных привилегий, потенциально открывает для атакующего любые другие ресурсы, к которым имеет доступ учетная запись взломанной службы. В Windows Vista появилось несколько механизмов, повышающих изоляцию служб. Я остановлюсь на двух. Первый механизм – это уникальный идентификатор безопасности службы (Service SID). Данный SID генерируется для каждой службы путем хеширования имени службы с помощью алгоритма SHA-1. К результату добавляется префикс S-1-5-80-. Просмотреть SID службы можно с помощью команды sc showsid, указав в качестве параметра имя службы (см. рис. 1).
Рис. 1 Вы можете поэкспериментировать, например, со службой W32Time. Для любой папки на NTFS в настройках разрешений (permissions) нужно лишь ввести имя пользователя в формате NT SERVICE, в нашем случае NT SERVICEw32time (см. рис 2).
Рис. 2 Нажимаете Check Names, затем ОК и видите пользователя (см. рис. 3), которому можно назначать права.
Рис. 3 Еще раз подчеркну, что w32time не является объектом-пользователем. Это – SID, но раз так, его можно использовать в списках ACL, причем как в графическом интерфейсе, так и в командной строке и программным путем. Более того, сервисные SID-ы можно использовать в настройках Windows Firewall, применяя те или иные правила к конкретной службе, точнее конкретному Service SID. Второй изменение, появившееся в Vista, это идентификаторы безопасности нового типа – Write Restricted SID. Если служба помечена типом Write Restricted SID, то ее SID добавляется в ее же маркере доступа в специальный список – Restricted SID list. При попытке такой службы записать что-либо в какой-либо файл алгоритм проверки прав доступа несколько изменяется. А именно, служба сможет записать в файл только в том случае, если разрешение Write дано явным образом SID-у этой службы, либо группе Everyone. Например, учетная запись ServiceAccount1 некоторой службы Service1 является членом группы Group1. Группа Group1 и только она имеет разрешение Write на папку Folder1. Что произойдет, если служба попытается что-то изменить в папке Folder1? В обычной ситуации ServiceAccount1 получит возможность записи в папку за счет членства в Group1. Но если служба Service1 помечена типом Write Restricted SID, то ее маркер доступа обрабатывается иначе, и она не сможет записать что-либо в папку, поскольку ей явным образом не дано разрешение Write, равно как не дано это право и Everyone. Просмотреть тип идентификатора безопасности можно с помощью команды sc qsidtype (см. рис. 4).
Рис. 4 В частности, на рис. 4 вы видите, что служба Windows Firewall относится как раз к упомянутому типу. Естественно, что введен этот тип был для того, чтобы дополнительно ограничить возможности службы (возможности стереть или перезаписать что-либо) в случае ее успешного взлома. Надо также добавить, что данный механизм предназначен в первую очередь не для администраторов систем, а для разработчиков служб. Только бы пользовались. В Windows 7 и Windows Server 2008 R2 работа над изоляцией служб была продолжена. Появились виртуальные учетные записи (virtual accounts) и управляемые учетные записи служб (managed service accounts). А собственно в чем проблема? Нужно изолировать службы – давайте создадим нужное количество локальных (или доменных) учетных записей пользователей. Для каждой критически важной службы свой account. Да, это решение. Но для локальных служб, которым не нужен сетевой доступ к ресурсам, необходимо вручную задавать пароли, длинные и сложные. И также вручную их периодически обновлять. Ну, раз уж мы за безопасность. Для служб, которые должны по сети обращаться к ресурсам в контексте доменных учетных записей, плюс к этому еще нужно регистрировать Service Principal Name (SPN), свой для каждой службы. Это неудобно. Но неудобство становится реальной проблемой, когда служба из-за просроченного пароля не может стартовать. А админ просто забыл сменить для нее пароль. Так вот для локальных служб вы можете использовать virtual accounts. Виртуальная учетная запись используется только для запуска конкретной службы, точнее для создания контекста безопасности конкретной службы. Вы не найдете эту запись среди пользователей в Computer Management. И, тем не менее, это – account, со своим уникальным SID-ом, со своим пользовательским профилем. А стало быть, вы можете назначать ему разрешения и, тем самым, разграничивать права доступа и четко их контролировать. Но также как и в случае с Local System, Local Service и Network Service операционная система берет на себя задачи управления паролями для virtual accounts. Мы изолируем нужные службы, и у нас не болит голова о паролях. Чтобы создать виртуальную учетную запись, нужно в настройках службы указать в качестве учетной записи: NT SERVICE (см. рис 5)
Рис. 5 После запуска службы virtual account отобразится в консоли Services (рис. 6), а в папке Users вы заметите появление нового пользовательского профиля. 
Рис. 6 По формату это очень напоминает сервисный SID. Но подчеркну, это не просто дополнительный уникальный SID для службы как в Vista, это отдельная учетная запись и, соответственно, другой уровень изоляции. По умолчанию виртуальные учетные записи используются, например, для пулов приложений (application pool) в IIS 7.5 в Windows Server 2008 R2. Надо иметь в виду, что virtual accounts предназначены для локального использования. Если служба, запущенная в контексте virtual account, обращается по сети, то это обращение происходит от имени учетной записи компьютера, на котором служба запущена. Если же необходимо, чтобы служба, например SQL Server, работала по сети от имени доменной учетной записи, то здесь как раз помогут managed service accounts. С ними, однако, связано больше тонкостей, и их рассмотрение выходит за рамки данного поста. Более подробно с MSA можно познакомиться здесь. Перечисленные мною механизмы изоляции служб на этом не заканчиваются. Можно еще упомянуть об изоляции нулевого сеанса, уровнях целостности, механизме DEP. Я сосредоточился на тех, которые, как мне кажется, в меньшей степени известны, но при этом имеют вполне практический смысл для администратора. Ну и конечно, работа по усилению защищенности служб в последующих версиях Windows будет продолжена.
Ввод сетевого пароля: где его взять? Методика определения и отключения.
Достаточно часто (особенно в небольших офисах с установленными локальными сетями) можно наблюдать картину, когда вроде все машины, подключенные к локальной сети, работаю нормально, но при доступе к какому-то определенному терминалу требуется ввод сетевого пароля. Где его взять? У сисадмина, как считает большинство юзеров. Как бы не так! А если в системе администратор вообще никаких паролей не устанавливал? Что делать тогда? Ответы на эти вопросы знают не только рядовые пользователи, но и даже некоторые начинающие системные администраторы. Но ничего особо сложнон тут нет.
Ввод сетевого пароля Windows 7: зачем это нужно?
Конечно, никто не спорит о том, что в офисах при наличии достаточно большого количества компьютеров, подключаемых к локальной сети, использование паролей доступа, как на уровне прямого ввода, так и на уровне удаленного доступа, оправдано.
Но вот зачастую, даже если на всех терминалах установлена операционная система Windows 7, в сети они вроде бы «видят» друг друга, но когда, например, производится попытка отправки документа на печать с использованием сетевого принтера, даже при корректных настройках ничего не получается, поскольку требуется ввод сетевого пароля. Где его взять? Администратор сети не в курсе. На самом деле решение данной проблемы есть, и оно достаточно простое.
Как узнать ввод сетевого пароля? Просмотр данных
Сами данные паролей скрыты от глаз пользователя любого уровня (будь он хоть частный юзер, хоть админ, система все равно не дает ему увидеть скрытые данные).
Тем не менее, выход есть. Если взять в расчет, что все папки, включая регистрационные данные, невидимы, нужно просто включить в том же «Проводнике» режим отображения таких объектов. Но и в этом случае найти папку с паролями будет достаточно сложно.
На самом деле все намного проще, и сил тратить не нужно на ввод сетевого пароля. Где его взять и найти интересующий нас параметр? Элементарно! Следует всего лишь использовать команду rundll32.exe keymgr.dll, KRShowKeyMgr в командной строке, запущенной от имени админа.
Как отключить сетевые пароли или изменить их?
В начальном варианте вызываем раздел «Выполнить» (Run) из стандартного меню «Пуск» или с использованием сочетания Win +R.
Затем в самой вызванной консоли прописываем команду Controluserpasswords2 и нажимаем клавишу ввода. В появившемся меню снимаем галочку с требования пароля для выделенных учетных записей (на Windows 10 не работает!).
Те же самые действия можно произвести из «Панели управления», где нужно обратиться к разделу центра управления сетями и общим доступом, а в текущем (общем) профиле установить галочку на пункте использования общего доступа с парольной защитой.
Настройки политики безопасности
В самом оптимальном варианте, когда требуется ввод сетевого пароля (где его взять, что ввести, включить или отключить службу), можно использовать и еще одно достаточно действенное средство – редактирование групповых политик с установкой разрешений доступа к тем или иным функциям системы на уровне администратора или локального юзера.
Для доступа используется команда gpedit.msc, а в самом редакторе — раздел конфигурации компьютера, где нужно найти директорию проверки сетевой безопасности «LAN Manager» и уже в ней активировать параметры отправки LM и NTLM.
Итог
Собственно, на этом – все. Если есть проблема с сетевым паролем, его использование следует просто отключить. Если потребуется, на Windows 7 и ниже можно установить новое сочетание. Но это придется делать на всех машинах, синхронизированных по сети, и при условии, что на всех установлена именно седьмая модификация системы.
Само собой разумеется, что в параметрах редактора групповых политик можно изменить и применить некоторые дополнительные настройки, которые могут быть отнесены к определенной группе или классу пользователей, работающих на одном и том же терминале.
Загрузка...
