Microsoft IIS занимает необычное положение в сетевой инфраструктуре: программный код, выполняемый в режиме пользователя, глубоко интегрирован с операционной системой и использует протоколы Internet для доставки приложений и контента удаленным пользователям. Для защиты IIS необходимо учесть все аспекты развертывания, в том числе сети, приложения, серверы и операционную среду.
Удивительно, как много средств компании тратят на защиту своих серверов, забывая при этом, что кто-то может получить физический доступ к машине и загрузить ее с помощью 3,5-дюймовой дискеты. В данной статье предполагается, что читатели не нуждаются в напоминаниях о контроле над физическим доступом, необходимости вовремя устанавливать исправления, выбирать сложные пароли и изменять стандартные пароли на административных системах (например, системных мониторах). Тем не менее некоторые администраторы забывают об элементарных мерах предосторожности, и именно таким образом взломщики получают чаще всего несанкционированный доступ к серверам; более подробно об этом рассказано в опубликованной институтом SANS статье «The Twenty Most Critical Internet Security Vulnerabilities (Updated) — The Experts? Consensus» (http://www.sans.org/top20).
Вооружившись знанием основ безопасности IIS, можно переходить к другим темам, таким как управление процессом идентификации, фильтрация портов, блокирование Web Distributed Authoring and Versioning (WebDAV) и использование инструмента безопасности URLScan. Но сначала следует развеять несколько мифов о безопасности IIS и познакомиться с некоторыми из наиболее эффективных методов и инструментов Microsoft для защиты Web-серверов.
Мифы о безопасности IIS
Приступая к изучению проблемы безопасности IIS, нужно прежде всего усвоить, что не следует безоговорочно верить всему прочитанному. Одна из причин, побудивших меня поделиться опытом работы с IIS, как раз и состоит в большом количестве неверной информации, исходящей из разных источников, в том числе Microsoft. Вот несколько примеров.
Анонимному пользователю необходимо право локальной регистрации (log-on-locally). В некоторых источниках указывается, что учетной записи IUSR_, используемой IIS для анонимной аутентификации, требуется право локальной регистрации. Такие сведения содержатся в Help-файлах IIS и на Web-узле компании Microsoft, в том числе в статье «HOW TO: Set Basic NTFS Permissions for IIS 5.0» (http://support.microsoft.com/?kbid=271071). Пользователи часто напоминают об этом требовании своим коллегам в группах поддержки и на электронных досках объявлений. Однако, за исключением случаев, когда IIS-сервер размещен на контроллере домена (DC), данное требование недействительно. Стандартная процедура аутентификации анонимного пользователя сводится к регистрации в сети, которая не требует полномочия log-on-locally.
Из соображений безопасности лучше запретить анонимному пользователю локальную регистрацию, так как в этом случае злоумышленник не может воспользоваться учетной записью anonymous user для локальной регистрации, которая предоставляет пользователю больше полномочий, чем сетевая регистрация. Например, взломщик, использующий учетную запись IUSR для регистрации через Windows 2000 Server Terminal Services, запускает интерактивный сеанс регистрации и поэтому получает доступ к другим сетевым ресурсам. Возможно, придется потратить некоторое время, чтобы понять различия между локальной и сетевой регистрацией, но это знание необходимо для оптимального решения проблем безопасности. Краткий обзор процедуры аутентификации приведен в статье по адресу www.microsoft.com/technet/prodtechnol/winxppro/ reskit/prdp_log_csky.asp.
Пользователям необходимы разрешения Change на журнальные файлы. В документе Secure Internet Information Services 5 Checklist (http://www.microsoft.com/technet/security/tools/ chklist/iis5chk.asp) содержится несколько ценных рекомендаций и одна крайне неудачная идея, а именно совет предоставить группе Everyone разрешения Read, Write и Change для генерируемых IIS файлов журнала регистрации (\%systemroot%system32logfiles). Дело в том, что предоставление таких разрешений группе Everyone не помешает злоумышленникам удалить эти файлы для того, чтобы замести следы, как предполагается в документе. Правильнее было бы предоставить разрешения Full Control на файлы журнала регистрации группам Administrators и System. Единственное исключение из этого правила относится к случаям, когда для записи файлов журнала регистрации IIS используется специализированное приложение для регистрации. В подобных случаях приходится предоставлять разрешение Change.
Active Server Pages (ASP) требует разрешения NTFS Execute. Во многих документах Microsoft приводятся рекомендуемые разрешения NTFS для контента IIS. В большинстве таких документов говорится, что для сценариев необходимо разрешение NTFS Execute. Данная рекомендация нарушает важный принцип безопасности, известный как принцип минимальных полномочий. Как правило, для любого сценария, связанного с механизмом выполнения сценариев, требуется только разрешение NTFS Read.
Администраторам IIS приходится отыскивать зерно истины среди утверждений, верных лишь наполовину. Задача осложняется тем, что иногда неверная информация исходит от самой Microsoft. Тем не менее знание мер, необходимых для защиты Web-серверов, наверняка поможет разобраться.
Идентификация процессов
Одно из главных правил безопасности сервера заключается в том, что все процессы имеют свой контекст безопасности. Это означает, что каждая программа на сервере выступает в роли сущности (entity). Сущностью может быть зарегистрированный пользователь или встроенная учетная запись (например, System), а каждый процесс имеет экземпляр (Identity). Администратор IIS, уделяющий внимание проблеме безопасности, обязан всегда знать имя экземпляра процесса, который исполняет Web-приложение. В таблице приведены подробные сведения о модели процессов IIS и связанных с ними именах экземпляров.
Взломщик может использовать несколько методов для доступа к экземпляру процесса. Проведя атаку с переполнением буфера против приложения или Web-сервера, он может овладеть контекстом безопасности экземпляра процесса. Другой метод состоит в использовании функции RevertToSelf, которая может быть вызвана исполняемым файлом. Если злоумышленник может запустить такой исполняемый файл, то приложение исполняется как экземпляр процесса. Следует обратить внимание, что в Internet Information Services (IIS) 5.0 и Internet Information Server (IIS) 4.0 процесс Inetinfo работает с учетной записью System (см. таблицу). Следовательно, в целях безопасности следует избегать запуска приложений «внутри процесса» (т. е. работающих от имени процесса Inetinfo). В IIS 6.0 Web-приложения не запускаются экземпляром System, за исключением тех случаев, когда администратор явно задает этот режим или сервер настроен на работу в режиме IIS 5.0. Администратор не может запретить программе использовать экземпляр процесса, но может проанализировать двоичный файл, чтобы обнаружить вызовы RevertToSelf. Для анализа можно задействовать утилиту DumpBin, которая поставляется вместе с большинством языков программирования. Требуется ввести следующую команду:
dumpbin /imports executable name| find «RevertToSelf»
Более подробно об анализе исполняемых файлов рассказано в документе Secure Internet Information Services 5 Checklist.
Фильтрация портов
Тема фильтрации портов выходит за рамки данной статьи, но нельзя не упомянуть о некоторых основных положениях. Например, единственный порт, необходимый для работы IIS, — порт 80; все остальные порты обеспечивают дополнительную функциональность. Как правило, требуется задействовать TCP-порт 443 для SSL (Secure Sockets Layer), TCP/UDP-порт 53 для SMTP и, вероятно, другие порты для прикладных функций. Следует разрешать соединения только для необходимых служб и никогда не открывать сетевые порты приложений Microsoft (TCP/UDP-порты 137, 138, 139 и 445) подозрительным сетям. Сетевые порты и работающие через них соответствующие службы предоставляют много возможностей для нападения. Я рекомендую начать настраивать IIS с порта 80 и не открывать никаких других портов без производственной необходимости. На многих сайтах для фильтрации портов применяются брандмауэры, но я предпочитаю размещать IIS-серверы в демилитаризованной зоне (DMZ), как будто взломщик проник сквозь брандмауэр. Защита с помощью хост-машин (host-based defense), как ее иногда называют, — важный уровень эшелонированной стратегии безопасности.
Чаще всего для фильтрации портов я пользуюсь бесплатной утилитой IP Security (IPSec), которая успешно работает и запускается из командной строки. Основное назначение IPSec не фильтрация портов, а создание двухточечных взаимно аутентифицированных и зашифрованных соединений. Предположим, что установлено соединение IPSec между IIS и брандмауэром Internet Security and Acceleration (ISA) Server 2000 и другое соединение, между брандмауэром и системой Microsoft SQL Server. Эти соединения можно настроить на взаимную аутентификацию с применением сертификатов и шифрованием всего трафика. Если взломщик получает доступ к компьютеру в DMZ, то он не сможет обратиться к машине SQL Server. Для этого требуется, чтобы сертификат, хранящийся на сервере IIS, передавался компьютеру SQL Server от компьютера с IP-адресом сервера IIS. Кроме того, злоумышленнику не удастся перехватить зашифрованный трафик. IPSec обеспечивает надежную защиту, и я рекомендую именно эту утилиту.
С помощью IPSec можно реализовать и фильтрацию портов с учетом состояния (state-aware). Например, если адрес IIS-сервера — 1.1.1.1 и данный сервер соединен с машиной SQL Server с адресом 1.1.1.2, то машину 1.1.1.1 можно настроить на связь только с 1.1.1.2 и с использованием только порта 1433. Более подробная информация содержится в статье Microsoft «INF: TCP Ports Needed for Communication to SQL Server Through a Firewall» (http://support.microsoft.com/?kbid=287932). Аналогичным образом можно настроить общедоступный IP-адрес IIS для работы только через порт 80 и любые другие необходимые порты. Утилита IPSec достаточно интеллектуальна, чтобы разрешить исходящие соединения в ответ на запросы к порту 80. Кроме того, IPSec позволяет блокировать исходящий трафик через порт 80, чтобы запретить использование браузера Microsoft Internet Explorer (IE) на IIS-сервере (широко применяемая мера предосторожности).
Пользовательский интерфейс IPSec требует изучения, его подробное описание дано в статье Microsoft «Building and Configuring More Secure Web Sites» (http://msdn.microsoft.com/library/en-us/dnnetsec/html/openhack.asp). Чтобы составить правила IPSec для Windows 2000, можно воспользоваться утилитой командной строки Ipsecpol, которая доступна на сайте Microsoft по адресу http://www.microsoft.com/windows2000/techinfo/ reskit/tools/existing/ipsecpol-o.asp. Например, чтобы создать правило, разрешающее только входящий трафик через порт 80, следует ввести команду
Ipsecpol servername-x -w REG -p «Port80Only» -r «BlockEverything» -n BLOCK -f 0+* Ipsecpol servername -x -w REG -p «Port80Only» -r «Allow80» -n PASS 0:80+*::TCP
Перед тем как использовать фильтрацию портов IPSec, нужно прочитать статью Microsoft «IPSec Default Exemptions Can Be Used to Bypass IPsec Protection in Some Scenarios» (http://support.microsoft.com/?kbid=811832), чтобы выяснить, следует ли дополнить реестр сервера параметром NoDefaultExempt. Если в отсутствие этого параметра IPSec обнаружит трафик, исходящий от порта 88 или направляющийся в него, то сервер будет игнорировать фильтры. Такое исключение должно обеспечить работу Kerberos, даже если порты Kerberos были специально блокированы. Если этому параметру реестра присвоено значение 1, то исключение отменяется. Недавно я обнаружил, что данный параметр реестра прописывается при применении пакета обновлений Windows 2000 Service Pack 4 (SP4). Информация об используемых в Windows 2000 портах приведена в таблице Default Port Assignments for Common Services по адресу http://www.microsoft.com/windows2000/techinfo/ reskit/samplechapters/cnfc/cnfc_por_simw.asp.
Блокирование WebDAV
Немногие темы столь запутанны, как использование WebDAV совместно с IIS. WebDAV — стандарт, сформулированный в документе Request for Comments (RFC) рабочей группы Internet Engineering Task Force (IETF) (http://www.ietf.org/rfc/rfc2518.txt). Он позволяет создать на клиентской стороне Web-папку, URL которой указывает на IIS-сервер. Затем в папку можно перенести мышью контент для публикации на Web-сервере. Эта функция реализована как в IIS 6.0, так и в IIS 5.0. WebDAV стал широко применяться на серверах Microsoft с появлением Windows 2000. Тем не менее многие администраторы не представляют потенциальных возможностей и риска WebDAV. Конечно, такая мощная функция, как WebDAV, открывает широкое поле деятельности для злоумышленника. Поэтому неудивительно, что выпущено множество исправлений системы безопасности для httpext.dll, расширения http, в котором реализованы функции WebDAV.
На мой взгляд, главный недостаток реализации WebDAV в Windows 2000 заключается в том, что по умолчанию он разворачивается вместе с IIS и его нельзя отключить из пользовательского интерфейса IIS. Администраторам Windows 2000 приходится с этим мириться, но администраторам Windows Server 2003, установившим IIS 6.0, будет приятно узнать, что WebDAV блокирован по умолчанию и его можно активизировать или отключить из контейнера Web Service Extensions на консоли IIS.
Вокруг способов активизации или отключения WebDAV в Windows 2000 возникла путаница, так как в разное время специалисты Microsoft предлагали три различных метода блокирования WebDAV, у каждого из которых есть свои достоинства и недостатки. Тем не менее в различных публикациях Microsoft рекомендованы все три метода.
Отказ в разрешении Execute для файла httpext.dll членам группы Everyone. Чтобы помешать первым злоупотреблениям WebDAV, специалисты Microsoft предложили лишить группу Everyone разрешения Execute на файл httpext.dll. Такой подход к блокировке WebDAV используется в инструменте IIS Lockdown. Однако у этого подхода есть два недостатка.
Во-первых, необходимо запретить Execute на всех серверах и внести это изменение при создании нового сервера. Во-вторых, удаление разрешения Execute не полностью блокирует WebDAV, что отмечается в статье Microsoft «Locking Down WebDAV Through ACL Still Allows PUT and DELETE Requests» (http://support.microsoft.com/?kbid=307934).
Добавление параметра реестра DisableWebDAV. На системах Windows 2000 SP2 и более поздних можно перейти в раздел реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesW3SVCParameters, добавить параметр DisableWebDAV и присвоить ему значение 1, чтобы отключить WebDAV. Это эффективное решение, но его необходимо реализовать на всех машинах.
Использование URLScan для блокирования команд WebDAV. Самый надежный метод защиты IIS — установить на IIS-серверах утилиту безопасности URLScan. Данный инструмент выполняет и множество других функций, помимо блокирования WebDAV, поэтому заслуживает более подробного рассмотрения.
Реализация URLScan
URLScan — фильтр Internet Server API (ISAPI), работающий на платформах IIS 6.0, IIS 5.0 и IIS 4.0. В ходе установки инструмента IIS Lockdown на IIS 5.0 или IIS 4.0 при желании можно развернуть URLScan 2.0. Однако я рекомендую использовать версию 2.5 с расширенной функциональностью. С Web-узла Microsoft можно загрузить различные версии URLScan. Ко времени публикации данной статьи должна быть выпущена программа установки URLScan для IIS 6.0. Для использования URLScan с IIS 6.0 не существует столь веских оснований, так как IIS 6.0 уже располагает основными функциями защиты, обеспечиваемыми утилитой.
URLScan сравнивает входящий URL с правилами, задаваемыми администратором в файле urlscan.ini (который находится вместе с urlscan.dll в каталоге \%systemroot%system32inetsrvurlscan) и, соответственно, пропускает или блокирует запросы. Например, URLScan можно настроить на обслуживание только запросов к файлам с определенными расширениями. Такое простое правило защитит систему от многих известных атак, направленных против IIS.
URLScan можно настроить на блокирование всех запросов, содержащих определенные заголовки HTTP, такие как заголовки WebDAV в приведенном ниже фрагменте файла urlscan.ini (хочу выразить благодарность Марку Барнетту, дополнившему этот листинг):
[DenyHeaders] Translate: DAV: Depth: Destination: If: Label: Lock-Token: Overwrite: TimeOut: TimeType: DAVTimeOutVal: Other:
Кроме того, с помощью URLScan можно блокировать URL, которые:
- содержат символы не из заданного диапазона;
- содержат указанные символы или последовательности символов;
- превышают определенную длину;
- содержат клиентские заголовки, превышающие определенную длину;
- содержат определенные команды HTTP.
С помощью URLScan можно записать все отвергнутые запросы в файле регистрации, а затем проанализировать журнал с использованием утилиты Log Parser Tool 2.0, которую можно получить по адресу http://www.microsoft.com/downloads, или инструмента Log Parser Tool 2.1 из комплекта ресурсов Microsoft Windows Server 2003 Resource Kit. Также можно переслать все блокированные запросы на специальную .asp-страницу для обработки; принимать запросы, но заносить определенные события в журнал как блокированные запросы; удалять или изменять серверные баннеры, которые IIS посылает клиенту.
URLScan может блокировать URL, длина которых превышает определенную величину, но большинство URL для IIS недостаточно длинны, чтобы вызвать переполнение буфера. Проанализировав длину URL, необходимую для конкретных Web-узлов, и установив правило URLScan, блокирующее все запросы, не отвечающие требованиям, можно существенно повысить безопасность сервера. С помощью одного этого правила можно снизить угрозу для серверов, так как взломщик должен послать URL, соответствующий некоторым требованиям (например, с конкретным расширением; содержащий лишь определенные команды HTTP; не содержащий таких компонентов, как символы не из заданного диапазона, дополнительных символов или косых черт; длиной менее 400 символов).
URLScan отличается богатой функциональностью для такой компактной программы, отсутствием каких-либо известных изъянов, а использование утилиты почти не отражается на производительности. Следует помнить, что наряду с изменением серверного баннера (и потенциальными последствиями для приложений, использующих баннер), URLScan блокирует только запросы к серверу; утилита не влияет на работу приложений и не может внезапно нарушить стабильность Web-сервера. URLScan легко удалить или перевести в режим мониторинга, в котором утилита регистрирует события, но не блокирует запросов.
Защита, защита и еще раз защита
Защищая Web-серверы от потенциальных взломщиков, важно понимать процесс идентификации и знать, какие приложения каких разрешений NTFS требуют. Важность фильтрации портов также трудно переоценить, но если брандмауэр взломан, настроен некорректно, или поражен другой сервер в демилитаризованной зоне, то можно использовать IPSec для защиты с помощью хост-машин. Кроме того, важно контролировать доступ по WebDAV к серверам, а с помощью URLScan можно настроить правила блокировки IIS. Наиболее эффективные из этих методов — использование URLScan и ограничение длины URL. В результате применения перечисленных инструментов взломщики переносят свои усилия с Web-серверов на приложения, исполняемые Web-серверами, но это уже тема для другой статьи.
Бретт Хилл — организатор узла http://www.iistraining.com, консультант по Microsoft IIS, IIS MVP; автор и преподаватель курсов IIS. С ним можно связаться по адресу: brett@iisanswers.com