Проблемы «песочницы»

Время от времени каждому администратору приходится развертывать Web-приложения, связанные с пересылкой конфиденциальной информации. Приложение необходимо установить на надежно защищенном сервере таким образом, чтобы никакая другая программа Microsoft IIS не имела доступа к файлам приложения. Эффективные меры позволяют защитить конфиденциальную информацию от злоумышленников и опасных программ, размещенных на одном сервере с конфиденциальной информацией. Я всегда считал, что приложения, нуждающиеся в особенной защите, необходимо размещать на отдельном сервере. Однако нередко администраторам приходится разворачивать защищенные приложения на одном сервере со многими другими программами.

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

Особенности изолирования

Желательно сразу предупредить руководителей предприятия о том, что идеальная изоляция приложений не достижима ни на одной из существующих платформ IIS. В частности, полная изоляция приложений в IIS 5.0 невозможна, потому что продукт не проектировался в расчете на использование «песочницы» (sandbox). Важнейшие компоненты и процессоры сценариев, такие как Cold Fusion компании Macromedia, работают в процессе inetinfo.exe, который должен выполняться в контексте учетной записи System. В таких условиях высокий уровень изоляции просто невозможен.

В IIS 6.0 Web-приложения по умолчанию запускаются в контексте безопасности встроенной учетной записи Network Service. Данный контекст — значительный шаг вперед по сравнению с учетной записью System. Благодаря одному этому улучшению IIS 6.0 — уже явно предпочтительный вариант для размещения Web-сервера. Уделив достаточное внимание деталям, можно обеспечить высокий уровень изоляции приложений на сервере IIS 6.0.

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

Представление и идентификация процесса

Для безопасности IIS всегда важно идентифицировать процесс, в котором выполняются приложения. Каждое приложение связано с конкретным экземпляром процесса. Например, если пользователь, зарегистрированный как Joe, запускает notepad.exe, то программа работает под управлением Joe и располагает пользовательскими правами и разрешениями Joe. Как правило, службы выполняются с правами учетной записи System, административные инструменты работают с расширенными правами учетной записи Administrator, а пользовательские программы, такие как Microsoft Office, выполняются с правами запустившего их пользователя. Во всех случаях программа связана со средой исполнения, именуемой также контекстом безопасности.

Как и другие приложения, IIS для запуска Web-приложений задействует хост-процесс (в зависимости от версии IIS). Хост-процесс оценивает системные ресурсы, используя идентификатор процесса. Например, IIS 6.0 задействует хост-процесс с именем w3wp.exe, который работает с идентификатором процесса Network Service. Однако если w3wp.exe всегда использует Network Service для доступа к файлам, то пользовательские разрешения NTFS теряют свое значение! Каждому файлу и программе требуется только разрешение Network Service для чтения, исполнения или записи (по необходимости), а любые другие разрешения излишни.

Очевидно, что такой сценарий неприемлем. Требуется более высокий уровень детализации при управлении разрешениями пользователей и групп. Для этой цели IIS не идентифицирует процессы, а представляет (impersonate) пользователя, сравнивая пользовательский маркер доступа, назначенный в ходе аутентификации, с разрешениями NTFS для файла. Таким образом, реализуются пользовательские разрешения.

Разработчики спроектировали как IIS 6.0, так и IIS 5.0 таким образом, чтобы IIS в большинстве случаев представлял пользователя, но некоторые Web-приложения обходят эту процедуру. Другими словами, программист может составить приложение, которое «обращается к себе» для доступа к системным ресурсам IIS. То есть IIS сверяет разрешения для доступа к системным ресурсам с разрешениями для экземпляра процесса, а не для учетной записи пользователя.

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

Microsoft ASP.NET — пример приложения, в котором не всегда используется представление. Для активизации представления (я рекомендую сделать это для приложений, не использующих аутентификацию на базе форм) следует выполнить действия, описанные в главе «ASP.NET Impersonation» руководства Microsoft .NET Framework Developer?s Guide (http://msdn.microsoft.com/library/ default.asp?url=/library/en-us/cpguide/html/cpconaspnet impersonation.asp).

Управлять представлением в ASP.NET можно с помощью параметра в файлах .config, однако не так легко убедиться в корректности представления в скомпилированных приложениях. Один из признаков неисправности — приложение работает, только если запущено в контексте учетной записи System. Если разработчики или поставщики настаивают на выполнении приложения в режиме Low application protection в IIS 5.0 или назначают идентификатор LocalSystem пулу приложений, в котором приложение размещено в IIS 6.0, то приложение должно потребовать привилегированного контекста. Это верный признак неполноты представления.

Другой способ определить, обращается ли приложение к файлам от имени экземпляра процесса или от имени учетной записи пользователя, — задействовать утилиту Filemon.exe компании Sysinternals. Эта бесплатная утилита показывает в реальном времени все обращения к файлам на сервере. Необходимо лишь отменить разрешения Full Control для нужного файла, запустить Filemon и обратиться к файлу, чтобы увидеть запись Access Denied в столбце результатов и имя пользователя, обратившегося к файлу. Процедура показана на экране 1.

Экран 1. Выяснение тонкостей доступа к файлу с помощью Filemon

Идентификация процесса чрезвычайно важна для изоляции приложений. Рассмотрим два приложения — защищенное и общедоступное. Если оба приложения работают с одним экземпляром процесса, то разработчик общедоступного приложения может загрузить на сервер программу, которая переключает экземпляр процесса. В данном контексте безопасности программа, работающая в общедоступном приложении, может прочитать весь контент Web-узла из безопасного приложения и даже вызывать размещенные в нем приложения. Самая большая угроза при этом исходит от пользователей, имеющих право загружать на сервер и запускать программы, особенно двоичные исполняемые файлы. Поэтому главную опасность представляют программисты, имеющие доступ к приложениям. Взломщик извне может добиться таких же результатов, успешно проведя атаку с использованием идентификатора процесса общедоступного приложения. Типичный пример — атаки с переполнением буфера. Злоумышленник также может разместить «троянского коня» на рабочей станции программиста и получить привилегированный доступ к серверу или получить доступ методами «социальной инженерии». По этой причине приложения, которые должны работать в контексте учетной записи System или Administrator, нельзя надежно изолировать друг от друга.

В идеальном случае, решая задачу создания изолированного в «песочнице» приложения, можно применить к Web-контенту разрешения NTFS. В результате получаем экземпляры процессов, связанных с защищенным приложением, и его пользователи — единственные субъекты безопасности, имеющие доступ к контенту. Другими словами, следует убедиться, что разрешения NTFS не дают доступа к экземпляру процесса любому другому Web-приложению. Для этого необходимо знать все идентификаторы процессов, используемые IIS. В IIS 6.0 назначить защищенному приложению уникальный идентификатор достаточно просто (об этом будет рассказано в следующем разделе), а для IIS 5.0 можно руководствоваться таблицей. Таблица применима и к IIS 6.0 при работе в режиме изоляции исполняемого процесса IIS 5.0.

Изменение идентификаторов процессов

При выполнении типичного Web приложения в IIS 5.0 можно увидеть три имени процесса, каждое с собственным идентификатором. Inetinfo.exe — главный процесс, который работает в контексте процесса System. IIS использует dllhost.exe, когда приложение настроено на работу в режиме Medium или High Application Protection в IIS Manager и выполняется в контексте пользователя IWAM_servername user (создаваемого в процессе установки IIS). Приложения ASP.NET выполняются в процессе с именем aspnet_wp.exe, который использует в качестве идентификатора процесса учетную запись ASPNET.

При запуске Web-приложений в Inetinfo с идентификатором процесса System возникает проблема. В случае атаки с переполнением буфера (как было при нападениях Code Red и Nimbda), взломщик получает доступ к самым широким правам на сервере.

Microsoft не поддерживает работу inetinfo.exe в контексте учетных записей, кроме учетной записи System. Кроме того, несмотря на возможность изменить идентификатор процесса приложений ASP.NET, все приложения ASP.NET выполняются в одном экземпляре aspnet_wp.exe. Лучшее решение для IIS 5.0 — использовать Component Services для настройки идентификатора IWAM для dllhost.exe. Сделав это, необходимо изменить пароль в метабазе и для локальной учетной записи пользователя IWAM. Из-за необходимости специализированных настроек усложняются развертывание, диагностика и администрирование. В результате, а также в силу зависимости от inetinfo.exe (работающей от имени System) не рекомендуется применять IIS 5.0 для изоляции приложений в «песочницах».

Объединять идентификаторы процессов IIS 6.0 гораздо проще, чем в IIS 5.0. По умолчанию любая программа, запускаемая на сервере IIS 6.0, будет выполняться в контексте учетной записи Network Service, за исключением приложений Common Gateway Interface (CGI), которые работают в собственном контексте пользователя, вызвавшего их. Назначить уникальный идентификатор любому пулу приложений, в котором размещено Web-приложение, можно на вкладке Identity в диалоговом окне свойств пула (экран 2).

Экран 2. Диалоговое окно Properties пула приложений

Однако есть одна особенность: учетная запись Network Service — член группы, существующей только в Windows Server 2003 с установленным IIS 6.0, группы IIS_WPG. Как указывается в справочных файлах IIS 6.0, группа IIS_WPG располагает минимальным набором полномочий, необходимых для IIS, и обеспечивает удобный способ использования учетной записи определенного пользователя в качестве идентификатора, не назначая вручную разрешений этому идентификатору. Далее: «В тех случаях когда учетная запись не принадлежит к группе IIS_WPG и не имеет соответствующих разрешений, попытка запуска исполнительного процесса закончится неудачей». Эта цитата не точна и вводит в заблуждение. Идентификатор, присвоенный пулу приложений (экран 2), должен быть членом группы IIS_WPG. Это обязательное условие. Нельзя назначить учетной записи пользователя все необходимые полномочия, так как некоторые из них встроены в группу IIS_WPG и связаны с http.sys.

Это обстоятельство имеет важное значение для изоляции приложений в IIS 6.0. Следует помнить, что программист может управлять представлением. Все экземпляры процессов (пулы приложений) являются членами группы IIS_WPG, поэтому по умолчанию все Web-приложения могут обращаться к любому контенту на сервере, доступ к которому для IIS_WPG разрешен настройками NTFS.

Задача администратора здесь простая, но не очевидная: необходимо назначить уникальный экземпляр процесса каждому изолируемому приложению, сделать экземпляр членом группы IIS_WPG и предоставить уникальному экземпляру разрешения NTFS Read и Execute для контента сайта. Нельзя использовать такие группы, как Users, Everyone, Authenticated Users и IIS_WPG для назначения разрешений на Web-сайте, поскольку уникальные экземпляры процесса будут членами этих групп.

Управление разрешениями для IIS_WPG

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

Группа IIS_WPG имеет разрешения Full Control в папке IIS Temporary Compressed Files. IIS использует эту папку в тех случаях, когда в IIS Manager активизирован режим сжатия. В результате сжатия IIS записывает сжатые данные в папку IIS Temporary Compressed Files и в ответ на последующие запросы извлекает документы из кэша. Для всех Web-узлов существует только одна папка IIS Temporary Compressed Files, и в соответствии со статьей Microsoft «Using HTTP Compression for Faster Downloads» (http://www.microsoft.com/resources/ documentation/IIS/6/all/techref/en-us/iisRG_PER_26.mspx) группа IIS_WPG должна иметь разрешения Full Control для данной папки. Эта информация противоречит сведениям, приведенным в статье Microsoft «Default permissions and user rights for IIS 6.0» (http://support.microsoft.com/ kb/812614), в которой стандартными разрешениями названы List, Read и Write. В действительности группа IIS_WPG наделена разрешениями Full Control.

Для изолируемых приложений угрозу представляет любая область, в которой группа IIS_WPG имеет разрешения Full Control. Администратору при управлении сжатием предоставляется следующий выбор.

  • Не использовать сжатия. Чтобы сжатия не было, нужно удалить группу IIS_WPG из числа имеющих разрешения в папке IIS Temporary Compressed Files.
  • Использовать сжатие только для надежно защищенных сайтов. Требуется удалить группу IIS_WPG из числа имеющих разрешения в папке IIS Temporary Compressed Files и назначить разрешения Full Control уникальной учетной записи, созданной для пула приложений.
  • Использовать сжатие только для сайтов, отличных от защищенного сайта. Сделать это проще всего в папке IIS Temporary Compressed Files: запретить доступ с Full Control экземпляру процесса, назначенного пулу приложений, в котором находится защищенное приложение. В такой конфигурации сжатие могут использовать все приложения, за исключением защищенного.

Легко заметить, что группа IIS_WPG также имеет разрешения Full Control в папке \%windir%system32inetsrvASP compiled templates. В статье Microsoft «ASP Template Caching» указывается, что для этой папки группе IIS_WPG требуются только разрешения Read, Write и Delete, но в действительности группе предоставляется Full Control. Неверная информация приводится и в статье Microsoft «AspDiskTemplateCacheDirectory», в которой говорится: «Как правило, идентификаторы процессов, выполняющих Asp.dll, — учетные записи IWAM_USER и System». Данное утверждение явно относится к IIS 5.0, но не к IIS 6.0, так как IIS 6.0 по умолчанию использует запись Network Service.

К счастью, размещение компилируемых шаблонов настраивается по сайту, папке и виртуальному каталогу. В результате можно построить раздельные папки кэша шаблонов ASP, назначив им такие разрешения NTFS, что ни одно другое приложение, работающее на сайте (за исключением имеющих разрешения Administrator или System), не сможет производить чтение или запись в папке кэша шаблонов. Местоположение определяется параметром AspDiskTemplateCacheDirectory в метабазе. Можно создать этот параметр метабазы с помощью Metabase Explorer или Adsutil, а затем связать его с уникальной папкой для защищенного приложения. Разрешения Full Control следует предоставить администраторам и уникальному экземпляру процесса, назначенному защищенному пулу приложений.

При подготовке программ к изоляции в ASP.NET необходимо корректно настроить разрешения для временных файлов ASP.NET. Группе IIS_WPG предоставляются разрешения Full Control в папке \%systemroot%Microsoft.NET Frame workv1.1.4322Temporary ASP.NET Files. К счастью, указать местонахождение временных файлов ASP.NET можно для каждого приложения отдельно через элемент файла web.config, как описано в статье Microsoft «ASP.NET Settings Schema». Таким образом обеспечивается должный уровень изоляции и защиты папки.

Безусловно, специалистам, не использующим ASP или ASP.NET, необходимо выяснить область полномочий группы IIS_WPG в языке сценариев или приложении, и принять соответствующие меры. Если возникает ситуация, когда для корректного функционирования приложения необходимо предоставить группе IIS_WPG разрешения в определенном каталоге и такой каталог единственный на всем сервере, следует убедиться, что другие приложения на сервере не могут прочитать и изменить данные защищенного приложения в этом каталоге. Как уже отмечалось, в число таких каталогов входят кэши временных файлов, а также общие базы данных, файлы настройки, общие двоичные файлы и т. д. Детали целиком определяются конкретными обстоятельствами.

С помощью утилиты cacls.exe можно вывести разрешения в текстовый файл для последующего анализа. Ниже приведен пример для стандартной установки IIS.

cacls C:inetpubwwwroot* /T > output.txt

Управление анонимным доступом

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

При назначении разрешений NTFS следует помнить, что для защищенного контента нельзя использовать такие группы, как Users, Authenticated Users и Everyone, если только анонимным пользователям явно не запрещено обращаться к другим Web-узлам во всем каталоге с контентом.

Другие технологии и факторы

Задача изоляции приложений часто не ограничивается отдельным сервером IIS и распространяется на другие серверы предприятия. Детали способа доступа к сетевым ресурсам, контекст безопасности, используемые службы и механизмы аутентификации играют определенную роль в организации доступа приложения к базе данных, файл-серверу и другим сетевым устройствам. Эти вопросы выходят за рамки данной статьи, но читатели могут ознакомиться с разделами COM+ в статье «What Are COM+ Partitions» и ограниченным делегированием в статье «Kerberos Protocol Transition and Constrained Delegation» на сайте Microsoft. Кроме того, можно прочитать документ «Configuring Application Isolation on Windows Server 2003 and Internet Information Services (IIS) 6.0».

Методичный подход — залог успеха

Разместить приложение на IIS-сервере, максимально изолировав его от других приложений на том же сервере, — нелегкая задача. IIS 5.0 не подходит для этой цели из-за неупорядоченности экземпляров процессов и управляющих ими механизмов. IIS 6.0 — гораздо более удобная платформа. Изолировать приложения здесь проще благодаря контролю над экземпляром процесса пулов приложений и управлению разрешениями NTFS. Для изоляции и защиты любых каталогов, использующих группу IIS_WPG, требуется точность, и администратору необходимо аккуратно назначать разрешения NTFS. Однако, придерживаясь методичного подхода, можно достичь высокой степени изоляции.

Специалист по IIS 7.0 и Web-службам в Microsoft, редактор журнала Windows IT Pro. brett@iisanswers.com