20.04.2004

Безопасность IIS 6.0

Популярность веб серверов, как главных целей для взломщиков и вирусописателей во всем мире создала естественные условия для Microsoft, чтобы сосредоточиться на ее "Trustworthy Computing Initiative". В результате IIS был полностью перепроектирован, с целью быть защищенным по умолчанию и защищенным по своей внутренней архитектуре. В этой статье мы обсудим конфигурацию, заданную по умолчанию, и изменения, включенные в IIS 6.0, чтобы сделать его более безопасной платформой для хостинга критических веб приложений.

Роит Белени и Майкл Макин, перевод и редакция Владимир Куксенок 
Популярность веб серверов, как главных целей для взломщиков и вирусописателей во всем мире создала естественные условия для Microsoft, чтобы сосредоточиться на ее "Trustworthy Computing Initiative". В результате IIS был полностью перепроектирован, с целью быть защищенным по умолчанию и защищенным по своей внутренней архитектуре. В этой статье мы обсудим конфигурацию, заданную по умолчанию, и изменения, включенные в IIS 6.0, чтобы сделать его более безопасной платформой для хостинга критических веб приложений.

Защищенный по умолчанию

В прошлом разработчики, включая Microsoft, снабжали установки по умолчанию своих серверов множеством типовых скриптов, обработчиков файлов и минимальными ограничениями файловой системы, чтобы обеспечить администраторам необходимую гибкость и простоту использования. Однако такой подход имел тенденцию увеличения доступной плоскости нападения и был основой нескольких атак против IIS. В результате IIS 6.0 разработан, чтобы быть более безопасным "из коробки", чем его предшественники. Самое примечательное изменение это то, что IIS 6.0 не устанавливается по умолчанию с Windows Server 2003. Другие изменения включают в себя:

- Заданная по умолчанию инсталляция - только статический HTTP сервер
По умолчанию IIS 6.0 настроен для обслуживания только статических HTML страниц, динамический контент не разрешается. Следующая таблица сравнивает возможности установки по умолчанию IIS 5.0 и IIS 6.0 .

Компонент IIS IIS 5.0 установка по умолчанию IIS 6.0 установка по умолчанию
Static file support включено включено
ASP включено отключено
Server-side includes включено отключено
Internet Data Connector включено отключено
WebDAV включено отключено
Index Server ISAPI включено отключено
Internet Printing ISAPI включено отключено
CGI включено отключено
Microsoft FrontPage® server extensions включено отключено
Password change interface включено отключено
SMTP включено отключено
FTP включено отключено
ASP.NET нет отключено
Background Intelligence Transfer Service нет отключено

- Не устанавливается никаких типовых приложений
IIS 6.0 не содержит никаких типовых скриптов, подобных showcode.asp и codebrws.asp . Первоначально эти программы были разработаны, чтобы позволить программистам быстро просматривать их код подключения к базе данных и осуществлять его отладку. Однако, showcode.asp и codebrws.asp корректно не проверяют ввод, чтобы гарантировать, что запрошенный файл находится в пределах корневой веб директории. Это позволяет взломщику просматривать любые файлы (включая те, которые содержат важные настройки конфигурации) в системе. Обратитесь по следующей ссылке для получения дополнительной информации об этой уязвимости: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS99-013.asp

- Улучшенный контроль прав доступа файловой системы
Анонимные пользователи больше не имеют прав на запись в домашнею директорию веб сервера. Кроме того, FTP пользователи изолированы в их собственных домашних каталогах. Эти ограничения препятствуют пользователю загружать злонамеренные файлы в другие части файловой системы сервера. Такие атаки могут включать "дефейс" веб сайтов, используя загрузку файлов в корневую директорию и удаленное выполнения команд через запуск злонамеренного исполняемого файла, который может быть загружен в каталог /scripts.

- Нет исполняемых виртуальных директорий
Виртуальные директории не имеют прав на исполнение файлов, находящихся в них. Это предотвращает использование многочисленных "directory traversal" уязвимостей и MDAC эксплойтов, которые существовали в прошлом.

- Удален Sub-authentication модуль
IISSUBA.dll был удален из IIS 6.0 . Любые учетные записи, который требовали эти функциональные возможности в предыдущих версиях IIS, требовали "доступ к этому компьютеру из сети" привилегий. Удаления этой DLL удаляет эту зависимость и таким образом уменьшает плоскость нападения, проводя все идентификации непосредственно через SAM или Active Directory.

- Абсолютные пути отключены
Доступ к абсолютным путям в файловой системе заблокирован по умолчанию. Это должно предотвратить "directory traversal" атаки, которые могут позволить атакующему выходить за пределы корневой веб директории и получить доступ к важным файлам файловой системы, например SAM файлам. Обратите внимание, что это может причинить проблемы при переносе приложений, которые использовали абсолютные пути на предыдущих версиях IIS.

Защищенный по внутренней архитектуре

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

Улучшенная проверка правильности данных

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

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

Чтобы препятствовать использованию переполнения буфера или кучи, которые могут быть обнаружены в будущем, Microsoft использовала принцип "глубокой защиты" во внутренней архитектуре IIS 6.0. Это было достигнуто добавлением определенных возможностей синтаксического анализа URL к набору возможностей включенных в HTTP.sys. Эти особенности в будущем могут настраиваться изменением определенных значений системного реестра. Следующая таблица проводит обзор наиболее важных ключей реестра (могут быть найдены здесь: HKLM\System\CurrentControlSet\Services\HTTP\Parameters).

AllowRestrictedChars Этот ключ принимает значение типа boolean, которое не равное нулю позволяет HTTP.sys принимать hex-коды символов в запросе URL. Значение по умолчанию - 0. Это рекомендованное значение, облегчающее задачу проверки правильности входящих данных на уровне сервера. Если ключ равен 1, злонамеренные символы могут быть закодированы в шестнадцатеричной системе счисления, в попытке обойти проверку правильности ввода.
MaxFieldLength Этот ключ позволяет администратору установить максимальный размер (в байтах) для каждого заголовка. Значение по умолчанию - 16 Кб.
MaxRequestBytes Этот ключ устанавливает максимальное значение строки запроса и заголовков. Значение по умолчанию также 16 Кб.
UrlSegmentMaxCountЭтот ключ определяет максимальное количество сегментов пути URL, принимаемых сервером. Фактически это ограничивает число слешей, которые могут быть включены пользователем в запросе URL. Рекомендуется устанавливать это значение на основе глубины корневой директории веб. Значение по умолчанию - 255.
UrlSegmentMaxLength Этот ключ устанавливает максимальное количество символов в любом сегменте пути URL. Значение по умолчанию - 260.
EnableNonUTF8 Значение этого ключа определяет допустимый набор символов. Заданное по умолчание значение 1 позволяет HTTP.sys принимать ANSI- и DBCS-закодированные URL в дополнение к URL закодированным в формате UTF8.

Расширенные механизмы протоколирования

Всестороннее протоколирование - основное требование для успешного обнаружения и реагирования на инциденты безопасности. Microsoft осознала эту необходимость и осуществила исчерпывающий и надежный механизм протоколирования в HTTP.sys . HTTP.sys пишет в log-файл перед диспетчеризацией запроса к рабочему процессу. Это гарантирует, что причина ошибки будет зарегистрирована, даже если это заставит рабочий процесс завершить работу некорректно. Начало log-файла состоит из даты и времени возникновения ошибки, обратного и целевого IP адресов и портов, версии протокола, HTTP запроса, URL, состояния протокола, идентификатора сайта и комментария об ошибке. Комментарий содержит детальную информацию о причине возникновения ошибки - может ли это быть по причине тайм-аута или из-за разрыва соединения вследствие неожиданного завершения рабочего процесса.

Пример log-файла HTTP.sys может быть найден по следующей ссылке: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/iis/iis6/proddocs/resguide/iisrg_log_qlow.asp

Защита от сбоя

В дополнения к настройкам в системном реестре, администраторы IIS 6.0 могут настроить сервер на автоматическое завершение или перезапуск рабочих процессов, приложения которых неоднократно завершались с ошибкой (в течение определенного времени). Это дополнительная гарантия защиты приложения от повторяющихся ошибок, которые быть индикаторами атак. Эта возможность названа "Защита от быстрого сбоя" (Rapid-Fail Protection).

Защита от быстрого сбоя может быть настроена через IIS Manager следующим образом:

1. В IIS Manager разверните локальный компьютер.
2. Выберите Application Pools.
3. Щелкните правой кнопкой мыши на приложении.
4. Нажмите на Properties.
5. В Health поставьте галочку на Enable rapid-fail protection.
6. В поле Failures напишите допустимое количество ошибок (перед завершением процесса).
7. В поле Time Period определите количество минут, в течение которых ошибки будут накапливаться.

Изоляция приложений

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

Принцип минимальных привилегий

IIS 6.0 придерживается фундаментального принципа защиты - принципа минимальных привилегий. Это было достигнуто путем включения всего кода, который должен выполняться с правами Local System (наивысший уровень), в HTTP.sys . Все рабочие процессы выполняются как Network Service (Сетевая служба), новый тип учетной записи в Windows 2003 с чрезвычайно ограниченными правами. Далее, IIS 6.0 позволяет использовать средства командной строки только администраторам, таким образом предотвращая использование этих средств злонамеренными эксплойтами. Такие изменение внутренней архитектуры уменьшают вероятность компрометирования сервера через потенциальную уязвимость. Кроме этих фундаментальных изменений в архитектуре, некоторые простые изменения конфигурации включают запрещение прав на запись в домашние директории веб сервера для анонимных пользователей, изоляцию FTP пользователей в их собственный домашние директории, что также увеличивает защищенность IIS 6.0 .

IIS 6.0 - шаг Microsoft в правильном направлении, помогающий организациям повысить свою безопасность. Он обеспечивает надежную и защищенную инфраструктуру для хостинга веб приложений. Улучшенная зашита в конфигурации по умолчанию - очевидный акцент к защите в процессе разработки и расширение возможностей мониторинга и протоколирования сервера IIS 6.0 . Однако, администраторы не должны получить ложное ощущение защищенности, просто перейдя на эту платформу, а объединить переход на новую платформу с созданием многократных уровней защиты. Это соответствовало бы принципу "глубокой защиты" и создало бы надежный щит от угроз подобных Code Red или Nimda.

или введите имя

CAPTCHA