Iis специальные возможности iis


Содержание

Iis специальные возможности iis

Опубликовано: Февраль 2012 г.

Обновлено: Февраль 2012 г.

Назначение: Windows Server 2012, Windows Server 2012 R2

В этом документе описан процесс установки веб-сервера IIS и его настройки для обслуживания статического содержимого. Статическим содержимым является веб-страница (HTML), которая доставляется пользователю в том виде, в котором она хранится. И наоборот, динамическое содержимое формируется веб-приложением, таким как ASP.NET, классическим приложением ASP или приложением PHP. Статическое содержимое отображает одинаковые сведения для всех пользователей; динамическое содержимое может отображать сведения о конкретном пользователе, например имя пользователя.

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

Содержание документа

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

    Windows Server® 2012

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

Эту процедуру можно также выполнить с помощью пользовательского интерфейса Windows или командной строки.

На начальной странице щелкните плитку Диспетчер сервера, а затем нажмите кнопку ОК.

В диспетчере сервера выберите Панель мониторинга и щелкните Добавить роли и компоненты.

В мастере добавления ролей и компонентов на странице Перед началом нажмите кнопку Далее.

На странице Выбор типа установки выберите Установка ролей или компонентов и нажмите кнопку Далее.

На странице Выбор целевого сервера выберите Выбор сервера из пула серверов, выберите имя своего компьютера и нажмите кнопку Далее.

На странице Выбор ролей сервера укажите Веб-сервер (IIS) и нажмите кнопку Далее.

На странице Выбор компонентов просмотрите выбранные по умолчанию компоненты, а затем нажмите кнопку Далее.

На странице Роль веб-сервера (IIS) нажмите кнопку Далее.

На странице Выбор служб ролей просмотрите выбранные службы и нажмите кнопку Далее.

Примечание
Установите службы ролей IIS 8 по умолчанию для веб-сервера статического содержимого.

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

На странице Ход выполнения установки убедитесь, что установка роли веб-сервера (IIS) и требуемых служб ролей успешно завершена, а затем нажмите кнопку Закрыть.

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

http://localhost

Должна отобразиться страница приветствия служб IIS по умолчанию.

На начальной странице введите Панель управления, а затем в результатах поиска щелкните значок Панель управления.

В панели управления выберите Программы, а затем Включение и отключение компонентов Windows.

В диалоговом окне Компоненты Windows щелкните Службы IIS, а затем нажмите кнопку ОК.

Будет установлен набор компонентов IIS 8 по умолчанию. Установите только компоненты по умолчанию для веб-сервера статического содержимого.

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

http://localhost

Должна отобразиться страница приветствия служб IIS по умолчанию.

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

Start /w pkgmgr /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-Security;IIS-RequestFiltering;IIS-HttpCompressionStatic;IIS-WebServerManagementTools;IIS-ManagementConsole;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

На этом шаге поясняется, как добавить веб-сайт для служб IIS с помощью пользовательского интерфейса диспетчера служб IIS или путем запуска команд Appcmd.exe в окне командной строки

Откройте диспетчер служб IIS.

    При работе в Windows Server 2012 на начальной странице щелкните Диспетчер сервера, а затем нажмите кнопку ОК. В диспетчере сервера выберите меню Сервис, а затем выберите Диспетчер служб IIS.

При работе в Windows 8 на начальной странице введите Панель управления, а затем в результатах поиска щелкните значок Панель управления. На экране Панель управления выберите Системы и безопасность, затем Администрирование, после чего выберите Диспетчер служб IIS.

На панели Соединения правой кнопкой мыши щелкните узел Сайты, а затем выберите Добавить веб-сайт.

В диалоговом окне Добавление веб-сайта в поле Имя сайта введите понятное имя веб-сайта.

Щелкните Выбрать, если нужно выбрать пул приложений, отличный от пула, указанного в поле Пул приложений. В диалоговом окне Выбор пула приложений в списке Пул приложений выберите пул приложений, а затем нажмите кнопку ОК.

В поле Физический путь введите физический путь к папке веб-сайта или нажмите кнопку обзора (. ), чтобы перейти к файловой системе для поиска папки.

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

В списке Тип выберите протокол для веб-сайта.

. Если необходимо указать статический IP-адрес для веб-сайта (по умолчанию для этого параметра задано Все неназначенные), введите IP-адрес в поле IP-адрес.

В поле Порт введите номер порта.

Дополнительно введите имя заголовка узла для веб-сайта в поле Заголовок узла.

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

Нажмите кнопку ОК.

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

Примечание
Чтобы этот синтаксис работал, необходимо либо находиться в следующем каталоге, либо иметь каталог в пути: %windir%\system32\inetsrv

appcmd add site /name:string /id:цел_чис_без_зн /physicalPath:строка /bindings:строка

Переменная name является именем, а переменная id — положительным целым числом, которое следует назначить сайту. Переменные name и id являются единственными переменными, которые требуются для добавления сайта с помощью команды appcmd. Но при добавлении сайта без задания значений атрибутов bindings и physicalPath сайт будет невозможно запустить.

Переменная physicalPath является абсолютным путем к содержимому сайта в файловой системе.

Переменная bindings содержит сведения, используемые для доступа к сайту. Она должна иметь вид протокол/IP_адрес:порт:заголовок_узла. Например, если указать для веб-сайта привязку http/*:85: , то это будет означать, что он прослушивает HTTP-запросы на порту 85 для всех IP-адресов и доменных имен (также известных как заголовки узлов или имена узлов). С другой стороны, привязка http/*:85: marketing.contoso.com настраивает сайт для прослушивания HTTP-запросов на порту 85 для всех IP-адресов и доменного имени marketing.contoso.com.

Чтобы добавить веб-сайт contoso с идентификатором 2 и содержимым в папке c:\contoso, который прослушивает HTTP-запросы на порту 85 для всех IP-адресов и доменного имени marketing.contoso.com, введите в командную строку следующее:

appcmd add site /name:contoso /id:2 /physicalPath:c:\contoso /bindings:http/*:85:marketing.contoso.com

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

В представлении Просмотр возможностей диспетчера служб IIS дважды щелкните пункт Проверка подлинности.

На странице Проверка подлинности выберите Анонимная проверка подлинности.

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

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

    Если нужно настроить определенную учетную запись пользователя, которую службы IIS используют для доступа к вашему сайту или приложению, выберите Указанный пользователь. Затем нажмите Установить, чтобы открыть диалоговое окно Задание учетных данных, и введите имя пользователя и пароль для удостоверения. Затем нажмите кнопку ОК.

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

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

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

Используйте следующий синтаксис, чтобы изменить учетную запись по умолчанию для анонимного доступа:

appcmd set config /section:anonymousAuthentication /userName:строка /password:строка

Переменная username является учетной записью, используемой службами IIS для анонимного доступа, а переменная password — это пароль, который хранится в файле конфигурации по умолчанию в зашифрованном виде. Например, чтобы использовать учетную запись Moe и пароль pssword1 для анонимного доступа, в командной строке введите следующее:

appcmd set config /section:anonymousAuthentication /userName:Moe /password:pssword1

Если клиентский запрос к веб-сайту не содержит имени документа, службы IIS ищут файл, имя которого определено в качестве документа по умолчанию. Обычно именем документа по умолчанию является Default.htm. Можно определить список имен документов по умолчанию в порядке старшинства.

В представлении Просмотр возможностей диспетчера служб IIS дважды щелкните пункт Документ по умолчанию.

На панели Действия нажмите кнопку Добавить.

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

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

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

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

appcmd set config /section:defaultDocument /+files.[value=’строка‘]

Переменная string является добавляемым в список именем файла. Например, чтобы добавить файл home.html в список документов по умолчанию, в командной строке введите следующее:

appcmd set config /section:defaultDocument /+files.[value=’home.html’]

Чтобы удалить файл home.html из списка документов по умолчанию, в командной строке введите следующую команду и нажмите клавишу ВВОД:

appcmd set config /section:defaultDocument /-files.[value=’home.html’]

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

В представлении Просмотр возможностей диспетчера служб IIS дважды щелкните пункт Сжатие.

Выберите Включить сжатие статического содержимого для сжатия службами IIS статического содержимого.

В поле Статическое содержимое настройте следующие параметры:

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

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

Кроме того, можно установить флажок Лимит места на диске на пул приложений (в МБ) и ввести максимальный размер дискового пространства (в мегабайтах), отводимого для каждого пула приложений, которое будет использоваться службами IIS при сжатии статического содержимого. Например, если существует 20 пулов приложений на сервере и параметр Лимит места на диске равен 100, максимальный объем дискового пространства будет равен 2 ГБ. Если выбрать параметр Лимит места на диске на пул приложений (в МБ) и ввести в текстовом поле определенное значение, то при достижении порогового значения службы IIS автоматически очистят временную папку в соответствии с правилом удаления наиболее давно использовавшихся файлов. Значение по умолчанию — 100 МБ для каждого пула приложений.

Нажмите кнопку Применить на панели Действия.

Чтобы включить сжатие HTTP статического содержимого, в командной строке введите следующую команду и нажмите клавишу ВВОД:

appcmd set config /section:urlCompression /doStaticCompression:True

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

appcmd set config /section:urlCompression /minFileSizeforComp:цел_чис /directory:строка /maxDiskSpace:цел_чис

Переменная minFileSizeforComp служит для задания минимального размера файла в байтах, подлежащего сжатию. Значение по умолчанию — 256. Переменная directory служит для указания каталога, где временно сохраняются и кэшируются сжатые версии статических файлов. По умолчанию используется следующая папка:

%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files

Переменная maxDiskSpace служит для определения максимального количества места на диске (в мегабайтах) для каждого пула приложений, которое будет использоваться службами IIS при сжатии статического содержимого. Значение по умолчанию — 100 МБ для каждого пула приложений.

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

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

Для повышения защищенности веб-сервера настройте фильтрацию запросов. Инструкции см. в статье Настройка фильтрации запросов в IIS.

IIS 7.0: краткая инструкция для системного администратора. Часть 1 – установка.

Как я и обещал в посте несколько дней назад, начинаю писать серию постов типа инструкций шаг за шагом «как это установить и настроить» для тех админов, у которых действительно мало времени «на найти и разобраться», да еще если все это на английском языке. Кстати, кому таки не лениво – вот здесь очень хорошая подборка англоязычных документов под общим названием «Windows Server 2008 Step-by-Step Guides» — очень полезно в работе. Надеюсь, найдутся время и ресурсы, чтобы их тоже «отфильтровать» и сделать на их базе русские версии.

Если вам не интересны мои мысли «почему я пишу про IIS 7.0», можете смело пропустить пару абзацев.

В ближайший месяц я буду писать о веб-платформе от Microsoft, и в основном это будет касаться администрирования Internet Information Services 7.0 (IIS 7.0), входящего в состав Windows Server 2008. Это не значит, что я не буду писать ни о чем другом – конечно буду, у меня масса планов и тем с барселонского TechEd IT Forum 2008, в основном по направлению Windows Server 2008 R2, просто про администрирование IIS7 буду писать в этот месяц намного чаще и более последовательно, чем я это делал ранее. Поэтому даже те, для кого тема IIS7 не интересна, смогут как минимум раз в неделю находить у меня на блоге что-то интересное по другим тематикам.

Почему именно IIS 7.0? Здесь несколько причин. Во-первых, в уже упомянутом сборнике документов «шаг за шагом» «Windows Server 2008 Step-by-Step Guides» по странному стечению обстоятельств документа по IIS 7.0 почему-то нет. Во-вторых, как показывает опыт семинаров TechNet в Украине – знания, и даже можно сказать – представления многих админов о технологиях Microsoft для веб базируются на «сказках-страшилках» конца прошлого века, и хотелось бы показать всем желающим простой путь попробовать все технологии самостоятельно, без каких-то предрассудков и прочих ОБС. В-третьих – мне самому, человеку, который достаточно долгий период своей жизни занимался вебом вообще и IIS в частности – а я помню и IIS 2.0, и 3.0, и 4.0 и, конечно же, 5.0 – эта тема близка и интересна, и могу сказать, что за 10 лет в этом направлении Microsoft сделал существенные, даже можно сказать – эпохальные шаги вперед. Потому хотелось бы поделиться и опытом, и знаниями в этой прогрессирующей области с коллегами. В-четвертых – небольшой сюрприз в рамках проводимой в Украине акции для тех, кто разворачивает и управляет веб-серверами под управлением продуктов Microsoft – украинский офис Microsoft проводит акцию, по которой вы можете получить лицензионный Windows Server 2008 Web Edition (коробочная версия) бесплатно для хостинга ваших проектов и сайтов в Интернете. Так что торопитесь получить такой легальный продукт – пишите через блог на почту. И, наконец, в-пятых – в Киеве проводится полигон по веб-технологиям Microsoft, в том числе и IIS 7.0, так что мои статьи послужат хорошим фоном для такого мероприятия.

Ну, вроде это вcе наиболее веские причины писать в ближайший месяц о IIS 7.0. Кроме одной – зачем вообще админу знание IIS 7.0, который, в принципе, больше является платформой для разработчиков, на которой они делают свои веб-проекты? Проблема в том, что, как показывает опыт, разработчики не очень «напрягаются» созданием архитектуры и проработкой деталей веб-проекта, таких, как безопасность, администрирование, масштабирование и т.п. будущего работаеющего решения. И все это становится головной болью админа. Другая головная боль – это работодатели, которые часто под словом «компьютерщик» понимают, что человек может и спаять сгоревшую плату, и сетку настроить, и программку бухгалтерскую написать. И конечно же – веб сайт родной фирмы «Рога и Ко» сделать – как же без него. А то, что в ИТ отрасли есть глубокая специализация – никого не волнует. И вот потом и пишет мне в Live Messenger такой админ – «Игорь, а что делать?! За что хвататься?!», или если такого «Игоря», который бы подсказал, нет рядом – начинается такое.

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

Часть 1. Установка IIS 7.0

Первый вопрос, который мне задают – что такое веб сервер под Windows, что нужно установить? Ответ – вебсервер под Windows – это служба IIS 7.0. Следующий вопрос – где взять IIS 7.0, откуда скачать? Ответ очень простой – IIS 7.0 (как и предыдущие версии, начиная с IIS 5.0) интегрирован в саму серверную ОС Microsoft Windows Server 2008 (а предыдущие версии IIS – соответственно в Windows Server 2003 и Windows 2000) и устанавливается как роль Windows Server. Тогда более тривиальный вопрос – где взять «настоящий» Windows Server 2008? Пробную версию Windows Server 2008 для всех экспериментов и тестирования рекомендую брать только с сайта Microsoft http://www.microsoft.com/windowsserver2008 — проверенная и гарантированно правильная версия (только не забудьте установить все обновления). Серийный номер для Windows Server 2008 не требуется – вы просто при установке в мастере установки оставляете его пустым и на вопрос, хотите ли вы все же его заполнить – гордо отвечаете НЕТ. Фактически, если вы при установке или в ходе эксплуатации таки введете настоящий продуктовый номер – вы получите «настоящую» версию. Версия без введенного серийного номера работает 60 дней, после чего требует активации. Мало кто любит читать иструкции при загрузке файлов, особенно те, которые написаны мелким шрифтом – на самом деле, на странице загрузке есть ссылка на инструкцию, какой скрипт надо запустить, чтобы сбросить счетчик активации Windows снова на 60 дней. Такую операцию надо не забыть сделать до истечения 60дневного срока (например, на 59й день эксплуатации). Всего вы можете посторить операцию сброса счетчика 3 раза – т.е. пробную версию можно эксплуатировать 240 дней, что вполне достаточно с тем, чтобы распробовать плюсы и минусы системы. Ну а для желающих уже сейчас эксплуатировать лицензионный Windows Server 2008 для своих веб-проектов – напоминаю про акцию, пишите.

Теперь о выборе редакции, которых доступно аж 4 – Datacenter, Enterprise, Standard, Web Edition. Пожалуйста, подходите более ответственно к их выбору. Зачем, ну зачем использовать Enterprise для запуска веб-сайтов – «шоб було?». Для таких задач есть оптимизированная редакция Web Edition. Сравнение возможностей разных редакций можно найти там же, на официальном сайте http://www.microsoft.com/windowsserver2008. Кроме того, некоторые соображения по использованию лицензионных соглашений и виртуализации в разных редакциях я написал на этом блоге ранее.

После установки экземпляра Windows Server 2008 и его конфигурации (если это также вызывает затруднения – смотрим видео с семинара по Windows Server 2008) переходим непосредственно к установке IIS 7.0. Что нового в IIS 7.0, какие модули включены в него и т.д. – я рассматривать не буду, все теоретические выкладки можно найти в электронной версии журнала TechNet Magazine, которая выходит в том числе и на русском. IIS 7.0 были посвящены 2 статьи в мартовском и июльском номерах журнала. Рекомендую ознакомиться с ними перед практическим применение – знание теории, пусть даже в сжатой форме весьма полезно.

Основным нововведением в направлении установки различных компонент и служб в Windows Server 2008 является понятие «роли». Роль представляет из себя набор всех необходимых компонент, настроек системы, безопасности и т.п., которые необходимы для выполнения определенной задачи. Кроме того, имеется также информация о взаимодействии ролей между собой – одна роль может работать как подмножество другой и, наоборот – роли могут конфликтовать между собой – об этом администратор будет уведомлен при установке такой роли поверх уже существующих. Установку и конфигурацию всего необходимого система выполняет автоматически при выборе конкретной роли. Такой подход гарантирует, что даже в случае ошибки администратора, связанной с установкой той или иной роли, не требуемой в текущий момент – система будет функционировать нормально и это не затронет работоспособность других ролей. Как впрочем, это также существенно упрощает и сам подход к управлению системой Windows Server 2008 в целом.

Управление ролями осуществляется через стандартную оснастку управления Windows Server 2008 – Server Manager или в процессе начальной конфигурации сервера через Initial Configuration Tasks.

IIS 7.0 устанавливается как роль Windows Server 2008. Для этого требуется:

1. Запустить оснастку Server Manager из меню Start или из панели Quick Launch. Server Manager по умолчанию стартует автоматически при входе администратора в систему. Server Manager является основным инструментом управления сервером Windows Server 2008.

2. В оснастке на стартовой странице убедиться, что сервер сконфигурирован правильно. Желательно проверить наличие статического IP адреса. Если он не установлен, его можно поменять тут же, из консоли Server Manager, открыв в правой панели по линку «View Network Connections» сетевые интерфейсы.

3. Выбираем в левой панели Server Manager пункт Roles, в правой панели видим список текущих ролей. В зависимости от редакции ОС и установленных ролей список может варьироваться. В данном примере ни одна роль не установлена.

4. Для установки новой роли используем в правой панели в разделе «Roles Summary» линк «Add Roles».

5. Запускается мастер установки ролей «Add Roles Wizard», пропускаем первую страницу «Before You Begin» мастера, нажав кнопку «Next >»

6. На странице «Select Server Roles» в списке ролей выбираем роль «Web Server (IIS)». Список ролей может отличаться в зависимости от редакции. Данный список соответствует редакции Windows Server 2008 Enterprise Edition x64.

7. При выборе роли «Web Server (IIS)» мастер автоматически предлагает установить сервисы, которые требуются для функционирования веб сервера. Это службы активации процессов, фактически, они обеспечивают среду исполнения процессов, обслуживающих вебсайты. Соглашаемся с установкой данных служб путем нажатия кнопки «Add Required Features» и нажимаем кнопку «Next >» в мастере.

8. На странице «Select Role Services» отображается список всех доступных модулей (сервисов), входящих в состав IIS 7.0, представляющих 3 большие группы – Web, Management и FTP – и внутри сгруппированых по назначению – общие модули для поддержки HTTP Common HTTP Features, модули для исполнения сценариев и приложений Application Development, модули управления журналированием и диагностикой Health and Diagnostics, модули обеспечения безопасности Security, производительности Performance, модули управления и совместимости с предыдущей версией IIS 6.0 Management Tools, и, наконец, модули FTP. По умолчанию роль веб сервера IIS 7.0 устанавливается и конфигурируется в минимальном наборе из 9 модулей:

a. только для работы со статическим HTML контентом (модули из Common HTTP Features),

b. только с подключением анонимных пользователей и с фильтрацией вредоносных запросов (Security),

c. с базовыми модулями для журналирования запросов к вебсайтам на сервере и просмотра очереди запросов (Health and Diagnostics),

d. с модулем сжатия статического контента при передаче страниц клиенту HTTP (Performance),

e. и консоли администрирования в режиме локального подключения к веб серверу IIS Management Console.

9. На этом шаге можно добавить дополнительные модули в конфигурацию согласно задачам будущих вебсайтов, которые будут работать на данном вебсервере. Не рекомендуется «просто так» добавлять модули, особенно, если вы не знаете их назначение. Краткое описание каждого модуля можно найти прямо на странице (в правом верхнем углу), которое отображается, когда вы выбираете модуль в списке. Не стоит торопиться (или, наоборот, переставлять всю систему, если установили лишнее) – вы всегда можете доустановить модули к уже установленной роли, или удалить уже установленные модули. Функции, выполняемые наиболее важными модулями, а также их настройку, мы рассмотрим отдельно.

10. При отметке отдельного модуля для добавления, также, как и при выборе роли, мастер автоматически проводит проверку всех связей и зависимостей и предлагает установить дополнительные модули, без которых функционирование выбраного невозможно. В данном примере для установки выбран модуль ASP.NET и мастер автоматически запрашивает разрешение на установку других модулей и служб, необходимых для его работы. Соглашаемся с установкой данных служб и модулей путем нажатия кнопки «Add Required Role Services». По окончанию выбора всех модулей нажимаем кнопку «Next >» в мастере.

11. На странице «Confirm Installation Selection» отображается для подтверждения информация о всех выбранных модулях, которые будут установлены. Также отображаются служебные и информационные сообщения рекомендательного характера. Например, рекомендация после установки роли IIS 7.0 выполнить обновления ОС или установить Windows System Resource Manager (WSRM), который позволяет обеспечить распределение ресурсов системы при выполнении веб-приложений. Нажатие кнопки «Next >» на этой странице устанавливает весь указанный перечень модулей.

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

13. После закрытия окна мастера установки роли в левой панели консоли Server Manager в разделе «Roles» среди других ролей появляется подраздел «Web Server (IIS)». В правой панели отображается информация о состоянии всех установленных ролей.

14. Выбираем подраздел «Web Server (IIS)» в левой панели Server Manager, в правой панели отображается информация о работе роли веб сервера. Здесь представлены:

a. Events: агрегированный список записей из всех журналов событий ОС за последние 24 часа, имеющих отношение к работе веб служб,

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

c. Role Services: в данном случае – список всех модулей IIS 7.0 с указанием установлен данный модуль или нет и с возможностями старта мастера установки/удаления модулей данной роли (о котором мы говорили выше),

d. Resources and Support: наиболее интересный раздел информации о каждой роли, который содержит в себе базу знаний с рекомендациями по дополнительной более тонкой настройке той или иной роли для отдельных сценариев использования. Рекомендуется к широкому использованию.

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

Расширенные возможности управления 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 (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. Нажмите кнопку Готово.

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 специальные возможности iis

Основным компонентом IIS является веб-сервер — служба WWW (называемая также W3SVC), которая предоставляет клиентам доступ к сайтам по протоколам HTTP и, если произведена настройка, HTTPS.

Один сервер IIS может обслуживать несколько сайтов (IIS 6.0 и выше). Каждый сайт имеет следующие атрибуты:

  • IP-адрес сайта;
  • TCP-порт, на котором служба WWW ожидает подключений к данному сайту;
  • Заголовок узла (Host header name) — значение заголовка Host запроса HTTP, указывающее обычно DNS-имя сайта.

Таким образом, например, один сервер с одним IP-адресом может обслуживать на одном TCP-порту несколько сайтов. Для этого необходимо создать несколько DNS-записей, указывающих на IP-адрес сервера, и различать сайты по заголовкам узла.

Для каждого сайта указывается домашний каталог — каталог в файловой системе сервера, соответствующий «корню» сайта. Например, если сайту www.example.com сопоставлен домашний каталог D:\example, то на запрос ресурса с адресом http://www.example.com/index.htm веб-сервер вернёт файл D:\example\index.htm.

Архитектура службы WWW

В IIS 6.0, доступном в составе систем Windows Server 2003, служба WWW претерпела серьёзные изменения. Был добавлен новый режим обработки запросов, называемый режимом изоляции рабочих процессов (англ. worker process isolation mode ). В этом режиме все веб-приложения, обслуживаемые сервером, работают в разных процессах, что повышает стабильность и безопасность системы. Кроме того, для приёма запросов HTTP был создан новый драйвер http.sys, который работает в режиме ядра, что ускоряет обработку каждого запроса.

Все запросы к статическому содержимому, не требующие исполнения скриптов, исполняются самим драйвером http.sys в ядре, что сближает веб-сервер IIS с серверами режима ядра.

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

Протокол SSL поддерживается отдельным процессом HTTP SSL, который служит мостом между протоколом TCP и драйвером http.sys.

Безопасность в службе WWW

Веб-сервер IIS предоставляет несколько способов разграничения доступа к сайтам и веб-приложениям. Служба WWW в составе IIS отличается от других веб-серверов тем, что функции обеспечения безопасности в ней тесно интегрированы с системой Windows NT, на основе которой она работает. В частности, чтобы получить доступ к защищённому ресурсу, посетитель должен ввести имя и пароль пользователя, существующего в системе Windows, на которой установлен IIS (или в домене Active Directory, если сервер принадлежит к домену). После этого пользователь работает с сайтом так же, как если бы он выполнил интерактивный вход в систему на сервере. К нему применяются установленные файловой системой NTFS разрешения на доступ к файлам и каталогам. Эта особенность IIS удобна для внутренних сайтов предприятий, однако практически неприменима для открытых сайтов Интернета, где невозможно создавать пользователя Windows для каждого зарегистрированного посетителя сайта. Поэтому в последнем случае разработчикам сайтов и веб-приложений обычно приходится использовать собственные механизмы ограничения доступа.

Определённый пользователь Windows сопоставляется с каждым посетителем сайта даже в том случае, когда ограничение доступа не требуется. Этот режим называется режимом анонимного доступа. В этом случае посетитель представляется на сервере как специальный пользователь, имя которого обычно имеет формат IUSR_xxxx (где xxxx — имя компьютера, на котором установлен IIS, в седьмой версии этот специальный пользователь не содержит имени компьютера, то есть просто IUSR). Этому пользователю должен быть разрешён доступ к ресурсам, которые открыты анонимным посетителям.

Начиная с версии 6.0 служба WWW поддерживает следующие методы аутентификации, то есть определения личности пользователя по имени и паролю: [2]

  • Анонимная аутентификация (anonymous authentication) — определение личности пользователя не выполняется.
  • Базовая аутентификация (basic authentication) — имя и пароль передаются по сети открытым текстом.
  • Дайджест аутентификация (digest authentication) — пароль обрабатывается хеш-функцией перед отправкой по сети, что делает невозможным его прочтение в случае перехвата злоумышленником.
  • Встроенная аутентификация Windows (integrated Windows authentication) — выполняется попытка входа на сервер с теми же учётными данными, под которыми работает браузер пользователя.
  • Аутентификация для доступа к UNC-ресурсам (UNC authentication) — имя и пароль передаются удаленному серверу, на котором находится опубликованный в IIS UNC-ресурс, и удаленный сервер выполняет аутентификацию.
  • Аутентификация с использованием .NET Passport (.NET Passport Authentication) (удалена в Windows Server 2008 и IIS 7.0) [3] — для аутентификации используется служба .NET Passport.
  • Аутентификация с использованием клиентского сертификата (certificate authentication) — для аутентификации пользователь должен предоставить SSL сертификат.

Реализация веб-приложений для IIS

Веб-сервер IIS поддерживает несколько различных технологий создания веб-приложений:

  • ASP.NET — разработанная Microsoft технология; для IIS это — основное на сегодняшний день [4] средство создания веб-приложений и веб-служб. IIS 6.0 поставляется вместе с операционными системами, в которые также изначально входит .NET Framework, так что поддержка ASP.NET как будто уже встроена в IIS 6.0; для более ранних версий необходимо отдельно загрузить и установить .NET Framework.
  • ASP — предшествовавшая ASP.NET технология создания динамических веб-страниц на основе сценариев. Входит в поставку IIS начиная с версии 3.0.
  • CGI — стандартная межплатформенная низкоуровневая технология создания динамических веб-страниц.
  • FastCGI — клиент-серверный протокол взаимодействия веб-сервера и приложения.
  • ISAPI — низкоуровневая технология, аналогичная интерфейсу модулей Apache, предоставляющая полный доступ ко всем возможностям IIS, возможность разработки веб-приложений в машинном коде и возможность переопределения части функций IIS и добавления к нему функций, как связанных с генерацией контента, так и не связанных с этим. Подсистема исполнения скриптов ASP и подсистема ASP.NET выполнены как модули ISAPI.
  • SSI — включение в одни страницы текста из других страниц. Строго говоря, веб-приложением не является, поскольку IIS поддерживает лишь ограниченный набор возможностей и без того малофункционального SSI. В частности, IIS5 поддерживает только статическое включение и игнорирует команды условного ветвления.

Сам сервер поддерживает только CGI, FastCGI [5] , ISAPI и SSI. Все остальные технологии являются надстройками, работающими через CGI, FastCGI или ISAPI.

При помощи CGI приложения для IIS могут разрабатываться на основе практически любых, в том числе сторонних, инструментов, допускающих запись в стандартный поток вывода и чтение переменных среды — Perl, C/С++ и даже средствами интерпретатора командной строки Cmd.exe.

Технология ISAPI позволяет, с одной стороны, создавать специальные приложения для IIS, требующие особенно тесного взаимодействия с механизмом сервера, а с другой стороны является удобной платформой для организации эффективного взаимодействия IIS с другими технологиями разработки веб-приложений — например, PHP и Perl.

Почтовые возможности

IIS поддерживает работу SMTP/POP3 сервисов. В современных версиях Microsoft Exchange Server реализация протоколов SMTP, POP3 и IMAP выполнена в виде подсистем к IIS, заменяющих поставляемые с IIS почтовые подсистемы.

Улучшение безопасности 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 5.0 и IIS 4.0: скрытые различия

Секреты безопасного перехода на новую версию сервера Internet

В операционной системе Windows 2000 реализовано множество новых возможностей, в том числе очередная версия информационного сервера Internet — Microsoft IIS 5.0. Теперь уже не нужно разыскивать Windows NT 4.0 Option Pack, поскольку IIS 5.0 входит в состав ядра и поставляется на компакт-диске с Windows 2000.

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

Новая версия сервера существенно отличается от предыдущей. Многие отличия уже достаточно хорошо известны: новые методы аутентификации, более высокая производительность, возможность запускать приложения в режиме объединенных изолированных процессов (pooled-out-of-process). Другие особенности известны не так широко, но тем не менее и они важны.

[Прим. редакции: Out-of-process сервер — это компонент, который реализован в виде отдельной программы, содержащей объекты. Этот тип сервера всегда работает в собственном пространстве процессов и поэтому практически не зависит от каких-либо программ клиента.]

Установка

При установке IIS 4.0 пользователь должен указать, где разместить корневые каталоги Web- и FTP-сервера. Из соображений безопасности и оптимизации администраторы систем предпочитают не располагать корень Web-сервера на томе С.

Однако в процессе обычной установки Windows 2000 корневой Web-каталог IIS 5.0 размещается на С: без каких-либо указаний со стороны администратора. Единственный способ установить информационный сервер IIS 5.0 в другое место — это выполнить автоматическую (unattended) установку. Чтобы запустить такую установку, можно воспользоваться утилитой Sysocmgr, поставляемой вместе с Windows 2000, и указать место для корневого каталога Web, FTP и inetsrv (последний по умолчанию находится в каталоге c:winnt). Если после установки IIS 5.0 обнаружится, что все относящиеся к информационному серверу продукты располагаются на диске С, следует немедленно переустановить IIS 5.0 в автоматическом режиме с указанием правильного размещения корневых каталогов. Информацию об особенностях автоматической установки можно найти в одном из следующих источников:

  • в статье Microsoft «How to Change the Default Installation Paths for FTP and the Web» (http://support.microsoft.com/ support/kb/articles/q259/6/71.asp);
  • в материалах Windows 2000 Resource Kit Deployment Planning Guide;
  • в документе «Microsoft Windows 2000 Guide to Unattended Setup» (unattend.doc), в файле support oolsdeploy.cab на компакт-диске Windows 2000.

Изменения в структуре файлов и каталогов

Каталог IISHelp. Справочный каталог IIS 5.0 — IISHelp — находится в каталоге \%systemroot%winnthelpiishelp. Help-файлы предыдущей версии, IIS 4.0, расположились там же, только каталог назывался раньше iis, а не iishelp. Справочные файлы зачастую «завязаны» со всевозможными административными инструментами, мастерами (wizard) и программами, доступ к которым должен быть ограничен. По этой причине в IIS 4.0 изначально заложена некоторая угроза безопасности, поскольку общедоступным объявляется весь справочный каталог целиком, включая файлы NT Help, что отображается в виде некоторого виртуального каталога на сайте Default Web. В IIS 5.0 виртуальный каталог Help отображается на сайте Default Web в каталог iishelp, а не в родительский каталог help.

Каталог Adminscripts. Примеры административных сценариев IIS 5.0 содержатся в файлах .vbs. Они демонстрируют возможности Microsoft Active Directory Service Interfaces (ADSI), связанные с обслуживанием Web-сервера. Найти каталог сценариев Adminscripts можно в inetpub. Для IIS 4.0 аналогичные данные были размещены в каталоге Adminsam-ples по адресу: \%systemroot%system32inetsrv.

Default-документы. В процессе установки IIS 4.0 создавались сайты Default Web и Administrative Web. На сайте Default располагался документ, который отображался всякий раз при обращении к «новоиспеченному» серверу. IIS 5.0 не создает подобный документ, вместо этого формируется активная серверная страница IIS-Start.asp. Когда происходит обращение к IISStart.asp, система проверяет, локальное это обращение или удаленное. Если локальное, то IISStart.asp запускает localstart.asp. Если запрос удаленный, то выдается сообщение Under Construction. Приложение IIS-Start.asp выполняется только в том случае, когда нет ни файла de-fault.asp, ни файла default.htm. Если создать такой default-документ, то он будет использоваться вместо IIS-Start.asp в процессе запуска IIS 5.0.

Каталог IISADMPWD. Сайт Default Web IIS 4.0 содержал виртуальный каталог IISADMPWD, где хранились файлы, с помощью которых пользователи могли менять пароли своих учетных записей через Web-браузер. Если выполняется «чистая» установка IIS 5.0 (т. е. не обновление IIS 4.0, а установка «с нуля»), то выясняется, что сайт Default Web больше не содержит виртуальный каталог IISADMPWD. Однако, несмотря на это, все необходимые файлы для изменения паролей через Web-браузер на сервере присутствуют. Чтобы предоставить пользователям доступ к этим файлам, нужно следовать рекомендациям, изложенным в статье Microsoft «IISADMPWD Virtual Directory Is Not Created During Clean Install of IIS 5.0» (http://support.microsoft.com/ support/kb/articles/q269/0/82.asp). Предоставление пользователям права менять пароль через обычный Web-браузер сопряжено с определенным риском. Об этом подробнее рассказано в других статьях Microsoft — «Malformed HTR Request Returns Source Code for ASP Scripting Files» (http://support.microsoft.com/ support/kb/articles/q260/0/69.asp) и «GET on HTR File Can Cause a `Denial of Service` or Enable Directory Browsing» (http://support.microsoft.com/ support/kb/articles/q267/5/59.asp). Кроме того, в первом номере нашего журнала за 2001 г. этому посвящена статья Кена Спенсера «Изменение паролей через Internet».

Отличия в работе

Неудаляемый анонимный пользователь. Во время установки IIS 5.0 и IIS 4.0 создается учетная запись IUSR_servername. С ее помощью регистрируются анонимные соединения с Web-сервером. Из соображений безопасности администраторы IIS 4.0 зачастую удаляют или переименовывают учетную запись IUSR_servername. При попытке удалить или переименовать аналогичную запись IUSR в IIS 5.0 программа воссоздаст ее при перезагрузке сервера. Единственный «обходной маневр» — создать и использовать аналог учетной записи IUSR без префикса IUSR в ее названии. Более подробно об этом рассказано в статье Microsoft «Correction and Addendum to Internet Information Services 5.0 Release Notes» (http://support.microsoft.com/ support/kb/articles/q254/2/60.asp).

Меньшая зависимость от реестра. Одно из наиболее серьезных скрытых отличий IIS 5.0 состоит в практически полной зависимости настроек сервера от метабазы данных, а не от реестра системы. Метабаза IIS 5.0 содержит множество параметров, которые в версии IIS 4.0 хранились в разделах реестра. Этот факт не так очевиден, поскольку раздел HKEY_LOCAL_MAC-HINESystem CurrentControlSetServicesInetinfo по-прежнему присутствует в реестре и отражает определенную информацию для новой версии IIS точно так же, как это было в предыдущей версии. На самом деле такой раздел нужен только для обеспечения обратной совместимости с IIS Microsoft Management Console (MMC).

WWW Distributed Authoring and Versioning (WebDAV). WebDAV — это разработанный с целью расширения возможностей протокола HTTP функциями файлового ввода/вывода. RFC 2518 описывает стандарт WebDAV, который позволяет открывать, сохранять, переименовывать, осуществлять поиск, создавать, изменять и удалять файлы на сервере IIS 5.0 непосредственно из приложений Microsoft Office, рабочего стола Windows 2000 и браузера Microsoft Internet Explorer (IE) 5.0.

WebDAV автоматически активизируется в версии IIS 5.0, и отключить его невозможно. Сервер IIS 5.0 выполняет постоянный мониторинг всего HTTP-трафика на предмет присутствия Web-DAV-команд, в том числе связанных с собственным изобретением Microsoft — Translate header. Когда сервер распознает команду WebDAV, Web-сервер обращается к расширению Internet Server API (ISAPI) — библиотеке httpext.dll — для обработки WebDAV-запроса. Web-DAV не зависит от расширений файлового API, поэтому нельзя найти httpext.dll в ссылках приложений, запущенных на IIS 5.0. Хотя httpext.dll — это расширение ISAPI, избавиться от него не удастся.

Контроль операций файлового ввода/вывода на Web-сервер — основа системы безопасности Web, а стандарт WebDAV разрешает пользователям выполнять файловые операции; таким образом, применение Web-DAV создает потенциальную угрозу безопасности. Для предотвращения доступа к файлу с использованием стандарта WebDAV обычная фильтрация на уровне порта не помогает, поскольку обращение к файлу осуществляется через HTTP-порт (порт 80).

Для того чтобы записать файлы на сервер через WebDAV, необходимо разрешение на запись для IIS 5.0 (IIS 5.0 Write). Это разрешение не привязано к определенному пользователю, и его активизация предоставляет всем пользователям право записывать файлы на Web-сервер. Так что, разрешая использовать WebDAV, администратор вынужден полностью полагаться на систему прав NTFS, чтобы проконтролировать доступ к файлам. Но право записи IIS 5.0 тем не менее не дает пользователям возможности модифицировать Active Server Pages (ASP) или другие файлы сценариев.

Экран 1. Предоставление доступа к тексту сценария.

Чтобы редактировать файлы сценариев, следует установить флажок Script source access, единственное свойство WebDAV, которое можно настраивать в IIS 5.0. На Экране 1 показана вкладка Home Directory в окне Default Web Site Properties. Когда устанавливаются флажки Script source access и Write и используется WebDAV-приложение, открывающее ASP или иной связанный с ним файл сценария, IIS 5.0 передает исходный текст ASP, вместо того чтобы выполнять код ASP, и посылает результат HTML. Флажок Script source access можно установить как на уровне всего Web-сайта, так и для отдельных страниц.

С применением WebDAV также связаны такие проблемы, как отказ в обслуживании (Denial of Service (DoS), блокировка файлов и нелегальный доступ к исходным текстам. В ответ на проявившиеся проблемы после внедрения WebDAV-программирования (в частности, команды Translate:f) Microsoft выпустила бюллетень безопасности Security Bulletin MS00-058, «Patch Available for `Specialized Header` Vul-nerability» (http://www.microsoft.com/technet/ security/bulletin/ms00-058.asp). Некоторые вопросы на ту же тему рассматриваются в статьях Microsoft «Internet Information Service May Re-turn Source of Active Server Pages File» (http://support.microsoft.com/ support/kb/articles/q256/8/88.asp) и «The Translate:f Security Hole» (http://www.4guysfromrolla.com/ webtech/0815001.shtml). Дополнительную информацию об остальных настройках системы безопасности можно найти в документации WebDAV, включенной в состав IIS 5.0.

Application mappings. Сервер IIS использует отображение приложений (application mappings) для привязки файлов с различными расширениями к тем или иным исполняемым программам. К примеру, в соответствии с алгоритмом application mappings файлы с расширением ASP перенаправляются для обработки asp.dll. При желании можно добавить новое отображение, чтобы позволить IIS воспользоваться файлами сценариев практически любого типа (Perl, Rexx или PHP).

Чтобы добраться до вкладки App Mappings в IIS 5.0 или IIS 4.0, нужно выбрать вкладку Home Directory в окне Default Web Site Properties, щелкнуть Configuration и затем App Mappings. Того же результата можно добиться путем установки произвольного виртуального каталога в качестве приложения.

Экран 2. Закладка IIS 5.0 App Mappings с разрешенными командами.

Экран 2 иллюстрирует вкладку App Mappings для IIS 5.0, а Экран 3 — для версии IIS 4.0. Стрелки, указывающие на правые колонки на том и другом экране, подчеркивают существенное различие между IIS 5.0 и IIS 4.0. Колонки озаглавлены по-разному: для IIS 5.0 — это Verbs, а для IIS 4.0 — Exclusions. По умолчанию, IIS 5.0 не разрешает использовать новые команды (verbs) в спецификации HTTP. Устанавливая связь приложение-исполняемый модуль, нужно указать команды, разрешенные системой для работы с HTTP. Сервер IIS 4.0, наоборот, по умолчанию разрешает использовать новые команды. Поэтому для IIS 4.0 нужно указать команды, запрещенные системой (исключения).

Экран 3. Закладка IIS 4.0 App Mappings с запрещенными командами.

Если проигнорировать сказанное или не заметить разницу в заголовках колонок App Mappings и указать исключенные команды (к примеру, DE-LETE и PUT), вместо разрешенных (к примеру, GET и POST) сервер возвратит сообщение об ошибке 403.1 Execute Access Forbidden («Исполнение запрещено»), сопроводив его маловразумительным дополнением: «You have attempted to execute a CGI, ISAPI or other executable program from a directory that does not allow programs to be executed.» («Попытка выполнить CGI, ISAPI или другую программу из каталога, который не предназначен для выполнения программ».) Поддавшись на это провокационное сообщение, можно никогда не отыскать причину ошибки. Система аудита здесь не поможет, так же как ничего не удастся добиться ни с помощью программы Filemon (выполняет мониторинг используемых в системе файлов, доступна по адресу: http://www.sysinternals.com), ни с помощью иной техники мониторинга, основанной на анализе разрешений NTFS (разрешения исполнять программы в данном случае). Предоставление группе Everyone права Full Control на исполняемые файлы тоже проблемы не решит.

Организация пула сокетов (Socket pooling). Когда для создания Web-сайта используется IIS 4.0, Web-сервер выделяет TCP-сокеты специально для Web-сайта. Например, если создано 20 Web-сайтов, каждый со своим IP-адресом, IIS 4.0 назначает сокет-соединение для каждого из этих 20 сайтов, и каждый из них «прослушивает» 80-й порт. В этом случае ограничиваются масштабируемость и производительность, поскольку ресурсы, занимаемые незадействованными сокетами, не могут использоваться другими сайтами.

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

Если Web-сервер имеет только один IP-адрес, то, вероятнее всего, для создания нескольких Web-сайтов на одном адресе IP используются заголовки хоста (host headers). Пул сокетов не поддерживает сайты такого типа, организация связного пула доступна только для Web-сайтов с различными IP-адресами. В оперативной документации по сайтам второго типа (основанные на анализе заголовка хоста) этот нюанс в работе IIS 5.0 описан недостаточно внятно.

В файле Readme из состава IIS 5.0 (см. статью Microsoft «Contents of Internet Information Server 5.0 Release Notes» по адресу: http://support.microsoft.com/ support/kb/articles/q250/9/79.asp) показаны скрытые различия в организации пула сокетов. Если для повышения производительности системы выполняется тонкая настройка одного из Web-сайтов, работающих на пул, это неизбежно оказывает воздействие и на все остальные Web-сайты в пуле сокетов. Отрегулировать параметры производительности Web-сайта можно на вкладке Performance в окне Default Web Site Properties, как показано на Экране 4.

Экран 4. Настройка производительности Web-узла.

Можно отключить функцию организации связного пула для IIS 5.0 для отдельно взятого сайта или сервера. Для отключения связного пула на сервере нужно набрать команду

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

где х — это номер Web-сайта. IIS 5.0 использует нумерацию, а не имена Web-сайтов, для того чтобы идентифицировать различные Web-сайты. IIS 5.0 назначает номера в той последовательности, в которой сайты создавались. С помощью программы MetaEdit 2.1 (ее можно загрузить по адресу: http://support.microsoft.com/ support/kb/articles/q232/0/68.asp) можно выяснить номера Web-сайтов, о которых идет речь. Номер Web-сайта также определяется с помощью следующей команды:

где websitename — это имя данного сайта, которое показывает Internet Service Manager (ISM). Важное замечание: команда чувствительна к регистру.

Протоколирование работы. Если в журналах IIS 5.0 или IIS 4.0 отображается неверное время, проблема может заключаться в том, что вместо локального времени сервера используется время по Гринвичу (Greenwich Mean Time, GMT). В соответствии со стандартом консорциума World Wide Web Consortium (W3C) в работе сервера IIS применяется GMT, поэтому программа, отвечающая за журнал событий, должна выполнять конвертацию GMT в локальное время. Для этого можно воспользоваться утилитой Convlog из состава Microsoft Windows Internet Information Server Resource Kit или же пакетом Windows 2000 Resource Kit.

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

IIS 5.0 обладает новым свойством, разрешающим проблему перехода даты. В окне Properties Web-сайта нужно последовательно выбрать вкладку Web Site, Enable Logging, W3C Extended Logging Format как Active Log Format и щелкнуть Properties. На вкладке General Properties в окне Extended Logging Properties (см. Экран 5) можно установить флажок Use local time for file naming and rollover, чтобы журнальные файлы формировались с учетом перехода даты в локальной временной зоне. Но вот датировка самих записей внутри файлов по-прежнему соответствует Гринвичу. Напоминаю, что сказанное относится к IIS 5.0.

Экран 5. Настройка IIS 5.0 для использования локального времени при создании журналов.

Для версии IIS 4.0 также можно настроить использование локального времени при определении перехода даты и именовании журнальных файлов, хотя технически это несколько сложнее, чем для IIS 5.0. В соответствии с рекомендациями, изложенными в статье Microsoft «Log Files Rolled Over According to GMT, Not Local Time Zone» (http://support.microsoft.com/ support/kb/articles/q193/6/12.asp), нужно набрать следующую команду для установки ключа метабазы в соответствии с локальным временем сервера:

В этой команде w3svc — это название раздела метабазы Web-сервера, а х — номер Web-сайта, для которого устанавливается локальное время регистрации журналов. Это решение можно использовать для любого сервера NT 4.0 с установленным Service Pack 5 (SP5) или SP4. В пакете исправлений SP6 описанная проблема с переходом даты решена.

Сквозная аутентификация (pass-through authentication). При создании виртуального каталога, который отображается на сетевой диск (remote share), требуется указать имя и пароль, чтобы система предоставила доступ к сетевому диску. Каждое очередное обращение к виртуальному диску будет происходить в контексте безопасности указанного имени и пароля, если только специально не указать в настройках сервера (справедливо и для IIS 4.0, и для IIS 5.0), что можно учитывать данные зарегистрированного пользователя. Такое использование учетных данных для аутентификации при обращении к сетевому диску называется pass-through authentication («сквозная аутентификация»).

Если требуется подключить сквозную аутентификацию для сервера IIS 5.0, нужно воспользоваться методом, который, с одной стороны, поддерживает сквозную аутентификацию, а с другой — создает в метабазе соответствующую запись. Сквозными называются следующие методы аутентификации: Anonymous (пароль не указывается), Basic и Integrated Windows. При использовании метода Integrated Windows в системе, настроенной на работу по протоколу Kerberos, сквозная аутентификация также поддерживается. Но для работы по протоколу Kerberos должны выполняться определенные требования:

  • клиент: Windows 2000 + IE 5.0 или старше;
  • сервер: Windows 2000 + IIS 5.0;
  • клиент и сервер принадлежат одному домену или находятся в доменах, связанных доверительными отношениями;
  • сервер IIS 5.0 сконфигурирован для использования метода Integrated Windows;
  • и, наконец, сервер Windows 2000 и ресурс Web, к которому происходит обращение, должны иметь одинаковые имена или же нужно использовать программу Setspn (входит в состав Windows 2000 Resource Kit) для регистрации имени Web в качестве нового имени Service Principal Name.

Для редактирования метабазы можно воспользоваться файлом сценария или программой MetaEdit 2.1. Приведенный ниже ASP-код активизирует сквозную аутентификацию на IIS 5.0 для виртуального каталога Protected на сайте Default. При этом нужно указать номер Web-сайта вместо единицы (1), а также имя виртуального каталога, названного в нашем случае Protected.

Команда IISReset. Остановка и запуск IIS 4.0 — процесс весьма сложный, но перезапускать Web-сервер из-за всевозможных «подвисаний» приходится часто. Многие администраторы IIS 4.0 в штатном режиме перезапускают серверы в ночное время либо используют командные файлы для перезапуска остановленных служб.

Для решения этой проблемы разработчики Microsoft добавили в Windows 2000 команду IISReset.exe. Это утилита командной строки, которая позволяет останавливать и запускать IIS 5.0 и зависимые службы. Чтобы остановить службы Internet, следует вместо значка Services в панели управления воспользоваться командой IISReset. В документации отмечается: «You should use the (IISReset) method, and not the Windows 2000 Services snap-in, for restarting Internet services. Because several Internet services run in one process, Internet services shut down and restart differently from other Windows services.» («Для перезапуска служб Internet следует использовать метод IISReset, а не оснастку Windows 2000 Services. Поскольку некоторые службы Internet функционируют как единый процесс, остановка и перезапуск служб сервера Internet протекают иначе, чем те же операции с другими службами Windows 2000».)

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

где seconds — время в секундах.

Экран 6. Настройка Windows 2000 для запуска IISReset.

Если IIS 5.0 не отвечает, можно запустить IISReset через Windows 2000 Service Control Manager (SCM). Для активизации этой возможности следует открыть контекстное меню IIS Admin Service приложения IIS 5.0 Services, выбрать Properties и щелкнуть на вкладке Recovery (см. Экран 6). На экране приведены установки по умолчанию, но при необходимости можно описать процедуру восстановления и задать необходимые временные параметры. На Экране 6 указано, что при любом сбое (первом, втором и всех последующих) будет вызываться программа IISReset. В поле Run file описывается файл, запускаемый после каждого сбоя (в данном случае указан C:WINNTSystem32iisreset.exe). Администратор может задать различные действия после первого, второго и всех последующих сбоев, а также вызвать специально разработанную программу, которая перезапустит остальные процессы, запишет нужные сообщения в журналы событий или оповестит обслуживающий персонал. Для вывода всех параметров, перечисленных в документации на IIS 5.0 для команды IISReset, достаточно просто набрать в командной строке:

SSL-соединения и Client Access Licenses

В дискуссионной статье, затрагивающей вопросы реализации сервера IIS 5.0 («Deploying Windows 2000 with IIS 5.0 for Dot Coms: Best Practices», http://www.microsoft.com/ technet/iis/iisdtcom.asp), отмечается, что .COM-бизнес должен иметь достаточное количество клиентских лицензий (Client Access Licenses, CAL) для использования всех доступных соединений Secure Sockets Layer (SSL).

При работе с Windows 2000 необходимо, чтобы каждый зарегистрированный пользователь обладал своей лицензией (CAL), а система, в свою очередь, ограничивает число одновременно подключенных пользователей количеством лицензий, приобретенных при покупке системы. Служба Windows 2000 License Logging Service отслеживает соблюдение этих правил. Если попытаться отключить эту службу, то Windows 2000 установит максимальное число одновременных соединений равным 10.

Неизвестный для большинства администраторов систем второй счетчик — счетчик SSL-соединений — существует отдельно от счетчика пользователей, прошедших аутентификацию. Windows 2000 + SP1 ограничивает число SSL-соединений, включая анонимные, количеством клиентских лицензий — CAL. Другими словами, имея 10 CAL, можно установить 10 зарегистрированных и 10 анонимных соединений одновременно. Т. е. лимит SSL-соединений существует, и если он превышен, то выводится сообщение:

Поскольку не имеет смысла ограничивать число анонимных SSL-соединений количеством закупленных клиентских лицензий, Microsoft Product Support Services (PSS) выпустила специальную заплатку. Дополнительную информацию о поведении IIS 5.0 при превышении лимита CAL можно найти в статье Microsoft «Error Message: HTTP 403.15 — Forbidden: Client Access Licenses Exceeded» (http://support.microsoft.com/ support/kb/articles/q264/9/08.asp). Можно модифицировать реестр, чтобы помешать IIS 5.0 и службе License Logging Service препятствовать созданию SSL-сессий. В раздел реестра HKEY_LOCAL_MACHINESYSTEM CurrentControlSetServicesW3SVCParameters нужно добавить параметр EnableCAL (тип REG_DWORD) и установить его значение равным 0. В статье Microsoft «What`s New in the Windows 2000 Server Licensing Model» (http://www.microsoft.com/windows2000/ guide/server/pricing/changes.asp) объясняется, что нарушения лицензионного соглашения с Microsoft не происходит, если число имеющихся лицензий CAL меньше числа анонимных SSL-соединений.

SSL и групповые символы (wildcards)

В IIS 4.0 если несколько сайтов размещаются на одном хосте или используется множество серверов одного домена (например, mysite.com), то в сертификате можно использовать групповой символ (например, *.mysite.com) для описания Common Name (CN) и присвоить этот сертификат всем сайтам или серверам. Работать с групповыми символами можно в том случае, если лицензия допускает многократное использование. К сожалению, IIS 5.0 уже не поддерживает групповые символы для описания CN. Если же Common Name сервера IIS 5.0 не соответствует DNS-имени, браузер пользователя выведет сообщение о том, что сертификат не соответствует запрашиваемому сайту. Пользователь должен будет подтвердить, что с сайтом установлены доверительные отношения.

Через некоторое время планируется выпустить заплатку для исправления этой ошибки (Windows 2000 SP1 проблему не решил). Подробнее о групповых символах CN рассказано в статье Microsoft «Accepted Wildcards Used by Server Certificates for Server Authentication» (http://support.microsoft.com/ support/kb/articles/q258/8/58.asp).

Переход к IIS 5.0

Существует еще ряд отличий между версиями IIS 4.0 и IIS 5.0, включая изменения в ASP, использование ODBC, COM+, MetaEdit, появление новых мастеров и шаблонов безопасности, изменения в настройках реестра. Большая часть изменений в IIS 5.0 существенно облегчает работу и демонстрирует способность Micro-soft извлекать уроки из неудач в реализации IIS 4.0. Я полагаю, что на версию IIS 5.0 следует перейти, как только представится такая возможность.

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

Брет Хилл — автор, инструктор и консультант по Microsoft IIS. Ведет сайт www.IISAnswers.com. Имеет сертификаты MCSE, MCT, MCP+Internet и A+/Network+. С ним можно связаться по адресу: brett@iisanswers.com.

Поделитесь материалом с коллегами и друзьями

Iis специальные возможности iis

Эту статью не стоит рассматривать как полноценное руководство по безопасности при настройке Internet Information Services версии 7.x — для того уже существует несколько талмудов, которые описывают предмет нашего разговора во всей его красе. Но не у всякого администратора имеется возможность досконально изучить эти книги, а конфигурировать веб-сервер надо уже сейчас. Поэтому хочется опубликовать краткий обзор мер безопасности, которые необходимо иметь в виду, работая с IIS , некий чек- лист что ли, по которому можно быстро пробежаться, сравнить с требованиями своего проекта и корпоративными гайдами по информационной безопасности.

Обозначение 7.x означает, что здесь собран материал для обеих версий продукта: IIS 7 , поставляемый с Windows Server 2008 и Windows Vista , и IIS 7.5 , который Вы можете найти в «коробке» от Windows Server 2008 R2 и Windows 7 .

Все меры, представленные в данной подборке, ни в коем случае не являются ОБЯЗАТЕЛЬНЫМИ. Более того, они могут даже противоречить системным требованиям Ваших веб-приложений. Решение о принятии той или иной меры все таки необходимо выносить в условиях конкретной ситуации. Здесь меры будут носить лишь ОПИСАТЕЛЬНЫЙ характер, чтобы администратор знал — вот здесь еще можно подкрутить ;)

Все ответы

Основы безопасности IIS

Административные меры безопасности IIS

Максимальное усиление безопасности IIS

Кратко об Internet Information Services 7.x

Internet Information Services 7.x — компонент веб-сервиса компании Microsoft для операционной системы Windows Server 2008 (R2) .

На момент написания данного материала IIS 7.5 является последним в длинной линейке версий IIS . Начиная с версии 6.0, Microsoft в цикле разработки данного продукта решила сосредоточить особое внимание на безопасности и непрерывно следует этому подходу до сих пор. В результате IIS 7.x поставляется с большим количеством изменений по сравнению со своим предшественником и имеет огромное количество новых возможностей, которыми только надо умело пользоваться. IIS 7.x был полностью переработан и сейчас базируется на новой модульной архитектуре. Это означает, что вместо монолитного «черного ящика», который устанавливается по умолчанию и имеет лишь пару дополнительных возможностей, IIS 7.x теперь имеет около 40 отдельных компонентов — так называемых модулей. По умолчанию устанавливаются только самые основные модули; дополнительные же могут быть легко добавлены в случае необходимости. Это помогает значительно уменьшить площадь атаки на сервер, просто потому, что ненужные средства отсутствуют в системе. Модульная архитектура имеет множество преимуществ, и в части безопасности, и в администрировании, и в производительности веб-сервера. Кроме того, IIS 7.x не ограничивает Вас набором предразработанных модулей — пишите свои, если хотите заменить существующие, или есть требование расширить функциональность веб-сервера.

Начало работы с IIS 7.0

Written on 21 Января 2009 . Posted in Web-серверы

ОГЛАВЛЕНИЕ

Новая архитектура IIS 7.0

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

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

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

В данный момент в состав IIS входит 40 модулей по умолчанию — например, обычная, анонимная проверка подлинности и проверка подлинности Windows® теперь выделены в отдельные модули, которые могут добавляться к конвейеру обработки запросов независимо. Для упрощения классификации модули сгруппированы в восемь подкатегорий (см. рис. 1).

Рис. 1 Модули IIS 7.0 разделены на восемь функциональных областей

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

Встроенный конвейер обработки запросов

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

Рис. 2 Интегрированный конвейер и модули IIS 7.0

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

Установка по умолчанию

Рассмотрим настройку нового модульного веб-сервера. Если взглянуть на установку IIS 7.0 по умолчанию, можно заметить, что включены только 10 модулей (если включена служба активации процессов Windows). Настройка IIS 7.0 предоставляет базовую функциональность IIS при установке роли веб-сервера, в частности, только модули, необходимые для предоставления статического содержимого, например, обычного кода HTML или классических страниц ASP. Последующая установка дополнительных компонентов на сервере определяется только вами. Ниже приведены функциональные возможности, включенные в установку по умолчанию:

  • Основные функции HTTP, включая статическое содержимое, документ по умолчанию, обзор каталога и ошибки HTTP
  • Функции работоспособности и диагностики, такие как ведение журнала HTTP и монитор запросов
  • Функции безопасности, такие как фильтрация запросов
  • Функции повышения производительности, такие как сжатие статического содержимого
  • Средства управления, в том числе консоль управления IIS
  • Служба активации процессов Windows

Как видите, это сервер с минимально необходимым количеством компонентов, в состав включающий ASP.NET и другие новые функции IIS 7.0, такие как функции диагностики и устранения неисправностей. Добавление на сервер дополнительных функциональных возможностей, таких как возможность передачи динамического содержимого, например, ASP.NET и FastCGI (PHP), осуществляется очень просто. Выберите необходимый для установки набор модулей в разделе «Add Role Services» (Добавление служб роли) роли веб-сервера в диспетчере Windows Server® 2008 Server Manager.

Новое хранилище настроек

Другим ключевым изменением в IIS 7.0, упрощающим вашу работу, является новое хранилище настроек. Метабаза, теперь являющаяся дополнительным устанавливаемым компонентов для обеспечения обратной совместимости, заменена системой настроек на основе XML. Я уже слышу, как вы говорите: «Но метабаза была в формате XML!» Да, была. Но она была громоздкой и не простой для чтения (по крайней мере, человеческого). Она заменена более гибкой системой XML. Подобно ASP.NET, IIS 7.0 использует файлы .config — простые, ясные, переносимые и простые для чтения файлы.

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

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

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

Включение настройки общего пользования осуществляется очень просто. На узле сервера диспетчера служб IIS выберите пункт «Shared Configuration» (Настройка общего пользования), который находится в разделе «Управление» на панели задач. Просто установите флажок «Enable shared configuration» (Включить настройки общего пользования), укажите физический путь к файлу настройки для совместного использования (обычно это общая папка UNC), введите учетные данные, необходимые для доступа к физическому пути, и нажмите кнопку «Применить». После нахождения файла .config появится запрос на ввод пароля шифрования. После завершения процесса перезапустите диспетчер служб IIS, чтобы он выбрал новый файл .config.

Поскольку структура новой системы настроек отличается от той, к которой вы привыкли, рассмотрим ее основы. Как показано на рис. 3, настройка IIS 7.0 разделена на две категории – параметры уровня сервера и параметры узла. Все параметры уровня сервера хранятся в файле applicationhost.config, который находится в папке %systemroot%\windows\system32\inetsrv\config. К ним относятся параметры всех установленных модулей, узлов на сервере и т.д. Параметры узла хранятся в отдельных файлах web.config.

Рис. 3 Существует один файл .config для параметров уровня сервера и отдельные файлы для каждого веб-узла на этом сервере

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

Файл web.config узла находится в физическом пути к узлу, например, %systemroot%\inetpub\wwwroot. Такая модель предоставляет такие же преимущества переносимости, которые были описаны ранее, но на уровне узла. Например, можно просто разработать узел на тестовом сервере, а затем перенести файл web.config и файлы приложения на рабочий сервер с помощью перетаскивания или функции xcopy.

При переносе или совместном использовании файлов .config следите за сведениями, зависящими от компьютера, такими как IP-адрес и буквы дисков. Службы IIS 7.0 предоставляют решение для возможных ошибок в подобных параметрах, поддерживая переменные среды операционной системы (например, %systemroot%). Кроме того, убедитесь, что на тестовых и рабочих серверах установлен одинаковый набор модулей. Это поможет избежать появления непредвиденных ошибок приложений. Ошибки также могут возникать, если в файле web.config содержится ссылка на неустановленный модуль или в случае конфликта стандартного модуля с пользовательским.

Управление веб-сервером

Теперь в вашем распоряжении этот новый, замечательный, настраиваемый, гибкий и переносимый веб-сервер. Как вы собираетесь управлять им? Управление было важной частью планирования и создания служб IIS 7.0, и существует несколько способов администрирования.

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

В IIS 6.0 пользовательский интерфейс оснастки консоли управления Microsoft® (MMC) имеет два основных знакомых представления, представление в виде дерева и представление в виде вкладок. Для перехода к определенному параметру необходимо щелкнуть его правой кнопкой мыши и выбрать «Properties» (Свойства), после чего появится набор вкладок, не говоря уж о переключателях и флажках.

К счастью, пользовательский интерфейс в IIS 7.0 полностью переработан. Этот пользовательский интерфейс, называемый диспетчером служб IIS, задумывался для реализации подхода, ориентированного на задачи, как показано на рис. 4. Также существует диспетчер Remote Manager для клиентов нижнего уровня, таких как Windows XP и Windows Server 2003. Его можно загрузить с веб-узла IIS.net/downloads.

Рис. 4 Новый пользовательский интерфейс в IIS 7.0

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

В диспетчер служб IIS также интегрированы свойства ASP.NET, избавляя от необходимости использовать дополнительную оснастку MMC. Каждое настраиваемое свойство имеет собственный значок, что упрощает поиск свойств. А поскольку диспетчер служб IIS создавался как приложение Windows Forms, можно легко добавлять значки подключаемых модулей для любых созданных пользовательских модулей или функций.

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

Другие способы управления

Для тех, кто предпочитает командную строку, доступно новое многостороннее средство APPCMD.exe, позволяющее выполнять простые задачи, такие как остановка узла или резервное копирование текущего файла .config, а также более сложные задачи, например, поиск схемы настройки. Синтаксис очень простой:

APPCMD (command) (object-type)

Для получения списка всех объектов, доступных для APPCMD, введите:

Чтобы просмотреть все команды, доступные для определенного типа объекта, введите:

В IIS 7.0 добавлены новый интерфейс API управляемого кода под названием Microsoft.Web.Administration и новый поставщик WMI (инструментария управления Windows), которые будут полезны всем программистам. Эти два метода предоставляют массу возможностей для создания сценариев, автоматизации и написания средств для управления IIS 7.0. Оба метода могут использоваться при помощи Windows PowerShell®, а поставщик WMI – также при помощи VBScript и JScript®. Дополнительные сведения имеются в блоге blogs.msdn.com/carlosag/archive/2006/04/17/MicrosoftWebAdministration.aspx.

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

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

Раньше существовало два способа удаленного управления сервером IIS: с помощью веб-узла удаленного управления или удаленного рабочего стола/служб терминалов для доступа к пользовательскому интерфейсу. Но при нахождении с внешней стороны брандмауэра или не на узле эти способы были не особо полезны. В службах IIS 7.0 эта проблема устраняется благодаря созданию способов удаленного управления непосредственно в пользовательском интерфейсе, работающем через совместимое с брандмауэром подключение HTTPS.

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

Служба удаленного управления в IIS 7.0 фактически представляет собой небольшое веб-приложение, работающее как отдельная служба под учетной записью локальной службы Windows NT® с именем NT Service\WMSVC. Такая модель обеспечивает сохранение возможности удаленного управления, даже если сам сервер IIS не отвечает.

Как и большинство функций IIS 7.0, удаленное управление в целях безопасности не установлено по умолчанию. Для установки функций удаленного управления добавьте службы ролей для роли веб-сервера в диспетчере сервера Windows Server 2008, который находится в разделе «Management Tools» (Средства управления). После установки функции необходимо включить удаленные подключения и запустить службу WMSVC, поскольку по умолчанию она остановлена.

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

sc config WMSVC start=auto

При включении удаленных подключений через службы управления появится список параметров, таких как «Удостоверяющие учетные данные», «Подключения» и «Ограничения для IPV4-адреса». В данный момент только одно решение является важным – определение набора удостоверяющих учетных данных для предоставления полномочия на подключение к IIS 7.0: только учетные данные Windows или учетные данные Windows и диспетчера IIS.

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

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

Делегированное администрирование в сущности является удаленным администрированием, но оно ограничивает область доступа отдельными узлами или веб-приложениями. Функция пользователей диспетчера IIS особенно полезна здесь. Можно создать пользователей IIS для этих разовых владельцев узлов и делегировать им полномочия на администрирование собственного узла или приложения. У них отсутствует доступ к параметрам уровня сервера, и они ограничены только параметрами определенного узла или веб-приложения.

Кроме того, можно указать функции и параметры, изменяемые пользователями или даже отображаемые в пользовательском интерфейсе. Например, если тип проверки подлинности, используемый для данного узла, не должен никем изменяться, можно указать, что эта функция только для чтения или не наследуется. Функция только для чтения доступна для пользователей, и они могут определять ее параметр, но не могут вносить изменения; значок ненаследуемой функции отсутствует в представлении диспетчера IIS делегированного пользователя. Такой вид делегирования функции позволяет предоставлять другим пользователям строго контролируемый доступ без предоставления административного управления веб-сервером.

Переход на IIS 7.0

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

В инфраструктуре совместимости метабазы IIS 6.0 используется компонент с названием ADOMapper. Он позволяет выполнять сценарии метабазы объектов на основе администратора (ABO) и интерфейса ADSI IIS 6.0 в новой системе настроек, ограничивая ее только возможностями IIS 6.0. Поэтому чтение и запись новых свойств IIS 7.0, доступ к новым данным выполнения, чтение и запись свойств ASP.NET или файлов web.config невозможны.

Устранение неполадок и диагностика

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

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

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

Рис. 5 Использование отслеживания сбойных запросов для устранения неисправностей

Разница между отслеживанием сбойных запросов и традиционным ведением журнала состоит в том, что при использовании первого ведение журнала начинается только при обнаружении определенного критерия сбойного запроса. Сам файл журнала – это документ XML с таблицей стилей XML, что делает его простым и ясным для чтения. Как и большинство других функций IIS 7.0, отслеживание сбойных запросов не устанавливается по умолчанию и находится в разделе работоспособности и устранения неисправностей программы установки. Его также необходимо включить в диспетчере IIS.

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

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