Поделиться через

Безопасное содержимое в IIS с помощью списков управления доступом файловой системы

Назим Лала

Введение

Список управления доступом (ACL) — это список разрешений, связанных с объектом. Каждая из этих записей разрешений называется записью управления доступом (ACE); ACE содержит разрешения, связанные с определенным объектом для определенного удостоверения. Например, для объектов файловой системы можно задать списки управления доступом для файлов и каталогов в файловой системе NTFS.

Для задания или изменения списков управления доступом можно использовать графический пользовательский интерфейс (например, "Мой компьютер" или "Windows® Обозреватель"). Щелкните правой кнопкой мыши любой файл или ресурс папки из одного из этих средств, выберите пункт "Свойства", а затем перейдите на вкладку "Безопасность", чтобы просмотреть графическое представление ACL в выбранном ресурсе. В этом диалоговом окне можно применить или удалить разрешения группы или пользователя к системным ресурсам, таким как файлы и папки. Вы также можете использовать служебную программу командной строки Cacl.exe для отображения или изменения списков управления доступом к файлам.

Основы ACL

Полезно начать с некоторых основных принципов ACL.

Общие разрешения IIS

Наиболее распространенными разрешениями, интересующими ACE, являются чтение, запись, выполнение и содержимое папки списка.

  • Разрешения на чтение и запись. Разрешения на чтение и запись предоставляют доступ для чтения и записи к объекту файловой системы соответственно.
  • Разрешение на содержимое папки списка. Разрешение содержимого папки списка используется для отображения содержимого папки и требуется для регистрации уведомлений об изменении файла в каталоге.
  • Разрешение на выполнение. Разрешение на выполнение используется для указания того, должна ли операционная система выполнять определенное приложение в качестве указанного пользователя. Это не касается сценариев динамического приложения, таких как PHP (или Microsoft® ASP.NET). Код выполняется при вызове файла .php или .aspx, но не с точки зрения операционной системы. Вместо настройки разрешения на выполнение следует изучить использование скрипта или выполнения разрешений.
  • Полный контроль. Разрешение полного управления предоставляет всем доступ к объекту файловой системы. Избегайте полного управления и используйте более детализированные разрешения на чтение и запись.
  • Скрипт IIS или разрешение на выполнение. Файлы с динамическим содержимым, например файлы .php (или .aspx), требуют разрешения скрипта для работы. Но обратите внимание, что в то время как списки управления доступом файловой системы имеют флаг выполнения, они не имеют ничего для скрипта. Это связано с тем, что службы IIS 7 и более поздних версий (IIS 7 и более поздних версий) имеют специальную конфигурацию, чтобы указать, имеет ли определенный файл динамический контент. Эта конфигурация хранится в конфигурации IIS вне списков управления доступом к файловой системе. При обсуждении сценариев или выполнения разрешений это фактически конфигурация IIS, а не разрешение на выполнение файловой системы.
  • Наследование объектов. Списки управления доступом файловой системы обычно наследуются. В некоторых случаях родительский каталог может иметь очень свободные списки управления доступом, которые необходимо переопределить на дочернем уровне, чтобы достаточно заблокировать содержимое. Эта проблема вряд ли возникает в размещенном сценарии, так как в корневом каталоге есть несколько разрешений.

Общие удостоверения IIS

Вы можете разрешить или запретить разрешения для определенных удостоверений с помощью списков управления доступом для защиты содержимого. Существует два типа удостоверений: удостоверения процесса (те, с которыми запускается рабочий процесс IIS) и удостоверения обработчика запросов (от проверки подлинности запроса).

  • Удостоверение рабочего процесса (WPI) Рабочий процесс IIS выполняется как WPI, который можно настроить с помощью параметров конфигурации пула приложений в IIS. IIS 6.0 в Windows Server 2003 и IIS 7 и более поздних версий в Windows Server®® 2008 имеют удостоверение "Сетевая служба" в качестве стандартного WPI. Windows Server® 2008 R2 использует удостоверение пула приложений в качестве WPI по умолчанию. Если приложение выполняет проверку подлинности и олицетворения, удостоверение пользователя, передаваемого запросом, является удостоверением пользователя, прошедшим проверку подлинности.
    Если Php.ini имеет значение fcgi.impersonate "true" (рекомендуется для IIS), процессы PHP выполняются в качестве прошедшего проверку подлинности пользователя. Важно отметить, что в случае анонимной проверки подлинности прошедший проверку подлинности пользователь будет настроенным анонимным пользователем.
  • IIS_IUSRS. Это встроенная группа удостоверений, которая является контейнером всех удостоверений рабочих процессов (WPIs) на сервере. СЛУЖБЫ IIS автоматически включают все WPIs в эту группу (не нужно добавлять их вручную).
    В IIS 6.0 в Windows Server 2003 эта группа называется IIS_WPG. Это объединяющая группа, содержащая все WPIs, поэтому не является хорошим кандидатом на изоляцию содержимого. Любое приложение, работающее в любом пуле приложений, будет работать как удостоверение, которое входит в эту группу, поэтому предоставление этому доступу на чтение группы означает, что все приложения могут читать содержимое.
  • IUSR / Анонимное удостоверение пользователя. Встроенная учетная запись IUSR используется по умолчанию для обозначения удостоверения пользователя всех пользователей, использующих анонимную проверку подлинности. Анонимная идентификация пользователя настраивается и может быть настроена на удостоверение, кроме встроенного по умолчанию.
    На практике следует настроить пользовательскую учетную запись для анонимной учетной записи пользователя и никогда не использовать встроенную учетную запись. Важно понимать, что в IIS анонимный пользователь не является отсутствием прошедшего проверку подлинности пользователя. Вместо этого анонимные запросы следует рассматривать как запросы, в которых прошедший проверку подлинности пользователь является анонимным удостоверением пользователя.
  • Удостоверение пула приложений. Это виртуальное удостоверение, связанное с определенным пулом приложений. Всякий раз, когда пользователь создает пул приложений, создается виртуальное удостоверение (идентификатор безопасности или идентификатор безопасности) с ним; это удостоверение внедряется в рабочий процесс IIS, чтобы рабочий процесс, выполняемый в этом пуле приложений, получил доступ к содержимому с разрешениями, заблокированными для этого виртуального удостоверения. В Windows Server 2008 с пакетом обновления 2 (SP2) администратор может создавать рабочие процессы с помощью этого виртуального удостоверения. Это можно настроить в параметрах конфигурации пула приложений IIS в качестве типа "Удостоверение пула приложений" и является типом удостоверения WPI по умолчанию для Windows Server 2008 R2. (Удостоверение уникально для пула приложений, создавшего его, и поэтому можно использовать для изоляции содержимого на сервере для пулов приложений более эффективно.)
  • Удостоверение пользователя с проверкой подлинности. Если приложение использует любую форму проверки подлинности (включая анонимную проверку подлинности), то это удостоверение пользователя, прошедшего проверку подлинности. В случае анонимной проверки подлинности это удостоверение будет настроено анонимное удостоверение пользователя.

Конвейер выполнения IIS

Чтобы понять, какие удостоверения применимы на каких этапах, полезно понять основы конвейера выполнения IIS. Две части конвейера, которые наиболее применимы, — это сопоставление проверки подлинности и обработчика.

  • Проверка подлинности. Перед проверкой подлинности контекст пользователя, прошедший проверку подлинности, неизвестен, и все рабочие процессы IIS выполняются в качестве WPI. Если у вас есть запрос PHP, который пытается получить доступ к содержимому перед проверкой подлинности запроса, то WPI должен получить доступ к содержимому. Этот сценарий возникает при использовании глобальных правил для переопределения URL-адресов, которые выполняются на этапе глобального предварительного запроса конвейера IIS, который возникает перед проверкой подлинности. Средство перезаписи URL-адресов может обрабатывать правила по-разному в зависимости от того, является ли доступ к ресурсу файлом или каталогом. Чтобы это было оценено, доступ к файловой системе должен произойти и из-за его положения в конвейере выполнения этот запрос доступа возникает как WPI.

    После проверки подлинности задан контекст пользователя, прошедший проверку подлинности, но не обязательно олицетворение запроса, пока запрос не будет сопоставлен с обработчиком. Для этапов между сопоставлением проверки подлинности и обработчика, скорее всего, будет выполняться как WPI.

  • Сопоставление обработчиков. На этом этапе конвейера выполнения запрос сопоставляется с обработчиком; например, запросы на *.php сопоставляются с обработчиком FastCGI. После этого сопоставления и включения олицетворения идентификатор обработчика является пользователем, прошедшим проверку подлинности, и весь доступ к ресурсам на этом этапе происходит с использованием удостоверения пользователя, прошедшего проверку подлинности.

Выбор удостоверения

Определение нужных учетных записей для предоставления разрешений зависит от профиля и критически важных ресурсов приложения. Основными соображениями являются разрешения на предоставление и проверка подлинности.

  • Предоставление соответствующих разрешений. Динамическое содержимое, например в PHP и ASP.NET приложениях, требует разрешения на скрипт IIS и доступ на чтение. Если необходимо запустить исполняемые файлы, у них должно быть разрешение на выполнение СЛУЖБ IIS, и они должны быть правильно настроены в списке ограничений CGI. Все, что не загружено пользователем, нуждается только в доступе на чтение в файловой системе.
    Содержимое, которое будет отправлено пользователем, должно находиться в отдельной папке, в которой назначается доступ на запись. Важно не предоставлять этим папкам разрешения на выполнение или скрипт, чтобы пользователи не могли отправлять и выполнять вредоносный код.
    Как правило, WPI должен иметь доступ на чтение ко всему содержимому для правильной работы приложения.
  • Приложения, требующие проверки подлинности. Для приложений, требующих проверки подлинности, заблокируйте все ресурсы в группу, содержащую всех прошедших проверку подлинности пользователей. Если у вас есть разные категории пользователей (администратор и неадминистратор), создайте отдельные группы и предоставьте доступ соответствующим образом. Например, если у приложения есть каталог администратора, содержащий скрипты администрирования, предоставьте разрешения на чтение этого каталога только группе администраторов. Если приложение олицетворяет, идентификатор обработчика является прошедшим проверку подлинности пользователем; в противном случае это ваш WPI. Если в файле Php.ini задано значение fcgi.impersonate, ваше удостоверение обработки fcgi является удостоверением пользователя, прошедшим проверку подлинности; в противном случае это WPI. С помощью этих сведений администратор может определить правильный набор списков управления доступом для размещения на содержимом.
  • Приложения, которые выполняются анонимно. Важно отметить, что выполнение анонимно в IIS означает, что вы проходите проверку подлинности в качестве анонимного удостоверения пользователя. В этом случае заблокируйте ресурсы для удостоверения пула приложений или настраиваемого анонимного удостоверения и предоставьте доступ к удостоверению пула приложений по анонимному удостоверению. Если вы предоставляете IIS_IUSRS доступ к содержимому, приложения, работающие в любом пуле приложений, имеют доступ к содержимому. Если вы разрешаете анонимным пользователям отправлять файлы, ваше приложение должно обеспечить дальнейшие проверка типов контента, которые эти пользователи могут отправлять, чтобы обеспечить безопасность сервера.

Настройка списков управления доступом

Существует несколько способов настройки списков управления доступом через оболочку, включая средства командной строки, такие как Icacls.exe. В этой статье рассматривается механизм манифеста средства веб-развертывания (XML), который можно использовать для задания списков управления доступом. Это используется при установке приложения с помощью средства веб-развертывания.

Чтобы предоставить разрешения на чтение, выполнение и запись в каталог файловой системы MyApp для пользователя Foo, добавьте следующую строку в файл Manifest.xml:

<setAcl path="MyApp" setAclAccess="ReadAndExecute, Write" setAclUser="Foo" />

Чтобы задать ACL в пути MyApp/Upload , чтобы разрешить анонимным пользователям отправлять содержимое, добавьте следующую строку в файл Manifest.xml:

<setAcl path="MyApp/Upload" setAclAccess="Write" setAclUser="anonymousAuthenticationUser" />

Обратите внимание, что anonymousAuthenticationUser — это специальный маркер, который будет разрешаться в настроенном удостоверении анонимной проверки подлинности.

Чтобы предоставить доступ на чтение к папке MyApp\Data для удостоверения пула приложений, добавьте следующую строку в файл Manifest.xml:

<setAcl path="MyApp/Data" setAclAccess="Read" />

Обратите внимание, что параметр setAclUse r здесь не используется (значение по умолчанию для этого — удостоверение пула приложений).