company_banner

Изоляция служб в 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).image
    Рис. 1

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

    Нажимаете Check Names, затем ОК и видите пользователя (см. рис. 3), которому можно назначать права.
    image
    Рис. 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).image
    Рис. 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)
    image
    Рис. 5

    После запуска службы virtual account отобразится в консоли Services (рис. 6), а в папке Users вы заметите появление нового пользовательского профиля. image
    Рис. 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 будет продолжена.
    Microsoft 404,08
    Microsoft — мировой лидер в области ПО и ИТ-услуг
    Поделиться публикацией
    Комментарии 54
    • +12
      В принципе, статья неплохая.

      На практике — «и чего только люди не придумают дабы не ставить *nix»
      • +4
        Если придумывают, значит это кому-то нжно. :)
        • +3
          Времена меняются… У Windows была инерция (в хорошем смысле), которую сейчас бездарно теряют ни на что.

          Кстати, ваша статья в очередной раз показала что специалисты адекватнее фанатиков (К.О., да). Если бы подобная статья была про *nix, непременно нашёлся бы кто-нибудь, сказавший что в виндовс это всё полностью через гуй делается. :P
        • +2
          Точно. Хороший пост, потому что демонстрирует, каких проблем у нас нет. Пока пользователи windows V/7 осваивают изоляцию служб и powershell, на десктопах с Linux эти функции давно есть и они просто месяцами работают прямо в инете.
        • +6
          Объявите конкурс на взлом… с вознаграждением. Иначе никто не поверит, и правильно сделает.
        • +2
          Написать простую службу для Windows становится все сложнее :(
          • 0
            «Времена меняются, и мы меняемся вместе с ними». Хотя, по-прежнему несложно, особенно если понимать, зачем она нужна.
            • 0
              ну, не знаю. я на C# их наклепал немало. единственное последствие усиленной изоляции, с которым я столкнулся, — это проблемы с MessageBox'ами, которые на XP работают без проблем, а на семерке вообще не показываются. хотя, в принципе, у меня и задачи были довольно простые.
          • –14
            Хорошая статья, спасибо.
          • +2
            Проблема одна — эти возможности являются рекомендательными. Т.е. по сути разработчики не будут париться и будут по прежнему всегда указывать LocalSystem. Как, к своему стыду, делаю и я.
            • 0
              Я поначалу тоже так делал, но в связи с тем, что все работы на серверах выполняют коллеги из IT-отдела пришлось делать по-правильному, потому что они не разворачивали сервисы от LocalSystem.

              Так что видимо нужен либо внешний фактор либо самостоятельно стремиться сделать как рекомендовано, чтобы избежать возможных проблем.
              • 0
                Я про то и толкую. Нужен механизм, при котором разворачивание системы от LocalSystem было бы очень затруднено.
                • 0
                  Зачем?
                  Если вы знаете, что это вредно и грозит последствиями вы всё равно будете так делать?

                  В нашем случае просто решили правильно организовать работу: разделили обязанности и в связи с этим в качестве мешающего фактора выступило IT.

                  А вообще можно было бы включить данное правило в стандарты кодирования на уровне конторы и за нарушение давать по рукам, не маленькие же.
                  • 0
                    Я не о себе а о всех кодерах. Только добросовестных кодеров недостаточно ибо вирусня попадет через недобросовестных
                    • 0
                      С тем, что недобросовестных разработчиков масса, я безусловно согласен и тут, конечно, будет проблема.

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

                      Насчёт мешающего механизма будем надеяться, что со временем по умолчания каждая новая устанавливаемая служба будет изолирована и не потребуется ручного вмешательства.
            • +4
              Насколько я понял, microsoft перенимает обычную для unix практику заведения отдельных пользователей и групп для демонов. Это плюс. Смущает, что механизмов несколько и появляются они от версии к версии, т.е. некая монолитность модели безопасности теряется.
              • +3
                Проблема в том, что это должно было быть сделано фиг знает сколько времени тому назад.
                • –1
                  То есть по вашему теперь и делать уже не нужно?
                  • +1
                    Нужно, конечно. Однако если сделать элементарные вещи по уму сразу, то можно бы было избежать многих проблем. А делать плохо, а потом исправлять, это самый ужасный путь, который можно только придумать.
                    Т.е. имея потенциально отличные средства обеспечения безопасности, делали откровенно плохо.
                    • –1
                      Все продукты развиваются эволюционно и приоритеты зависят от того что хотят пользователи.

                      Или вы хотите сказать что у других производителей и сообществ все с первого раза совершенно выходит?
                      • +2
                        Вы чего на людей бросаетесь?
                        • +1
                          Нет, но это я так понимаю, был сознательный выбор. Снижение уровня безопасности. Запуск сервисов с минимальными правами, это не открытие Америки. Очень давно известная вещь. А запуск сервисов с максимальными правами, он часть концепции «по умолчанию разрешено все». В такой концепции проще делать, меньше вопросов от пользователей, но и дырок больше на порядок, а последствия их использования тоже на порядок разрушительней.
                          • –1
                            Это был сознательный выбор для обеспечения беспроблемной работы наибольшего количества унаследованного ПО.

                            Любое повышение безопасности ОС ломает стороннее ПО, потому что реальная система это всегда компромис между безопасностью и удобством. Кто в результате крайний? Конечно же MS.

                            Как вы убедились в комментариях коллеги paz к этой статье сторонние разработчики не хотят писать безопасный код. Они хотят писать код без труда. Это естественно для людей поэтому любые изменения в системе безопасности ОС Windows делаются постепенно.
                            • +1
                              Я именно про это и пишу, только другими словами.
                              А вывод должен быть следующим, для более.менее ответственных приложений, нужно выбирать системы, где по дефолту максимум запрещено/ограничено.
                              Иначе можно в результате удобства для лентяев и в результате дырок, по двое-трое суток стоять на ушах, как мне приходилось.
                              • –1
                                Для создания безопасных систем есть групповые политики и настройки локальной системы позволяющие так закрутить гайки на Windows что даже Пентагон и множество других организаций обрабатывающих информацию деликатного характера использует Windows без каких либо проблем.
                                • +2
                                  Все это я уже проходил. Не нужно мне это. Потом оказывается, что жизненно важный специализированный софт отказывается работать с закрученными гайками.
                                  • –2
                                    А если вы в другой ОС например закрутите гайки например такие как Selinux у вас проблем не будет?

                                    Или вы все еще верите в ОС абсолютно безопасные по умолчанию? :)
                                    • +1
                                      Не нужно передергивать. Должны по умолчанию соблюдаться ЭЛЕМЕНТАРНЫЕ нормы безопасности.
                                      Абсолютной безопасности никто не дает, но система может иметь приемлемый уровень безопасности и неприемлемый.
                                      • –1
                                        Для большинства организаций на этой планете безопасность Windows вероятно достаточна.

                                        Видно у них другое понимание элементарных норм.
                                        • +2
                                          > Видно у них другое понимание элементарных норм.

                                          Или непонимание.
                                          • –1
                                            Все вокруг неумехи. Один вы в знаете как мир обезопасить.

                                            Может вам пойти таки поработать в Пентагон или другие организации обрабатывающие секретные данные?
                                • –1
                                  >>А вывод должен быть следующим, для того чтобы воры не залезли в форточку, нужно копать бункер на глубине 80 метров.
                                  Вот вы примерно это сказали.
                                  Надо выбирать системы не где «по дефолту», а где можно настроить с теми настройками которые вам требуется.
                                  • +1
                                    Если по дефолту «все разрешено», то или не сможешь настроить, или это будет связано с офигенным геморроем.
                                    Элементарные дырки дожны быть закрыты по дефолту. Это все, что я хочу сказать.
                          • 0
                            «самый ужасный путь, который можно только придумать» — истеричное высказывание. Всегда есть путь хуже (/лучше).

                            «делали откровенно плохо» — конфликтоген. Вы бы сделали лучше? Wellcome!

                            Сорри за эмоции, просто задолбали оценки «умников». Заходишь на любой OpenSource проект и легко можешь отличить комменты некоторых наших соотечественников.

                            • 0
                              Извините, но это был наполовину сознательный выбор.
                              Подход, чтобы по дефолту было бы все разрешено. Было нацелено на то, чтобы малоквалифицированные пользователи и разработчики встречали как можно меньше непонятного.
                              Плюсы подхода, это захват рынка, большое количество разработчиков и пользователей, которым нужно нажимать только кнопку «Next».
                              Минусы подхода, большое количество дырок и разрушительные последствия этих дырок. Разгул вирусов. Непонимание массой пользователей самой необходимости соблюдать элементарные правила.
                              При разработке NT были заложены все средства для создания очень хорошо защищенной ОС. А потом этими средствами воспользовались не очень хорошо.

                          • –1
                            Делать то может и нужно, но я сомневаюсь, что большинство пользователей, администраторов и программистов обрадуются и начнут делать «как нужно». Всех уже приучили к плохому. А к нему, как всем известно, легче привыкают.
                        • +1
                          Не совсем так. Запустить сервис от имени другого пользователя можно было и раньше. Другое дело, что пользователь этот становился локальным, со всеми вытекающими отсюда последствиями. И если в /etc/password проблема отключения консольного входа разруливается элементарно через задание пустого шелла, то в Windows всё чуть-чуть сложнее из-за множества способов этого самого входа. Навскидку — терминальный, локальный (консольный), RDP и их комбинации (Fast User Switching, например).

                          И всё это использует единую систему аутентификации. В отличии от Linux-овой Samba, например, которую можно прикрутить к pam, можно к ntlmauth, а можно и вообще ни к чему не прикручивать. Соответственно, аутентификационные службы должны четко знать, кого пускать, а кого — нет. Ведь в случае с Windows авторизация службы может проходить не только на локальном компьютере, но и на удаленном. Но при этом её нужно порезать в локальных правах как можно сильнее. И вот из-за этого весь этот сыр-бор, вкратце.
                        • 0
                          А можно такую же статью, только, что называется, under the hood?
                          • 0
                            Про виртуальные учётные записи не знал — спасибо статье. Но сам механизм как-то напоминает костыль.
                            Зачем вообще пароли для учётных записей, которыми не пользуются живые люди?
                            • 0
                              Чтобы взломщик не мог запустить процесс с именем виртуального пользователя с дополнительными и нужными взломщику правами.
                              • 0
                                Если у пользователя нет пароля то как раз взломщик не сможет запустить процесс под этим пользователем.

                                Когда я говорю «нет пароля» я имею ввиду не пустой пароль, а отсутствие возможности логина по паролю.
                            • 0
                              Кэп: Чтобы удалённый злоумышленник не смог получить доступ к локальному компьютеру, зная только имя учётной записи.
                              • +1
                                Интересная статья, но увы — все способы обходятся. Хотя вынужден признать — эскалацию прав в W7 сделать стало несколько сложнее.

                                Но про LocalSystem — как сейчас помню :)
                                @echo off
                                sc create CmdAsSystem type= own type= interact binPath= "cmd /c start /low cmd /k (cd c:\ ^& color ec ^& title ***** SYSTEM *****)" > nul
                                net start CmdAsSystem
                                sc delete CmdAsSystem > nul
                                • –1
                                  Изготовление абсолютно защищенной системы экономически не окупится. Ей просто пользоваться будет невозможно. Поэтому делают системы которые способны обеспечить защищенность такого уровня чтобы взламывать их стало экономически не выгодно.
                                  • +4
                                    Экономическая выгода определяется не защищённостью системы, а тем, что она защищает.
                                    • –1
                                      А разве это не очевидно?

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

                                      Если стоимость взлома превышает стоимость данных то ломать врядли будут.
                                  • 0
                                    Это уже не работает. Интерактивные службы были запрещены. Но раньше действительно было возможно.
                                  • +1
                                    > Только бы пользовались
                                    Ждем просвещающую статью про то, как пользоваться
                                    • +3
                                      90% людей работает с правами администратора, можно примитивно дать им программку которая пропишется из под них под учетной записью System и творить с компом что угодно. Работает на любой ОС начиная с XP и заканчивая Windows Server 2008R2.
                                      • +1
                                        Вот это и есть вещь, которую нужно менять.

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                      Самое читаемое