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

Изменения в безопасности между IIS 6.0 и IIS 7 и выше

  • Статья

Команда IIS

Введение

IIS 7 и более поздних версий позволяют улучшить безопасность iis 6.0. В этом документе описаны эти улучшения в отношении проверки подлинности, авторизации, SSL, списка ограничений расширения веб-службы и ограничений IP-адресов.

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

Для ASP.NET разработчиков приложений существовали до IIS 7, две модели проверки подлинности, необходимые для программирования. Эти модели были конвейерами IIS и ASP.NET. Во-первых, СЛУЖБЫ IIS проверят запрос и выполняют свои процедуры проверки подлинности, а затем передают его в ASP.NET, чтобы она могла выполнить аналогичную задачу.

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

Эти изменения будут рассмотрены в предстоящих разделах.

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

В IIS 7 и более поздних версиях анонимная проверка подлинности ведет себя так же, как и в предыдущих версиях с одним изменением — возможность выполняться под содержимым удостоверения рабочего процесса. Каждый пул приложений настроен для запуска в содержимом учетной записи пользователя, а значение по умолчанию для этой учетной записи — NETWORKSERVICE.

Это было очень распространено для ASP.NET приложений, чтобы отключить олицетворение и запустить под удостоверением пула приложений с помощью следующего кода в файлах web.config:

<identity impersonate="false"/>

Существует несколько сценариев, в которых приложения должны выполняться в контексте удостоверения процесса:

  • Удостоверение процесса — это учетная запись с низким уровнем привилегий, а администраторы заблокировали свои системы для этой учетной записи.
  • Удостоверение процесса предоставлено сетевому доступу и используется для доступа к ресурсам серверной части, таким как базы данных

В рамках изменения iis 7 и выше мы хотели сделать этот сценарий безопасным и простым. Для реализации этого сценария в IIS требуется:

  • Установка и включение модуля анонимной проверки подлинности
  • Задание анонимного имени пользователя и пароля пустой строкой

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

<anonymousAuthentication enabled="true" userName="" defaultLogonDomain="" />

Эта конфигурация сообщает СЛУЖБАМ IIS всегда выполняться в контексте удостоверения рабочего процесса.

По умолчанию анонимное удостоверение проверки подлинности в IIS 7.0 и выше является учетной записью IUSR. Эта учетная запись — это низкое удостоверение привилегий с минимальными правами и привилегиями. Дополнительные сведения о новой встроенной учетной записи см . в статье "Общие сведения о встроенной учетной записи и группе" в IIS 7 и выше .

Изменения в паспорте

Поддержка устаревшей проверки подлинности Passport была встроенна в IIS 5/6 и Windows Server 2000 и 2003. Поддержка паспортов в IIS 5 и 6 была предоставлена в качестве проверка box на вкладке "Безопасность каталогов" в диспетчере служб IIS для включения проверки подлинности паспорта. Эта проверка box предоставила службам IIS возможность отправлять устаревшие проблемы протокола Tweener. Помимо этого, все еще необходимо зарегистрировать веб-сайт на портале подготовки службы Passport, получить ключ шифрования и настроить устаревший диспетчер Passport Manager на сервере, прежде чем интеграция IIS будет работать.

В Windows Server 2008 и более далеко устаревшие двоичные файлы Passport и интеграция с IIS были удалены.

Служба Passport с тех пор изменилась в Windows Live ID. Хотя новая служба Live ID, безусловно, выросла из устаревшей службы Passport, есть серьезные изменения. Одним из самых больших изменений является интеграция партнерского сайта с Live ID. Вы можете добавить проверку подлинности Live ID с помощью общедоступного пакета SDK веб-проверки подлинности Windows Live ID. Хотя служба Windows Live ID также поддерживает федерацию удостоверений и ADFS, эта возможность является новой функциональностью для конкретных случаев и не является заменой "Passport".

проверка подлинности с помощью форм

Проверка подлинности форм является частью ASP.NET и позволяет удостоверениям Windows и не Windows проходить проверку подлинности и получать объект пользователя, который приложения могут использовать позже. IIS 7 и более поздних версий полностью поддерживают проверку подлинности форм и могут быть настроены для защиты доступа ко всем типам контента.

Как IIS 7 и более поздних версий определяют удостоверение, прошедшее проверку подлинности

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

  • Во-первых, службы IIS определяют, настроено ли имя пользователя и пароль в виртуальном каталоге. Если определен набор учетных данных, эти учетные данные будут использоваться. Для администраторов IIS 7 эти учетные данные являются учетными данными UNC
  • Если учетные данные не настроены в виртуальном каталоге, службы IIS будут использовать учетные данные, предоставленные во время проверки подлинности. Эти учетные данные могут принадлежать удостоверению, настроенном для анонимной проверки подлинности или учетным данным, предоставленным пользователем во время подтверждения проверки подлинности, если включен базовый, дайджест или проверка подлинности Windows.
  • Если пользователь, прошедший проверку подлинности (например, проверка подлинности форм включена), мы определим, следует ли использовать удостоверение процесса.
  • Если на данный момент у нас нет удостоверения, СЛУЖБЫ IIS возвратит доступ, отказано в доступе.

Авторизация

Поддержка AzMan

В IIS 6.0 мы представили новую модель авторизации на основе правил AZMan. В IIS 7 и выше мы устарели эту функцию в пользу новой модели, которая очень похожа на модель авторизации ASP.NET (см. раздел авторизации URL ниже).

Авторизация URL-адресов

В IIS 7 и более поздних версиях у вас есть два решения авторизации. Первое — использовать модель авторизации ASP.NET. Этот метод требует определения всех правил авторизации в <конфигурации system.web> и требует нулевого изменения для приложений, которые уже имеют правила, написанные для ASP.NET. Вторая модель — перейти к новой архитектуре авторизации IIS. Эта модель очень похожа на ASP. Модель NET с некоторыми незначительными изменениями:

  • Правила не зависят от порядка
  • Правила запрета отсортированы в верхней части списка
  • Правила обрабатываются в противоположном порядке ASP.NET, главным образом в порядке: бабушка и дедушка, родитель, потом ребенок; ASP.NET авторизация обрабатывает правила в противоположном порядке:дочерний, родительский, а затем бабушка и дедушка

Чтобы лучше понять различия между моделью авторизации ASP.NET и моделью авторизации IIS, сначала рассмотрим конфигурацию авторизации ASP.NET:

<authorization>
    <allow users="Vik_Malhotra" />
    <deny roles="administrators" />
    <deny users="*" />
</authorization>

В этом примере мы разрешаем Vik_Malhotra, но мы отрицаем всех остальных. В IIS конфигурация очень похожа:

<authorization>
    <add accessType="allow" users="Vik_Malhotra" />
    <add accessType="deny" roles="administrators" />
    <add accessType="deny" users="*" />
</authorization>

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

SSL

В IIS 6.0 службы IIS хранили сведения, связанные с SSL, в метабазе и управляли значительной частью процесса согласования SSL в сочетании с HTTP.SYS. В IIS 7 и выше мы переместили большую часть этой конфигурации в HTTP. Хранилище SYS.

Чтобы иллюстрировать, как каждый из параметров конфигурации IIS 6.0 переносится в конфигурацию IIS 7 и выше (или HTTP.SYS конфигурации), показанная ниже диаграмма.

Конфигурация метабазы IIS 6.0 Описание свойства Архитектура IIS 7.0 и выше
AccessSSLFlags AccessSSLFlags — это битовая маска AccessSSSL AccessSSL128 AccessSSSLNegotiateCert AccessSSSLRequireCert AccessSSLMapCert 0 означает отсутствие SSL. Свойство по-прежнему поддерживается в конфигурации IIS 7.0 и выше в <разделе доступа>
CertCheckMode Включение или отключение списка отзыва сертификатов (список отзыва сертификатов) проверка. Теперь это значение будет храниться в http.sys в объекте PHTTP_SERVICE_CONFIG_SSL_PARAM.
ОтзывFreshnessTime Если свойству RevocationFreshnessTime присвоено значение 1 (true), то список отзыва сертификатов (CRL) клиента сертификата обновляется CRL из удаленного расположения, даже если список отзыва сертификатов, кэшированный на клиенте сертификата, является допустимым. Интервал времени ожидания по умолчанию — один день, если вы не используете revocationURLRetrievalTimeout для указания другого интервала времени ожидания (в минутах). Теперь это значение будет храниться в http.sys в объекте PHTTP_SERVICE_CONFIG_SSL_PARAM.
SecureBindings Свойство SecureBindings указывает строку, используемую службами IIS для определения безопасных конечных точек сети, используемых экземпляром сервера. Это свойство по-прежнему поддерживается в конфигурации IIS 7.0 и выше в <разделе привязки> для <сайтов>. Протокол, используемый по протоколу https.
SSLAlwaysNegoClientCert Свойство SSLAlwaysNegoClientCert управляет согласованиями подключения клиента SSL. Если для этого свойства задано значение true, при согласовании SSL-подключений сервер немедленно согласовывает сертификат клиента, предотвращая дорогостоящее повторное согласование. Настройка SSLAlwaysNegoClientCert также помогает устранить взаимоблокировки сертификатов клиента, которые могут возникать, когда клиент блокирует отправку большого текста запроса при получении запроса на повторное согласование. Теперь это значение будет храниться в http.sys в объекте PHTTP_SERVICE_CONFIG_SSL_PARAM.
SSLCertHash Свойство SSLCertHash используется для хранения хэша используемого SSL-сертификата. Теперь это значение будет храниться в http.sys в объекте PHTTP_SERVICE_CONFIG_SSL_PARAM.
SslCtlIdentifier Свойство SslCtlIdentifier содержит уникальное значение, определяющее определенный список доверия сертификатов (CTL). Он должен использоваться с SslCtlStoreName, чтобы точно ссылаться на CTL. Теперь это значение будет храниться в http.sys в объекте PHTTP_SERVICE_CONFIG_SSL_PARAM.
SslCtlStoreName Свойство SslCtlStoreName содержит имя хранилища CryptoAPI, содержащего списки доверия сертификатов (CTL). Он должен использоваться с SslCtlIdentifier, чтобы точно ссылаться на CTL. Теперь это значение будет храниться в http.sys в объекте PHTTP_SERVICE_CONFIG_SSL_PARAM.
SSLStoreName Свойство SSLStoreName используется для хранения имени хранилища, в котором находится пара ключей сертификата. Теперь это значение будет храниться в http.sys в объекте PHTTP_SERVICE_CONFIG_SSL_PARAM.
SslUseDsMapper Свойство SslUseDsMapper указывает, следует ли службам IIS использовать сопоставителя сертификатов службы каталогов Windows или сопоставителя сертификатов IIS. Если для SSLUseDSMapper задано значение false, служба IIS использует сопоставителя сертификатов IIS. Теперь это значение будет храниться в http.sys в объекте PHTTP_SERVICE_CONFIG_SSL_PARAM.

Дополнительные сведения об объекте HTTP.SYS PHTTP_SERVICE_CONFIG_SSL_PARAM см. в следующей документации.

Все эти изменения обрабатываются прозрачно под крышкой, так что как сервер Администратор istrator нет ничего специального, что вам нужно сделать- IIS сделает все для вас. Если у вас есть приложения, обращающиеся к старым свойствам IIS 6.0, теперь расположенным в HTTP. Хранилище конфигураций SYS, наш интерфейс карты ABO гарантирует, что правильные значения считываются и записываются, поэтому приложения не завершаются ошибкой, но вместо этого будут работать.

Список ограничений расширения веб-службы

В IIS 7 и выше эта функция была немного изменена таким образом, чтобы его имя теперь считывает isapiCgiRestrictionList , но в противном случае она действует и ведет себя так, как она была в IIS 6.0.

Причина этого изменения заключается в том, чтобы подчеркнуть его истинное использование. В IIS 6.0 эта функция была добавлена, чтобы гарантировать, что двоичные файлы ISAPI или CGI не удалось скопировать на серверы IIS, а затем разрешить выполнение. При редизайне для IIS 7 и выше у нас есть две поддерживаемые модели:

  • Конвейер ISAPI "классический"
  • Новый интегрированный конвейер

Если мы находитесь в конвейере ISAPI "классической", все будет продолжать работать так, как это ожидалось при использовании IIS 6.0. Чтобы проиллюстрировать эту точку, рассмотрим, как работает ASP.NET при выполнении в режиме ISAPI. Сначала необходимо добавить полный путь aspnet_isapi.dll и задать его allowed="true", как показано ниже:

<isapiCgiRestriction>
    <add path="F:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"
    allowed="true" groupId="ASP.NET v2.0.50727" description="ASP.NET v2.0.50727" />
</isapiCgiRestriction>

Теперь и только теперь этот код (aspnet_isapi.dll) будет разрешено выполнять. Если мы переключили режим конвейера на интегрированный и измененный разрешено="false", ASP.NET код по-прежнему будет выполнен.

Почему? Причина заключается в том, что isapiCgiRestrictionList применяется только к коду ISAPI и CGI. В интегрированном режиме ASP.NET теперь является частью новой архитектуры и в результате не затрагивается isapiCgiRestrictionList. Если вы не хотите запускать ASP.NET код в новом интегрированном конвейере, необходимо просто удалить управляемыйEngine из списка модулей.

Ограничения IP-адресов

Ограничения IP-адресов работают точно так же, как и в прошлом, за исключением того, что теперь мы поддерживаем новое свойство "allowUnlisted". Это свойство было добавлено, чтобы упростить настройку политик безопасности для системы на глобальном уровне. Например, если вашей политике требуется разрешить только определенные IP-адреса, но отклонить все остальные, которые не перечислены, было очень легко сделать в прошлом. Аналогичным образом, отклонение только заданного набора IP-адресов и разрешение всех, которые не перечислены, можно сделать сейчас. Администратор сервера может задать глобальную политику, а затем заблокировать это значение, чтобы его нельзя было изменить на сервере администраторами приложений или сайтов.

Чтобы проиллюстрировать, рассмотрим компьютер разработки, к которому пользователи будут получать доступ только локально. Следующая конфигурация реализует политику, задав параметр allowUnlisted="false", а затем явно разрешает доступ localhost (127.0.0.1):

<system.webServer>
    <security>
        <ipSecurity allowUnlisted="false">
            <add ipAddress="127.0.0.1" allowed="true" />
        </ipSecurity>
    </security>
</system.webServer>