Защита без компромиссов

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

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

Детальное управление доступом

Ключ к надежной защите Web-узла IIS — использование имеющихся в распоряжении администратора функций управления доступом. Чтобы управлять доступом, можно определять разрешенные типы файлов и операции (verb) HTTP, применимые к каждому типу файлов; ограничивать обращения к определенному контенту по каналам IP; позволять или запрещать запись, чтение и доступ к каталогам. Эти параметры можно настроить из интерфейса пользователя IIS Manager в IIS 6.0 или через оснастку IIS консоли Microsoft Management Console (MMC) в IIS 6.0 и более ранних версиях. Кроме того, можно с успехом задействовать детальные файловые разрешения NTFS и назначать отдельные разрешения для каждого типа контента и области Web-узла. О разрешениях NTFS рассказано в статье «Разрешения NTFS для Web-сервера» Windows 2000 Magazine/RE № 7 за 2002 год.

Обратите внимание на разрешения для индивидуальных файлов. Например, лишь немногим администраторам известно, что не нужно разрешать доступ по чтению к файлам .asp и что следует сбросить флажок Read для всех .asp-файлов из консоли IIS Manager (см. экран 1).

Экран 1. Настройка разрешений для .asp-файлов

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

Учетная запись IUSR обрабатывает анонимные запросы к Web-ресурсам. Назначая разрешения NTFS, следует предоставить доступ Read в анонимном режиме и доступ Read для конкретных пользователей или групп в режиме с аутентификацией. Если запретить учетной записи IUSR доступ Read, например, к файлу index.html, то анонимные пользователи Web не смогут обратиться к нему.

Установка URLScan

Многие администраторы разворачивают URLScan на Web-узлах IIS 5.0 в качестве дополнительного уровня защиты. URLScan — фильтр Internet Server API (ISAPI), который перехватывает запросы, получаемые Web-сервером из Internet и анализирует их в поисках необычных элементов. Инструмент можно загрузить с сайта по адресу http://www.microsoft.com/technet/security/ tools/urlscan.mspx.

Многие функции URLScan встроены в IIS 6.0 или стали ненужными в обновленной архитектуре, но URLScan по-прежнему может пригодиться для защиты IIS 6.0, и я рекомендую установить утилиту. URLScan располагает гибкими параметрами фильтрации для отражения новых атак и возможностями более детального управления Web-запросами через функцию DenyUrlSequences. Например, администратор IIS 6.0 может ограничить длину определенных частей запроса, а с помощью URLScan можно определить длину заголовков индивидуальных запросов HTTP. Ограничение длины защищает от длинных строк, способных вызвать переполнение буфера. Вероятно, главное достоинство URLScan заключается в дополнительном уровне защиты, который будет полезен, если во встроенных механизмах безопасности IIS 6.0 будут все-таки обнаружены уязвимые места.

Хранение данных, не размещаемых в Web

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

Изолированные административные каталоги

Существует на удивление много Web-узлов, административным каталогам которых присвоены такие легко угадываемые имена, как admin, backup, logs или stats. Подобных каталогов на общедоступном Web-узле быть не должно. Они представляют собой отличную мишень для злоумышленников, которым не потребуется много времени для установления их местоположения.

Поэтому конфиденциальную информацию желательно разместить на особом сайте и спрятать с помощью хост-заголовков (host header) и нестандартных портов (портов с более высокими номерами или портов других прикладных протоколов). Хост-заголовки позволяют разместить по одному IP-адресу несколько Web-узлов, различаемых по хост-имени. Например, по одному IP-адресу можно разместить основной Web-узел http://www.example.com и дополнительный сайт admin.example.com. Доступ к сайту ограничивается разрешениями и аутентификацией, применяемыми к IP-адресу. Если конфиденциальный каталог необходимо оставить на общедоступном Web-узле, то нужно, по крайней мере, изменить имя каталога на трудно угадываемое и ввести ограничения по IP-адресу и доступу пользователей, например потребовать клиентские сертификаты Secure Sockets Layer (SSL). Важно отметить, что непонятные имена не ограничивают доступ к сайту, но сайт становится менее очевидной мишенью.

Привести Webroot в порядок

Есть ли в Web-узле файл с именем вроде test.asp? Если такой файл имеется, значит, администратор пренебрегал «уборкой мусора» в каталогах Web-контента. Тестовые сценарии, резервные копии, старые версии файлов, устаревший контент и временные файлы могут подорвать безопасность сервера. Даже самые бессодержательные файлы несут крупицу информации, которая может пригодиться взломщику. Если эти файлы удалить, то взломщик не сможет использовать их против Web-узла.

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

Еще один совет: при публикации новой редакции Web-узла следует пометить все файлы одним временем. Это облегчит поиск файлов, измененных или созданных взломщиком.

Тонкая настройка параметров IIS

Многие параметры IIS недоступны непосредственно из IIS Manager, но с их помощью можно остановить атаку или сузить ее область. Например, в ходе атаки с переполнением буфера на Web-узел обрушивается огромное количество данных. Администраторы IIS 6.0 могут использовать параметры метабазы MaxRequestEntityAllowed и AspMaxRequestEntityAllowed, чтобы ограничить размер тела запроса или запроса Active Server Pages (ASP) соответственно. Эти параметры позволяют установить максимальный размер в байтах тела запроса, указанный в заголовке величины контента HTTP. Редактировать базу данных можно с помощью инструмента IIS Metabase Explorer (см. экран 2). Metabase Explorer входит в пакет Microsoft IIS 6.0 Resource Kit Tools, который можно загрузить с сайта http://www.microsoft.com. В табл. 1 показаны некоторые параметры метабазы, которые иногда полезно менять. В табл. 2 приведено несколько параметров реестра, изменение которых также желательно.

Экран 2. Редактирование метабазы IIS

Следовать философии Microsoft

Самое очевидное различие между стандартными установками IIS 6.0 и IIS 5.0 заключается в том, что первый отражает новую стратегию «безопасности по умолчанию», принятую в Microsoft. Для реализации нового подхода Microsoft отказалась от установки компонентов по умолчанию и назначает самые строгие параметры безопасности, сохраняя при этом возможность организовать базовый Web-узел. Но лишь немногие администраторы реализуют этот подход на практике; они устанавливают функции, которых не используют, или ослабляют режим безопасности до такой степени, что сервер становится уязвимым.

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

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

Автор, специализирующийся на проблемах безопасности Windows. Имеет сертификат IIS MVP. Его книга Hacking the Code вышла в издательстве Syngress. С ним можно связаться по адресу (mburnett@xato.net)