Iis о приложениях


Содержание

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

IIS (Internet Information Services)

Internet Information Services
Разработчики: Microsoft
Постоянный выпуск: 10 / 29 July 2015 года ; 4 years ago ( 2015-07-29 )
Состояние разработки: Active
Написана на: C++ (язык программирования) [1]
Операционная система: Windows NT
Локализация: Same languages as Windows
Тип ПО: Web server
Лицензия: Part of Windows NT (same license)
Веб-сайт iis .net

IIS (англ. Internet Information Services ) является Visual Basic приложением, которое располагается на веб-сервере и отвечает на запросы браузера. Приложение IIS использует HTML для представления своего пользовательского интерфейса и использует скомпилированый код Visual Basic для обработки запросов и реагирования на события в браузере. Для пользователя приложение IIS представляется рядом страниц HTML. Для разработчика приложение IIS состоит из особого типа объекта, называемого WebClass, который в свою очередь, содержит ряд ресурсов, называемых webitems. WebClass выступает в качестве центрального функционального блока приложения, обрабатывающего данные из браузера и отправляющего информацию пользователям. Разработчик описывает ряд процедур, которые определяют, каким образом WebClass отвечает на эти запросы. webitems являются HTML-страницами и другими данными, которые WebClass может отправить в браузер в ответ на запрос.

Содержание

Архитектура

Internet Information Services (IIS) 7 и выше обеспечивает архитектуру обработки запросов, которая включает в себя:

  • Служба активации процесса Windows (WAS), который позволяет сайтам использовать отличающиеся от HTTP и HTTPS протоколы.
  • Веб-движок сервера, который может быть изменен путем добавления или удаления модулей.
  • Интегрированные конвейеры обработки запросов от IIS и ASP.NET.

Компоненты

IIS содержит несколько компонентов, которые выполняют важные функции для приложений и ролей веб-сервера в Windows Server® 2008 (IIS 7.0) и Windows Server 2008 R2 (IIS 7.5). Каждый компонент имеет функции, такие как прослушивание запросов к серверу, управление процессами и чтение файлов конфигурации. Эти компоненты включают в себя обработчики протокола, такие как HTTP.sys и службы, такие как World Wide Web Publishing (служба WWW) и службы активации процесса Windows (WAS).

Internet Information Server (IIS) имеет свой собственный ASP.NET Process Engine для обработки запроса ASP.NET. Способ настройки приложения ASP.NET зависит от того, какая версия IIS приложения используется.

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

По заявлениям разработчиков, IIS повышает доступность веб-сайтов и приложений при одновременном снижении системного администрирования и стоимости развертывания. IIS 7.5 поддерживает HTTP, HTTPS, FTP, FTPS, SMTP и NNTP.

Ключевые особенности

  • Встроенные расширения
    • WebDAV и FTP
    • Фильтрация запросов
    • Модули администрирования
  • Усовершенствования управления
    • Анализатор соответствия рекомендациям
    • Windows PowerShell провайдер и cmdlets
    • Ведение журнала конфигурации и трассировки
  • Улучшения хостинга приложений
    • Управляемые учетные записи служб
    • Hostable веб-ядро
    • Трассировка неудачных запросов для FastCGI
  • Улучшения .NET поддержки для Server Core

Установка

  • Нажмите кнопку Пуск и выберите Панель управления.
  • На панели управления выберите Программы, а затем Включение и отключение компонентов Windows.
  • В диалоговом окне «Компоненты Windows» нажмите Службы IIS, а затем кнопку ОК.

Конфигурирование

Настройка веб-узла по умолчанию: При установке IIS настроен для использования в качестве веб-узла по умолчанию; тем не менее может потребоваться изменить некоторые настройки. Чтобы изменить основные параметры для веб-узла и имитировать действия, которые требуются для настройки Apache в первый раз с помощью файла конфигурации:

  1. Войдите в систему на компьютере веб-сервера с правами администратора.
  2. Нажмите кнопку Пуск, выберите Настройка и щелкните Панель управления.
  3. Дважды щелкните значок Администрирование, а затем дважды щелкните значок Диспетчер служб Интернета.
  4. Щелкните правой кнопкой мыши веб-узел, который необходимо настроить, на левой панели и выберите команду Свойства.
  5. Перейдите на вкладку веб-узел .
  6. В поле Описание введите описание веб-узла.
  7. Введите адрес Internet Protocol (IP) для веб-узла или оставьте значение по умолчанию все (не назначено) .
  8. Измените порт протокола управления передачей (TCP), соответствующим образом.
  9. Перейдите на вкладку Домашний каталог.
  10. Чтобы использовать папку на локальном компьютере, выберите каталог на данном компьютере и нажмите кнопку Обзор, чтобы найти папку, которую требуется использовать.
  11. Чтобы использовать папку, общий ресурс с другого компьютера в сети, выберите параметр Общая папка другого компьютера и затем введите путь или нажмите кнопку Обзор, чтобы выбрать общую папку.
  12. Нажмите кнопку Чтение предоставить доступ на чтение к папке (обязательно).
  13. Нажмите кнопку ОК, чтобы принять свойства веб-сайта.

Создание нового веб-узла:

Чтобы создать новый веб-узел на сервере Apache, необходимо настроить виртуальный узел и настроить отдельные параметры для узла. Если используются службы IIS, можно создать новый веб-узел путем перевода следующих терминов в эквивалентные термины IIS:

Apache термин Термин IIS
Корень документа Каталог домашней страницы веб-узла IIS
Имя_сервера Заголовок узла IIS
Прослушивание IIS IP-адрес и TCP-порт

Чтобы создать новый веб-узел в IIS, выполните следующие действия:

  1. Войдите в систему на компьютере веб-сервера с правами администратора.
  2. Нажмите кнопку Пуск, выберите Настройка и щелкните Панель управления.
  3. Дважды щелкните значок Администрирование, а затем дважды щелкните значок Диспетчер служб Интернета.
  4. Щелкните Действие, выберите пункт Создать и выберите веб-узел.
  5. После запуска мастера создания веб-узла, нажмите кнопку Далее.
  6. Введите описание веб-узла. Это описание используется для идентификации веб-узла в диспетчере служб Интернета только для внутренних целей.
  7. Выберите IP-адрес для веб-узла. Если выбрать все (без значения), веб-узел будет доступен для всех интерфейсов и всех настроенных IP-адресов.
  8. Введите номер порта TCP, чтобы опубликовать на нем сайт.
  9. Введите имя заголовка узла (реальные имя, которое используется для доступа к этому узлу).
  10. Нажмите кнопку Далее.
  11. Введите путь к папке, которая содержит документы веб-узла, или нажмите кнопку Обзор, выберите папку и нажмите кнопку Далее.
  12. Укажите права доступа для веб-узла и нажмите кнопку Далее.
  13. Нажмите кнопку Готово.

Использование FastCGI для хостинга PHP приложений на IIS 7.0

Использование FastCGI для хостинга PHP приложений на IIS 7.0

Автор: Руслан Якушев

Данная статья описывает конфигурацию модулей FastCGI и PHP для хостинга PHP приложений на IIS 7.0

Важно: Данная статья содержит инструкции по установке компонента FastCGI в операционных системах Windows Server 2008 и Windows Vista SP1. Обратите внимание: на Windows Vista должен быть установлен SP1.

Содержание

  • Краткий Обзор
  • Включение поддержкиFastCGIвIIS7.0
    • Windows Server 2008
    • Windows Vista SP1
    • Обновление модуляFastCGI
    • Administration Pack для IIS 7.0
  • Установка и настройка PHP
  • НастройкаIIS7.0 для обработкиPHPзапросов
    • Используя консоль управления IIS
    • Используя командную строку
  • Рекомендуемые руководства по конфигурированиюFastCGIиPHP
    • Безопасная изоляция для PHP Web сайтов
    • Режим рециркуляцииPHPпроцессов
    • Версионность PHP
    • Рекомендации по безопасностиPHP
  • Конфигурирование PHP на уровне сайтов
  • МодульURLrewritingдляPHPприложений
  • Полезные ресурсы

Благодаря модулю FastCGI в IIS поддерживается большинство популярных приложений коллективной работы, которые используют протокол FastCGI для хостинга на Web сервере IIS высокопроизводительных и надёжных средств. FastCGI предоставляет высокопроизводительную альтернативу CGI (Common Gateway Interface), стандартного средства, являющегося интерфейсом между внешними приложениями и Web серверами, которые поддерживаются как часть возможностей IIS начиная с первых версий сервера.

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

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

Добавьте роль CGI сервиса через меню Server Manager -> Roles -> Add Role Services. Этим мы включим поддержку двух сервисов CGI и FastCGI:

Windows Vista SP1

Добавьте расширение CGI, используя Control Panel -> Programs and Features -> Turn Windows features on or off. Этим мы включим поддержку двух сервисов CGI и FastCGI:

Важно: Установка обновлений для модуля FastCGI

Установка пакета администрирования для IIS 7.0

Примечание: Данный шаг не обязателен (опционален).

Из большого числа полезных функций административного пакета IIS 7.0 можно выделить интерфейс конфигурирования модуля FastCGI. Административный пакет может быть установлен из следующих источников:

  • Административный пакет для IIS 7.0 CTP2 — x86
  • Административный пакет для IIS 7.0 CTP2 — x64

Установка и настройка PHP

Рекомендуется использовать сборку non-thread safe PHP с модулем FastCGI сервера IIS 7.0. Эта сборка PHP дает значительный прирост производительности в отличие от стандартной сборки, т.к не производит проверок thread-safety, которые не требуются, так как сам FastCGI гарантирует однопоточное исполнение процессов, в окружении сервера.

  1. Загрузите последнюю версию non-thread safe пакета, включая бинарные файлы, по следующей ссылке http://www.php.net/downloads.php.
  2. Распакуйте файлы в директорию (например C:\PHP). Переименуйте файл php.ini-recommended в php.ini.
  3. Откройте переименованный файл php.ini, уберите комментарии с нижеперечисленных строк и измените значения в соответствии с предложенными:
    • Установите fastcgi.impersonate= 1. Модуль FastCGI для IIS может исполнять роль выдачи ключей безопасности для вызовов клиента. Это позволяет IIS определять контекст безопасности для выполняемых запросов.
    • Значение cgi.fix_pathinfo=1. cgi.fix_pathinfo обеспечивает поддержку *реальных путей* PATH_INFO/PATH_TRANSLATED для CGI. В предыдущих версиях PHP значение PATH_TRANSLATED указывало на SCRIPT_FILENAME, и не затрагивало директивы PATH_INFO. Дополнительную информацию о PATH_INFO смотрите в документации cgi. Установка данного значения в 1 решает проблему задаваемых путей PHP CGI изменяя пути так чтобы они соотвествовали спецификации.
    • Установите cgi.force_redirect = 0.
    • Установите для директивы open_basedir путь к папке или сетевому ресурсу на котором расположены Web сайт(ты).
    • Директива extension_dir определяет расположение расширений для PHP. Обычно, для PHP версий 5.2.X значение для данной директивы устанавливается в extension_dir= «./ext«
    • Для включения необходимых расширений PHP уберите комментарии в файле php.ini с соответствующих строчек, к примеру:
      extension=php_mssql.dll
      extension=php_mysql.dll
  4. Для проверки удачной установки PHP выполните следующую команду:

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

Настройка IIS 7.0 для обработки PHP запросов

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

Прим.переводчика: при запросе клиентом файла с расширением *.php с Web сайта/сервера, расположенного на IIS 7.0, сервер будет «отдавать» обработку php файлов приложению, отвечающему за обработку php файлов.

Используя консоль управления IIS

Откройте IIS Manager и выберете “Handler Mappings” на уровне управления сервером:

Запустите “Add Module Mapping” для конфигурации, представленной на рисунке ниже:

Нажмите OK. На запрос о создании приложения FastCGI нажмите Yes.

Протестируйте корректную привязку заголовков, созданием файла phpinfo.php в папке C:\inetpub\wwwroot, используя следующий код:

Откройте браузер и перейдите по ссылке http://localhost/phpinfo.php. Если установка прошла корректно, то вы увидите стандартную страницу конфигурации PHP:

Примечание: Если Вы не видите в списке модулей «FastCgiModule», то это означает, что модуль не зарегистрирован, либо не включен. Для того, чтобы проверить, зарегистрирован ли модуль FastCGI откройте конфигурационный файл IIS по следующему адресу: %WINDIR%\windows\system32\config\applicationHost.config и проверьте присутствие значения в следующей секции:

Также, в этом же файле, убедитесь в том, что модуль FastCGI добавлен в секцию :

Используя командную строку

Альтернативой предыдущим шагам может служить использование команды appcmd.

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

C:\>%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath=’c:\\php-cgi.exe’]

После этого создайте привязку заголовков:

C:\>%windir%\system32\inetsrv\appcmd set config /section:system.webServer/handlers /+[name=’PHP_via_FastCGI’,path=’*.php’,verb=’*’,modules=’FastCgiModule’,scriptProcessor=’c:\\php-cgi.exe’,resourceType=’Unspecified’]

Примечание: Если вы используете PHP версий 4.X,то вместо php-cgi.exe необходимо использовать php.exe.

Рекомендуемые руководства по конфигурированию FastCGI и PHP

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

Безопасная изоляция для PHP Web сайтов

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

  • Используйте один пул приложений на один Web сайт
  • Используйте выделенный аккаунт пользователя для пула приложений
  • Используйте анонимного пользователя для идентификации пула приложений
  • Убедитесь в том, что реализация FastCGI включена в файле php.ini (fastcgi.impersonate=1)

Более подробно о безопасной изоляции в окружении общего хостинга написано в документации «Изолирование сайтов с пулами приложений»

Режим рециркуляции PHP процессов

Убедитесь в том, что FastCGI всегда рециркулирует (перезагружает — прим.перевод) процессы php-cgi.exe, прежде чем завершается работа основного PHP процесса. Режим рециркуляции процессов FastCGI контролируется параметром конфигурации, который называется instanceMaxRequests (максимальное кол-во запросов на экземпляр приложения — прим.перевод). Данное значение определяет, какое кол-во запросов выполнит FastCGI, прежде чем произойдёт рециркуляция. В PHP так же существует функция рециркуляции, которая контролируется параметром PHP_FCGI_MAX_REQUESTS. Установка наименьшего значения для instanceMaxRequests или подобного параметра PHP_FCGI_MAX_REQUESTS, гарантирует, что основной PHP процесс не будет закончен преждевременно.

Свойства для FastCGI могут быть изменены при помощи IIS Manager или командной строки, используя приложение appcmd.

Для настройки процесса рециркуляции FastCGI, используя IIS Manager, вам необходимо установить Административный пакет для IIS 7.0 и выбрать на уровне севера меню FastCGI settings (параметры FastCGI):

Далее необходимо выбрать приложение FastCGI, которое вы хотите настроить и нажать «Edit. » в панели Actions:

В окне «Edit FastCGI application» установите для параметра instanceMaxRequest значение 10000 нажмав кнопку обзора в меню EnvironmentVariables:

Добавьте переменную PHP_FCGI_MAX_REQUESTS,установив для неё значение в 10000:

Примечение: Если вы не установите данные значения, то по умолчанию они будут следующими: instanceMaxRequests = 200, PHP_FCGI_MAX_REQUESTS = 500 (для большинства сборок PHP).

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

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

C:\>%windir%\system32\inetsrv\appcmd set config -section:system.webServer/fastCgi /[fullPath=’c:\\php-cgi.exe’].instanceMaxRequests:10000
C:\>%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/fastCgi /+»[fullPath=’C:\\php-cgi.exe’].environmentVariables.[name=’PHP_FCGI_MAX_REQUESTS’,value=’10000′]»

Большинство PHP приложений могут зависеть от функций или расширений доступных только в определённой версии PHP. Если такие приложения должны быть размещены на одном сервере хостинга, то необходимо чтобы на данном сервере одновременно поддерживались и работали разные версии PHP. Обработчик FastCGI в IIS 7.0 полноценно поддерживает одновременную работу различных версий PHP на одном сервере.

К примеру, допустим что на своём Web сервере вы планируете поддерживать следующие сборки: PHP 4.4.8, PHP 5.2.1 и PHP 5.2.5 non-thread safe. Для включения данной возможности вы должны положить соответствующие исполняемые файлы PHP в различные папки на файловой системе (к примеру C:\php448\, C:\php521\ и C:\php525nts) и создать соответствующие пулы приложений для каждой версии:

C:\>%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath=’c:\php448\php.exe’]
C:\>%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath=’c:\php521\php-cgi.exe’]
C:\>%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath=’c:\php525nts\php-cgi.exe’]

Так, если у вас есть 3 Web сайта (site1, site2, site3), каждый из которых должен использовать различные версии PHP, вы можете задать соответствие заголовков для каждого из сайтов, создав соответствующий пул приложений FastCGI.

Примечание: Каждый пул приложений процессов FastCGI будет идентифицируется уникально — комбинацией полного пути и свойствами аргументов.

C:\>%windir%\system32\inetsrv\appcmd set config site1 –section:system.webServer/handlers /+”..[name=’PHP448_via_FastCGI’,path=’*.php’,verb=’*’,modules=’FastCgiModule’,scriptProcessor=’c:\php448\php.exe’,resourceType=’Either’]
C:\>%windir%\system32\inetsrv\appcmd set config site2 –section:system.webServer/handlers /+”..[name=’PHP521_via_FastCGI’,path=’*.php’,verb=’*’,modules=’FastCgiModule’,scriptProcessor=’c:\php521\php-cgi.exe’,resourceType=’Either’]
C:\>%windir%\system32\inetsrv\appcmd set config site3 –section:system.webServer/handlers /+”..[name=’PHP525nts_via_FastCGI’,path=’*.php’,verb=’*’,modules=’FastCgiModule’,scriptProcessor=’c:\php525nts\php-cgi.exe’,resourceType=’Either’]

Рекомендации по безопасности PHP

Следующие настройки могут быть использованы для улучшения безопасности установленного PHP. Следуя рекомендациям найдите и измените в файле php.ini следующие значения:

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

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

safe_mode=Off
safe_mode_g >

Ограничение безопасного режима.

Лимит времени выполнения

Лимит на использование размеров памяти и файлов.

Настройка сообщений об ошибках и ведения логов.

Модуль FastCGI для IIS может обрабатывать запросы с ошибками, если PHP отправляет данные в stderr (стандартный поток ошибок – прим.перевод) используя протокол FastCGI. Отключение ведения логов FastCGI предотвращает отправку приложением PHP сообщений об ошибках, используя stderr, генерируя при этом ошибку с кодом 500 для клиентов.

Скрытие присутствия PHP

Конфигурирование PHP на уровне сайтов

Данная секция описывает процедуры, которые необходимы для настройки PHP на уровне сайтов. Хочется обратить внимание на то, что данная рекомендация обнародована и проверена Radney Jasmin совместно с хостинг провайдером GoDaddy.com, который официально поддерживает PHP хостинг на Windows Server 2008 посредством FastCGI.

Пулы процессов PHP на уровне сайтов

Когда каждый Web сайт имеет собственный пул приложений (это является рекомендованной практикой для IIS 7.0), появляется возможность ассоциировать выделенный пул процессов FastCGI с каждым Web сайтом. Пул приложений процессов FastCGI идентифицируется уникально — комбинацией полного пути и атрибутами аргументов. Итак, если необходимо создать несколько процессорных пулов FastCGI для некоторого исполняемого процесса, такого как php-cgi.exe,то атрибуты аргументов могут использоваться для разграничения процессорных пулов. В дополнении процессы php-cgi.exe с применением ключа командной строки «-d», могут использоваться для определения INI записи в процессе PHP. Данный ключ может быть использован для установки различных значений PHP, которые позволяют задавать уникальность аргументов для каждого пула.

К примеру, если двум Web сайтам «website1» и «website2» необходимо использовать собственные настройки PHP, то нужно изменить пул процессов FastCGI следующим образом:

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

Тогда website1 может иметь сопоставление PHP заголовков, как показано ниже:

и website2 может иметь следующее сопоставление PHP заголовков:

Определение месторасположения файла php.ini

Во время запуска процесс PHP определяет месторасположение файла конфигурации php.ini используя различные настройки. В официальной документации PHP детально описан процесс инициализации (начального запуска) процесса PHP. Так, одним из мест поиска процессом PHP своего файла конфигурации (php.ini) может быть директива PHPRC (PHPRC – это переменная среда ОС, как TMP или Temp – прим.перевод). Если процесс PHP находит файл конфигурации, определённый в вышеописанной директиве, то он начинает использовать данный файл конфигурации, игнорируя путь заданный по умолчанию в файле php.ini. Данная директива полезна для пользователей хостинга, они могут применять свои собственные настройки php.ini на уровне своих сайтов.

К примеру, существует два Web сайта: website1 и website2; расположенных по следующим путям C:\WebSites\website1 и C:\WebSites\website2, тогда пул процессов php-cgi.exe в секции файла applicationHost.config должен иметь следующий вид:

В данном случае WebSite1 имеет свои настройки php.ini файла, который расположен в директории C:\WebSites\website1, тогда как WebSite2 имеет свои настройки файла php.ini, который расположен в директории C:\WebSites\website2. Данная конфигурация так же предполагает что значение PHPRC не задано, иначе сделать уникальные установки файла php.ini на уровне сайтов не представляется возможным.

Большинство популярных PHP приложений используют функциональность URL rewriting на Web серверах, которая предоставляет отображение дружественных ссылок и более корректное предоставление информации для поисковых машин (ссылки вида http://site.name/page123,а не http://site.name/mod_content/page.php=id123&disp — прим.перевод). В IIS 7.0 поддержка URL rewriting (перезапись ссылок) поддерживается посредством модуля URL rewrite.

В следующих статьях представлено подробное описание данного модуля:

  • Работа с модулем Microsoft URL Rewrite. Описывается метод настройки модуля URL Rewrite.
  • Детальное описание конфигурации модуля Microsoft URL Rewrite. Описывается функционал данного модуля и возможность всех опций.
  • Настройка популярных PHP приложений совместно с модулем URL Rewrite:
    • WordPress
    • MediaWiki
    • b2Evolution
    • Mambo
    • Drupal

Cервер приложений Internet Information Services (IIS)

Администраторам и разработчикам Web-приложений необходим надежный, легкоуправляемый, высокопроизводительный и защищенный Web-сервер. В Internet Information Services (IIS) 6.0 и Microsoft ® Windows ® Server 2003 появилось много новых возможностей, обеспечивающих надежность, доступность, управляемость, масштабируемость и безопасность сервера Web- приложений.


IIS 6.0 — ключевой компонент платформы приложений Windows Server 2003 — представляет собой интегрированный набор сервисов и средств, обеспечивающих разработку и развертывание высокопроизводительных Web-сайтов, Web-приложений и Web-сервисов.

Роль сервера приложений в семействе продуктов Windows Server 2003 сочетает в себе следующие серверные технологии:

1. Internet Information Services (IIS) 6.0 Информационные службы Интернета (IIS) 6.0. Они являются полноценным веб-сервером, оптимизированным для запуска веб-приложений и служб на узле.

2. Microsoft .NET Framework;

Это компьютерная платформа, разработанная для упрощения разработки приложений в распределенной среде Интернета. Microsoft .NET Framework предоставляет среду для объектно-ориентированного программирования, гарантирующую безопасное выполнение кода, и исключает затруднения, связанные с обеспечением быстродействия сценариев. В Microsoft .NET Framework входят два основных компонента:

· общая языковая среда выполнения

· библиотека классов Microsoft .NET Framework.

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

Библиотека классов Microsoft .NET Framework — собрание повторно используемых объектов, которые можно применять при создании приложений ASP.NET.

3. ASP.NET это часть Microsoft .NET Framework. ASP.NET представляет собой откомпилированную среду, основанную на технологии .NET. Имеется возможность создавать приложения на любом совместимом с .NET языке, в том числе на Visual Basic .NET, C# и JScript .NET. Кроме того, возможности среды .NET Framework, в том числе управляемая общая языковая среда времени выполнения, безопасность типов и наследование, доступны любому приложению ASP.NET

4. ASP; Active Server Pages (ASP) — активные серверные страницы. Страницы ASP являются средой создания серверных сценариев для разработки динамических интерактивных приложений веб-серверов. Они позволяют разработчикам объединять нужным образом страницы в формате HTML, команды сценариев и компоненты COM для создания мощных и гибких веб-приложений.

5. UDDI-сервисы; UDDI (Universal Description, Discovery and Integration) — это промышленный стандарт публикации и поиска сведений о веб-службах. В некоторые продукты семейства Windows Server 2003 включаются службы UDDI, веб-службы, обеспечивающие использование возможностей UDDI на предприятиях или в организациях. Службы UDDI являются стандартной веб-службой XML. Они позволяют разработчикам предприятия эффективно изучать, открывать совместный доступ и повторно использовать веб-службы непосредственно через средства разработки. Они не включены в Windows Server 2003, Web Edition. Кроме того, Windows Server 2003, Standard Edition поддерживает только изолированную установку служб UDDI. Поддержка распределенной установки доступна в Windows Server 2003, Enterprise Edition и Windows Server 2003, Datacenter Edition. При изолированной установке служб UDDI компоненты веб-сервера UDDI и баз данных UDDI устанавливаются на один компьютер. При распределенной установке компоненты UDDI распределены по нескольким серверам.

6. COM+; расширение модели объектных компонентов (COM). COM+ основано на интегрированных службах и свойствах COM, облегчая разработчикам создание и использование компонентов программного обеспечения на любом языке и используя любые средства.

7. Microsoft Message Queuing (MSMQ). Сервер очередей сообщений Microsoft. Очередь сообщений создается для взаимодействия приложений в распределенной среде (на разных компьютерах). Особенность MSMQ в том, что компьютеры не обязательно должны быть одновременно в сети. То есть можно отправить сообщение, можно получить, а за всем этим следит сервер MSMQ.

Таким образом, сервер приложений позволяет разработчикам Web-приложений и администраторам осуществлять хостинг динамических приложений, например для управления базой данных приложений Microsoft ASP.NET, не надо устанавливать на сервере дополнительное программное обеспечение.

В Windows Server 2003 сервер приложений можно настроить двумя способами: через мастер Configure Your Server или из приложения Add/Remove Components.

Архитектура обработки запросов в IIS 6.0

Сложность кода Web-сайтов и приложений постоянно возрастает.

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

Таким образом, Web-сервер должен выполнять роль активного диспетчера среды выполнения приложения, автоматически определяя ошибки приложения и реагируя на них.

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

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

Также кардинально повышена надежность и масштабируемость благодаря применению модели изоляции процесса (называемую моделью изоляции рабочего процесса ).

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

В IIS 6.0 заложены две новые концепции

1. пулы приложений (application pools)

2. рабочие процессы (worker processes).

Пулы приложений применяются для управления набором Web-сайтов и приложений. Каждый пул приложения соответствует одной очереди запросов в HTTP.sys и одному или более Windows-процессам, обрабатывающим эти запросы.

IIS 6.0 поддерживает до 2 000 пулов приложений.

Одновременно могут работать несколько таких пулов. Например, сервер может выполнять приложение для учета кадров в одном пуле и бухгалтерское приложение — в другом.

То есть Интернет-провайдер (Internet Service Provider, ISP) может запускать Web-сайты и приложения одного клиента в одном пуле приложений, а Web-сайты второго клиента — в другом.

Пулы приложений отделяются друг от друга границами процессов в Windows Server 2003. Таким образом, приложения в одном пуле не влияют на приложения в другом; кроме того, запросы к приложениям нельзя перенаправлять из одного пула в другой.

Рабочий процесс обслуживает запросы к Web-сайтам и приложениям в пуле. Вся обработка Web-приложений, аутентификация и авторизация, выполняется новой библиотекой DLL Web – сервиса, которая загружается в один или несколько рабочих хост-процессов. Исполняемый файл рабочего процесса называется W3wp.exe.

В предыдущей версии IIS (IIS 5.0) один процесс, Inetinfo.exe, выполнял функции главного процесса Web-сервера. Он перенаправлял запросы к «внепроцессным» приложениям, размещенным в процессах DLLHost.exe.

IIS 6.0, напротив, состоит из двух новых компонентов:

1. Компонент WWW Service Administration and MonitoringДиспетчер пользовательского режима, управляющий работой сервера и следящий за выполнением кода приложения. Этот компонент не загружает и не исполняет код приложения. Другими словами компонент пользовательского режима, предназначенного для администрирования и мониторинга.

2. Стек HTTP режима ядра (HTTP.sys), который помещает в очередь и разбирает входящие HTTP-запросы, а также кэширует и возвращает контент сайта и приложения. HTTP.sys не загружает код приложения — он просто анализирует и перенаправляет запросы.

Таким образом, HTTP.sys в IIS принимает запросы и помещает их в очереди.

Каждая очередь запросов соответствует одному пулу приложений.

Так как HTTP.sys не выполняет код приложений, на него не влияют ошибки в коде пользовательского режима, обычно нарушающие нормальную работу Web-сервера.

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

1. перезапуска процесса, который начнет принимать запросы,

2. исчерпания очередей,

3. отсутствия места в очередях

4. остановки администратором самого Web-сервиса.

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

Такая архитектура позволяет IIS 6.0 отделять операции Web-сервера от выполнения кода Web-сайта и приложения без ухудшения производительности.

Настройка сервера и управление рабочим процессом

При инициализации часть сервиса WWW, отвечающая за конфигурирование, использует хранящуюся в памяти конфигурационную метабазу для инициализации таблицы маршрутизации (routing table) пространства имен HTTP.sys.

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

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

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

По мере добавления новых приложений и их пулов Web-сервис настраивает HTTP.sys на прием новых адресов, создает новые очереди запросов для новых пулов приложений и указывает, куда перенаправлять новые URL. Для динамического изменения информации о маршрутизации перезапуск сервиса не требуется.

В роли управляющего рабочим процессом компонент WWW Service Administration и Monitoring отвечает за управление жизненным циклом рабочего процесса, обрабатывающего запросы.

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

Режим изоляции рабочего процесса

IIS 6.0 предоставляет новый режим изоляции приложения для управления обработкой Web-сайтов и приложений — режим изоляции рабочего процесса.

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

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

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

Первым делом HTTP.sys отправляет запросы, адресованные к Web-сайтам и приложениям, соответствующим очередям пулов приложений.

Затем рабочий процесс, обслуживающий пул приложений, извлекает запросы напрямую из очереди приложений в HTTP.sys. Такая модель позволяет избавиться от лишних переключений процессов, возникающих при отправке запросов внепроцессному DLLHost.exe и обратно (как в IIS 4.0 и 5.0), что увеличивает производительность.

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

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

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

Дополнительное преимущество — возможность задействовать другие сервисы операционной системы, доступные на уровне процесса [например управление распределением процессорного времени (CPU throttling)] для пулов приложений. Кроме того, архитектура Windows Server 2003 поддерживает гораздо больше параллельных процессов, чем в предыдущих операционных системах.

Режим изоляции рабочего процесса не дает одному приложению или сайту остановить другие приложения.

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

включение/выключение сайта или приложения (независимо от остальных работающих сайтов или приложений),

· изменение используемого приложением компонента,

· наблюдение за счетчиками производительности,

· регулирование ресурсов, выделяемых приложению.

Режим изоляции рабочего процесса в IIS 6.0 имеет следующие особенности.

1. Кэширование в режиме ядра.. В IIS 6.0 кэширование в режиме ядра осуществляется как в режиме изоляции рабочего процесса, так и в режиме изоляции IIS 5.0 (см. ниже). В качестве единой точки приема всех входящих (серверных) HTTP-запросов HTTP.sys создает высокопроизводительный канал связи для серверных HTTP-приложений и обеспечивает общее управление соединениями, регулирование полосы пропускания и протоколирование на стороне Web-сервера. IIS 6.0 основан на HTTP.sys и специально настроен на увеличение производительности Web-сервера. Кроме того, в некоторых случаях HTTP.sys напрямую обрабатывает запросы в ядре. Как статический, так и динамический контент Web-сайтов и приложений может помещаться в кэш HTTP.sys для уменьшения времени ответа.

2. Четкое разделение между пользовательским кодом и сервером.Весь пользовательский код обрабатывается рабочими процессами, полностью изолированными от ядра Web-сервера. Это важное усовершенствование по сравнению с IIS 5.0, так как ISAPI зачастую выполняются внутрипроцессно в ядре Web-сервера. Если ISAPI, загруженный в рабочий процесс, вызывает сбой или нарушение доступа к памяти, останавливается лишь рабочий процесс, выполняющий ISAPI. Тем временем сервис WWW создает новый рабочий процесс, заменяющий рухнувший. На остальные рабочие процессы это не оказывает никакого влияния.

3. Множественные пулы приложений.В IIS 5.0 приложения можно объединять во внепроцессный пул, но только в один, который выполняется в среде DLLHost.exe. Когда IIS 6.0 работает в режиме изоляции процессов, администраторы могут создать до 2 000 пулов приложений, причем каждый из них можно конфигурировать раздельно.

4. Улучшенная поддержка распределителей нагрузки. Благодаря пулам приложений IIS 6.0 поддерживает физическое разделение приложений. IIS 6.0 способен автоматически взаимодействовать с распределителями нагрузки (load balancers) или с коммутаторами для блокирования трафика к проблемному приложению, параллельно продолжая принимать запросы к другим приложениям. В IIS 6.0 также встроена модель расширения, позволяющая генерировать события и команды при обнаружении сбоя в конкретном приложении. Такая конфигурация позволят распределителям нагрузки и коммутаторам автоматически блокировать трафик к проблемным приложениям, не препятствуя запросам к работающим.

5. Web-сады (Web gardens).На обслуживание запросов, адресованных одному пулу приложений, можно настроить несколько рабочих процессов. По умолчанию каждому пулу соответствует один рабочий процесс. Однако пул можно настроить так, чтобы ему соответствовал набор из N эквивалентных рабочих процессов, разделяющих нагрузку. Такая конфигурация называется Web-садом. HTTP.sys распределяет запросы между рабочими процессами в группе. Распределение запросов основано на принципе карусели. Преимущества Web-садов в том, что, если один рабочий процесс замедляется, например, когда подсистема выполнения сценариев перестает отвечать, прием и обработка запросов продолжается остальными рабочими процессами.

6. Слежение за состоянием. Компонент WWW Service Administration and Monitoring следит за состоянием приложений, периодически проводя тестовый опрос рабочих процессов, чтобы выяснить, не заблокированы ли они. В случае блокировки рабочего процесса сервис WWW завершает рабочий процесс и создает вместо него новый. Сервис WWW поддерживает коммуникационный канал с каждым рабочим процессом и всегда в состоянии определить сбой в рабочем процессе по обрыву канала.

7. Привязка к процессорам (processor affinity). Рабочие процессы можно привязать к конкретным процессорам, чтобы увеличить частоту попаданий в кэш процессора (уровня L1 или L2). Реализация привязки к процессорам приводит к тому, что рабочие процессы IIS 6.0 выполняются на конкретных процессорах, и эта привязка распространяется на все рабочие процессы, обслуживающие Web-сайты и приложения в каком-либо пуле. Привязку к процессорам можно использовать в сочетании с Web-садами, выполняемым на многопроцессорных компьютерах, где под конкретные пулы приложений выделены кластеры процессоров.

8. Сопоставление сайтов и приложений с пулами приложений. В IIS 6.0, как и в IIS 5.0, приложения определяются как пространства. Сайты по умолчанию считаются простыми приложениями, в которых пространство имен сконфигурировано как приложение. Пул приложений можно настроить на обслуживание от одного Web-приложения до множества приложений и сайтов. Чтобы поместить приложение в пул, следует использовать IIS Manager или напрямую модифицировать метабазу.

9. Запуск по требованию. Пулы приложений позволяют запускать процессы, обслуживающие группу пространства имен по требованию, т. е. при первом запросе к URL, который является частью этого пространства имен. Компонент WWW Service Administration and Monitoring выполняет запуск процесса по требованию и в целом контролирует жизненный цикл рабочих процессов.

10. Время ожидания в простое. Пул приложений можно настроить на остановку собственных рабочих процессов, если они простаивают в течение определенного периода. Это нужно для освобождения неиспользуемых ресурсов. При необходимости для данного пула приложений запускаются дополнительные рабочие процессы (см. далее «Запуск по требованию»).

11. Быстрая защита от сбоев. При сбое рабочий процесс обрывает коммуникационный канал с компонентом WWW Service Administration and Monitoring. Последний обнаруживает это и принимает меры, обычно включающие запись события в журнал и перезапуск рабочего процесса. Кроме того, IIS 6.0 можно настроить на автоматическую блокировку рабочего процесса, если в пуле приложений возникает определенное число сбоев за заданный период. Такое поведение называется быстрой защитой от сбоев (rapid-fail protection). Быстрая защита от сбоев переводит пул приложений в состояние «не обслуживается», и HTTP.sys немедленно возвращает сообщение 503 (Service Unavailable) на любые запросы к частям этого пространства имен, в том числе на запросы, уже помещенные в очередь этого пула приложений.

12. Отбрасывание (orphaning) рабочих процессов.Режим изоляции рабочего процесса можно настроить на отбрасывание рабочих процессов, которые считаются зависшими. Например, если рабочий процесс не отвечает на тестовые опросы в течении определенного периода, сервис WWW обычно завершает его и запускает новый. А если включено отбрасывание, он оставляет зависший процесс в памяти и запускает новый. Кроме того, сервис WWW можно настроить на выполнение команды над рабочим процессом (например на подключение отладчика) при его отбрасывании.

13. Повторное использование рабочих процессов.Сейчас многие организации страдают от проблем, связанных с тем, что Web-приложения вызывают утечки памяти, плохо написаны или содержат непонятные ошибки. Это вынуждает администраторов периодически перезапускать Web-серверы. В предыдущих версиях IIS способа перезапустить Web-сайт, не прерывая работу всего сервера, не было. Режим изоляции рабочего процесса можно настроить на периодический перезапуск рабочих процессов в пуле приложения для борьбы со сбойными приложениями. Рабочие процессы можно настроить на перезапуск в соответствии со следующими критериями: истекшим временем, количеством обслуженных запросов, временем суток, использованием виртуальной и физической памяти, а также по требованию. Когда рабочий процесс считает необходимым выполнить перезапуск, он уведомляет WWW-сервис, который в свою очередь дает команду на завершение существующим рабочим процессам и выделяет заданное время на обработку оставшихся запросов. Одновременно сервис WWW создает замещающий рабочий процесс для той же группы пространства имен, и новый рабочий процесс запускается до завершения работы старого. Это предотвращает перебои в обслуживании. Старый рабочий процесс поддерживает связь с HTTP.sys для завершения обработки своих запросов, а затем либо нормально завершает работу, либо его работа завершается извне, если он не остановился по истечении заданного периода.

14. Режим изоляции IIS 5.0 Некоторые приложения не совместимы с режимом изоляции рабочего процесса IIS 6.0, например приложения-фильтры, читающие необработанные данные, или приложения, полагающиеся на выполнение в Inetinfo.exe или DLLHost.exe. Поэтому IIS 6.0 способен работать в другом режиме изоляции, который называется режимом изоляции IIS 5.0 и обеспечивает совместимость. Использование этого режима напоминает работу с самим IIS 5.0, так как в нем присутствуют те же основные процессы пользовательского режима. В частности, есть те же методы изоляции приложений (низкий, средний в пуле и высокий), а Inetinfo.exe — по-прежнему главный процесс, через который проходят все запросы.

Система безопасности IIS

Система безопасности IIS использует преимущества стандартов безопасности Интернет, поддерживаемых Windows.

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

Secure Sockets Layer (SSL). Протоколы безопасности SSL широко используются Web-браузерами и серверами для аутентификации, конфиденциальности и целостности сообщений. При помощи функций безопасности SSL можно проверить целостность содержания Web-сервера, реквизиты пользователей и шифровать передаваемые по сети сообщения.

Transport Layer Security (TLS). TLS основан на SSL. Он помогает выполнять безопасную аутентификацию пользователей, а независимым программистам позволяет создавать поддерживающий TLS код, способный обмениваться зашифрованной информацией с другим процессом без ознакомления с кодом, созданным другим программистом. Кроме того, TLS является каркасом для построения новых методов шифрования с открытым ключом и шифрования больших объемов данных. TLS служит и для повышения производительности, уменьшая сетевой трафик и предлагая схему кэширования сессий, позволяющую сократить количество соединений, устанавливаемых «с нуля».

PKCS #7. Этот протокол описывает формат зашифрованных данных, например цифровых подписей или цифровых конвертов.

PKCS #10. Этот протокол описывает формат посылаемых сертификационным центрам (Certificate Authority, CA) запросов на получение сертификата.

Обычная проверка подлинности. Обычная аутентификация — стандартный метод сбора информации об именах пользователей и паролях. Она посылает пароли по сети в формате Base64 Encoded. К ее достоинствам можно отнести то, что она является частью спецификации HTTP 1.0 и поэтому поддерживается большинством браузеров. Однако обычная аутентификация имеет существенный минус — использующие ее Web-браузеры пересылают пароли в незашифрованном виде.

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

Они проходят через одношаговый процесс — хеширование (hashing). Результат этого процесса называется хешем (hash), или выборкой сообщения (message digest). Исходный текст не может быть расшифрован из хеша. Перед хешированием к паролю добавляется дополнительная информация генерируемая сервером, поэтому никто не сможет перехватить хеш пароля и с его помощью выдавать себя за истинного клиента. Краткая аутентификация основана на методологии общего секретного пароля. Она структурирована для использования несколькими прокси-серверами. Краткая аутентификация поддерживается не всеми обозревателями. Если не поддерживающий краткую аутентификацию браузер пошлет запрос на сервер, требующий именно этот способ аутентификации, сервер не будет обрабатывать запрос и сообщит клиенту об ошибке.

Путем проверки подлинности можно удостовериться в личности каждого клиента, запрашивающего доступ к Web-узлам.

IIS поддерживает для служб HTTP и FTP:

1. анонимную проверку подлинности HTTP и FTP;

2. обычную проверку подлинностиHTTP и FTP;

3. краткую проверку подлинности для доменов Windows 2000 и браузеров, поддерживаю щих этот способ аутентификации, реализованныйв HTTP I.I;

4. интегрированную проверку подлинности Windows (толькоHTTP).

Application Pool Identities в IIS

Каждый пул приложений в IIS использует свой собственный рабочий процесс (IIS Worker Process). Удостоверение пула приложений (Application Pool Identities) представляет из себя имя учетной записи, под которой выполняется рабочий процесс этого пула.

В IIS 6.0 и IIS 7.0 пул приложений по умолчанию работал под встроенной системной учетной записью NetworkService. Эта запись не требует пароля и имеет на локальном компьютере ограниченные права, что является хорошей практикой с точки зрения безопасности. Однако под этой учетной записью могут одновременно работать разные системные службы Windows, и при использовании одного и того же идентификатора одни службы могут воздействовать на работу других.

Начиная с Windows Server 2008 SP2 для того, чтобы изолировать рабочие процессы IIS от других системных служб, можно использовать виртуальные учетные записи (Virtual Accounts). Они позволяют запускать рабочий процесс для каждого пула приложений под собственной уникальной учетной записью ApplicationPoolIdentity. Эта учетная запись не требует управления и создается автоматически при создании каждого нового пула. Также она не имеет практически никаких привилегий в системе и не использует профиль пользователя, что повышает безопасность веб-сервера.

Для примера возьмем Application Pool с именем PubSite1. Открываем Task Manager и находим рабочий процесс IIS (w3wp.exe), выполняющийся от имени PubSite1. Как видите, имя учетной записи совпадает с именем пула приложений. Дело в том, что начиная с IIS 7.5 для каждого вновь созданного пула приложений по умолчанию создается виртуальная учетная запись с именем этого пула, и его рабочий процесс запускается из под этой записи.

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

При необходимости тип идентификации пула приложений можно изменить. Для этого запускаем IIS Manager, переходим в раздел Application Pools, выбираем нужный пул и открываем его свойства (Advanced Settings).

В свойствах выбираем пункт Identity.

Здесь мы указываем учетную запись, от имени которой будет работать данный пул приложений:

• ApplicationPoolIdentity — учетная запись удостоверения пула приложений. Создается автоматически при запуске пула приложений и имеет самые минимальные права на локальном компьютере. Это наиболее безопасный вариант, начиная с IIS 7.5 используется по умолчанию;
• LocalService – встроенная учетная запись, которая имеет ограниченные права на локальном компьютере. Примерно то же самое, что и NetworkService, но ограничена только локальным компьютером;
• LocalSystem – системная учетная запись, имеющая неограниченные права на локальном компьютере. Наименее безопасный вариант, по возможности не рекомендуется ее использовать;
• NetworkService — учетная запись, которая имеет ограниченные права на локальном компьютере, а также может использоваться для доступа к ресурсам в сети Active Directory на основании учетной записи компьютера.

Кроме того, в качестве удостоверения можно использовать и обычную учетную запись пользователя. Для этого надо выбрать Custom Account, нажать кнопку Set и ввести имя пользователя и пароль. Можно указать любого доменного или локального пользователя.

Примечание. При использовании учетной записи пользователя надо отслеживать срок действия пароля и своевременно менять его.

То же самое можно сделать с помощью утилиты командной строки appcmd. Чтобы указать учетную запись, которая будет использоваться для пула приложений, используется следующий синтаксис:

appcmd set config /section:applicationpools /[name=″имя пула приложений″].processModel.identityType:SpecificUser|NetworkService|LocalService|LocalSystem

Для примера изменим тип удостоверения для пула приложений PubSite1 на NetworkService:

appcmd set config /section:applicationpools
/[name=″PubSite1″].processModel.identityType:NetworkService

Профиль пользователя

По умолчанию IIS не использует профиль пользователя, но некоторые приложения могут потребовать использование профиля, например для хранения временных файлов. Профиль для учетной записи NetworkService создается системой и всегда доступен. Стандартные пулы приложений (DefaultAppPool, Classic .NET AppPool и т.п.) также имеют профиль пользователя на диске, однако при использовании ApplicationPoolIdentity профиль не создается автоматически.

Если вы хотите настроить ApplicationPoolIdentity на использование пользовательского профиля, то надо зайти в расширенные свойства пула и перевести параметр Load User Profile в состояние True.

Настройка доступа к ресурсам

Иногда веб-приложению может потребоваться доступ к определенной папке или файлу на диске. Чтобы добавить ApplicationPoolIdentity в Access Control List (ACL):

• Запускаем Windows Explorer;
• Выбираем нужный файл или директорию, кликаем по ней правой клавишей мыши и выбираем пункт Свойства (Properties);
• Переходим на вкладку Безопасность (Security),
• Кликаем по кнопке Изменить (Edit), затем Добавить (Add);
• В поле Размещение (Locations) выбираем локальную машину;
• Вводим имя пользователя в виде ″IIS AppPool\имя пула приложений″. Так для пула приложений PubSite1 имя пользователя будет выглядеть ″IIS AppPool\PubSite1″;
• Проверяем имя клавишей Проверить имена (Check Names) и жмем ОК.

Также при желании можно воспользоваться утилитой командной строки ICACLS. Для примера дадим права на изменение для PubSite1:

ICACLS C:\Web\Pubsite1 /grant ″IIS AppPool\PubSite1″:M

Список разрешений выглядит следующим образом:

D – удаление;
F – полный доступ;
M – изменение;
RX – чтение и выполнение;
R – чтение;
W – запись.

Если ресурс находится в сети, то для доступа к нему лучше всего использовать учетную запись NetworkService. Рабочий процесс, запущенный под этим аккаунтом, для доступа к ресурсам использует учетные данные компьютера, сгенерированные при добавлении компьютера в домен. Для того, чтобы дать процессу доступ к сетевому ресурсу, в качестве пользователя указываем компьютер:

• Выбираем тип объекта (Object Type) Computers;
• В поле Размещение (Locations) выбираем домен;
• Вводим имя пользователя в виде domainname\machinename$, например contoso\SRV12$;
• Проверяем имя и жмем ОК.

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

Plesk Documentation and Help Portal

  • Administrator’s Guide, Plesk 12.0
  • About Plesk
  • About Plesk Users

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

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

Пул приложений IIS может работать в следующих режимах:

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


Чтобы изменить режим работы пула приложений IIS:

  1. Перейдите на страницу Инструменты и настройки >Пул приложений IIS.
  2. Перейдите на вкладку Глобальные настройки.
  3. Выберите нужный режим и нажмите OK.

Чтобы настроить дополнительные параметры пула приложений IIS:

  1. Перейдите на страницу Инструменты и настройки >Пул приложений IIS.
  2. Укажите максимальное допустимое количество рабочих процессов, обрабатывающих запросы для пула приложений IIS, и период бездействия рабочего процесса (в минутах), после которого его следует завершить.
  3. Чтобы ограничить объем ресурсов процессора, который может использовать пул приложений IIS, уберите галочку Без ограничений и укажите число (в процентах) в поле Максимальная загрузка ЦП (%), выберите действие, которое следует выполнить, когда рабочий процесс превысит максимальную загрузку ЦП, и укажите период сброса для наблюдения за использованием процессора в пулах приложений. Когда проходит указанное количество минут с момента последнего сброса, IIS сбрасывает таймеры ЦП для вывода в журнал и периодов ограничения.
  4. Выберите нужные опции перезапуска в зависимости от времени или потребления ресурсов, чтобы настроить периодический перезапуск пула приложений IIS и избежать нестабильных состояний, которые могут привести к сбоям, зависаниям и утечкам памяти в приложениях.
  5. Нажмите OK.

Чтобы остановить все приложения, запущенные в пуле приложений сервера:

  1. Перейдите на страницу Инструменты и настройки >Пул приложений IIS.
  2. Нажмите Stop (Остановить).

Чтобы запустить все приложения в пуле приложений:

  1. Перейдите на страницу Инструменты и настройки >Пул приложений IIS.
  2. Нажмите Start (Запустить).

Чтобы перезапустить все приложения в пуле приложений:

  1. Перейдите на страницу Инструменты и настройки >Пул приложений IIS.
  2. Нажмите Перезапустить. Это может оказаться удобным, если известно, что в некоторых приложениях произошла утечка памяти или они стали функционировать нестабильно после длительного времени работы.

Улучшение безопасности 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

Веб-приложения ASP.NET, разрабатываемые в среде Visual Studio, публикуются на веб-сервере IIS.

В настоящей статье рассмотрен пример размещения веб-приложения на IIS-севере.

Первым шагом необходимо выполнить настройку IIS.

Предварительно необходимо выполнить настройку сервера через средство администрирования IIS — Диспетчер служб IIS: зайдем в Панель управления -> Администрирование -> Диспетчер служб IIS.

Новый сайт (веб-приложение) будет размещено в узле по умолчанию (в моем случае это Default Web Site). Для этого вначале создадим в каталоге этого узла папку для приложения. По умолчанию каталогом для стандартного веб-узла является каталог C:inetpubwwwroot. Перейдем в этот каталог и создадим в нем папку web, которая будет содержать наше приложение.

Теперь возвращаемся в Диспетчер служб IIS, нажимаем правой кнопкой мыши на имя узла по умолчанию и в контекстном меню выбираем пункт «Добавить приложение«. Скриншот ниже.

В окне «Добавление приложения» необходимо ввести соответствующие настройки (в качестве физического пути приложения указывается каталог, созданный ранее):

Сайт у нас практически создан. Теперь осталось разместить в каталоге C:inetpubwwwrootweb приложение.

Вторым шагом выполняем публикацию приложения через Visual Studio.

Перейдем к созданному приложению в Visual Studio. Нажмем правой кнопкой на название проекта и в появившемся меню выберем «Опубликовать«.

В открывшемся окне мастера публикации необходимо выполнить ряд этапов.

Нажмем на кнопку «Настроить» и укажем название профиля. Название профиля может быть произвольным.

После ввода профиля откроется окно настроек публикации. Необходимо выбрать способ публикации «файловая система» и указать каталог для публикации приложения.

«Целевое расположение» может быть указано произвольно. Но в дальнейшем необходимо выполнить копирования опубликованного веб-приложения в каталог, созданный ранее — C:inetpubwwwrootweb.

После установки этих настроек, при нажатии кнопки далее откроется окно для установки ряда дополнительных опций.

Прежде всего здесь надо указать конфигурацию: Release или Debug. Кроме того, также можно указать целевой фреймворк и ряд дополнительных опций, такие как подключение к базе данных. Но в данном случае оставим все настройки по умолчанию и нажмем на кнопку «Опубликовать». После окончания процесса публикации по указанному пути появятся опубликованные файлы.

Следует учитывать, что каталог для веб-приложения, созданный в C:inetpubwwwroot — по умолчанию имеет права «только для чтения».

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

Plesk Documentation and Help Portal

  • Administrator’s Guide, Plesk 12.0
  • About Plesk
  • About Plesk Users

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

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

Пул приложений IIS может работать в следующих режимах:

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

Чтобы изменить режим работы пула приложений IIS:

  1. Перейдите на страницу Инструменты и настройки >Пул приложений IIS.
  2. Перейдите на вкладку Глобальные настройки.
  3. Выберите нужный режим и нажмите OK.

Чтобы настроить дополнительные параметры пула приложений IIS:

  1. Перейдите на страницу Инструменты и настройки >Пул приложений IIS.
  2. Укажите максимальное допустимое количество рабочих процессов, обрабатывающих запросы для пула приложений IIS, и период бездействия рабочего процесса (в минутах), после которого его следует завершить.
  3. Чтобы ограничить объем ресурсов процессора, который может использовать пул приложений IIS, уберите галочку Без ограничений и укажите число (в процентах) в поле Максимальная загрузка ЦП (%), выберите действие, которое следует выполнить, когда рабочий процесс превысит максимальную загрузку ЦП, и укажите период сброса для наблюдения за использованием процессора в пулах приложений. Когда проходит указанное количество минут с момента последнего сброса, IIS сбрасывает таймеры ЦП для вывода в журнал и периодов ограничения.
  4. Выберите нужные опции перезапуска в зависимости от времени или потребления ресурсов, чтобы настроить периодический перезапуск пула приложений IIS и избежать нестабильных состояний, которые могут привести к сбоям, зависаниям и утечкам памяти в приложениях.
  5. Нажмите OK.

Чтобы остановить все приложения, запущенные в пуле приложений сервера:

  1. Перейдите на страницу Инструменты и настройки >Пул приложений IIS.
  2. Нажмите Stop (Остановить).

Чтобы запустить все приложения в пуле приложений:

  1. Перейдите на страницу Инструменты и настройки >Пул приложений IIS.
  2. Нажмите Start (Запустить).

Чтобы перезапустить все приложения в пуле приложений:

  1. Перейдите на страницу Инструменты и настройки >Пул приложений IIS.
  2. Нажмите Перезапустить. Это может оказаться удобным, если известно, что в некоторых приложениях произошла утечка памяти или они стали функционировать нестабильно после длительного времени работы.

Расширенные возможности управления IIS 7.0 с помощью IIS Administration Pack

Для того, чтобы воспользоваться расширенными возможностями администрирования IIS 7.0, необходимо установить Administration Pack.

В состав Administration Pack входит набор модулей, расширяющих функциональность оболочки Internet Information Services Manager:

  • Configuration Editor – редактор конфигурации веб-приложения
  • .NET Authorization Rules – модуль управления правилами авторизации для приложения
  • .NET Error Pages – инструмент конфигурирования страниц, отображаемых в случае возникновения ошибок
  • FastCGI Settings – редактор конфигурации обработчиков CGI приложений, таких как PHP
  • Request Filtering – модуль фильтрации запросов к серверу
  • IIS Reports – инструмент создания графических отчетов по логам сервера

Configuration Editor

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

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

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

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

Что еще более удобно, инструмент позволяет экспортировать C#, JavaScript код или набор инструкций командной строки для автоматизации применения настроек блокировки на других серверах.

.NET Authorization Rules и .NET Error Pages

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

Модуль авторизации предлагает возможные варианты правил для разрешения или запрета доступа.

А модуль конфигурирования «ошибочных» страниц позволяет связать адрес страницы с HTTP кодом ошибки.

FastCGI Settings

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

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

Request Filtering

Модуль Request Filtering позволяет гибко настроить исключения для обрабатываемых запросов.

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

Помимо этого можно настроить общие ограничения на длину запроса и размер возвращаемого ответа.

IIS Reports

Инструмент IIS Reports позволяет оперативно получать удобную статистику по работе веб-сервера.

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

Инструмент поддерживает графическое представление в виде гистограммы и круговой диаграммы, а также экспорт отчетов в HTML.

Все вместе эти инструменты позволяют упростить управление веб-сервером IIS.

Как настроить сервер IIS для запуска ISAPI приложения?

Этот пост для тех, кто хочет узнать как настраивать IIS для работы ISAPI приложений и как их потом запускать. Предполагается, что ISAPI приложение уже создано и нам нужно только настроить IIS и запустить наше приложение на localhost

IISInternet Information Server – программа-сервер, от компании Microsoft (у меня на борту Windows 8.1 стояла версия IIS 8.5, единственное, нужно было её активировать).

Как настроить сервер IIS для запуска ISAPI приложения?

Теперь одна из самых важных вещей – настройка сервера IIS. Об этом я уже много и подробно писал в длинной и подробной статье “Delphi+UniGui. Пишем первый “Hello World” под WEB. Легко и просто”, поэтому в принципе, материал той статьи подойдет в большинстве своем и для этой статьи. Пэтому, часть того материала, я просто копирую.

Основные шаги по настройке IIS

Добавляем новый пул приложений

Назовем его, скажем, MyWebApps, версия среды – без управляемого кода, режим конвейера – встроенный. Делаем все как на картинке ниже

Заходим в настройки…

Включаем поддержку 32-разрядных приложений

Далее, настраиваем параметры перезапуска

Жмем Ок, выходим из этого окна.

Далее идем в сайты и добавляем новое приложение

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

Выбираем физический путь, например C:\WebAps

Далее, 2 раза кликаем на MyWebApplication на дереве слева

Далее, убеждаемся что ISAPI-dll находится в группе Enabled (Включен), если в группе Disabled (Выключен), то…

Включаем, если отключен

Далее
Далее, добавляем приложение в число разрешенных…

Выбираем физический путь

В итоге должно получиться так…

Как обратиться к ISAPI приложению в браузере?

Первый вариант – напрямую

Далее, можно попробовать открыть браузер и набрать в адресной строке

Илон Маск рекомендует:  Что такое код ccvs_reverse
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL