Asp обзор объектов iis admin


Содержание

работа Построение веб-приложения на основе asp. Net и архитектуры сервера iis 0 — реферат

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»

ИНСТИТУТ МАТЕМАТИКИ И КОМПЬЮТЕРНЫХ НАУК

КАФЕДРА ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ

Построение веб-приложения на основе ASP.NET и архитектуры сервера IIS 7.0

Выполнил: студент 367 гр.

Введение

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

А что такое интернет без веб страниц и, соответственно, веб серверов?

Сейчас на рынке можно достаточно большое количество самых разных веб серверов. Один из наиболее распространенных – это Internet Information Server корпорации Microsoft. Учитывая последние тенденции к комплексным решениям Microsoft выпустила IIS 7.0, дающий разработчикам и администраторам новые возможности при создании и управлении сайтами.

В своей работе я ознакомился с новыми возможностями и применил их на практике.

Изучив возможности нового веб сервера, создать свой аутентификационный модуль для веб приложения.

Задачи:

1. Изучить новые возможности IIS 7.0

2. Познакомится с ASP.NET

3. Написать модуль аутентификации

Теоретическая часть

Безопасность в сети необходима, особенно если дело касается денег. Злоумышленники прибегнут к всевозможным ухищрениям лишь бы добраться до номера вашего банковского счета, логина и пароля в интернет-магазине. Данный проект написан на C# с применением технологии ASP.NET неслучайно. Существует множество готовых решений и предусмотренных классов для обеспечения безопасности соединения. Microsoft предлагает комплексные решения для многих задач. Продукты этой фирмы используются почти всеми, как в корпоративной сети, так и в обычной жизни. Интересующая нас задача — это создание и сопровождение полноценных защищенных веб приложений, таких как интернет магазин например.

Для создания безопасного веб-приложения необходимо полное понимание слабых мест в системе безопасности. Также необходимо ознакомиться с функциями обеспечения безопасности Windows, .NET Framework и ASP.NET. И, наконец, очень важно понимать способы использования этих функций безопасности для борьбы с угрозами.

Давайте рассмотрим поближе систему безопасности ASP.NET

Чтобы обеспечить безопасность веб-приложений, ASP.NET используется совместно с Microsoft .NET Framework и службами Microsoft Internet Information Services (IIS). Для создания безопасного приложения ASP.NET следует выполнить две основные функции:

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

· Авторизация (Ограничивает право доступа, предоставляя определенные разрешения или отказывая в них удостоверенной личности)

ASP.NET в сочетании со службами Microsoft Internet Information Services (IIS) может выполнять проверку подлинности учетных данных пользователя, например имен и паролей, используя любой из перечисленных ниже методов проверки подлинности:

· Windows: стандартная, шифрованная или встроенная проверка подлинности Windows (NTLM или Kerberos).

· Проверка подлинности в формах, в которых разработчик создает страницу входа и управляет проверкой подлинности в приложении.

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

Рассмотрим Архитектуру безопасности ASP.NET

Рис.1 Архитектура безопасности ASP.NET

Как показано на рисунке, все веб-клиенты взаимодействуют с приложениями ASP.NET с помощью служб IIS. При необходимости IIS проверяет подлинность запроса и затем определяет местонахождение запрошенного ресурса (например, приложение ASP.NET). Если клиент авторизован, ему предоставляется доступ к этому ресурсу.

Во время выполнения приложение ASP.NET может использовать встроенные средства безопасности ASP.NET. Кроме того, в приложении ASP.NET могут использоваться средства безопасности платформы .NET Framework.

Два стандартных стандартных сценария обеспечения безопасности: олицетворение(проверка подлинности Windows) и проверки подлинности с помощью форм с использованием файлов «cookies».

Олицетворение

Рис.2 Олицетворение. На рисунке показана следующая последовательность событий:

1. Запрос поступает в службы IIS от клиента сети.

2. Службы IIS проверяют подлинность клиента, используя стандартную, шифрованную или встроенную безопасность Windows (NTLM или Kerberos).

3. Если клиент проходит проверку подлинности, службы IIS передают удостоверенный запрос в ASP.NET.

4. Приложение ASP.NET олицетворяет клиент, выполняющий запрос, используя лексему доступа, переданную из IIS, и использует разрешения NTFS-файла для предоставления доступа к ресурсам. Приложение ASP.NET должно только проверить, что в файле конфигурации ASP.NET для олицетворения задано значение true ; код безопасности для ASP.NET писать не требуется. Если олицетворение не включено, приложение запускается с удостоверением процесса ASP.NET. Для Microsoft Windows 2000 Server и Windows XP Professional удостоверением по умолчанию является локальная учетная запись с именем ASPNET, которая создается автоматически при установке ASP.NET. Для Microsoft Windows Server 2003 удостоверением по умолчанию является удостоверение пула приложений для приложения IIS (по умолчанию учетная запись NETWORK SERVICE).

5. Если доступ разрешен, приложение ASP.NET возвращает запрошенный ресурс через IIS.

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

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

Рис.3 Проверка подлинности форм. На рисунке показана следующая последовательность событий:

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

2. Службы IIS получают запрос, и так как IIS разрешают анонимный доступ, они не выполняют никакой проверки подлинности пользователя и передают запрос приложению ASP.NET.

3. Так как ASP.NET использует режим поверки подлинности с помощью форм, приложение ASP.NET проверяет билет проверки подлинности на основе форм для запроса (отдельный файл «cookie»). Если к запросу не приложен билет проверки подлинности, ASP.NET перенаправляет запрос на страницу входа в систему, указанную в файле конфигурации приложения. На странице входа в систему пользователь вводит необходимые учетные данные, обычно имя и пароль. Код приложения проверяет учетные данные, чтобы подтвердить их подлинность. Если учетные данные проходят проверке подлинности, код приложения вкладывает билет проверки подлинности в ответ, который представляет учетные данные пользователя. (Пароль не включается). Если проверка подлинности не пройдена, ответ возвращается с сообщением об отказе в доступе, либо форма входа в систему представляется повторно.Выпущенный билет проверки подлинности включается в следующий запрос к приложению ASP.NET. ASP.NET проверяет допустимость использования билетом проверки подлинности сообщения (MAC).

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

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

IIS 7.0 Особенности

В основе выпуска IIS 7.0 лежит полностью модульный веб-сервер, включающий более 40 компонентов, которые можно объединять в компактные веб-серверы, оптимизированные для необходимой роли в топологии приложения. Эти компоненты создаются на основе нового слоя расширяемости, что позволяет разработчикам расширять или замещать практически любую функцию сервера в машинном коде или с помощью Microsoft® .NET Framework. IIS 7.0 предлагает расширяемость компонентов этапа выполнения, управления и рабочих компонентов, облегчая создание комплексных решений в соответствии с конкретными потребностями. На базе основной платформы IIS 7.0 берется за решение многих проблем, связанных с управляемостью и эксплуатацией сервера. Он обладает принципиально новой системой настройки, обеспечивающей полностью делегированное управление узлами и, в конечном итоге, делающей реальностью развертывание веб-приложений с использованием xcopy. Новые интерфейсы API для целей управления и диагностические компоненты делают процедуры развертывания, администрирования и устранения неполадок сервера значительно проще и удобнее, чем когда-либо прежде.

IIS 7.0 разбивает веб-сервер на небольшое ядро сервера и более чем 40 модулей компонентов, подключаемых к этому ядру. Эти модули — такие, как StaticFileModule, который позволяет загружать статическое веб-содержимое, или WindowsAuthModule, поддерживающий встроенную проверку подлинности NTLM, — можно устанавливать на сервере независимо, чтобы обеспечить именно те функциональные возможности, которые необходимы.

Эти модули можно в любое время полностью удалить с сервера или намеренно отключить на время работы конкретного приложения, которому они не требуются. Такая возможность позволяет администраторам сервера быстро развертывать серверы минимальной конфигурации со значительным уменьшением мест, доступных для атак, и существенным увеличением производительности за счет выполнения только необходимого кода. Архитектура, построенная из независимых компонентов, является важнейшим свойством IIS 7.0, ведущим к снижению рисков нарушения безопасности и минимизации необходимости вносить исправления. Она делает возможными специализированные развертывания сервера, для которых объединяются выбранные компоненты IIS и специальные составляющие, оптимизированные для конкретной роли сервера в топологии приложения, например, обратных прокси и кэширующих серверов, серверов балансировки нагрузки протокола HTTP или SSL и серверов безопасности Sentinel.

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

Упрощенное развертывание и настройка

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

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

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

В полном соответствии основной идее IIS 7.0 система настройки является полностью расширяемой. Новые модули могут добавлять собственные схемы настройки, позволяя приложениям настраивать свои компоненты наряду с настройкой IIS и ASP.NET:

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

IIS 7.0 продолжает поддерживать существующий код настройки, использующий для записи в традиционную метабазу интерфейсы API объекта ABO (Admin Base Object) или сценарии, использующие интерфейсы высокого уровня ADSI (Active Directory® Service Interfaces) и объекты WMI (Windows Management Instrumentation) для настройки IIS. Это достигается посредством предоставления слоя совместимости, который эмулирует интерфейсы API объектов ABO, являющиеся основой для всех других традиционных интерфейсов API настройки, позволяя таким сценариям читать и изменять настройку тем же способом, как они делали это в предыдущих версиях IIS. В то время как новый формат настройки с использованием структурированного XML облегчает работу с конфигурацией в привычном текстовом редакторе, IIS предоставляет администраторам также узел с инструментами управления и интерфейсы API, облегчающие управление сервером и делающие возможной автоматизированную настройку и развертывание.

.NET Framework и создание сценариев

Кроме администрирования сервера вручную с помощью IIS Manager или инструмента командной строки appcmd.exe IIS 7.0 предоставляет множество возможностей программного администрирования. Во-первых, можно использовать интерфейс API Microsoft.Web.Administration для управления сервером из приложений .NET. Или использовать новый интерфейс API COM для непосредственного управления системой настройки IIS, либо получить к ней доступ из среды создания сценариев, например ASP или Windows® Script Host (WSH). Существует также новый поставщик WMI и поддержка традиционных поставщиков WMI и ADSI посредством слоя совместимости метабазы.

Microsoft.Web.Administration, новый интерфейс API администрирования .NET, облегчает приложениям управляемого кода обеспечивать программную поддержку узлов и приложений IIS, получать доступ к важной информации о состоянии и диагностическим данным и изменять настройку сервера. Способность приложений на основе .NET Framework беспрепятственно получать доступ к информации о настройке IIS и данным о состоянии открывает необъятный простор для написания приложений настройки с использованием .NET и управляющих приложений или даже выполнения задач управления непосредственно из страниц ASP.NET.

Создание компонентов веб-сервера

IIS 7.0 дает возможность сформировать сервер в соответствии с конкретными потребностями, позволяя добавлять или заменять в сервере любой компонент для обеспечения требуемого набора функций. В основе этой возможности лежит совершенно новый интерфейс расширяемости веб-сервера, на основе которого создаются все существующие компоненты HTTP IIS 7.0. Этот интерфейс API является открытым, что означает возможность реализации любого из компонентов, поставляемых с IIS 7.0. Для IIS это самое важное и фундаментальное усовершенствование по сравнению с предыдущей ограниченной моделью расширяемости ISAPI.

Новый интерфейс расширяемости представляет собой набор интуитивных классов C++, определяющих объектную модель и дающих возможность модулю предоставлять службы обработки запросов на IIS. Эти классы определяются в заголовочном файле в Windows Vista SDK.

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

· Проверка запроса с помощью класса IHttpRequest

· Управление откликом с помощью класса IHttpResponse

· Использование полезных функций служебных программ класса IHttpServer

· Обеспечение проверки подлинности с помощью класса IHttpUser

· Получение доступа к разделу пользовательской настройки вашего модуля с помощью интерфейсов API настройки

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

Разработчики получат преимущество также благодаря усовершенствованным шаблонам для управления памятью и состоянием. Большинство интерфейсов API сервера IIS 7.0 используют для возвращаемых данных память, управляемую сервером, вместо запроса на выделение буферов и управления ими, как это делает ISAPI и большинство существующих интерфейсов API в Win32®. В прошлом это был один из наиболее подверженных ошибкам и утомительных этапов разработки ISAPI. Новый интерфейс API упрощает также многие сложные задачи обработки запросов, например, буферизацию отклика, проверку подлинности и подготовку данных отклика для клиента

Интеграция ASP.NET

В составе сервера IIS 7.0 ASP.NET приходит в двух версиях: Режим Classic и режим Integrated Режим Classic работает точно так же, как он работал в предыдущих версиях IIS. Режим Integrated, являющийся платформой по умолчанию, использует совершенно новый обработчик для обеспечения интеграции высочайшего уровня с веб-сервером IIS. В режиме Integrated интерфейсы API ASP.NET можно использовать для разработки модулей IIS 7.0, которые напрямую интегрируются с веб-сервером и в состоянии предоставлять практически все возможные службы благодаря лежащему в основе интерфейсу API на C++,.

По существу, это оптимальный вариант — знакомые интерфейсы и удобные службы приложений .NET Framework и ASP.NET 2.0, такие, как управление членством и ролями, плюс неограниченная возможность расширения сервера, ранее доступная только составляющим ISAPI, написанным на C.

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

Рис 4. Жизненный цикл ASP.NET

Для разработчиков ASP.NET преимущества интегрированного конвейера заключаются в следующем:

  • Интегрированный конвейер может вызывать все события, объявленные в объекте HttpApplication, что позволяет существующим HTTP-модулям ASP.NET работать в интегрированном режиме IIS 7.0.
  • И модули машинного кода, и модули управляемого кода можно настраивать на уровне веб-сервера, веб-узла и веб-приложения. Это относится и к встроенным модулям управляемого кода ASP.NET для управления состоянием сеанса, проверкой подлинности форм, профилями и ролями. Более того, поддержку модулей управляемого кода можно включить или отключить для всех запросов, независимо от того, предназначен ли запрос для ресурса ASP.NET, например ASPX-файла.
  • Модули управляемого кода можно вызывать на любом этапе конвейера. Это можно сделать до обработки запроса на сервере, после обработки на сервере или в любой момент во время обработки.
  • Регистрация, включение и отключение модулей выполняется в файле Web.config приложения.

Модули управляемого кода в службах IIS 7.0

  • FormsAuthenticationModule
  • ProfileModule
  • RoleManagerModule
  • SessionStateModule

Разработка настраиваемых модулей управляемого кода


Жизненный цикл приложения ASP.NET можно расширить с помощью модулей, в которых реализован интерфейс IHttpModule. Модули, в которых реализован интерфейс IHttpModule, являются модулями управляемого кода. Интегрированный конвейер ASP.NET и IIS 7.0 также можно расширить с помощью модулей машинного кода, которые в данном разделе не рассматриваются. Модуль управляемого кода можно задать как файл класса в папке App_Code приложения. Также можно создать модуль как проект библиотеки классов, скомпилировать его и добавить в папку Bin приложения. После создания настраиваемого модуля его необходимо зарегистрировать с помощью IIS 7.0. Для управления модулями управляемого кода IIS 7.0 можно воспользоваться одним из описанных ниже методов. Например, чтобы зарегистрировать модуль управляемого кода только для одного приложения, можно изменить файл Web.config этого приложения. Если модуль находится в папке App_Code или Bin и зарегистрирован в файле Web.config приложения, этот модуль вызывается только для этого приложения. Чтобы зарегистрировать модуль Web.config приложения, необходимо изменить элемент modules в разделе system.webServer . Изменения, внесенные с помощью IIS Manager или средства Appcmd.exe, вносятся в файл Web.config приложения.

Модули управляемого кода также можно зарегистрировать в элементе modules хранилища конфигурации IIS 7.0 (файл ApplicationHost.config). Модули, зарегистрированные в файле ApplicationHost.config, обладают глобальной областью действия, поскольку они зарегистрированы для всех веб-приложений, размещенных с помощью служб IIS 7.0. Модули машинного кода, заданные в элементе globalModules файла ApplicationHost.config, также обладают глобальной областью действия. Если глобальный модуль в веб-приложении не используется, его можно отключить.

Практическая часть

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

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

Модуль реализован с применением стандартного класса IHttpModule.

public class userAuth : IHttpModule

public void Init(HttpApplication app)

app.AuthenticateRequest += new EventHandler(this.Authorize);

При каждом обращении к странице возникает событие AuthenticateRequest, на которое модуль реагирует обработчиком события Authorize

public void Authorize(Object source, EventArgs e)

HttpApplication application = (HttpApplication)source;

IIS 7.0 Построение решений веб-сервера с использованием сквозной расширяемости

Веб-платформа IIS 7.0 поддерживает большее число технологий инфраструктуры приложений для размещения многофункциональных приложений, чем любая предыдущая версия IIS, она буквально напичкана функциями, которые можно использовать для развертывания этих приложений сразу же после установки. Однако в то же время вы видите (в установке Windows®) не обязательно то, что всегда получаете.
Архитектура IIS 7.0 выполнена таким образом, что позволяет ей быть расширяемой сверху донизу, это дает возможность заменять любую часть встроенного набора функций на собственные разработки, которые наилучшим образом соответствуют вашим требованиям. В результате этого вместо латания лоскутного одеяла из подключаемых модулей IIS 7.0 дает совершенно уникальные возможности по расширяемости путем реализации всех собственных функций поверх общедоступной модели расширяемости. Эта конструкция прослеживается по всей платформе, начиная от самого модульного механизма веб-сервера и до системы настройки консоли диспетчера IIS.
В этой статье я постараюсь погрузиться в тонкости модели расширения IIS 7.0, рассмотрев для этого исходный код общего пользования проекта модуля изменения ответа, который позволяет получать отклики приложений IIS и изменять их «на лету», используя для этого настраиваемые правила изменения откликов. Вначале я построю модуль веб-сервера, воспользовавшись встроенной в сервервозможностью расширения ASP.NET. Затем я создам функции развертывания и управления для модуля, разработав раздел пользовательской настройки и создав специальную страницу управления для диспетчера IIS.

Расширение веб-сервера

Модульная архитектура IIS 7.0 предоставляет возможность полностью перестроить веб-сервер под требуемую рабочую нагрузку. Зачастую это может быть выполнено просто путем установки только тех функций, которые необходимы для вашего приложения, в результате чего появляется веб-сервер с урезанной функциональностью, позволяющей делать только то, что необходимо, и ничего более.
Однако это только первый шаг. Зачастую нужная рабочая нагрузка требует наличия дополнительных функций, которые могут не входить во встроенный набор функций IIS. Или же в некоторых случаях приложениям может потребоваться специальный набор функций, для выполнения которых встроенные функции недостаточно приспособлены. Поскольку все функции IIS 7.0 построены на общедоступных интерфейсах расширяемости API, вы можете заменить любой из них собственной разработкой, которая наилучшим образом соответствует вашим требованиям.
IIS 7.0 предоставляет два способа разработки модулей веб-сервера. Во-первых, можно использовать новый интерфейс API для модулей на C++, на котором основана большая часть встроенных функций. Интерфейс API модулей заменяет расширение ISAPI и интерфейс API фильтра, применявшиеся в предыдущих версиях IIS. Этот интерфейс API является существенным усовершенствованием по сравнению с ISAPI, поскольку он способен поддерживать все функции IIS 7.0 и гораздо проще для использования в программировании. Узнать подробней об усовершенствованиях в этом интерефейсе API можно по адресу: mvolo.com/blogs/serverside/archive/2006/10/07/10-reasons-why-server-development-is-better-with-IIS7.aspx.
Во-вторых, в IIS 7.0 введена интеграция с ASP.NET, которая позволяет разрабатывать модули IIS 7.0 с использованием хорошо знакомых интерфейсов API модулей в ASP.NET. В объединенном режиме ASP.NET эти модули становятся полноправными участниками конвейерной обработки запросов IIS, как видно из рис. 1. Это позволяет модулям ASP.NET получать доступ ко встроенным объектам IIS, таким как запросы и ответы, на всех стадиях обработки и обрабатывать запросы для всех типов ресурсов — не только для тех, которые обрабатываются платформой ASP.NET.

Рис. 1 Модули ASP.NET в обработке запросов IIS 7.0

Это позволяет использовать одинаково по всему веб-узлу такие многосторонние функции ASP.NET, как проверка подлинности на основе форм, элементы управления входом в систему и служба членства. Для более подробного изучения того, как объединенный режим ASP.NET может быть использован с целью повышения функциональных возможностей приложений, написанных не для платформы ASP.NET, прочтите мою статью в январском номере журнала MSDN® Magazine за 2008 год, расположенную по адресу: msdn.microsoft.com/msdnmag/issues/08/01/PHPandIIS7.
Для разработчиков истинная ценность объединенного режима ASP.NET заключается в возможности наращивать функциональность веб-сервера IIS с использованием платформы Microsoft® .NET Framework. Это дает существенные преимущества при быстрой разработке приложений путем обеспечения возможности строить эти приложения на основе широкой поддержки платформ .NET Framework, ASP.NET, а также других платформ, таких как Windows Workflow Foundation.

Модуль изменения ответа

Объединенный конвейер ASP.NET дает возможность модулям ASP.NET выполнять широкий спектр задач в ходе обработки каждого запроса. Этот спектр содержит все, начиная от задач проверки подлинности или авторизации и до изменения исходящих ответов перед их отправкой клиенту.
Назначением модуля изменения ответа является выполнение изменения ответа: он позволяет изменять существующие ответы «на лету» при помощи набора правил замены. Для этого можно использовать механизм фильтрации ответов ASP.NET, который, благодаря объединения со средой выполнения, обеспечивает фильтрацию исходящих ответов любого содержания, включая статические файлы, а также сценарии ASP и PHP.
Если в прошлом вы разработали модуль ASP.NET, то вас, несомненно, обрадует тот факт, что вы сможете использовать те же интерфейсы API для разработки модулей ASP.NET на платформе IIS 7.0. Фактически, имеющиеся у вас модули продолжают работать точно так же, как они работали в предыдущих версиях IIS (если только не нужно использовать преимущества объединенного режима IIS 7.0 и запускать их для обработки всех запросов). Модуль является классом, реализующим интерфейс System.Web.IHttpModule и регистрирующим обработчики событий для событий конвейерной обработки одного или нескольких запросов. Модуль изменения ответов именно такой:

По существу, модуль подписывается на событие PreRequestHandlerExecute, которое происходит всякий раз перед выполнением обработчика запроса. Метод OnPreRequestHandlerExecute используется для чтения сведений настройки с целью определить, имеет ли ответ какие-нибудь применимые для него правила замены (подробнее о настройке — далее в этой статье), и в случае наличия таковых регистрировать поток фильтра ответов, который затем будет использован для фильтрации исходящих ответов, как показано на рис. 2.
Figure 2 Фильтр ответов

Фильтрация ответов выполняется внутри класса ChainedBufferedStringResponseFilter, который отвечает за преобразование байтов ответов в строку при помощи набора символов ответов, а также за вызов одного или несколько фильтров ответов, которые применимы к данному запросу. Модуль связывает фильтр с ответом путем установки свойства HttpResponse.Filter. Это свойство принимает все объекты, порожденные от абстрактного класса System.IO.Stream, и позднее использует их для фильтрации тела экземпняра исходящего ответа.
Функция фильтрации ответов ASP.NET — всего лишь один из механизмов, которые становится возможным использовать при разработке модулей ASP.NET для объединенного режима платформы IIS 7.0. Кроме того, можно переписывать URL-адреса, выполнять проверку подлинности и авторизацию запросов, модифицировать или выпускать файлы «cookie» и заголовки ответов, журналировать запросы и многое другое. Большинство задач, которые ранее требовали разработки в среде ISAPI в машинном коде, теперь могут быть реализованы путем простого написания модулей ASP.NET. Поэтапные указания по сборке модулей ASP.NET для IIS 7.0, параметрам среды разработки и выполнению развертывания можно найти по адресу: mvolo.com/blogs/serverside/archive/ 2007/08/15/Developing-IIS7-web-server-features-with-the-.NET-framework.aspx.
При разработке модуля IIS 7.0 можно использовать возможности ряда функций IIS, используемых для целей управления и развертывания. Одна из таких функций — возможность указывать пользовательскую настройку модуля в файлах настройки IIS 7.0 и либо принудительно развертывать эту настройку автоматически самим приложением, либо управлять ею с помощью ряда средств администрирования IIS 7.0 и интерфейсов API. Выполнение такой процедуры является залогом того, что все функции, выполняемые модулем, будут правильно настроены и управляемы конечными пользователями.

Расширение настройки

Новая система настройки является основой для большого числа основных вариантов развертывания и управления, возможных для платформы IIS 7.0. Вместо того, чтобы быть машинно-ориентированным зранилищем настройки закрытого формата, система настройки IIS 7.0 основана на структурированных файлах настройки формата XML, располагающихся в тех же файлах настройки, используемых системой настройки ASP.NET. Более того, синтаксис данных настройки IIS идентичен синатксису данных настройки ASP.NET; эти данные могут быть совместно записаны в распространяемые файлы web.config, с которыми разработчики ASP.NET очень хорошо знакомы.
Такая схема открывает многие двери. Во-первых, она позволяет приложениям указывать данные настройки IIS вместе со своим прикладным содержимым, что упрощает процесс их развертывания до простой публикации содержимого на сервере. Это гарантирует, что приложения будут работать правильно без необходимости изменять данные машинной настройки, хранящиеся на каждом сервере, на котором эти приложения развертываются, а также без необходимости иметь полномочия администратора на каждом сервере. Структурированный файл настроки формата XML совместно с возможностью размещать настройку ASP.NET вместе с настройкой IIS в одном файле значительно упрощает задачу разработчиков создавать данные настройки, относящиеся к IIS, и управлять ими. Эта задача может выполняться с помощью редактора файлов XML, например Notepad и Visual Studio®, или может быть автоматизирована с помощью интерфейсов API настройки, предоставляемых стеком администрирования IIS 7.0.
Но самым замечательным здесь является тот факт, что система настройки IIS 7.0 является полностью расширяемой. Возможность предоставлять специальному веб-серверу право публикации настроек, которые могут устанавливаться и управляться вместе с настройкой IIS 7.0, играет ключевую роль в построении полных решений для IIS 7.0.
В отличие от системы настройки .NET, добавление нового раздела настройки IIS 7.0 не требует использования программного кода, поскольку сами разделы IIS 7.0 определяются с использованием схемы, основанной на XML. Фактически, все встроенные разделы настройки IIS 7.0 определяются с использованием этого механизма. Найти определения всех разделов настройки IIS можно найти в каталоге %windir%\system32\inetsrv\config\schema в файле IIS_Schema.xml. Например, раздел настройки , который включает и настраивает документы по умолчанию для вашего приложения, определяется следующим образом:

Такая схема определяет все элементы и атрибуты, которые составляют раздел настройки, их типы и дополнительные сведения, такие как определения коллекций и характер проверки атрибутов. Для получения дополнительных сведений о синтаксисе и определениях схем см. комментарии в заголовке файла настройки IIS_Schema.xml.

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

Модуль изменения ответа требует наличия собственного раздела настройки для настройки ряда специальных параметров, в том числе сведений о том, какие правила фильтрации применимы для данного приложения. Чтобы предоставить возможность использовать этот раздел в файлах настройки IIS, в первую очередь необходимо создать файл схемы, который описывал бы структуру раздела (см. рис. 3). Этот файл определяет раздел responseModification и его структуру, включая необходимые атрибуты и коллекцию правил фильтрации, которые могут настраиваться для вызова различных фильтров с дополнительной информацией о том, что и чем должно заменяться.
Figure 3 Схема настройки модуля изменения ответа

Для установки этого раздела настройки необходимо сделать две вещи. Во-первых, скопируйте файл responsemod_schema.xml, содержащий сведения о схеме раздела, в папку %windir%\system32\inetsrv\config\schema. Затем объявите раздел настройки в основном файле настройки сервера, applicationHost.config. Последняя задача потребует написания некоторого кода, если вы пожелаете выполнить эту установку с помощью программы.
Чтобы упростить процесс установки раздела настройки IIS 7.0, я написал служебную программу iisschema.exe, которая выполняет обе эти задачи автоматически. Эту программу можно получить по адресу: mvolo.com/blogs/serverside/archive/2007/08/04/IISSCHEMA.EXE-_2D00_-A-tool-to-register-IIS7-configuration-sections.aspx. С использованием этой программы процедура установки раздела схемы настройки становится одношаговой:

После того как схема раздела настройки установлена, а сам раздел объявлен в файле applicationHost.config, можно начать использовать его для определения данных настройки модуля.
Для управления настройкой раздела можно использовать любое из средств настройки IIS или интерфейсов API, точно так же, как это делалось бы с любым встроенным разделом настройки IIS 7.0. Например, я хочу включить функцию изменения ответов для моего приложения с помощью AppCmd, средства командной строки IIS 7.0:

Кроме того, я могу добавить в раздел настройки responseModification коллекцию правил:

Если теперь вы откроете файл web.config в корневой папке веб-узла по умолчанию (обычно это %windir%\inetpub\wwwroot), вы обнаружите следующий код:

Если вы исправили файл приложения web.config с целью изменения данных настройки модуля, а затем загрузили его на сервер, приложение будет настроено таким образом, чтобы использовать эти новые параметры. Точно так же, если вы загрузили приложение на другой сервер, на котором установлен раздел настройки, вы можете быть уверены, что данное приложение будет использовать нужные параметры без необходимости перенастройки его на этом сервере.
В дополнение к AppCmd, теперь можно использовать для управления данными настройки данного раздела любой интерфейс API настройки IIS 7.0, включая управляемый интерфейс Microsoft.Web.Administration, поставщик WMI из IIS 7.0, объекты COM настройки IIS 7.0 , а также Windows PowerShell®. Кроме установки и чтения данных настройки, можно выполнять любые задачи управления, поддерживаемые системой настройки IIS 7.0, включая управление процессом делегирования данного раздела приложениям, защиту их содержимого путем шифрования настройки и т.д. Те мне менее, чтобы эти данные настройки были полезными, вам потребуется возможность читать их из модуля изменения ответа.
Интерфейс API Microsoft.Web.Administration является новым интерфейсом .NET Framework, предоставляемым IIS 7.0; он позволяет программам иметь доступ к данным настройки IIS 7.0. Кроме того, что этот интерфейс предоставляет программам настройки и установки возможность управлять настройкой, он также дает возможность считывать данные настройки непосредственно из управляемого модуля.
Можно использовать этот интерфейс API для чтения раздела настройки из модуля сразу же после регистрации раздела настройки, поскольку интерфейс API предоставляет нестрого типизированную модель для чтения разделов настройки. Перед тем как делать это, вам необходимо добавить ссылку на файл Microsoft.Web.Administration.dll, который находится в папке %windir%\system32\inetsrv. Заметим, что эта библиотека DLL входит в состав только IIS 7.0 под Windows Vista® или Windows Server® 2008 и не поставляется в составе .NET Framework или комплекта SDK для Windows.
После того, как ссылка добавлена, можно читать данные настройки модуля:

Илон Маск рекомендует:  Типовые макеты

Класс WebConfigurationManager в пространстве имен Microsoft.Web.Administration почти идентичен WebConfigurationManager в пространстве имен System.Web.Configuration и призван заменить последний для работы с управляемыми модулями IIS 7.0, выполняющими чтение настройки IIS 7.0. Метод GetSection выбирает объект раздела настройки по пути, указанному в текущем запросе HTTP.

Строго типизированный класс настройки

Объект ConfigurationSection предоставляет нестрого типизированный доступ к любому разделу настройки, не требуя написания дополнительного кода. Можно получить доступ ко включенному атрибуту путем простого извлечения его имени в индексаторе объекта раздела и приведения его к ожидаемому типу.
Тем не менее, можно продвинуться на один шаг вперед, создав строго типизированную оболочку для раздела настройки. Можно быстро создать класс оболочки с помощью служебной программы, написанной Канвальетом Синглой (Kanwaljeet Singla), участником команды IIS; эту программу можно загрузить по адресу: blogs.iis.net/ ksingla/archive/2006/12/04/tool-to-generate-strongly-typed-classes-for-configuration-sections.aspx. Она позволяет создавать класс оболочки для раздела, имеющего примерно такой вид, как показан на рис. 4. Этот класс просто обертывает нижележащий класс ConfigurationSection и предоставляет строго типизированные свойства для доступа к исходным данным настройки.
Figure 4 Строго типизированная обертка раздела настройки

Как видно из реализации свойства Enabled, обертывание атрибутов настройки является достаточно простым. Обертывание дочерних элементов и коллекций требует последующей реализации классов оберток, наследуемых соответственно из ConfigurationElement и ConfigurationCollection (не показаны), точно таких же, как сама обертка раздела.
После того, как класс обертки создан, его можно скомпилировать в отдельную сборку и указать ссылку на него в проекте модулей или просто добавить его в виде файла исходного кода. Это позволит модулю иметь безопасный относительно типов доступ к разделу настройки:

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

Расширение IIS Manager

Итак, я уже показал, как создать модуль изменения ответа и позволить ему читать специальный раздел настройки, который управляет его поведением. Эта настройка может храниться в тех же файлах настройки, что содержат оставшиеся данные настройки IIS, может развертываться вместе с приложением в файлах web.config, а также может обрабатываться с помощью различных программных средств и интерфейсов API, в том числе AppCmd.exe и Microsoft.Web.Administration.
К этому моменту модуль изменения ответа может быть развернут и соответствующим образом настроен в любой среде IIS. Тем не менее, можное продвинуться еще на один шаг вперед, предоставив функции специальные возможности управления для консоли диспетчера IIS. Сделав это, вы получите ряд преимуществ. Это позволит системным администраторам без труда настраивать модуль с помощью консоли диспетчера IIS, не требуя от них править непосредственно файлы настройки или использовать другие низкоуровневые служебные программы и интерфейсы API. Это также позволяет обрабатывать данные настройки модуля с помощью средств удаленного администрирования диспетчера IIS, которые предоставляют пользователю преимущества службы веб-управления (WmSvc).
В отличие от других средств, которые тоже поддерживают функции удаленного администрирования, архитектура удаленного администрирования диспетчера IIS имеет ряд ключевых преимуществ. Во-первых, она позволяет пользователям, не обладающим правами администратора на сервере, управлять веб-узлами и приложениями, которые доступны для них. Во-вторых, механизм удаленного администрирования диспетчера IIS использует протокол HTTPS, а не DCOM, который проще проходит через корпоративные брандмауэры. В сочетании обе эти возможности делают диспетчер IIS Manager привлекательным для делегированного удаленного управления веб-узлами IIS, особенно в средах совместного веб-размещения.
В полном соответствии с основной идеей IIS 7.0, диспетчер IIS имеет расширяемую архитектуру, на которой основано большинство встроенных функций диспетчера IIS. С целью упрощения случая удаленного управления каждая функция управления состоит из двух частей: компонентов клиентской части, которая предоставляет пользовательский интерфейс внутри диспетчера IIS, и серверных компонентов, которые предоставляют собственно сами службы управления.
Служба на стороне сервера загружается внутри диспетчера IIS Manager в случаях локального управления или внутри службы веб-управления в случаях удаленного управления. Во втором случае диспетчер IIS поддерживает необходимый обмен данными между компонентами в диспетчере IIS на машине клиента и службой, запущенной внутри WmSvc на машине принимающего сервера.

Создание службы

Клиентские и серверные компоненты обычно выполнены в виде двух отдельных сборок .NET, которые не ссылаются друг на друга. Обмен данными между клиентскими и серверными компонентами осуществляется посредством абстракции ModuleServiceProxy диспетчера IIS, которая использует для обмена информацией набор нестрого типизированных свойств и основных типов .NET.
Серверная сборка обычно содержит реализацию класса Microsoft.Web.Management.Server.ModuleProvider, который выполняет требуемую регистрацию служб и клиентских модулей, а также реализацию класса Microsoft.Web.Management.Server.ModuleService, который представляет методы служб для выполнения требуемых задач управления.
Моя сборка Mvolo.ResponseModificationUI.Server.dll содержит класс ResponseModificationModuleProvider, который отвечает за регистрацию класса служб ResponseModificationModuleService в дополнение к классу клиентского модуля ResponseModificationModule, как это показано на рис. 5.
Figure 5 Класс поставщика модулей

Класс ResponseModificationModuleService порождается от класса ConfigurationModuleProvider, который предоставляет встроенную поддержку для управления функциями делегирования диспетчера IIS, основанными на состоянии делегирования нижележащего раздела настройки. Все, что нужно сделать, — указать имя раздела настройки, responseModification, и диспетчер IIS автоматически переключит состояние делегирования функций в зависимости от того, заблокирован или разблокирован этот раздел для отдельных путей настройки. Инфраструктура Microsoft.Web.Management предоставляет несколько других базовых классов ModuleProvider, которые поддерживают немного другие случаи делегирования для средства диспетчера IIS.
Метод GetModuleDefinition возвращает тип модуля диспетчера IIS, который будет создан на стороне клиента, чтобы зарегистрировать требуемые компоненты интерфейса пользователя диспетчера IIS, такие как страница управления.
Обратите внимание на то, что тип класса ResponseModificationModule на стороне клиента — строковый, но не объект типа Type, поскольку серверная сборка может не ссылаться на сборку клиента, которая будет загружена в диспетчер IIS на машине удаленного клиента. Это один из побочных эффектов, обусловленный тем фактом, что компоненты клиента и сервера могут быть запущены в разных процессах и не могут совместно использовать пользовательские типы.
Класс ResponseModificationModuleService отвечает за реализацию функций управления и использование методов служб, которые вызваются страницей управления в диспетчере IIS (см. рис. 6).
Figure 6 Класс службы модулей

Метод GetFilterRules является примером использования нескольких методов службой, выполняющей задачи управления с использованием системы настройки, а также других ресурсов, локальных для сервера. Экземпляр службы всегда создается на сервере, так что он постоянно работает на локальных ресурсах, поэтому нет необходимости волноваться о раздельном доступе к ресурсам в случае удаленного администрирования. Обратите внимание на то, что я снова использую интерфейс API Microsoft.Web.Administration для доступа к разделу настройки responseModification, при этом использую строго типизированную обертку ResponseModificationConfigurationSection, созданную для обеспечения доступа модуля к настройке.
Свойство ManagementUnit является основной точкой доступа к локальному серверу, оно предоставляет ряд других объектов, которые обеспечивают доступ к системе настройки и другим объектам управления, сосредоточенным на сервере, которые были созданы с помощью платформы Microsoft.Web.Management с целью помочь в реализации задач управления сервером. Практический опыт показывает, что реализации служб должны всегда использовать блок управления для задач управления локальной настройкой, а не создавать собственные системы настройки.
Методы наподобие GetFilterRules могут возвращать клиенту данные, используя основные типы, например, ArrayList, для пересылки данных клиентским компонентам. Снова обратите внимание на то, что нельзя осуществлять обмен данными ипри помощи строго типизированных классов, определенных на серверной или клиентской сборках, потому что они предназначены для раздельного использования и не должны ссылаться друг на друга. Служба ResponseModificationModuleService также определяет дополнительные методы служб, аналогичные GetFilterRules, в том числе EditFilterRule, AddFilterRule и DeleteFilterRule, предназначенные для выполнения операций управления, которые могут быть затребованы страницей модуля изменения ответа.

Создание страницы модуля
Клиентские компоненты определяют функции графического интерфейса пользователя (GUI), предоставляемые пользователю с помощью диспетчера IIS. Клиентская сборка обычно содержит реализацию следующих классов:
Класс Microsoft.Web.Management.Client.Module, ответственный за регистрацию всех требуемых страниц диспетчера IIS и других расширений пользовательского интерфейса.
Класс Microsoft.Web.Management.Client.ModulePage, который содержит описание текущей страницы управления, отображаемой диспетчером IIS.
Класс Microsoft.Web.Management.Client.ModuleServiceProxy, коорый предоставляет клиентские компоненты совместно с классом локального прокси для вызова методов служб, используемых ModuleService.
Сборка Mvolo.ResponseModificationUI.Server.dll содержит класс ResponseModificationModule, показанный на рис. 7 (не путать собственно с классом IhttpModule, предоставляющим службы модуля при конвейерной обработке запросов IIS), который предоставляет главную точку входа для регистрации всех требуемых компонентов пользовательского интерфейса в диспетчере IIS. Этот класс регистрирует класс ResponseModificationModulePage, который содержит описание текущей управляющей страницы.
Figure 7 Класс модулей

Каждая реализация модуля создается однократно за время управляющего подключения, выоплненного диспетчером IIS, она ответственна за регистрацию всех страниц управления и элементов пользовательского интерфейса, необходимых для данного подключения. ResponseModificationModule регистрирует класс ResponseModificationModulePage, который определяет содержимое управляющей страницы.
Честно говоря, я не большой поклонник программирования пользовательских интерфейсов, я предпочел бы программировать низкоуровневые серверные программы, которые не требуют разработки интерфейса. К счастью для меня, платформа Microsoft.Web.Management предоставляет целый ряд базовых классов и поддерживающих классов, предназначенных для создания обычных управляющих страниц, включая класс Microsoft.Web.Management.Client.Win32.ModuleListPage, который я использовал для ResponseModificationModulePage.
Этот класс имеет встроенное представление в виде списка для просмотра списков элементов и работы с ними, включая упорядочение списков и работу с элементами списка. С минимальными переделками я смог создать страницу управления, содержащую перечень правил изменения ответов (см. центральную панель на рис. 8).

Рис. 8 Страница изменения ответов в диспетчере IIS

Затем я создал перечень действий, показанный в правом окне, позволяющий добавлять, изменять и удалять правила изменения ответов. При создании этого перечня задач я использовал возможности класса Microsoft.Web.Management.Client.TaskList (см. правую панель на рис. 8).
Еще немного усилий, и функция изменения, показанная на рис. 8, является на свет. Можно изучить детали пользовательского интерфейса, посмотрев исходный код для платформы изменения ответа.
Операции создания новой страницы, добавления, правки и удаления, запускаемые с панели действия, выполняются с помощью методов класса ResponseModificationModuleServiceProxy, который предоставляет локальный прокси для методов модулей, вызываемых службой модулей:

Диспетчер IIS автоматически передает вызовы, сделанные к классу прокси службы модулей, на связанную службу модуля по каналу обмена данными, который может представлять собой локальный канал совместно используемой памяти или канал https на удаленный сервер.

Развертывание расширения

При развертывании расширения диспетчера IIS учтите, что нужно зарегистрировать тип поставщика модуля в файле настройки диспетчера IIS на сервере (%windir%\system32\inetsrv\config\administration.config). Настройка, показанная на рис. 9, регистрирует поставщик модуля и предоставляет возможность использовать его на всех веб-узлах по умолчанию. Заметим, что и клиентская, и серверная сборки, образующие расширение, Mvolo.ResponseModificationUI.Server.dll и Mvolo.ResponseModificationUI.Client.dll, должны быть зарегистрированы в глобальном кэше сборок (GAC) и, следовательно, должны иметь строгое имя и подпись. Это требование, позволяющее выполнить установку расширений диспетчера IIS.
Figure 9 Настройка расширения диспетчера IIS

Когда диспетчер IIS используется для удаленного управления сервером, он автоматически предложит пользователю загрузить клиентскую сборку вне зависимости от того, есть она уже или еще нет (это происходит при управлении IIS 7.0 на Windows Server 2008 клиентом Windows Vista SP1, Windows XP или Windows Server 2003 с использованием удаленного диспетчера IIS, который доступен по адресу: iis.net/ downloads/?tab >

Окончательная сборка

После развертывания модуля и установки схемы раздела настройки и расширения диспетчера IIS функция изменения ответа готова к использованию. Теперь можно применять эту функцию к любому приложению на вашем сервере и настраивать его с помощью любой программы настройки или интерфейсов API IIS 7.0.
Кроме того, можно использовать диспетчер IIS для быстрого управления правилами изменения ответов в приложениях как на локальном, так и на удаленном сервере. Используя поддержку делегирования диспетчера IIS, можно установить, кто из пользователей имеет право удаленно создавать и изменять правила изменения ответов для определенных веб-узлов сервера.
Для демонстрации функции изменения ответов в действии на рис. 10 показано, как настроены правила для приложения Qdig моей галереи изображений (см. msdn.microsoft.com/msdnmag/issues/08/01/PHPandIIS7). На рис. 11 показано, как использован фильтр Mvolo.ResponseModification.Filters.RegExReplace, поставляемый в составе платформы изменения ответа, для вставки текста колонтитулов на всех страницах веб-узла без изменения исходного кода приложения.
Figure 10 Включение колонтитулов

Рис. 11. Использование модуля изменения ответов для изменения ответов

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

Шесть новых компонентов безопасности в IIS 7.0

Уязвимые места в защите Web-сервера могут привести к катастрофическим последствиям. Наглядный пример: Microsoft Internet Information Services (IIS) 5.0 печально известна недостаточной продуктивностью.

Успешное управление Web-сервером и уменьшение вероятности атак

Со временем компания Microsoft перепроектировала IIS с акцентом на безопасность. В результате появилась версия IIS 6.0, признанная самым надежно защищенным коммерческим Web-сервером (об этом свидетельствует малое число рекомендаций по продукту на сайте Secunia, см. secunia.com/product/1438).

В версии IIS 7.0 надежно защищенная архитектура IIS 6.0 получила дальнейшее развитие. Благодаря модульности можно полностью удалять отдельные компоненты, снижая вероятность атаки на Web-сервер. Пулы приложений, реализованные в IIS 6.0 с целью изолировать приложения друг от друга (и процессов Web-сервера), размещены в «песочнице». Новые функции делегирования позволяют владельцам управлять сайтами без необходимости в повышении прав. Фильтрация запросов с помощью URLscan встроена в сервер. А администраторы могут непосредственно в IIS 7.0 задать правила, указывающие, кто из пользователей имеет доступ к различным URL-адресам.

Эти новшества относятся к числу улучшений безопасности IIS 7.0. Они заслуживают внимательного изучения и могут даже заставить администраторов пересмотреть подходы к управлению и настройке Web-узлов.

«Песочницы» для приложений

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

Web-приложения выполняются в рабочих процессах. Пулы приложений сопоставляют Web-приложения с рабочими процессами. Конкретный рабочий процесс используется только для приложений из одного пула. Файл рабочего процесса в IIS 6.0 и IIS 7.0 — w3wp.exe.

В IIS 6.0 новые Web-узлы и приложения размещаются в одном пуле приложений. Этот пул приложений по умолчанию работает с учетной записью NetworkService. Администратор может вручную создавать новые пулы приложений и распределять Web-приложения по пулам. По умолчанию эти пулы приложений также работают с учетной записью NetworkService, что может привести к нежелательным последствиям во время выполнения, когда все Web-приложения функционируют с одинаковыми правами. Приложение в пуле A может прочитать конфигурацию пула приложений B и даже получить доступ к содержимому файлов приложений пула B. Достаточно просто создать новые пулы приложений и настроить для каждого специальные учетные записи, но управлять этими учетными записями в течение длительного времени утомительно.

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

В качестве дополнительной меры предосторожности можно изменить списки управления доступом ACL файлов с контентом, чтобы предоставить доступ к уникальному идентификатору SID пула вместо NetworkService. Это помешает приложению в пуле A прочитать файлы контента приложения в пуле B.

IUSR и IIS_IUSRS

С идентификацией процесса косвенно связан вопрос об удостоверении, используемом сервером для анонимных запросов. В прошлых версиях IIS в качестве удостоверения для анонимных пользователей применялась локальная учетная запись IUSR_servername. В IIS 7.0 появилась новая встроенная учетная запись IUSR. Нельзя выполнить локальную регистрацию с учетной записью IUSR, поэтому у нее нет пароля (то есть нет опасности отгадывания паролей). Учетная запись IUSR всегда имеет один и тот же идентификатор SID, поэтому списки управления доступом можно переносить между компьютерами Windows Server 2008 (а также компьютерами Windows Vista). Если применять учетную запись IUSR нельзя (например, если анонимным запросам требуется доступ к сети с проверкой подлинности), можно отключить учетную запись анонимного пользователя, и IIS 7.0 будет применять для анонимных запросов учетные данные рабочего процесса.

Еще одно новшество — встроенная группа IIS_IUSRS. Эта группа заменяет группу IIS_WPG. В IIS 6.0 группа IIS_WPG обеспечивает минимальные права для запуска рабочего процесса, и администратор должен вручную добавить в эту группу учетную запись, чтобы предоставить пользовательские учетные данные для рабочего процесса. В IIS 7.0 аналогичную роль играет группа IIS_IUSRS, но явно добавлять учетные записи в группу не требуется. Вместо этого IIS 7.0 автоматически зачисляет учетные записи в IIS_IUSRS, когда они назначаются в качестве удостоверения для пула приложений. Как и учетная запись IUSR, группа IIS_IUSRS — встроенная, поэтому у нее всегда одинаковое имя и идентификатор SID во всех экземплярах Server 2008. В результате списки управления доступом и другие настройки полностью переносимы между компьютерами Windows Server 2008 (и Vista).

Делегирование функций

Не каждую настройку Web-сервера нужно защищать административными правами. Некоторые настройки представляют собой простые решения уровня приложения, которые могут быть выполнены разработчиками и менеджерами продуктов. Например, в IIS 6.0 административные права необходимы, чтобы изменить документ по умолчанию для Web-приложения. Но действительно ли для замены default.aspx на profile.aspx всегда требуются административные права?

В IIS 7.0 решения о конфигурации можно делегировать владельцам сайта или приложения. В IIS 7.0 применяется новая система настройки на основе XML, созданная по образцу ASP.NET. На уровне сайта и приложения параметры конфигурации как IIS 7.0, так и ASP.NET находятся в одинаковых файлах web.config.

Делегированные настройки, такие как документ по умолчанию, можно изменить на уровне Web-узла или приложения, непосредственно изменив файл web.config, или из графического интерфейса пользователя IIS Manager (Экран 1), который обновляет web.config за администратора. В разделе system.webServer файла web.config содержатся параметры конфигурации IIS 7.0, как показано на Экране 2.

Нужные разделы определены в специальном файле конфигурации, именуемом applicationHost.config. У каждого раздела applicationHost.config есть режим делегирования по умолчанию. В примере на Экране 3 можно изменить документ по умолчанию и настройки просмотра каталогов, но не разделы asp, caching и cgi.

Как поступить, если существуют веские основания запретить владельцу Web-узла изменять документ по умолчанию? Решение простое: в IIS 7.0 можно блокировать элементы конфигурации, которые в результате нельзя назначить или изменить в файлах web.config. В случае с документом по умолчанию можно глобально изменить стандартный режим переназначения на Deny или явно установить режим переназначения Deny для конкретных мест с помощью тегов расположения. Группа разработчиков IIS предложила вводить такие изменения с помощью тегов расположения, как показано в Листинге 1. Делегирование функций очень удобно для перегруженных работой администраторов, так как позволяет наделить владельцев Web-узлов и приложений правом управлять теми настройками Web-сервера, которые влияют лишь на их сайты и приложения

Административное делегирование

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

В IIS Manager, как показано на Экране 4, пользователи могут подключиться к серверу IIS 7.0 с применением учетных данных Windows или учетных данных IIS Manager. Удобство учетных записей IIS Manager заключается в том, что они обеспечивают очень узкий и ограниченный набор прав для пользователя: административные права Web-узла IIS. Эти учетные данные вне IIS Manager бесполезны.

Для дистанционного использования имеется автономная версия IIS Manager для Windows Vista, Windows Server 2003 и XP. Прежде чем установить удаленное соединение в IIS Manager, необходимо явно разрешить дистанционное управление на Web Server:

Правила брандмауэра или политики удаленного доступа могут затруднить дистанционное использование инструментов. По этой причине IIS Manager работает через протокол HTTPS, одновременно безопасный и согласующийся с брандмауэрами. По умолчанию служба Web Management Service использует самозаверяющий сертификат и прослушивает порт 8172.

Компания Microsoft предоставляет IIS 7.0 Manager для дистанционного управления по адресу www.iis.net/go/1524. Дополнительные ресурсы (в том числе подробные инструкции по настройке) можно найти, выполнив поиск с ключевыми словами «IIS 7.0 remote administration» на сайте iis.net. На этом сайте Microsoft приведены дополнительные сведения о новых компонентах IIS.

Встроенный фильтр запросов

Многие администраторы IIS-серверов знакомы с UrlScan, загружаемым инструментом для IIS 4.0 и более поздних версий, который ограничивает типы запросов, обслуживаемых IIS. Цель фильтрации запросов — защитить Web-сервер от потенциально опасных запросов.

В IIS 7.0 инструмент UrlScan был усовершенствован и вошел в состав модуля фильтрации запросов Web-сервера. Модуль фильтрации запросов отвергает запросы на основе настраиваемого критерия. Например, модуль может отвергнуть запросы с двойным кодированием или запросы необычного размера (большой объем полезных данных POST или слишком длинные URL-адреса). Можно также отвергать запросы по типу файлов, пути или командам HTTP, не поддерживаемым на сайте.

Настройку фильтрации запросов в IIS 7.0 можно делегировать, предоставив администраторам сайтов возможность определить собственные правила фильтрации в файлах web.config, чего нельзя сделать с помощью UrlScan в IIS 6.0.

Авторизация URL


У Web-приложений часто есть области, доступ к которым предоставляется только определенным пользователям. Например, только менеджеру разрешено обращаться к отчетам о продуктивности сотрудников в системе управления кадрами. Страницы с ограничением обычно группируются в каталогах с такими именами, как Administration, Reporting или Moderation. В прошлых версиях IIS было довольно неудобно организовать надежную защиту этих разделов от несанкционированного доступа. Даже при использовании встроенной функции ASP.NET авторизации URL необходимо защитить такие данные, как файлы PDF и Excel, не подходящие для ASP.NET. Для управления правилами URL-авторизации ASP.NET приходится прибегать к утомительному процессу редактирования XML.

В IIS 7.0 сохранилась URL-авторизация ASP.NET, но в самом Web-сервере появилась дополнительная функция авторизации URL. Доступом к материалам любого типа (например, статическим, PHP, ASP) можно управлять по пользователям, группам и URL-адресам. Например, не составляет труда предоставить доступ ко всем объектам на пути Reporting только пользователям, принадлежащим к группе Managers, не затрагивая списков доступа к файлам. На Экране 5 показана конфигурация правил авторизации URL в IIS Manager.

Правила авторизации URL сохраняются в разделе system.webServer файлов web.config с синтаксисом, чуть отличным от правил авторизации ASP.NET, как показано в Листинге 2.

Поскольку правила авторизации целиком содержатся в файлах конфигурации (локальных web.config), их легко переносить между приложениями и серверами. А авторизация URL в IIS 7.0 применима к пользователям и группам Windows, так же, как к пользователям и ролям ASP.NET.

IIS совершенствуется

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

Об авторе: Дерек Хетчард (derek@ardentdev.com) — консультант и тренер, имеет звание Microsoft MVP

Листинг 1. Использование тегов расположения для назначения режима переназначения Deny

Каковы все учетные записи пользователей для IIS / ASP.NET и чем они отличаются?

под Windows Server 2008 с ASP.NET 4.0 установлен целый ряд связанных учетных записей пользователей, и я не могу понять, какой из них, как они отличаются, и какой из них действительно тот, под которым работает мое приложение. Вот список:

  • группу iis_iusrs
  • запись iusr
  • DefaultAppPool
  • ASP.NET v4.0
  • NETWORK_SERVICE
  • МЕСТНАЯ СЛУЖБА.

1 ответов

это очень хороший вопрос, и, к сожалению, многие разработчики не задают достаточно вопросов о IIS / ASP.NET security в контексте веб-разработчика и настройки IIS. Вот так.

чтобы покрыть перечисленные идентификаторы:

IIS_IUSRS:

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

IUSR:

этот счет аналогичен старому IUSR_ локальная учетная запись, которая была анонимным пользователем по умолчанию для веб-сайтов IIS5 и IIS6 (т. е. настроенная на вкладке Безопасность каталога свойств сайта).

подробнее о IIS_IUSRS и IUSR посмотреть:

DefaultAppPool:

если пул приложений настроен для запуска с помощью функции идентификации пула приложений, то «синтезированная» учетная запись называется IIS AppPool\

будет создан на лету, чтобы использовать в качестве удостоверения пула. В этом случае будет синтезированная учетная запись под названием IIS AppPool\DefaultAppPool создано на время жизни бассейна. Если вы удалите пул, эта учетная запись больше не будет существовать. При применении разрешений к файлам и папкам необходимо добавить с помощью IIS AppPool\

. Вы также не увидите эти учетные записи пула в Диспетчере пользователей компьютеров. Дополнительные сведения см. В следующем разделе:

ASP.NET v4.0:

это будет идентификатор пула приложений для ASP.NET v4.0 Пул Приложений. См. DefaultAppPool выше.

NETWORK SERVICE:

на NETWORK SERVICE учетная запись-это встроенный идентификатор представлен в Windows 2003. NETWORK SERVICE — это низко привилегированная учетная запись, под которой вы можете запускать пулы приложений и веб-сайты. Веб-сайт, работающий в пуле Windows 2003, все еще может олицетворять анонимную учетную запись сайта (IUSR_ или что бы вы ни настроили как анонимное удостоверение).

In ASP.NET до Windows 2008 вы могли бы иметь ASP.NET выполнение запросов под учетной записью пула приложений (обычно NETWORK SERVICE ). В качестве альтернативы вы можете настроить ASP.NET к олицетворение анонимной учетной записи сайта через настройка в web.config файл локально (если этот параметр заблокирован, то это должно быть сделано администратором в ).

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

в IIS7.x / ASP.Управление net impersonation теперь настроено через аутентификацию функция конфигурации сайта. Таким образом, вы можете настроить запуск в качестве идентификатора пула, IUSR или специального анонимного аккаунта.

LOCAL SERVICE:

на LOCAL SERVICE учетная запись-это встроенная учетная запись, используемая диспетчером управления службами. Она имеет минимальный набор привилегий на локальном компьютере. Он имеет довольно ограниченный объем использования:

LOCAL SYSTEM:

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

На Практике:

на практике предпочтительным подход к обеспечению безопасности веб-сайта (если сайт получает собственный пул приложений — что является значением по умолчанию для нового сайта в MMC IIS7) должен выполняться под Application Pool Identity . Это означает установку идентификатора сайта в расширенных настройках пула приложений в Application Pool Identity :

на веб-сайте вы должны затем настроить функцию аутентификации:

щелкните правой кнопкой мыши и отредактируйте анонимную аутентификацию запись:

обеспечить «удостоверение пула приложений» выбран:

когда вы приходите, чтобы применить права доступа к файлам и папкам, вы предоставляете удостоверение пула приложений, какие права требуются. Например, если вы предоставляете удостоверение пула приложений для ASP.NET v4.0 разрешения пула, то вы можете сделать это через Explorer:

нажмите Кнопка «Проверить имена»:

или вы можете сделать это с помощью ICACLS.EXE утилиты:

. или. если пул приложений сайта называется BobsCatPicBlog затем:

я надеюсь, это поможет прояснить ситуацию.

обновление:

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

ИТ База знаний

ShareIT — поделись знаниями!

Полезно

Узнать IP — адрес компьютера в интернете

Онлайн генератор устойчивых паролей

Онлайн калькулятор подсетей

Калькулятор инсталляции IP — АТС Asterisk

Руководство администратора FreePBX на русском языке

Руководство администратора Cisco UCM/CME на русском языке

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Похожие статьи

Оптимизация гипервизора Hyper-V

Про Google Password Checkup

Самое интересное про SMTP, POP3 и IMAP

Настройка DHCP сервера на CentOS или Ubuntu

Apache или IIS – сравнение и преимущества

Про веб — сервера

Если вы, или ваша организация намереваетесь создать Web – сервис, будь то сайт или приложение, то так или иначе вы обратите внимание на наиболее популярные на рынке платформы для создания web – серверов – Apache или Internet Information Services (IIS), которые занимают около 70% от всей доли интернета.

Многие сравнивают противостояние этих двух платформ как соперничество между Microsoft и Linux. В данной статье мы беспристрастно и объективно рассмотрим плюсы и минусы этих платформ.

Apache

Apache HTTP web – сервер – полное название платформы, распространяемой организацией Apache Software Foundation как открытое программное решение или проще говоря «open-source». Программное обеспечение сервера распространяется абсолютно бесплатно и его лицензия позволяет конечному пользователю редактировать исходный код, чтобы адаптировать Apache под свои нужды, а так же, внести вклад в будущее развитие серверной платформы.

Веб – сервер Apache может работать на всех популярных операционных системах, но чаще всего он используется в рамках Linux. Именно в паре с СУБД MySQL и PHP – скриптами образуется известный комплекс программного обеспечения LAMP Web – сервер (Linux, Apache, MySQL, PHP), который повсеместно используется в сети интернет.

В рамках исследования Netcraft, проводимого в феврале 2014 года, web – сервер Apache занимал 42% рынка. Однако стоит отметить, что в том же июне 2013 года этот показатель составлял 54% и 59% в 2010 году. Это связано с улучшением позиций основного конкурента IIS и ростом позиций Nginx.

С точки зрения функционала, Apache имеет впечатляющие характеристики. Многие функции реализуются как совместимые модули, расширяющие базовый функционал, диапазон которых варьируется от поддержки языков программирования до обеспечения различных схем аутентификации. Например, это могут быть языки Perl или Python. Модули аутентификации включают в себя элементы управления доступом к различным директориям сервера, пароль, установление подлинности и так далее. Многие другие функции, такие как Secure Sockets Layer (SSL) или TLS (Transport Layer Security) так же обеспечивается модульной системой. Помимо этого, Apache поддерживает возможность развернуть несколько web – сайтов, или графических интерфейсов приложений. Веб – сервер сжимает страницы, чтобы уменьшить их размер, что обеспечивает высокую скорость их загрузки. Наряду с высоким показателем безопасности, это является конкурентной чертой Apache.

Выделим два основных недостатка Apache HTTP web – сервера:

  • Перенасыщенность функционалом: Еще раз стоит подчеркнуть, что Apache действительно чрезвычайно богат на функции, возможности и инструментарий. Но, к сожалению, в рамках типовой инсталляции пользователь задействует только 10 % от этих функций.
  • С точки зрения архитектуры, Apache, работает по модели «процессов». Это означает, что для каждого соединения Apache выделяет отдельную «коннекцию», или другими словами поток данных, что вызывает значительную загрузку. Конкуренты, а именно асинхронные платформы и сервера работающие по модели «событий», имеют преимущество обработки нескольких процессов одновременно в рамках одной транзакции.

Internet Information Services (IIS) это веб – сервер разработки компании Microsoft и занимает второе место на рынке вслед за Apache. Платформа IIS будет работать только с Windows и поставляется в комплекте с этой операционной системы. В отличие от Apache, где основную поддержку продукта предоставляет сообщество разработчиков, IIS официально поддерживается компанией Microsoft. Разработка этого продукта не так стремительна по сравнению с Apache, но как было сказано выше, одним из главных конкурентных преимуществ IIS является официальная поддержка компании Microsoft, что очень важно для крупного бизнеса. Многие специалисты в области ИТ признают IIS одним из немногих коммерческих продуктов, который по настоящему может быть конкурентом «open-source» решению.

Постоянная доработка безопасности, производительности и удобства администрирования позволили увеличить долю присутствия на рынке IIS с 21% в 2010 году до 32% в феврале 2014 (ранее указанное исследование компании Netcraft). Самые большие продвижения были сделаны с точки зрения безопасности. Версия IIS 6.0 была уязвима к атакам: известный вирус Code Red, который заменял содержимое web – сайта на баннер об авторах вируса. Важно отметить, что многие уязвимости проявляются на уровне операционной системы.

Как и Apache, IIS использует различные расширения для внедрения дополнительного функционала. Например, работа с файлами по FTP, маршрутизация с помощью Application Request Routing (ARR), который позволяет вести балансировку нагрузки и повышать отказоустойчивость, различные медиа – компоненты, аудио, видео, динамическое изменение URL и прочие. Веб – сервер IIS предлагает более высокую совместимость с программной платформой .NET Framework и ASPX (Active Server Pages) чем Apache. Важно, что в IIS поддерживаются такие функции как мониторинг, отслеживание запросов в режиме реального времени. Конечно, IIS можно назвать «условно» бесплатным, так как распространяется он в комплекте с Microsoft Windows Server.

Илон Маск рекомендует:  Что такое код dngettext

С точки зрения производительности, IIS уступает Apache, в виду архитектурной особенности и строгой работы на Windows.

Подведем итог

И IIS и Apache имеют свои плюсы и минусы. Определиться с web – сервером поможет учет следующих факторов: Сервер IIS должен быть приобретен в комплекте с Windows, Apache не имеет официальной технической поддержки, но имеет высокие показатели безопасности, IIS отлично совместим с .NET и так далее. В таблице ниже приведены некоторые сравнительные характеристики:

Опция Apache IIS
Поддерживаемая ОС Windows, Linux, Unix, Mac OS Windows
Техническая поддержка Сообщество Корпоративная
Стоимость Полностью бесплатно Покупается в комплекте с Windows
Разработка «open-source» Проприетарное решение
Безопасность Хорошо Отлично
Производительность Хорошо Хорошо
Рынок 42% 32%
  • WEB сервер Apache
  • IIS
  • 5895
  • 83


Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас :( Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации :) Просто оставьте свои данные в форме ниже.

работа Построение веб-приложения на основе asp. Net и архитектуры сервера iis 0 — реферат

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»

ИНСТИТУТ МАТЕМАТИКИ И КОМПЬЮТЕРНЫХ НАУК

КАФЕДРА ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ

Построение веб-приложения на основе ASP.NET и архитектуры сервера IIS 7.0

Выполнил: студент 367 гр.

Введение

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

А что такое интернет без веб страниц и, соответственно, веб серверов?

Сейчас на рынке можно достаточно большое количество самых разных веб серверов. Один из наиболее распространенных – это Internet Information Server корпорации Microsoft. Учитывая последние тенденции к комплексным решениям Microsoft выпустила IIS 7.0, дающий разработчикам и администраторам новые возможности при создании и управлении сайтами.

В своей работе я ознакомился с новыми возможностями и применил их на практике.

Изучив возможности нового веб сервера, создать свой аутентификационный модуль для веб приложения.

Задачи:

1. Изучить новые возможности IIS 7.0

2. Познакомится с ASP.NET

3. Написать модуль аутентификации

Теоретическая часть

Безопасность в сети необходима, особенно если дело касается денег. Злоумышленники прибегнут к всевозможным ухищрениям лишь бы добраться до номера вашего банковского счета, логина и пароля в интернет-магазине. Данный проект написан на C# с применением технологии ASP.NET неслучайно. Существует множество готовых решений и предусмотренных классов для обеспечения безопасности соединения. Microsoft предлагает комплексные решения для многих задач. Продукты этой фирмы используются почти всеми, как в корпоративной сети, так и в обычной жизни. Интересующая нас задача — это создание и сопровождение полноценных защищенных веб приложений, таких как интернет магазин например.

Для создания безопасного веб-приложения необходимо полное понимание слабых мест в системе безопасности. Также необходимо ознакомиться с функциями обеспечения безопасности Windows, .NET Framework и ASP.NET. И, наконец, очень важно понимать способы использования этих функций безопасности для борьбы с угрозами.

Давайте рассмотрим поближе систему безопасности ASP.NET

Чтобы обеспечить безопасность веб-приложений, ASP.NET используется совместно с Microsoft .NET Framework и службами Microsoft Internet Information Services (IIS). Для создания безопасного приложения ASP.NET следует выполнить две основные функции:

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

· Авторизация (Ограничивает право доступа, предоставляя определенные разрешения или отказывая в них удостоверенной личности)

ASP.NET в сочетании со службами Microsoft Internet Information Services (IIS) может выполнять проверку подлинности учетных данных пользователя, например имен и паролей, используя любой из перечисленных ниже методов проверки подлинности:

· Windows: стандартная, шифрованная или встроенная проверка подлинности Windows (NTLM или Kerberos).

· Проверка подлинности в формах, в которых разработчик создает страницу входа и управляет проверкой подлинности в приложении.

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

Рассмотрим Архитектуру безопасности ASP.NET

Рис.1 Архитектура безопасности ASP.NET

Как показано на рисунке, все веб-клиенты взаимодействуют с приложениями ASP.NET с помощью служб IIS. При необходимости IIS проверяет подлинность запроса и затем определяет местонахождение запрошенного ресурса (например, приложение ASP.NET). Если клиент авторизован, ему предоставляется доступ к этому ресурсу.

Во время выполнения приложение ASP.NET может использовать встроенные средства безопасности ASP.NET. Кроме того, в приложении ASP.NET могут использоваться средства безопасности платформы .NET Framework.

Два стандартных стандартных сценария обеспечения безопасности: олицетворение(проверка подлинности Windows) и проверки подлинности с помощью форм с использованием файлов «cookies».

Олицетворение

Рис.2 Олицетворение. На рисунке показана следующая последовательность событий:

1. Запрос поступает в службы IIS от клиента сети.

2. Службы IIS проверяют подлинность клиента, используя стандартную, шифрованную или встроенную безопасность Windows (NTLM или Kerberos).

3. Если клиент проходит проверку подлинности, службы IIS передают удостоверенный запрос в ASP.NET.

4. Приложение ASP.NET олицетворяет клиент, выполняющий запрос, используя лексему доступа, переданную из IIS, и использует разрешения NTFS-файла для предоставления доступа к ресурсам. Приложение ASP.NET должно только проверить, что в файле конфигурации ASP.NET для олицетворения задано значение true ; код безопасности для ASP.NET писать не требуется. Если олицетворение не включено, приложение запускается с удостоверением процесса ASP.NET. Для Microsoft Windows 2000 Server и Windows XP Professional удостоверением по умолчанию является локальная учетная запись с именем ASPNET, которая создается автоматически при установке ASP.NET. Для Microsoft Windows Server 2003 удостоверением по умолчанию является удостоверение пула приложений для приложения IIS (по умолчанию учетная запись NETWORK SERVICE).

5. Если доступ разрешен, приложение ASP.NET возвращает запрошенный ресурс через IIS.

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

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

Рис.3 Проверка подлинности форм. На рисунке показана следующая последовательность событий:

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

2. Службы IIS получают запрос, и так как IIS разрешают анонимный доступ, они не выполняют никакой проверки подлинности пользователя и передают запрос приложению ASP.NET.

3. Так как ASP.NET использует режим поверки подлинности с помощью форм, приложение ASP.NET проверяет билет проверки подлинности на основе форм для запроса (отдельный файл «cookie»). Если к запросу не приложен билет проверки подлинности, ASP.NET перенаправляет запрос на страницу входа в систему, указанную в файле конфигурации приложения. На странице входа в систему пользователь вводит необходимые учетные данные, обычно имя и пароль. Код приложения проверяет учетные данные, чтобы подтвердить их подлинность. Если учетные данные проходят проверке подлинности, код приложения вкладывает билет проверки подлинности в ответ, который представляет учетные данные пользователя. (Пароль не включается). Если проверка подлинности не пройдена, ответ возвращается с сообщением об отказе в доступе, либо форма входа в систему представляется повторно.Выпущенный билет проверки подлинности включается в следующий запрос к приложению ASP.NET. ASP.NET проверяет допустимость использования билетом проверки подлинности сообщения (MAC).

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

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

IIS 7.0 Особенности

В основе выпуска IIS 7.0 лежит полностью модульный веб-сервер, включающий более 40 компонентов, которые можно объединять в компактные веб-серверы, оптимизированные для необходимой роли в топологии приложения. Эти компоненты создаются на основе нового слоя расширяемости, что позволяет разработчикам расширять или замещать практически любую функцию сервера в машинном коде или с помощью Microsoft® .NET Framework. IIS 7.0 предлагает расширяемость компонентов этапа выполнения, управления и рабочих компонентов, облегчая создание комплексных решений в соответствии с конкретными потребностями. На базе основной платформы IIS 7.0 берется за решение многих проблем, связанных с управляемостью и эксплуатацией сервера. Он обладает принципиально новой системой настройки, обеспечивающей полностью делегированное управление узлами и, в конечном итоге, делающей реальностью развертывание веб-приложений с использованием xcopy. Новые интерфейсы API для целей управления и диагностические компоненты делают процедуры развертывания, администрирования и устранения неполадок сервера значительно проще и удобнее, чем когда-либо прежде.

IIS 7.0 разбивает веб-сервер на небольшое ядро сервера и более чем 40 модулей компонентов, подключаемых к этому ядру. Эти модули — такие, как StaticFileModule, который позволяет загружать статическое веб-содержимое, или WindowsAuthModule, поддерживающий встроенную проверку подлинности NTLM, — можно устанавливать на сервере независимо, чтобы обеспечить именно те функциональные возможности, которые необходимы.

Эти модули можно в любое время полностью удалить с сервера или намеренно отключить на время работы конкретного приложения, которому они не требуются. Такая возможность позволяет администраторам сервера быстро развертывать серверы минимальной конфигурации со значительным уменьшением мест, доступных для атак, и существенным увеличением производительности за счет выполнения только необходимого кода. Архитектура, построенная из независимых компонентов, является важнейшим свойством IIS 7.0, ведущим к снижению рисков нарушения безопасности и минимизации необходимости вносить исправления. Она делает возможными специализированные развертывания сервера, для которых объединяются выбранные компоненты IIS и специальные составляющие, оптимизированные для конкретной роли сервера в топологии приложения, например, обратных прокси и кэширующих серверов, серверов балансировки нагрузки протокола HTTP или SSL и серверов безопасности Sentinel.

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

Упрощенное развертывание и настройка

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

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

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

В полном соответствии основной идее IIS 7.0 система настройки является полностью расширяемой. Новые модули могут добавлять собственные схемы настройки, позволяя приложениям настраивать свои компоненты наряду с настройкой IIS и ASP.NET:

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

IIS 7.0 продолжает поддерживать существующий код настройки, использующий для записи в традиционную метабазу интерфейсы API объекта ABO (Admin Base Object) или сценарии, использующие интерфейсы высокого уровня ADSI (Active Directory® Service Interfaces) и объекты WMI (Windows Management Instrumentation) для настройки IIS. Это достигается посредством предоставления слоя совместимости, который эмулирует интерфейсы API объектов ABO, являющиеся основой для всех других традиционных интерфейсов API настройки, позволяя таким сценариям читать и изменять настройку тем же способом, как они делали это в предыдущих версиях IIS. В то время как новый формат настройки с использованием структурированного XML облегчает работу с конфигурацией в привычном текстовом редакторе, IIS предоставляет администраторам также узел с инструментами управления и интерфейсы API, облегчающие управление сервером и делающие возможной автоматизированную настройку и развертывание.

.NET Framework и создание сценариев

Кроме администрирования сервера вручную с помощью IIS Manager или инструмента командной строки appcmd.exe IIS 7.0 предоставляет множество возможностей программного администрирования. Во-первых, можно использовать интерфейс API Microsoft.Web.Administration для управления сервером из приложений .NET. Или использовать новый интерфейс API COM для непосредственного управления системой настройки IIS, либо получить к ней доступ из среды создания сценариев, например ASP или Windows® Script Host (WSH). Существует также новый поставщик WMI и поддержка традиционных поставщиков WMI и ADSI посредством слоя совместимости метабазы.

Microsoft.Web.Administration, новый интерфейс API администрирования .NET, облегчает приложениям управляемого кода обеспечивать программную поддержку узлов и приложений IIS, получать доступ к важной информации о состоянии и диагностическим данным и изменять настройку сервера. Способность приложений на основе .NET Framework беспрепятственно получать доступ к информации о настройке IIS и данным о состоянии открывает необъятный простор для написания приложений настройки с использованием .NET и управляющих приложений или даже выполнения задач управления непосредственно из страниц ASP.NET.

Создание компонентов веб-сервера

IIS 7.0 дает возможность сформировать сервер в соответствии с конкретными потребностями, позволяя добавлять или заменять в сервере любой компонент для обеспечения требуемого набора функций. В основе этой возможности лежит совершенно новый интерфейс расширяемости веб-сервера, на основе которого создаются все существующие компоненты HTTP IIS 7.0. Этот интерфейс API является открытым, что означает возможность реализации любого из компонентов, поставляемых с IIS 7.0. Для IIS это самое важное и фундаментальное усовершенствование по сравнению с предыдущей ограниченной моделью расширяемости ISAPI.

Новый интерфейс расширяемости представляет собой набор интуитивных классов C++, определяющих объектную модель и дающих возможность модулю предоставлять службы обработки запросов на IIS. Эти классы определяются в заголовочном файле в Windows Vista SDK.

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

· Проверка запроса с помощью класса IHttpRequest

· Управление откликом с помощью класса IHttpResponse

· Использование полезных функций служебных программ класса IHttpServer

· Обеспечение проверки подлинности с помощью класса IHttpUser

· Получение доступа к разделу пользовательской настройки вашего модуля с помощью интерфейсов API настройки

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

Разработчики получат преимущество также благодаря усовершенствованным шаблонам для управления памятью и состоянием. Большинство интерфейсов API сервера IIS 7.0 используют для возвращаемых данных память, управляемую сервером, вместо запроса на выделение буферов и управления ими, как это делает ISAPI и большинство существующих интерфейсов API в Win32®. В прошлом это был один из наиболее подверженных ошибкам и утомительных этапов разработки ISAPI. Новый интерфейс API упрощает также многие сложные задачи обработки запросов, например, буферизацию отклика, проверку подлинности и подготовку данных отклика для клиента

Интеграция ASP.NET

В составе сервера IIS 7.0 ASP.NET приходит в двух версиях: Режим Classic и режим Integrated Режим Classic работает точно так же, как он работал в предыдущих версиях IIS. Режим Integrated, являющийся платформой по умолчанию, использует совершенно новый обработчик для обеспечения интеграции высочайшего уровня с веб-сервером IIS. В режиме Integrated интерфейсы API ASP.NET можно использовать для разработки модулей IIS 7.0, которые напрямую интегрируются с веб-сервером и в состоянии предоставлять практически все возможные службы благодаря лежащему в основе интерфейсу API на C++,.

По существу, это оптимальный вариант — знакомые интерфейсы и удобные службы приложений .NET Framework и ASP.NET 2.0, такие, как управление членством и ролями, плюс неограниченная возможность расширения сервера, ранее доступная только составляющим ISAPI, написанным на C.

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

Рис 4. Жизненный цикл ASP.NET

Для разработчиков ASP.NET преимущества интегрированного конвейера заключаются в следующем:

  • Интегрированный конвейер может вызывать все события, объявленные в объекте HttpApplication, что позволяет существующим HTTP-модулям ASP.NET работать в интегрированном режиме IIS 7.0.
  • И модули машинного кода, и модули управляемого кода можно настраивать на уровне веб-сервера, веб-узла и веб-приложения. Это относится и к встроенным модулям управляемого кода ASP.NET для управления состоянием сеанса, проверкой подлинности форм, профилями и ролями. Более того, поддержку модулей управляемого кода можно включить или отключить для всех запросов, независимо от того, предназначен ли запрос для ресурса ASP.NET, например ASPX-файла.
  • Модули управляемого кода можно вызывать на любом этапе конвейера. Это можно сделать до обработки запроса на сервере, после обработки на сервере или в любой момент во время обработки.
  • Регистрация, включение и отключение модулей выполняется в файле Web.config приложения.


Модули управляемого кода в службах IIS 7.0

  • FormsAuthenticationModule
  • ProfileModule
  • RoleManagerModule
  • SessionStateModule

Разработка настраиваемых модулей управляемого кода

Жизненный цикл приложения ASP.NET можно расширить с помощью модулей, в которых реализован интерфейс IHttpModule. Модули, в которых реализован интерфейс IHttpModule, являются модулями управляемого кода. Интегрированный конвейер ASP.NET и IIS 7.0 также можно расширить с помощью модулей машинного кода, которые в данном разделе не рассматриваются. Модуль управляемого кода можно задать как файл класса в папке App_Code приложения. Также можно создать модуль как проект библиотеки классов, скомпилировать его и добавить в папку Bin приложения. После создания настраиваемого модуля его необходимо зарегистрировать с помощью IIS 7.0. Для управления модулями управляемого кода IIS 7.0 можно воспользоваться одним из описанных ниже методов. Например, чтобы зарегистрировать модуль управляемого кода только для одного приложения, можно изменить файл Web.config этого приложения. Если модуль находится в папке App_Code или Bin и зарегистрирован в файле Web.config приложения, этот модуль вызывается только для этого приложения. Чтобы зарегистрировать модуль Web.config приложения, необходимо изменить элемент modules в разделе system.webServer . Изменения, внесенные с помощью IIS Manager или средства Appcmd.exe, вносятся в файл Web.config приложения.

Модули управляемого кода также можно зарегистрировать в элементе modules хранилища конфигурации IIS 7.0 (файл ApplicationHost.config). Модули, зарегистрированные в файле ApplicationHost.config, обладают глобальной областью действия, поскольку они зарегистрированы для всех веб-приложений, размещенных с помощью служб IIS 7.0. Модули машинного кода, заданные в элементе globalModules файла ApplicationHost.config, также обладают глобальной областью действия. Если глобальный модуль в веб-приложении не используется, его можно отключить.

Практическая часть

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

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

Модуль реализован с применением стандартного класса IHttpModule.

public class userAuth : IHttpModule

public void Init(HttpApplication app)

app.AuthenticateRequest += new EventHandler(this.Authorize);

При каждом обращении к странице возникает событие AuthenticateRequest, на которое модуль реагирует обработчиком события Authorize

public void Authorize(Object source, EventArgs e)

HttpApplication application = (HttpApplication)source;

Улучшение безопасности IIS

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

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

На рынке существуют различные продукты, которые, как утверждается, могут сделать ваш сервер более защищенным, но не ограждают от всех возможных видов атак. Существует весьма распространенное заблуждение о том, что безопасность веб-сайта можно улучшить посредством ревизии исходного кода. Это не всегда соответствует действительности. Помимо написания безопасного кода, сайт, созданный средствами ASP.NET, следует также надежно защитить со стороны IIS-сервера. В этой статье будут различные аспекты безопасности IIS, чтобы оградить ваш сайт от незаконного проникновения.

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

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

Более того, некоторые хакеры осуществляют так называемые «пассивные» атаки, следы от которых обнаружить еще сложнее. Во время пассивной атаки злоумышленник вообще не предпринимает никаких действий, а просто наблюдает за тем, что происходит в системе. Таким образом, детектирование, предупреждение и противодействие подобного рода атакам может быть затрудненно в особенности там, где работают неграмотные администраторы или плохо проработана политика безопасности.

По сути, IIS представляет собой набор различных WWW-служб, обрабатывающих запросы, которые поступают на различные TCP/IP порты (например, за 80-м портом обычно закреплен протокол HTTP). Перед тем как до ASP.NET дойдут запросы, происходит верификация (аутентификация, авторизация и т. д.) в соответствии с настройками IIS. В IIS есть различные возможности (см. рисунок ниже) для ограничения доступа и запрета некоторых типов запросов.

Рисунок 1: Средства безопасности в IIS

Регулирование прав доступа

IIS позволяет выборочно запрещать или разрешать доступ к файлам, папкам, сайту или серверу. Системный администратор может определять, какой удаленный компьютер может подключаться к IIS, а какой нет. В отношении каждого IP-адреса или DNS-имени можно настроить отдельные ограничительные правила. Допустим, если в коде на ASP.NET есть уязвимость, то, по сути, злоумышленник имеет неограниченный доступ к веб-сайту. Однако если выставить запрет на доступ со стороны IIS, появится следующее сообщение ‘Forbidden: IP address of the client has been rejected (403.6)’ или ‘DNS name of the client is rejected (403.8)’. Соответствующий HTTP-статус будет отражен в журнале. В связи с ограничением прав существуют два термина, касающиеся настройки IIS: IP Restriction и Domain Restriction.

Запрет на соединение предпочтительнее конфигурировать на как можно более низком уровне в модели OSI.

Чтобы сконфигурировать политику относительно DNS для разрешения доступ всем, кроме специально указанных адресов, кликните на ‘Edit Feature Settings’. Появится окно ‘IP Address and Domain Restrictions’.

Рисунок 2: Запрет на доступ определенным клиентам

Затем вы можете создать правила для определенных хостов или подсетей. Чтобы создать правило, разрешающее доступ для конкретного клиента или подсети, кликните на “Allow Entry” и укажите отдельный IP-адрес или диапазон IP-адресов.

Рисунок 3: Разрешение на доступ определенным хостам

MIME предотвращает хранение на сервере неизвестных типов файлов и позволяет загружать только те файлы, которые указаны явным образом. Хотя конфигурационные и информационные файлы обычно не хранятся в корневой директории, если злоумышленник попытается загрузить файл, не разрешенный в настройках, возникнет ошибка 404.3 и HTTP-статус запишется в лог. Если вы хотите разрешить загрузку определенных типов файлов, добавьте новый MIME type, как показано на рисунке ниже.

Рисунок 4: Добавление нового MIME type

IIS позволяет настраивать наборы правил для разрешения и запрета определенных типов запросов. Фильтрация позволяет пропускать запросы для определенного пространства имен и жестко интегрирована в систему журналирования событий. Запросы могут фильтроваться по параметрам HTTP-заголовка, расширениям файлов, размеру запроса и подстроке, входящей в URL.

При фильтрации по параметрам HTTP-заголовка в секции «verbs», например, можно разрешить только GET- или POST-запросы. Следующий набор XML-тегов как раз позволяет отфильтровать HTTP-заголовок по типу запроса (необходимо добавить этот код в конфигурационный файл):

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

Запрос также может быть отклонен при превышении определенного размера запроса.

И последний пример, в котором запросы фильтруются на основе подстрок (в данном случае – «. .»), входящих в URL.

Настройка пула приложений

Когда необходимо получить информацию из внешнего источника, может возникнуть конфликт, поскольку довольно сложно разделить между собой пулы веб-приложений. Иначе говоря, код, запущенный внутри одного пула, будет влиять на работоспособность другого пула. Чтобы в некоторой степени предотвратить этот конфликт, в IIS предусмотрена настройка пула приложений. Каждый пул приложений имеет свой конфигурационный файл, которых хранится в папке %systemdriver\inetpub\temp\appPools, и дополнительный идентификатор безопасности (SID), инжектируемый в соответствующий процесс w3wp.exe. Соответственно, каждый конфигурационный файл пула закреплен за своим SID’ом через права доступа.

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

Рисунок 5: Добавление пула приложений

Используя ISAPI, разработчики часто пишут дополнительные модули, чтобы расширить функционал сервера во время запроса определенного типа файла. Например, сайты на PHP могут работать на IIS-сервере при помощи расширения PHP ISAPI. Соответственно, сайты на ASP.NET (или файлы .aspx) по умолчанию привязаны к расширению ASP.NET ISAPI. Когда клиент запрашивает файл с расширением .aspx, дальнейшая обработка происходит через расширение IIS ISAPI, которое уже определяет, какие дополнительные действия должны быть предприняты.

В IIS можно запретить или разрешить те или иные расширения ISAPI. Если расширение запрещено, при запросе файла соответствующего типа в лог заносится статус 404.2, поскольку злоумышленник может удаленно внедрить и выполнить вредоносный код. После добавления новых расширений в дальнейшем необходимо провести аудит безопасности сервера. Чтобы добавить расширение, укажите имя фильтра и путь к библиотеке DLL.

Рисунок 6: Добавление нового расширения

Хакеры часто проводят DOS-атаки, отправляя на сервер огромные запросы, что в свою очередь может сказаться на размере логов. При помощи логов, например, можно выявить факты неправомерного доступа. В ОС Windows имеет встроенная функция записи в журнал важной информации: время авторизации, попытки подбора пароля и т. д., что является одним из признаков атаки. Для каждого сайта можно настроить систему фиксации событий в формате W3C.

Рисунок 7: Настройка логов

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

Настройка страниц ошибок

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

Рисунок 8: Неудачный пример страницы с ошибкой

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

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

Рисунок 9: Настройка страниц ошибок

Даже после грамотной настройки IIS не следует забывать о безопасности приложений. В последнее время много внимания уделяется уязвимостям в веб-приложениях: SQL-инъекциям, межсайтовому скриптингу, воспроизведению сессий (session replay), RFI и многим другим. С каждым днем злоумышленники становятся все более изощренными. Таким образом, свои позиции следует защищать со всех фронтов.

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

Подписывайтесь на каналы «SecurityLab» в Telegram и Яндекс.Дзен, чтобы первыми узнавать о новостях и эксклюзивных материалах по информационной безопасности.

Базовые сведения об IIS

Структура каталогов IIS

Основные компоненты IIS расположены в каталоге %systemroot%\System32\inetsrv . Структура каталогов inetsrv показана в следующей таблице.

Каталог Описание
ASP Compiled Templates Содержит используемый шаблон ASP.
History Содержит историю изменений метабазы, позволяющую выполнять откат изменений в метабазе.
iisadmpwd Содержит ASP-страницы, относящиеся к аутентификации IIS Admin.
MetaBack Каталог по умолчанию для резервных файлов метабазы.

Примечание. Более подробная информация о метабазе приведена в разделе «Метабаза» далее в лекции.

Веб-сайт администрирования

В IIS 6 веб-сайт администрирования позволяет управлять всем сервером Windows из локального или удаленного веб-браузера. Веб-сайт администрирования располагается в каталоге %systemroot%\System32\ServerAppliance . Он функционирует через SSL, используя порт 8098 по умолчанию. Для доступа к веб-сайту администрирования введите в строке адреса браузера https://имя_компьютера:8098 (где имя_компьютера представляет собой имя компьютера, который необходимо администрировать).

Файлы справки IIS

Все файлы справки IIS 6 перемещены в централизованное место расположения вместе с остальными файлами справки Windows. Это папка %systemroot%\help\iishelp . Самым простым способом вызова справки IIS является выбор команды Help/Help Topics (Справка/Вызов справки) в консоли MMC.

Каталог Inetpub

Каталог Inetpub является основным каталогом файлов IIS. В нем расположены каталоги с содержимым каждой установленной службы. Путь по умолчанию для каталога Inetpub – C:\Inetpub .

Каталог Inetpub содержит следующие подкаталоги.

Каталог Описание
AdminScripts Содержит сценарии Visual Basic, используемые для администрирования сервера IIS.
ftproot Каталог верхнего уровня службы FTP.
mailroot Каталог верхнего уровня службы SMTP.
nntpfile Каталог верхнего уровня службы NNTP.
wwwroot Каталог верхнего уровня веб-сайта по умолчанию.

Учетные записи, используемые в IIS

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

IUSR_COMPUTERNAME

Учетная запись обеспечивает анонимный доступ к веб-сайту при подключении пользователя к веб-странице без представления входных данных. Такой пользователь по умолчанию является членом группы Guest (Гость).

IWAM_COMPUTERNAME

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

IIS_WPG

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

Эти процессы можно просмотреть в консоли MMC Computer Management (Управление компьютером) панели Administrative Tools (Администрирование). Для открытия списка Users and Groups (Пользователи и группы) выполните следующие действия.

  1. В меню Start (Пуск) выберите Administrative Tools\ Computer Management (Администрирование\Управление компьютером).
  2. Список пользователей и групп содержится в окне Local Users and Groups (Локальные пользователи и группы) консоли Computer Management (Управление компьютером).
  3. Если компьютер является контроллером домена, список пользователей и групп располагается в окне Active Directory Users And Computers (Компьютеры и пользователи Active Directory) панели Administrative Tools (Администрирование).


Для управления IIS служит оснастка MMC . MMC представляет собой универсальное средство, позволяющее сохранять единую структуру и внешний вид приложений. Для управления IIS 6 используется оснастка IIS . Консоль IIS MMC расположена в окне Start\Administrative Tools (Пуск\Администрирование).

Консоль Microsoft Management Console

С помощью оснастки IIS Manager (или MMC) (см. рис. 1.2) осуществляется управление FTP-сайтами, наборами приложений, веб-сайтами, виртуальными серверами SMTP и NNTP на данном компьютере или на той машине, с которой установлено соединение. По умолчанию соединение установлено с локальным компьютером. Для подключения другого компьютера щелкните правой кнопкой мыши на имени локального компьютера и выберите команду Connect (Подключить).

Управление сайтом с помощью MMC

В верхней части окна IIS Manager (Диспетчер IIS) находится панель инструментов, с помощью которой на сайте выполняются основные функции. Над панелью инструментов располагается строка меню, содержащая команды управления. Нужно помнить, что MMC представляет собой отдельную программу, и что не все опции в ней связаны с IIS. Некоторые опции предназначены для настройки компонентов MMC. Вид панели инструментов и меню изменяется в зависимости от выбора объекта в левой области окна IIS Manager.

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

Свойства локального компьютера. Свойства локального компьютера позволяют изменять параметры, глобально влияющие на все компоненты IIS. Для открытия окна свойства локального компьютера щелкните правой кнопкой мыши на имени_компьютера (локального компьютера) в окне IIS MMC, затем выберите Properties (Свойства). Отобразится окно Properties (см. рис. 1.3).

Изменение любых параметров в этом окне требует последующего перезапуска IIS. На IIS в целом здесь влияют два параметра: Enable Direct Metabase Edit (Включить прямое изменение метабазы) и Encode Web Logs In UTF-8 (Использовать для веб-журналов кодировку UTF-8).

Параметр Enable Direct Metabase Edit (Включить прямое изменение метабазы) позволяет редактировать метабазу при работе IIS. В предыдущих версиях IIS метабаза представляла собой исполняемый файл, доступ к которому был возможен только при помощи специальной утилиты из пакета инструментальных средств. Теперь этот файл можно редактировать в программе Notepad (Блокнот), так как он представлен в формате XML (Расширяемый язык разметки). Можно помещать конфигурацию в буфер и вставлять ее из буфера, сохранять конфигурацию, причем изменения будут вступать в силу незамедлительно. Данный способ работы требует включения журнала метабазы, но так как это является установкой по умолчанию, то никаких вопросов возникать не должно.

Опция Encode Web Logs In UTF-8 (Использовать для веб-журналов кодировку UTF-8) указывает, что в журналах веб и/или FTP должна использоваться кодировка UTF-8, а не локальный набор символов. UTF-8 представляет собой стандарную кодировку текста с восьмибитным кодированием символов Unicode. Для представления каждого символа требуется от одного до шести октетов. UTF-8 использует универсальный набор символов и поддерживает ASCII-текст для совместимости с прежними версиями.

What are all the user accounts for IIS/ASP.NET and how do they differ?

Under Windows Server 2008 with ASP.NET 4.0 installed there is a whole slew of related user accounts, and I can’t understand which one is which, how to they differ, and which one is REALLY the one that my app runs under. Here’s a list:

  • IIS_IUSRS
  • IUSR
  • DefaultAppPool
  • ASP.NET v4.0
  • NETWORK_SERVICE
  • LOCAL SERVICE.

1 Answer 1

This is a very good question and sadly many developers don’t ask enough questions about IIS/ASP.NET security in the context of being a web developer and setting up IIS. So here goes.

To cover the identities listed:

IIS_IUSRS:

This is analogous to the old IIS6 IIS_WPG group. It’s a built-in group with it’s security configured such that any member of this group can act as an application pool identity.

IUSR:

This account is analogous to the old IUSR_ local account that was the default anonymous user for IIS5 and IIS6 websites (i.e. the one configured via the Directory Security tab of a site’s properties).

For more information about IIS_IUSRS and IUSR see:

DefaultAppPool:

If an application pool is configured to run using the Application Pool Identity feature then a «synthesised» account called IIS AppPool\

will be created on the fly to used as the pool identity. In this case there will be a synthesised account called IIS AppPool\DefaultAppPool created for the life time of the pool. If you delete the pool then this account will no longer exist. When applying permissions to files and folders these must be added using IIS AppPool\

. You also won’t see these pool accounts in your computers User Manager. See the following for more information:

ASP.NET v4.0:

This will be the Application Pool Identity for the ASP.NET v4.0 Application Pool. See DefaultAppPool above.

NETWORK SERVICE:

The NETWORK SERVICE account is a built-in identity introduced on Windows 2003. NETWORK SERVICE is a low privileged account under which you can run your application pools and websites. A website running in a Windows 2003 pool can still impersonate the site’s anonymous account (IUSR_ or whatever you configured as the anonymous identity).

In ASP.NET prior to Windows 2008 you could have ASP.NET execute requests under the Application Pool account (usually NETWORK SERVICE ). Alternatively you could configure ASP.NET to impersonate the site’s anonymous account via the setting in web.config file locally (if that setting is locked then it would need to be done by an admin in the machine.config file).

Setting is common in shared hosting environments where shared application pools are used (in conjunction with partial trust settings to prevent unwinding of the impersonated account).

In IIS7.x/ASP.NET impersonation control is now configured via the Authentication configuration feature of a site. So you can configure to run as the pool identity, IUSR or a specific custom anonymous account.

LOCAL SERVICE:

The LOCAL SERVICE account is a built-in account used by the service control manager. It has a minimum set of privileges on the local computer. It has a fairly limited scope of use:

LOCAL SYSTEM:

You didn’t ask about this one but I’m adding for completeness. This is a local built-in account. It has fairly extensive privileges and trust. You should never configure a website or application pool to run under this identity.

In Practice:

In practice the preferred approach to securing a website (if the site gets its own application pool — which is the default for a new site in IIS7’s MMC) is to run under Application Pool Identity . This means setting the site’s Identity in its Application Pool’s Advanced Settings to Application Pool Identity :

In the website you should then configure the Authentication feature:

Right click and edit the Anonymous Authentication entry:

Ensure that «Application pool identity» is selected:

When you come to apply file and folder permissions you grant the Application Pool identity whatever rights are required. For example if you are granting the application pool identity for the ASP.NET v4.0 pool permissions then you can either do this via Explorer:

Click the «Check Names» button:

Or you can do this using the ICACLS.EXE utility:

. or. if you site’s application pool is called BobsCatPicBlog then:

I hope this helps clear things up.

Update:

I just bumped into this excellent answer from 2009 which contains a bunch of useful information, well worth a read:

IIS 7.0 Построение решений веб-сервера с использованием сквозной расширяемости

Веб-платформа IIS 7.0 поддерживает большее число технологий инфраструктуры приложений для размещения многофункциональных приложений, чем любая предыдущая версия IIS, она буквально напичкана функциями, которые можно использовать для развертывания этих приложений сразу же после установки. Однако в то же время вы видите (в установке Windows®) не обязательно то, что всегда получаете.
Архитектура IIS 7.0 выполнена таким образом, что позволяет ей быть расширяемой сверху донизу, это дает возможность заменять любую часть встроенного набора функций на собственные разработки, которые наилучшим образом соответствуют вашим требованиям. В результате этого вместо латания лоскутного одеяла из подключаемых модулей IIS 7.0 дает совершенно уникальные возможности по расширяемости путем реализации всех собственных функций поверх общедоступной модели расширяемости. Эта конструкция прослеживается по всей платформе, начиная от самого модульного механизма веб-сервера и до системы настройки консоли диспетчера IIS.
В этой статье я постараюсь погрузиться в тонкости модели расширения IIS 7.0, рассмотрев для этого исходный код общего пользования проекта модуля изменения ответа, который позволяет получать отклики приложений IIS и изменять их «на лету», используя для этого настраиваемые правила изменения откликов. Вначале я построю модуль веб-сервера, воспользовавшись встроенной в сервервозможностью расширения ASP.NET. Затем я создам функции развертывания и управления для модуля, разработав раздел пользовательской настройки и создав специальную страницу управления для диспетчера IIS.

Расширение веб-сервера

Модульная архитектура IIS 7.0 предоставляет возможность полностью перестроить веб-сервер под требуемую рабочую нагрузку. Зачастую это может быть выполнено просто путем установки только тех функций, которые необходимы для вашего приложения, в результате чего появляется веб-сервер с урезанной функциональностью, позволяющей делать только то, что необходимо, и ничего более.
Однако это только первый шаг. Зачастую нужная рабочая нагрузка требует наличия дополнительных функций, которые могут не входить во встроенный набор функций IIS. Или же в некоторых случаях приложениям может потребоваться специальный набор функций, для выполнения которых встроенные функции недостаточно приспособлены. Поскольку все функции IIS 7.0 построены на общедоступных интерфейсах расширяемости API, вы можете заменить любой из них собственной разработкой, которая наилучшим образом соответствует вашим требованиям.
IIS 7.0 предоставляет два способа разработки модулей веб-сервера. Во-первых, можно использовать новый интерфейс API для модулей на C++, на котором основана большая часть встроенных функций. Интерфейс API модулей заменяет расширение ISAPI и интерфейс API фильтра, применявшиеся в предыдущих версиях IIS. Этот интерфейс API является существенным усовершенствованием по сравнению с ISAPI, поскольку он способен поддерживать все функции IIS 7.0 и гораздо проще для использования в программировании. Узнать подробней об усовершенствованиях в этом интерефейсе API можно по адресу: mvolo.com/blogs/serverside/archive/2006/10/07/10-reasons-why-server-development-is-better-with-IIS7.aspx.
Во-вторых, в IIS 7.0 введена интеграция с ASP.NET, которая позволяет разрабатывать модули IIS 7.0 с использованием хорошо знакомых интерфейсов API модулей в ASP.NET. В объединенном режиме ASP.NET эти модули становятся полноправными участниками конвейерной обработки запросов IIS, как видно из рис. 1. Это позволяет модулям ASP.NET получать доступ ко встроенным объектам IIS, таким как запросы и ответы, на всех стадиях обработки и обрабатывать запросы для всех типов ресурсов — не только для тех, которые обрабатываются платформой ASP.NET.

Рис. 1 Модули ASP.NET в обработке запросов IIS 7.0

Это позволяет использовать одинаково по всему веб-узлу такие многосторонние функции ASP.NET, как проверка подлинности на основе форм, элементы управления входом в систему и служба членства. Для более подробного изучения того, как объединенный режим ASP.NET может быть использован с целью повышения функциональных возможностей приложений, написанных не для платформы ASP.NET, прочтите мою статью в январском номере журнала MSDN® Magazine за 2008 год, расположенную по адресу: msdn.microsoft.com/msdnmag/issues/08/01/PHPandIIS7.
Для разработчиков истинная ценность объединенного режима ASP.NET заключается в возможности наращивать функциональность веб-сервера IIS с использованием платформы Microsoft® .NET Framework. Это дает существенные преимущества при быстрой разработке приложений путем обеспечения возможности строить эти приложения на основе широкой поддержки платформ .NET Framework, ASP.NET, а также других платформ, таких как Windows Workflow Foundation.

Модуль изменения ответа

Объединенный конвейер ASP.NET дает возможность модулям ASP.NET выполнять широкий спектр задач в ходе обработки каждого запроса. Этот спектр содержит все, начиная от задач проверки подлинности или авторизации и до изменения исходящих ответов перед их отправкой клиенту.
Назначением модуля изменения ответа является выполнение изменения ответа: он позволяет изменять существующие ответы «на лету» при помощи набора правил замены. Для этого можно использовать механизм фильтрации ответов ASP.NET, который, благодаря объединения со средой выполнения, обеспечивает фильтрацию исходящих ответов любого содержания, включая статические файлы, а также сценарии ASP и PHP.
Если в прошлом вы разработали модуль ASP.NET, то вас, несомненно, обрадует тот факт, что вы сможете использовать те же интерфейсы API для разработки модулей ASP.NET на платформе IIS 7.0. Фактически, имеющиеся у вас модули продолжают работать точно так же, как они работали в предыдущих версиях IIS (если только не нужно использовать преимущества объединенного режима IIS 7.0 и запускать их для обработки всех запросов). Модуль является классом, реализующим интерфейс System.Web.IHttpModule и регистрирующим обработчики событий для событий конвейерной обработки одного или нескольких запросов. Модуль изменения ответов именно такой:

По существу, модуль подписывается на событие PreRequestHandlerExecute, которое происходит всякий раз перед выполнением обработчика запроса. Метод OnPreRequestHandlerExecute используется для чтения сведений настройки с целью определить, имеет ли ответ какие-нибудь применимые для него правила замены (подробнее о настройке — далее в этой статье), и в случае наличия таковых регистрировать поток фильтра ответов, который затем будет использован для фильтрации исходящих ответов, как показано на рис. 2.
Figure 2 Фильтр ответов

Фильтрация ответов выполняется внутри класса ChainedBufferedStringResponseFilter, который отвечает за преобразование байтов ответов в строку при помощи набора символов ответов, а также за вызов одного или несколько фильтров ответов, которые применимы к данному запросу. Модуль связывает фильтр с ответом путем установки свойства HttpResponse.Filter. Это свойство принимает все объекты, порожденные от абстрактного класса System.IO.Stream, и позднее использует их для фильтрации тела экземпняра исходящего ответа.
Функция фильтрации ответов ASP.NET — всего лишь один из механизмов, которые становится возможным использовать при разработке модулей ASP.NET для объединенного режима платформы IIS 7.0. Кроме того, можно переписывать URL-адреса, выполнять проверку подлинности и авторизацию запросов, модифицировать или выпускать файлы «cookie» и заголовки ответов, журналировать запросы и многое другое. Большинство задач, которые ранее требовали разработки в среде ISAPI в машинном коде, теперь могут быть реализованы путем простого написания модулей ASP.NET. Поэтапные указания по сборке модулей ASP.NET для IIS 7.0, параметрам среды разработки и выполнению развертывания можно найти по адресу: mvolo.com/blogs/serverside/archive/ 2007/08/15/Developing-IIS7-web-server-features-with-the-.NET-framework.aspx.
При разработке модуля IIS 7.0 можно использовать возможности ряда функций IIS, используемых для целей управления и развертывания. Одна из таких функций — возможность указывать пользовательскую настройку модуля в файлах настройки IIS 7.0 и либо принудительно развертывать эту настройку автоматически самим приложением, либо управлять ею с помощью ряда средств администрирования IIS 7.0 и интерфейсов API. Выполнение такой процедуры является залогом того, что все функции, выполняемые модулем, будут правильно настроены и управляемы конечными пользователями.

Расширение настройки

Новая система настройки является основой для большого числа основных вариантов развертывания и управления, возможных для платформы IIS 7.0. Вместо того, чтобы быть машинно-ориентированным зранилищем настройки закрытого формата, система настройки IIS 7.0 основана на структурированных файлах настройки формата XML, располагающихся в тех же файлах настройки, используемых системой настройки ASP.NET. Более того, синтаксис данных настройки IIS идентичен синатксису данных настройки ASP.NET; эти данные могут быть совместно записаны в распространяемые файлы web.config, с которыми разработчики ASP.NET очень хорошо знакомы.
Такая схема открывает многие двери. Во-первых, она позволяет приложениям указывать данные настройки IIS вместе со своим прикладным содержимым, что упрощает процесс их развертывания до простой публикации содержимого на сервере. Это гарантирует, что приложения будут работать правильно без необходимости изменять данные машинной настройки, хранящиеся на каждом сервере, на котором эти приложения развертываются, а также без необходимости иметь полномочия администратора на каждом сервере. Структурированный файл настроки формата XML совместно с возможностью размещать настройку ASP.NET вместе с настройкой IIS в одном файле значительно упрощает задачу разработчиков создавать данные настройки, относящиеся к IIS, и управлять ими. Эта задача может выполняться с помощью редактора файлов XML, например Notepad и Visual Studio®, или может быть автоматизирована с помощью интерфейсов API настройки, предоставляемых стеком администрирования IIS 7.0.
Но самым замечательным здесь является тот факт, что система настройки IIS 7.0 является полностью расширяемой. Возможность предоставлять специальному веб-серверу право публикации настроек, которые могут устанавливаться и управляться вместе с настройкой IIS 7.0, играет ключевую роль в построении полных решений для IIS 7.0.
В отличие от системы настройки .NET, добавление нового раздела настройки IIS 7.0 не требует использования программного кода, поскольку сами разделы IIS 7.0 определяются с использованием схемы, основанной на XML. Фактически, все встроенные разделы настройки IIS 7.0 определяются с использованием этого механизма. Найти определения всех разделов настройки IIS можно найти в каталоге %windir%\system32\inetsrv\config\schema в файле IIS_Schema.xml. Например, раздел настройки , который включает и настраивает документы по умолчанию для вашего приложения, определяется следующим образом:

Такая схема определяет все элементы и атрибуты, которые составляют раздел настройки, их типы и дополнительные сведения, такие как определения коллекций и характер проверки атрибутов. Для получения дополнительных сведений о синтаксисе и определениях схем см. комментарии в заголовке файла настройки IIS_Schema.xml.

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

Модуль изменения ответа требует наличия собственного раздела настройки для настройки ряда специальных параметров, в том числе сведений о том, какие правила фильтрации применимы для данного приложения. Чтобы предоставить возможность использовать этот раздел в файлах настройки IIS, в первую очередь необходимо создать файл схемы, который описывал бы структуру раздела (см. рис. 3). Этот файл определяет раздел responseModification и его структуру, включая необходимые атрибуты и коллекцию правил фильтрации, которые могут настраиваться для вызова различных фильтров с дополнительной информацией о том, что и чем должно заменяться.
Figure 3 Схема настройки модуля изменения ответа

Для установки этого раздела настройки необходимо сделать две вещи. Во-первых, скопируйте файл responsemod_schema.xml, содержащий сведения о схеме раздела, в папку %windir%\system32\inetsrv\config\schema. Затем объявите раздел настройки в основном файле настройки сервера, applicationHost.config. Последняя задача потребует написания некоторого кода, если вы пожелаете выполнить эту установку с помощью программы.
Чтобы упростить процесс установки раздела настройки IIS 7.0, я написал служебную программу iisschema.exe, которая выполняет обе эти задачи автоматически. Эту программу можно получить по адресу: mvolo.com/blogs/serverside/archive/2007/08/04/IISSCHEMA.EXE-_2D00_-A-tool-to-register-IIS7-configuration-sections.aspx. С использованием этой программы процедура установки раздела схемы настройки становится одношаговой:

После того как схема раздела настройки установлена, а сам раздел объявлен в файле applicationHost.config, можно начать использовать его для определения данных настройки модуля.
Для управления настройкой раздела можно использовать любое из средств настройки IIS или интерфейсов API, точно так же, как это делалось бы с любым встроенным разделом настройки IIS 7.0. Например, я хочу включить функцию изменения ответов для моего приложения с помощью AppCmd, средства командной строки IIS 7.0:

Кроме того, я могу добавить в раздел настройки responseModification коллекцию правил:

Если теперь вы откроете файл web.config в корневой папке веб-узла по умолчанию (обычно это %windir%\inetpub\wwwroot), вы обнаружите следующий код:

Если вы исправили файл приложения web.config с целью изменения данных настройки модуля, а затем загрузили его на сервер, приложение будет настроено таким образом, чтобы использовать эти новые параметры. Точно так же, если вы загрузили приложение на другой сервер, на котором установлен раздел настройки, вы можете быть уверены, что данное приложение будет использовать нужные параметры без необходимости перенастройки его на этом сервере.
В дополнение к AppCmd, теперь можно использовать для управления данными настройки данного раздела любой интерфейс API настройки IIS 7.0, включая управляемый интерфейс Microsoft.Web.Administration, поставщик WMI из IIS 7.0, объекты COM настройки IIS 7.0 , а также Windows PowerShell®. Кроме установки и чтения данных настройки, можно выполнять любые задачи управления, поддерживаемые системой настройки IIS 7.0, включая управление процессом делегирования данного раздела приложениям, защиту их содержимого путем шифрования настройки и т.д. Те мне менее, чтобы эти данные настройки были полезными, вам потребуется возможность читать их из модуля изменения ответа.
Интерфейс API Microsoft.Web.Administration является новым интерфейсом .NET Framework, предоставляемым IIS 7.0; он позволяет программам иметь доступ к данным настройки IIS 7.0. Кроме того, что этот интерфейс предоставляет программам настройки и установки возможность управлять настройкой, он также дает возможность считывать данные настройки непосредственно из управляемого модуля.
Можно использовать этот интерфейс API для чтения раздела настройки из модуля сразу же после регистрации раздела настройки, поскольку интерфейс API предоставляет нестрого типизированную модель для чтения разделов настройки. Перед тем как делать это, вам необходимо добавить ссылку на файл Microsoft.Web.Administration.dll, который находится в папке %windir%\system32\inetsrv. Заметим, что эта библиотека DLL входит в состав только IIS 7.0 под Windows Vista® или Windows Server® 2008 и не поставляется в составе .NET Framework или комплекта SDK для Windows.
После того, как ссылка добавлена, можно читать данные настройки модуля:

Класс WebConfigurationManager в пространстве имен Microsoft.Web.Administration почти идентичен WebConfigurationManager в пространстве имен System.Web.Configuration и призван заменить последний для работы с управляемыми модулями IIS 7.0, выполняющими чтение настройки IIS 7.0. Метод GetSection выбирает объект раздела настройки по пути, указанному в текущем запросе HTTP.

Строго типизированный класс настройки

Объект ConfigurationSection предоставляет нестрого типизированный доступ к любому разделу настройки, не требуя написания дополнительного кода. Можно получить доступ ко включенному атрибуту путем простого извлечения его имени в индексаторе объекта раздела и приведения его к ожидаемому типу.
Тем не менее, можно продвинуться на один шаг вперед, создав строго типизированную оболочку для раздела настройки. Можно быстро создать класс оболочки с помощью служебной программы, написанной Канвальетом Синглой (Kanwaljeet Singla), участником команды IIS; эту программу можно загрузить по адресу: blogs.iis.net/ ksingla/archive/2006/12/04/tool-to-generate-strongly-typed-classes-for-configuration-sections.aspx. Она позволяет создавать класс оболочки для раздела, имеющего примерно такой вид, как показан на рис. 4. Этот класс просто обертывает нижележащий класс ConfigurationSection и предоставляет строго типизированные свойства для доступа к исходным данным настройки.
Figure 4 Строго типизированная обертка раздела настройки

Как видно из реализации свойства Enabled, обертывание атрибутов настройки является достаточно простым. Обертывание дочерних элементов и коллекций требует последующей реализации классов оберток, наследуемых соответственно из ConfigurationElement и ConfigurationCollection (не показаны), точно таких же, как сама обертка раздела.
После того, как класс обертки создан, его можно скомпилировать в отдельную сборку и указать ссылку на него в проекте модулей или просто добавить его в виде файла исходного кода. Это позволит модулю иметь безопасный относительно типов доступ к разделу настройки:

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

Расширение IIS Manager

Итак, я уже показал, как создать модуль изменения ответа и позволить ему читать специальный раздел настройки, который управляет его поведением. Эта настройка может храниться в тех же файлах настройки, что содержат оставшиеся данные настройки IIS, может развертываться вместе с приложением в файлах web.config, а также может обрабатываться с помощью различных программных средств и интерфейсов API, в том числе AppCmd.exe и Microsoft.Web.Administration.
К этому моменту модуль изменения ответа может быть развернут и соответствующим образом настроен в любой среде IIS. Тем не менее, можное продвинуться еще на один шаг вперед, предоставив функции специальные возможности управления для консоли диспетчера IIS. Сделав это, вы получите ряд преимуществ. Это позволит системным администраторам без труда настраивать модуль с помощью консоли диспетчера IIS, не требуя от них править непосредственно файлы настройки или использовать другие низкоуровневые служебные программы и интерфейсы API. Это также позволяет обрабатывать данные настройки модуля с помощью средств удаленного администрирования диспетчера IIS, которые предоставляют пользователю преимущества службы веб-управления (WmSvc).
В отличие от других средств, которые тоже поддерживают функции удаленного администрирования, архитектура удаленного администрирования диспетчера IIS имеет ряд ключевых преимуществ. Во-первых, она позволяет пользователям, не обладающим правами администратора на сервере, управлять веб-узлами и приложениями, которые доступны для них. Во-вторых, механизм удаленного администрирования диспетчера IIS использует протокол HTTPS, а не DCOM, который проще проходит через корпоративные брандмауэры. В сочетании обе эти возможности делают диспетчер IIS Manager привлекательным для делегированного удаленного управления веб-узлами IIS, особенно в средах совместного веб-размещения.
В полном соответствии с основной идеей IIS 7.0, диспетчер IIS имеет расширяемую архитектуру, на которой основано большинство встроенных функций диспетчера IIS. С целью упрощения случая удаленного управления каждая функция управления состоит из двух частей: компонентов клиентской части, которая предоставляет пользовательский интерфейс внутри диспетчера IIS, и серверных компонентов, которые предоставляют собственно сами службы управления.
Служба на стороне сервера загружается внутри диспетчера IIS Manager в случаях локального управления или внутри службы веб-управления в случаях удаленного управления. Во втором случае диспетчер IIS поддерживает необходимый обмен данными между компонентами в диспетчере IIS на машине клиента и службой, запущенной внутри WmSvc на машине принимающего сервера.

Создание службы

Клиентские и серверные компоненты обычно выполнены в виде двух отдельных сборок .NET, которые не ссылаются друг на друга. Обмен данными между клиентскими и серверными компонентами осуществляется посредством абстракции ModuleServiceProxy диспетчера IIS, которая использует для обмена информацией набор нестрого типизированных свойств и основных типов .NET.
Серверная сборка обычно содержит реализацию класса Microsoft.Web.Management.Server.ModuleProvider, который выполняет требуемую регистрацию служб и клиентских модулей, а также реализацию класса Microsoft.Web.Management.Server.ModuleService, который представляет методы служб для выполнения требуемых задач управления.
Моя сборка Mvolo.ResponseModificationUI.Server.dll содержит класс ResponseModificationModuleProvider, который отвечает за регистрацию класса служб ResponseModificationModuleService в дополнение к классу клиентского модуля ResponseModificationModule, как это показано на рис. 5.
Figure 5 Класс поставщика модулей

Класс ResponseModificationModuleService порождается от класса ConfigurationModuleProvider, который предоставляет встроенную поддержку для управления функциями делегирования диспетчера IIS, основанными на состоянии делегирования нижележащего раздела настройки. Все, что нужно сделать, — указать имя раздела настройки, responseModification, и диспетчер IIS автоматически переключит состояние делегирования функций в зависимости от того, заблокирован или разблокирован этот раздел для отдельных путей настройки. Инфраструктура Microsoft.Web.Management предоставляет несколько других базовых классов ModuleProvider, которые поддерживают немного другие случаи делегирования для средства диспетчера IIS.
Метод GetModuleDefinition возвращает тип модуля диспетчера IIS, который будет создан на стороне клиента, чтобы зарегистрировать требуемые компоненты интерфейса пользователя диспетчера IIS, такие как страница управления.
Обратите внимание на то, что тип класса ResponseModificationModule на стороне клиента — строковый, но не объект типа Type, поскольку серверная сборка может не ссылаться на сборку клиента, которая будет загружена в диспетчер IIS на машине удаленного клиента. Это один из побочных эффектов, обусловленный тем фактом, что компоненты клиента и сервера могут быть запущены в разных процессах и не могут совместно использовать пользовательские типы.
Класс ResponseModificationModuleService отвечает за реализацию функций управления и использование методов служб, которые вызваются страницей управления в диспетчере IIS (см. рис. 6).
Figure 6 Класс службы модулей

Метод GetFilterRules является примером использования нескольких методов службой, выполняющей задачи управления с использованием системы настройки, а также других ресурсов, локальных для сервера. Экземпляр службы всегда создается на сервере, так что он постоянно работает на локальных ресурсах, поэтому нет необходимости волноваться о раздельном доступе к ресурсам в случае удаленного администрирования. Обратите внимание на то, что я снова использую интерфейс API Microsoft.Web.Administration для доступа к разделу настройки responseModification, при этом использую строго типизированную обертку ResponseModificationConfigurationSection, созданную для обеспечения доступа модуля к настройке.
Свойство ManagementUnit является основной точкой доступа к локальному серверу, оно предоставляет ряд других объектов, которые обеспечивают доступ к системе настройки и другим объектам управления, сосредоточенным на сервере, которые были созданы с помощью платформы Microsoft.Web.Management с целью помочь в реализации задач управления сервером. Практический опыт показывает, что реализации служб должны всегда использовать блок управления для задач управления локальной настройкой, а не создавать собственные системы настройки.
Методы наподобие GetFilterRules могут возвращать клиенту данные, используя основные типы, например, ArrayList, для пересылки данных клиентским компонентам. Снова обратите внимание на то, что нельзя осуществлять обмен данными ипри помощи строго типизированных классов, определенных на серверной или клиентской сборках, потому что они предназначены для раздельного использования и не должны ссылаться друг на друга. Служба ResponseModificationModuleService также определяет дополнительные методы служб, аналогичные GetFilterRules, в том числе EditFilterRule, AddFilterRule и DeleteFilterRule, предназначенные для выполнения операций управления, которые могут быть затребованы страницей модуля изменения ответа.

Создание страницы модуля
Клиентские компоненты определяют функции графического интерфейса пользователя (GUI), предоставляемые пользователю с помощью диспетчера IIS. Клиентская сборка обычно содержит реализацию следующих классов:
Класс Microsoft.Web.Management.Client.Module, ответственный за регистрацию всех требуемых страниц диспетчера IIS и других расширений пользовательского интерфейса.
Класс Microsoft.Web.Management.Client.ModulePage, который содержит описание текущей страницы управления, отображаемой диспетчером IIS.
Класс Microsoft.Web.Management.Client.ModuleServiceProxy, коорый предоставляет клиентские компоненты совместно с классом локального прокси для вызова методов служб, используемых ModuleService.
Сборка Mvolo.ResponseModificationUI.Server.dll содержит класс ResponseModificationModule, показанный на рис. 7 (не путать собственно с классом IhttpModule, предоставляющим службы модуля при конвейерной обработке запросов IIS), который предоставляет главную точку входа для регистрации всех требуемых компонентов пользовательского интерфейса в диспетчере IIS. Этот класс регистрирует класс ResponseModificationModulePage, который содержит описание текущей управляющей страницы.
Figure 7 Класс модулей

Каждая реализация модуля создается однократно за время управляющего подключения, выоплненного диспетчером IIS, она ответственна за регистрацию всех страниц управления и элементов пользовательского интерфейса, необходимых для данного подключения. ResponseModificationModule регистрирует класс ResponseModificationModulePage, который определяет содержимое управляющей страницы.
Честно говоря, я не большой поклонник программирования пользовательских интерфейсов, я предпочел бы программировать низкоуровневые серверные программы, которые не требуют разработки интерфейса. К счастью для меня, платформа Microsoft.Web.Management предоставляет целый ряд базовых классов и поддерживающих классов, предназначенных для создания обычных управляющих страниц, включая класс Microsoft.Web.Management.Client.Win32.ModuleListPage, который я использовал для ResponseModificationModulePage.
Этот класс имеет встроенное представление в виде списка для просмотра списков элементов и работы с ними, включая упорядочение списков и работу с элементами списка. С минимальными переделками я смог создать страницу управления, содержащую перечень правил изменения ответов (см. центральную панель на рис. 8).

Рис. 8 Страница изменения ответов в диспетчере IIS

Затем я создал перечень действий, показанный в правом окне, позволяющий добавлять, изменять и удалять правила изменения ответов. При создании этого перечня задач я использовал возможности класса Microsoft.Web.Management.Client.TaskList (см. правую панель на рис. 8).
Еще немного усилий, и функция изменения, показанная на рис. 8, является на свет. Можно изучить детали пользовательского интерфейса, посмотрев исходный код для платформы изменения ответа.
Операции создания новой страницы, добавления, правки и удаления, запускаемые с панели действия, выполняются с помощью методов класса ResponseModificationModuleServiceProxy, который предоставляет локальный прокси для методов модулей, вызываемых службой модулей:

Диспетчер IIS автоматически передает вызовы, сделанные к классу прокси службы модулей, на связанную службу модуля по каналу обмена данными, который может представлять собой локальный канал совместно используемой памяти или канал https на удаленный сервер.

Развертывание расширения

При развертывании расширения диспетчера IIS учтите, что нужно зарегистрировать тип поставщика модуля в файле настройки диспетчера IIS на сервере (%windir%\system32\inetsrv\config\administration.config). Настройка, показанная на рис. 9, регистрирует поставщик модуля и предоставляет возможность использовать его на всех веб-узлах по умолчанию. Заметим, что и клиентская, и серверная сборки, образующие расширение, Mvolo.ResponseModificationUI.Server.dll и Mvolo.ResponseModificationUI.Client.dll, должны быть зарегистрированы в глобальном кэше сборок (GAC) и, следовательно, должны иметь строгое имя и подпись. Это требование, позволяющее выполнить установку расширений диспетчера IIS.
Figure 9 Настройка расширения диспетчера IIS

Когда диспетчер IIS используется для удаленного управления сервером, он автоматически предложит пользователю загрузить клиентскую сборку вне зависимости от того, есть она уже или еще нет (это происходит при управлении IIS 7.0 на Windows Server 2008 клиентом Windows Vista SP1, Windows XP или Windows Server 2003 с использованием удаленного диспетчера IIS, который доступен по адресу: iis.net/ downloads/?tab >

Окончательная сборка

После развертывания модуля и установки схемы раздела настройки и расширения диспетчера IIS функция изменения ответа готова к использованию. Теперь можно применять эту функцию к любому приложению на вашем сервере и настраивать его с помощью любой программы настройки или интерфейсов API IIS 7.0.
Кроме того, можно использовать диспетчер IIS для быстрого управления правилами изменения ответов в приложениях как на локальном, так и на удаленном сервере. Используя поддержку делегирования диспетчера IIS, можно установить, кто из пользователей имеет право удаленно создавать и изменять правила изменения ответов для определенных веб-узлов сервера.
Для демонстрации функции изменения ответов в действии на рис. 10 показано, как настроены правила для приложения Qdig моей галереи изображений (см. msdn.microsoft.com/msdnmag/issues/08/01/PHPandIIS7). На рис. 11 показано, как использован фильтр Mvolo.ResponseModification.Filters.RegExReplace, поставляемый в составе платформы изменения ответа, для вставки текста колонтитулов на всех страницах веб-узла без изменения исходного кода приложения.
Figure 10 Включение колонтитулов

Рис. 11. Использование модуля изменения ответов для изменения ответов

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

Илон Маск рекомендует:  Самостоятельная разработка веб-сайтов с помощью конструкторов
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL