Изоляция служб в Windows
Как известно, службы Windows представляют собой одно из наиболее излюбленных мест для атак на операционную систему. В худшем (для нас, конечно) случае атакующий получает возможность действовать на атакованном компьютере в контексте учетной записи, от имени которой запущена взломанная служба. И если эта учетная запись обладает административными правами, то фактически злоумышленник получает полный контроль над компьютером. От версии к версии в Windows появляются новые механизмы, обеспечивающие дополнительную изоляцию служб и, как следствие, усиливающие безопасность системы в целом. Я хотел бы вкратце рассмотреть, что принципиально изменилось в этом направлении за последние несколько лет.
Первые существенные изменения в механизмах защиты служб появились в Windows XP Service Pack 2. Сейчас уже сложно себе это представить, но до выхода SP2 все службы самой операционной системы запускались в контексте встроенной учетной записи Local System, обладающей на компьютере максимально полными административными правами. SP2 добавил еще две записи: Local Service и Network Service. Принципиальные отличия трех перечисленных записей можно найти в табл. 1.
32. История Windows NT
| 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).
РЕШЕНИЕ.системные прерывания, процессор 100%, майнер вирус.
Рис. 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 будет продолжена.
Источник: habr.com
Что такое «НТ АВТОРИТЕТ» и «НТ СЕРВИС»
Я могу найти много информации о том, что «NT AUTHORITY» косая черта «что-то». То же самое для «NT SERVICE». Но не для части до слэша. Я сталкиваюсь с ними время от времени в своей работе. Я мог бы получить документацию, например, с администраторами доменов, в которую иногда входят пользователи из этих двух «мест» (NT AUTHORITYSYSTEM или NT SERVICEMSSQLSERVER).
Так что я понимаю, что они какие-то стандартные пользователи.
Так что я бы на самом деле хотел понять, что это за ядро до слэша. Это как-то связано с Windows NT, потому что это не так? Какого черта с этими буквами «NT»? Власть и Служба одного уровня?
изменён ZygD 338
задан ZygD 338
1 ответ 1
Если вы хотите немного поиграть с определениями, NT_AUTHORITY относится к самой операционной системе Windows. Или, возможно, как «вещи, которые ОС разрешает от вашего имени».
(Сначала NT означало New Technology, версию ОС, которая обычно предназначалась для бизнеса. Это контрастировало с менее строгими и менее безопасными ядрами Windows 9.x, используемыми в Windows 98, 98 и более ранних версиях. Начиная с Windows 2000, различные версии были объединены в версии на основе Windows NT 4. В конечном итоге они переросли в Windows Vista, 7, 8.x и скоро выйдут 10.
Токен «NT» в основном является устаревшим токеном, оставленным с более ранних времен. Вы можете думать об этом как о суррогате самой Windows. Официально, это родитель для набора пользователей службы, которые выполняют фоновые задачи и операции обслуживания.
Токены на правой стороне косой черты относятся к отдельным «пользователям» внутренних служб ОС. Например, NT AUTHORITYSYSTEM обрабатывает системные службы, NT AUTHORITYLOCAL SERVICE выполняет локальные службы, NT AUTHORITYNETWORK SERVICE — сетевые службы, и так далее. Дополнительную информацию можно найти в этой теме и в различных местах MSDN. Творческое использование предпочитаемой вами поисковой системы может помочь вам найти еще больше.
По сути, то же самое запускается от имени службы, которая (по сути) является утилитой, работающей в фоновом режиме. (Служба BITS, например, загружает обновления в фоновом режиме.) Работает очень много сервисов, и токен NT_SERVICE используется как способ отличить их от других вещей. Вот статья , в которой более подробные технические детали. (Однако я не отключил бы никакие услуги, если вы точно не знаете, для чего они нужны. Это хороший способ исправить ситуацию.)
Источник: poweruser.guru
ГЛАВА 13
Серверные программы, рассмотренные в главах 11 и 12, являются консольными приложениями, выполняющимися как фоновые задачи. Вообще говоря, эти серверы могут выполняться в течение неопределенно длительного времени, обслуживая многочисленных клиентов по мере того, как те будут подключаться к серверу, посылать запросы, принимать ответы и разрывать соединения. Таким образом, указанные серверы могут работать как службы непрерывного действия, однако, чтобы быть в полной мере эффективными, эти службы должны быть управляемыми.
Службы Windows Services,[33] известные ранее под названием NT Services, предоставляют все средства управления, необходимые для превращения наших серверов в службы, которые могут активизироваться по команде или во время запуска системы еще до входа в нее пользователей, приостанавливаться, а также возобновлять или прекращать свое выполнение. Службы могут даже осуществлять мониторинг работоспособности самих служб. Информация о службах хранится в системном реестре.
В конечном счете, любая серверная система наподобие тех, которые были разработаны в главах 11 и 12, должна быть преобразована в службу, особенно в тех случаях, когда она предназначена для использования широким кругом клиентов или внутри организации.
Windows предоставляет целый ряд служб; в качестве примера можно привести службы telnet, отправки и приема факсимильных сообщений, а также службы управления безопасностью учетных записей и драйверы устройств. Доступ ко всем службам можно получить через пиктограмму Administrative Tools (Администрирование), который находится в окне панели управления.
Примитивную форму управления сервером можно было наблюдать в приведенной в главе 6 программе JobShell (программа 6.3), которая обеспечивает возможность перевода сервера под управление задачи и его остановку путем посылки сигнала завершения работы. В то же время, службы Windows Services предоставляют гораздо более широкие возможности и отличаются высокой надежностью, как это будет продемонстрировано в данной главе на примере преобразования программы к форме, обеспечивающей управление службами Windows Services.
В данной главе также показано, как преобразовать существующее консольное приложение в службу Windows, осуществить ее установку, а также организовать мониторинг и управление этой службой. Кроме того, здесь рассматривается ведение журнала учета событий, что обеспечивает регистрацию действий службы.
Написание программ, реализующихслужбы Windows Services: обзор
Службы Windows выполняются под управлением диспетчера управления службами (Service Control Manager, SCM). Преобразование консольного приложения, такого как serverNP или serverSK, в службу Windows осуществляется в три этапа, после выполнения которых программа переходит под управление SCM.
1. Создание новой точки входа main(), которая регистрирует службу в SCM, предоставляя точки входа и имена логических служб.
2. Преобразование прежней функции точки входа main() в функцию ServiceMain(), которая регистрирует обработчик управляющих команд службы и информирует SCM о своем состоянии. Остальная часть кода, по существу, сохраняет прежний вид, хотя и может быть дополнена командами регистрации событий. Имя ServiceMain() является заменителем имени логической службы, причем логических служб может быть несколько.
3. Написание функции обработчика управляющих команд службы, которая должна предпринимать определенные действия в ответ на команды, поступающие от SCM.
По мере описания каждого из этих трех этапов будут даваться отдельные разъяснения, касающиеся создания служб, их запуска и управления ими. Более подробные сведения приводятся в последующих разделах, а взаимодействие между отдельными компонентами службы иллюстрируется на рис. 13.1 далее в этой главе.
Функция main()
Задачей новой функции main(), которая вызывается SCM, является регистрация службы в SCM и запуск диспетчера службы (service control dispatcher). Для этого необходимо вызвать функцию StartServiceControlDispatcher, передав ей имя (имена) и точку (точки) входа одной или нескольких логических служб.
BOOL StartServiceCtrlDispatcher(LPSERVICE_TABLE_ENTRY lpServiceStartTable)
Эта функция принимает единственный аргумент lpServiceStartTable, являющийся адресом массива элементов SERVICE_TABLE_ENTRY, каждый из которых представляет имя и точку входа логической службы. Конец массива обозначается двумя последовательными значениями NULL.
Функция возвращает значение TRUE, если регистрация службы прошла успешно. Если служба уже выполняется или возникают проблемы с обновлением записей реестра (HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices), функция завершается с ошибками, обработка которых может осуществляться обычным путем.
Основной поток процесса службы, которая вызывает функцию StartService-ControlDispatcher, связывает поток с SCM. SCM регистрирует службу с вызывающим потоком в качестве потока диспетчера службы. SCM не осуществляет возврата в вызывающий поток до тех пор, пока не завершат выполнение все службы. Заметьте, однако, что фактического запуска логических служб в этот момент не происходит; запуск службы требует вызова функции StartService, которая описывается далее в этой главе.
Типичная основная программа службы, соответствующая случаю единственной логической службы, представлена в программе 13.1.
Программа 13.1. main: точка входа main службы
Источник: www.uhlib.ru
Что такое «NT AUTHORITY» и » NT SERVICE»
Я могу найти много информации о том, что такое «NT AUTHORITY» полоснуть «что-то». То же самое для «NT SERVICE». Но не для той части, что перед косой чертой. Я сталкиваюсь с ними время от времени в своей работе. Я мог бы получить документацию, например, с администраторами домена, которая иногда включает пользователей из этих 2 «мест» (NT AUTHORITYSYSTEM или NT SERVICEMSSQLSERVER).
Я так понимаю они какие-то обычные пользователи.
поэтому я хотел бы понять, что это за ядро, что перед разрез. Это как-то связано с Windows NT, потому что так не кажется? Что же с теми «НТ» письма? Авторитет и обслуживание на одном уровне?
1 ответов
Если вы готовы играть немного быстро и свободно с определениями, NT_AUTHORITY по существу относится к самой операционной системе Windows. Или, возможно, как » вещи, которые ОС разрешает от вашего имени.»
(сначала NT означало новую технологию, версию ОС, предназначенную для бизнеса. Это контрастирует с менее строгим, менее безопасным Windows 9.ядра x, используемые в Windows 98, 98 и более ранних версиях. Начиная с Windows 2000, различные версии были объединены на версия, основанная на Windows NT 4. Они в конечном итоге переросли в Windows Vista, 7, 8.x, и скоро будет выпущен 10.
токен «NT» в основном является устаревшим токеном, оставшимся с более ранних времен. Вы можете думать об этом как о суррогате для самой Windows. Более официально, это родитель для набора пользователей службы, которые обрабатывают фоновые задачи и операции обслуживания.
маркеры в правой части косой черты относятся к отдельным внутренним сервисным «пользователям» ОС.Для например, системаорган дескрипторов системных служб, полномочия НТлокальные служба местных служб, администрации сети службы NTэто сетевые сервисы, и так далее. Больше фона можно найти в этой теме и различные места MSDN. Творческое использование вашей предпочтительной поисковой системы может помочь вам найти еще больше.
по существу, то же самое выполняется от имени службы, которая (по существу) является утилитой, которая работает в фоновом режиме. (бит услуги, например, загружает обновления в фоновом режиме.) Есть очень много сервисов, которые работают, и токен NT_SERVICE используется как способ отличить их от других вещей. Вот статьи это немного более техническая деталь. (Я бы не отключил никаких услуг, если вы точно не знаете, для чего это нужно. Это хороший способ облажаться.)
Источник: kompsekret.ru
ILYA Sazonov: ITPro
Виртуальные учётные записи — это самое простейшее, но при этом очень мощное, средство защиты, о котором следует знать системным администраторам.
Время от времени администраторам приходится устанавливать ПО подозрительного происхождения или сомнительного качества. Если это ПО создаёт сервис или является приложением в IIS, то самое время применить Virtual Accounts для ограничения прав такого приложения и уменьшения зоны поражения в случае компрометации приложения.
Как правило разработчики не утруждают себя и запускают ПО от Local System, самые крутые от Network Service. В первом случае мы получаем очень уязвимую систему, и угрозу для всей доменной инфраструктуры. Во втором случае ситуация лучше, но не многим: стандартную учётную запись Network Service легко атаковать, и в случае наличия системных уязвимостей или конфигурационных ошибок скомпрометировать систему.
До 2008 года мы были обречены создавать обычные учетные записи для запуска сервисов и пулов IIS с ограниченными правами. Проблема обычных учётных записей в наличие пароля: его надо задать, где-то хранить и к тому же менять! Всё это на практике приводит к легкой компрометации обычных учётных записей. В Windows Server 2008 появились Virtual Accounts.
Эти учётные записи не создаются администратором, их не существует в обычном понимании, они не хранятся в разделе реестра SAM на диске, у них нет паролей. Тем не менее от имени виртуальной учётной записи можно запустить сервис или пул IIS путем их специальной, но очень элементарной настройки: учётная запись просто задаётся в специальном формате. (Разработчики могут использовать в своём приложении специальное API для динамического создания и использования виртуальных учётных записей). При перезапуске сервиса виртуальная учётная запись пересоздается. Таким образом к ней невозможно подобрать пароль – в результате намного сложнее скомпрометировать систему.
Формат виртуальной учётной записи:
IIS AppPoolимя пула
Вот пример как запускается сервис WSUS:
Имя сервиса MSSQL$MICROSOFT##WID
Имя учётной записи NT SERVICEMSSQL$MICROSOFT##WID
Надо отметить, что виртуальные учётные записи не видны среди других учётных записей в диалоговых окнах выбора учётных записей.
Например, на том же сервере WSUS:
Тем не менее если указать имя виртуальной учётной записи в явном виде и нажать «Проверить», то учётная запись подхватится.
Это верно и при назначении прав на локальные папки, если сервису или пулу нужно иметь туда доступ, а также при назначении прав на другие объекты (например, Security Rights или права на DCOM). Если права назначены, то это видно:
Что касается доступа к сетевым ресурсам, то вместо виртуальной учётной записи будет использоваться учётная запись компьютера (в формате Comp$): именно для неё нужно предоставлять права, например, на сетевую папку. Безусловно это понижение безопасности: виртуальные учётные записи предназначены прежде всего для локального использования. Для распределенного применения (несколько серверов, сетевой доступ) есть другой тип учётных записей – gMSA, но это уже другая история.
Источник: isazonov.wordpress.com