Local service control что это

Обновлено: 18.05.2024

Однажды мне захотелось управлять одним из домашних компьютеров удаленно, но при этом взаимодействовать с текущим пользователем, но компьютер был довольно слабый и при запуске например TeamViewer’а нагрузка процессора поднималась до 98% и компьютер начинал заметно тормозить. Попробовал стандартный RDP, но тогда «выбивался» текущий пользователь и для входа локально приходилось набивать пароль. Но чуть позже мне случайно попалась команда shadow.

Наблюдать за другим сеансом служб удаленных рабочих столов.
SHADOW | <ID сеанса>> [/SERVER:<сервер>] [/V]
<имя сеанса> Имя сеанса.
<ID сеанса> Идентификатор сеанса.
/SERVER:<сервер> Сервер терминалов (по умолчанию текущий).
/V Отображение информации о выполненных действиях.

Например для управления консольным сеансом(пользователем который непосредственно сидит перед компьютером) текущего терминального сервера достаточно ввести команду выполнить - shadow 0. Выход осуществляется через alt * на обычном компьютере и через ctrl * на терминальном сервере.
Но есть неприятная особенность: эта команда работает только из под rdp сессии. Но мой управляемый компьютер был под управлением windows xp поэтому пришлось расширить его возможности сделав из него терминальный сервер (в интернете полно статей как это можно сделать). Тогда все стало довольно просто, подключаемся любым пользователем с правами администратора по rdp и запускаем команду выполнить - shadow 0 попадаем в консольный сеанс, собственно что мне и нужно было. Для уменьшения аппаратных затрат можно при создании rdp подключения выбрать функцию «При подключении запускать следующую программу» и там набрать shadow 0 как на рисунке.

Тогда получается что запускается всего 2 процесса.

Для того что бы все это работало нам необходимо сначала включить RemoteRPC, например через реестр:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server]
“AllowRemoteRPC”=dword:00000001

После этого можно будет через Диспетчер служб удаленных рабочих столов посмотреть какие пользователи залогинены на компьютере, какие у них id и какие процессы запущены (жаль только названия, нет информации о нагрузке).

По умолчанию пользователю будет задаваться вопрос с разрешением управления, можно отключить вопрос или сделать только удаленное наблюдение, меняется через реестр:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services]
«Shadow»=dword:0000000x

Где x может иметь значения:
0 — удаленное управление не разрешено
1 -полный контроль с разрешения клиента
2 -полный контроль без разрешения клиента
3 -наблюдение за сеансом с разрешением клиента
4 -наблюдение за сеансом без разрешения клиента

По умолчания этой строчки вообще нет и её нужно будет создавать.

Так же можно включить через групповые политики локальные или доменные. Для включения локально запускаем gpedit.msc — выбираем административные шаблоны — добавление и удаление шаблонов, добавляем System.adm из папки WINDOWS\inf

Теперь настраиваем: конфигурация компьютера — административные шаблоны — компоненты windows — службы терминалов — устанавливает правила для удаленного управления. Для windows xp.

И конфигурация компьютера — административные шаблоны — компоненты windows- службы удаленных рабочих столов – узел сеансов удаленных рабочих столов – подключения – устанавливает правила удаленного управления для пользовательских сеансов служб удаленных рабочих столов. Для windows 7.
Все это работает и в домене, если у пользователя есть соответствующие права.

В доменных настройках профиля пользователя тоже есть настройка подобных прав (я встречал эти настройки даже в домене win 2000)

Если рассматривать терминальный сервер, то там через свойства RDP(через конфигурация узла сеансов удаленных рабочих столов) можно выставить любому пользователю права на удаленное управление,

и отдельно настроить взаимодействие или управление удаленным сеансом.

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

svchost.exe local service - это нормально что local service? или это вирус? спасибо

Да, это нормально.
Эта софтина - встроенный комбайн "на все случаи жизни".

помоему вирус если-бы Network servise бло-бы нормально, лечи

А проц загружает сильно? Бывает в него поселяется какая то гадость. Цеплял давненько.

Если запущено от имени local service и SYSTEM то это нормально, обычные системные процессы Windows, ничего опасного если же запущено от Администратора (или текущего пользователя) , то это 100% вирус.

НОрмально - это службы оси. Вирусы могут под них маскироваться. Например, я видел такой, который выдавал себя за ctfmon.exe (в этом случае их два в диспетчере).

у меня как то был svghost -во енто вирус в диспетчере задач отображался если специально не искать хрен заметишь

Если место расположения этого файла в папке C:/Windows/system32 то это файл службы windows, если в другом месте, то это вирус.

помогите разобраться NT AUTHORITY\NETWORK SERVICE

помимо пользовательских локальный профилей в настройке пользователя профилей имеется пользователь NT AUTHORITY\NETWORK SERVICE
его удаляю а спустя какоето время он снова появляется,
для чего он нужен и какие службы за него отвечают, как его отключить?

панель управления --> учетные записи пользователей --> вкладка Дополнительно --> дополнительное управление пользователями жмем Дополнительно ---> локальные пользователи и группы удаляем тех поддержку сети пользователя. :) все никто под этой учеткой из сети не зайдет!

Это сама винда :)))
ещё есть
NT AUTHORITY\LOCAL SERVICE
NT AUTHORITY\SYSTEM
Удалять и отключать их не надо :)))

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

Как известно, службы Windows представляют собой одно из наиболее излюбленных мест для атак на операционную систему. В худшем (для нас, конечно) случае атакующий получает возможность действовать на атакованном компьютере в контексте учетной записи, от имени которой запущена взломанная служба. И если эта учетная запись обладает административными правами, то фактически злоумышленник получает полный контроль над компьютером. От версии к версии в Windows появляются новые механизмы, обеспечивающие дополнительную изоляцию служб и, как следствие, усиливающие безопасность системы в целом. Я хотел бы вкратце рассмотреть, что принципиально изменилось в этом направлении за последние несколько лет.

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

Учетная запись	Локальные ресурсы	Сетевые ресурсы
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 SERVICE\w32time (см. рис 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 будет продолжена.

Читайте также: