На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

IISLockdown и UrlScan

В конце 2001 года Microsoft выпустила средство под названием IISLockdown Wizard (ссылка есть в разделе "Дополнительная литература и ссылки" в конце этой главы). Как следует из названия, это автоматизированная, использующая стандартные шаблоны утилита, предназна­ченная для создания безопасной конфигурации сервера IIS. С ее помощью можно настроить следующие элементы.
» Internet-службы. Позволяет отключать четыре ПК-службы (WWW, FTP, SMTP и NNTP) согласно выполняемой роли сервера.
■ Соответствия сценариев. Позволяет отключить сценарии соответствия библиотек ISAPI согласно выполняемой роли сервера.
* Дополнительная защита. В разделе Catchall предусмотрена возможность использования выбранных по умолчанию виртуальных каталогов с помощью команд USSamples,
MSADC, IISHetp, Scripts и тл. Устанавливает списки контроля доступа NTFS в целях предотвращения запуска анонимными пользователями системных утилит (типа cmd. ехе) и от записи в каталоги с полезными данными. Позволяет отключить WebDAV.
Хотя здесь приведен практически полный список настроек безопасности для защиты US-сервера, некоторые проблемы все же не были учтены. Программа IISLockdown не предусматривает установки пакетов обновлений и исправлений и никакие затрагивает других потенциально уязвимых аспектов систем Windows. Не предусмотрена и установка брандмауэра для защиты сервера. Программа IISLockdawn позволяет значительно упростить жизнь администратора, но не позволяет оставлять другие двери открытыми для атак хакеров.
Поскольку большинство настроек IISLockdown Wizard могут быть выполнены вручную, мы считаем, что одной из наиболее привлекательных возможностей этой программы является UrlScan. На самом деле, UrlScan может быть извлечена отдельно с помощью программы установки IISLockdown (iislockd.exe). Для этого достаточно запустить IISLockdown Installer из командной строки с использованием следующих аргументов, iislockd.exe /q /с /t:c:\lockdown_files
После извлечения программа UrlScan может быть вручную установлена на защищаемом сервере (запускфайла iislockd.exe без аргументов автоматически установит UrlScan в составе IISLockdown Wizard).
Программа UrlScan состоит из двух файлов Urlscan.dll и UrlScan.ini, которые должны находиться в одном каталоге. Файл UrlScan.dll представляет собой фильтр ISAPI, который устанавливается перед сервером IIS таким образом, что может перехватывать HTTP-запросы до их получения IIS-сервером. В конфигурационном файле UrlScan. ini задается, какие запросы должен отклонять ISAPI-фильтр UrlScan. Сведения об отклоненных запросах записываются в файл под названием UrlScan. log, создаваемый в том же каталоге, в котором хранятся файлы UrlScan. dll и UrlScan. ini (регистрационные файлы могут называться UrlScan.MMDDyy. log при организации ежедневной регистрации, где MMDDYY—пата создания файла). В ответ на отклоненные запросы, программа UrlScan отправляет HTTP-ответ 404 "Object not found" ("Объект не обнаружен"), разочаровывая хакера, выполняющего поиск ценной информации об атакуемом сервере.
После установки UrlScan может быть настроен на отклонение HTTP-запросов в зависимости от следующих критериев:
т метод запроса (например команды GET, POST, head и т.д.);
■ расширение файла запрошенного ресурса;
■ наличие подозрительных символов в URL-адресе (см. раздел "Использование свойств файловой системы", в котором поясняется важность такой проверки);
■ наличие не ASCII-символов в адресе URL;
■ наличие специальных строк символов в URL-адресе; * наличие заданных заголовков в НТТР-запросс.
Конкретные значения каждого из этих параметров задаются в файле UrlScan. ini, а в файле UrlScan. doc содержится подробное описание каждого критерия фильтрации.
Настройка параметров в файле UrlScan. ini не вызывает затруднений, к тому же вместе с IISLockdown поставляется несколько предопределенных шаблонов этих параметров. Наиболее жесткие параметры задаются с помощью файла шаблона urlscan_static . ini, который
Файл загружается только при инициализации сервера IIS, и для того, чтобы какие-либо изменения в конфигурационном файле вступили в силу, следует перезапустить сервер IIS.
предназначен для того, чтобы ограничить возможности сервера обслуживанием запросов статических HTML-файлов с помощью одних только запросов GET. Хотя мы иногда сомневаемся в целесообразности использования фильтра ISAPI для защиты от атак на US-сервер, UrlScan представляет собой мощное средство контроля, которое позволяет администраторам разрешать обслуживание только определенных запросов к Web-серверу, и мы настоятельно рекомендуем его использование при запуске IIS-ссрвсра.
НА ЗАМЕТКУ
Функции безопасности, встроенные в сервер US б, эквивалентны или превосходят большинство возможностей программы UrlScan 2.5. Мы рекомендуем ознакомиться со сравнительным анализом встроенных возможностей IIS6 и UrlScan 2.5 на Web-странице компании Microsoft (см. раздел "Дополнительная литература и ссылки" в конце этой главы). Единственное исключение составляет возможность UrlScan под названием RemoveServerHeader, которую не поддерживает сервер IIS 6. В этом мы немного расходимся во мнениях с Microsoft и рекомендуем использовать эту вадможнекпъ на своих US-оерверах в цепях защиты от атак с помощью автоматизированных "червей", работа которых основывается на использовании HTTP-заголовков.
Хакинг Web-приложений
Самый надежный и верный механизм взлома серверов семейства Windows NT основан на использовании запущенных в системе Web-приложений. Подмена Web-страниц происходит каждый час (популярный Web-узел Attrition.org перестал отслеживать подмену страниц в середине 2001 года по причине резко растущего количества таких происшествий), почти регулярно появляются сенсационные сообщения о кражах со взломанных Web-серверов сведений с кредитных карточек клиентов (ссылки на выборочные исследования таких происше­ствий см. в разделе "Дополнительная литература и ссылки").
Широкое распространение взломов Web-серверов обусловлено несколькими взаимосвязанными проблемами. Во-первых, Web-приложения во многом играют основную роль при взаимодействии современных организаций со своими клиентами, поставщиками, партнерами и обществом, Web-приложения доступны круглосуточно, семь дней в неделю, поэтому взять и просто отказаться от них неудобно. Таким образом, Web-приложения являются постоянной целью для всего самого худшего, что может обрушиться на них через Internet.
Понятно, что Web-службы нельзя просто отключить, поэтому компании прикладывают максимум усилий для их защиты. Теперь перейдем ко второй проблеме. Очень сложно защитить то, что должно давать, по крайней мере, минимальный доступ к данным всем пользователям или некоторым из них. Еще хуже, что функциональная сложность приложений возрастает в соответствии с ростом требований пользователей, что повышает вероятность погрешностей в защите программ. Web-приложения, разрабатываемые обычными людьми, становятся легкой добычей хакеров.
И наконец, в основе Web-приложений лежат простые протоколы, основанные на передаче текста, их легко сможет декодировать и разобрать на составные части даже полуобразованный "сетевой маньяк". Да вы и сами заметили, что до сих пор в данной главе основным оружием хакеров был Web-браузер и документация RFC!
Здесь важно отметить, что каждое Web-приложение обладает своими уникальными свойствами, которые несколько смягчают общие недостатки защиты. Таким образом, для атаки типичного Web-приложения необходимо применять различные методы, гибкие подходы и нередко умение увязать несколько на первый взгляд никак не связанных ошибок В едином процессе взлома. Подробное описание таких подходов и методов - это тема отдельной книги, которая была таки написана. Ее название — Секреты хакеров. Безопасность Web-пршюжений — готовые решения (Джоел Скембрей, Майк Шема, Йен-Минг Чек, Дэвид боке. Издательский дом "Вильяме", 2003).

Если после прочтения этой главы запуск Web-сервера Internet на основе IIS совсем вас не пугает, проверьте свой пульс. Однако риск можно существенно снизить, следуя представленным в тексте главы рекомендациям, которые далее повторяются В кратком виде и представлены согласно степени важности, т.е. первый пункт критически важен, последний — просто важен (поняли, в чем дело?). ■
Т Для создания периметра защиты вокруг Web-серверов применяйте контроль доступа на уровне сети с помощью маршрутизаторов, брандмауэров и других устройств. Блокируйте все несущественные соединения в обоих направлениях (список часто используемых при взломе портов в системах Windows см. в главе 3, "Предварительный сбор данных и сканирование"). Хотя этот вопрос не был подробно описан в данной главе, самое худшее, что можно сделать, — предоставить доступ к уязвимой службе, например SMB. (если нужно, перечитайте главы 4, "Инвентаризация", и 5, "Атака на службы Windows"). Обеспечьте блокирование исходящих из Web-сервера соединений, чтобы не дать хакеру загрузить файлы из удаленной системы по протоколу TFTP или FTP или не дать подключить удаленную службу к командной строке системы.
■ Блокируйте все несущественные входящие и исходящие соединения Web-сервера на уровне узла, чтобы обеспечить "эшелонированную защиту". Управление доступом к сети на уровне узла a Windows Server 2003 обеспечивается с помощью TCP/iP Security или с помощью фильтров IPSec (см. главу 16, "Возможности и средства защиты в системах Windows").
■ Обеспечьте безопасность своей версии сервера IIS. В IIS 6 была коренным образом изменена модель исполнения процессов, а новые настройки по умолчанию позволяют блокировать многие типы атак. Тем не менее, сохраняющиеся возможности обратной совместимости заставляют помнить о взломах прошлых версий IIS. Прочитайте, проанализируйте и примените конфигурации, описанные в списке Microsoft If S 4 Security Checklist (за исключением вопросов, которые не относятся к версии IIS 5) и в списке Secure Internet Information Services 5 Checklist.
■ Используйте программы IlSlockdown и UrlScan от компании Microsoft для защиты всех своих Web-ссрвсров (см. ссылку в разделе "Дополнительная литература и ссылки").
■ Тщательно следите за выпусками "горячих исправлений"! В этой главе продемонстрированы результаты атак на переполнение буфера типа уязвимого места . htr. Хотя созданы исправления этих ошибок, проблемы с переполнением буфера обычно исправляются только на уровне кода заплатой от производителя, поэтому до обновления сервер остается уязвимым. Помочь в поиске необходимой заплаты способна удобная программа Microsoft Network Security Hotfix Checker (файл hfnetchk. exe), о которой можно подробнее прочесть в приложении А, "Перечень мер по защите Windows Server 2003".
■ Удалите неиспользуемые связи (с расширениями файлов) для сценариев и неиспользуемые библиотеки ISAPI. В этой главе мы рассказали о многочисленных проблемах, которые способны вызывать специально подготовленные запросы к библиотекам 1SAPI.
■ Отключите ненужные службы. Для работы сервера ITS 5 требуются такие службы: IIS Admin Service, Protected Storage и World Wide Web Publishing Service. Кроме того, в Windows Server 2003 невозможно остановить следующие службы с помощью графического пользовательского интерфейса: Event Log, Plug and Play, Remote Procedure Call (RPC), Security Accounts Manager, Terminal Services (если только последняя служба была установлена, что для Web-сервера не рекомендуется) и сервис Windows Management Instrumentation Driver Extensions. Все остальное можно отключить. Даже в одиночку сервер IIS
способен обслуживать запросы страниц. В зависимости от архитектуры Web-приложений, может потребоваться включение других служб для обеспечения некоторых функций, например, для доступа к базам данных. Особенно обратите внимание на отключение служб Indexing Service, FTP Publishing Service, SMTP Service и Telnet.
■ Тшательно продумайте использование шаблонов Security Templates для предварительной настройки устанавливаемых Web-сервероВ. За основу можно взять шаблон от Microsoft hisecweb. inf.
■ Не создавайте корневые каталоги Web-серверов на системном диске, чтобы в системный каталог нельзя было зайти, используя программы для "путешествий" по файловой системе типа Unicode или двойного декодирования (сочетанием "точка-точка-косая черта" нельзя перейти на другой диск).
■ Всегда используйте файловую систему NTFS на дисках Web-сервера и явным образом настраивайте списки контроля доступа (ACL). Для облегчения этой работы используйте утилиту cacls, которая описана в данной главе. Для всех исполняемых файлов каталога %systemroot% должны быть установлены права System: Full, Administrators: Full.
■ Удалите разрешение на запись и выполнение файлов во всех каталогах для групп Everyone, Users и других непривилегированных групп. Удалите разрешение на запись файлов во всех каталогах для пользователей IUSR и IWAM, а также тщательно продумайте разрешения на выполнение программ. Обратитесь к рекомендациям по спискам АСЬдля виртуальных каталогов в перечне советов Secure IIS 5 Checklist.
■ Найдите и удалите вызовы функции RevertToSelf в существующих приложениях ISAP1, чтобы их нельзя было использовать для расширения привилегий учетных записей IUSR или IWAM. Проверьте, чтобы настройка сервера IIS Application Protection была установлена в значение Medium (по умолчанию) или High, тогда вызовы функции RevertToSelf будут предоставлять управление только с правами учетной записи IWAM.
■ Не храните секретную информацию в файлах Active Server или во включаемых файлах! Используйте для операций получения конечного результата объекты СОМ или аутентификацию SQL, встроенную в Windows, чтобы в сценариях ASP пароли не нужно было использовать в строках соединения. Обязательно пользуйтесь тегами <%%> для выделения в сценариях информации, предназначенной для выполнения на сервере. Хотя такой способ защищает не от всех типов атак по раскрытию исходного кода, разработчики, по крайней мере, будут помнить о том, что их код может попасть в плохие руки.
■ Отключите службу Parent Paths, которая позволяет использовать строку символов ".
в сценариях и вызывать функции типа MapPath в приложениях. Откройте свойства нужного компьютера сети в утилите IIS Admin (iis . msc), измените основные свойства: WWW Service (WWW-служба)1* Home Directory (Домашний катало г) ^Application Settings (Параметры приложений^СопАдигайоп (Настройка) ^Application Options (Параметры приложения) и снимите флажок у пункта Enable Parent Paths.
■ Переименуйте файлы с расширением . inc в .asp-файлы (не забудьте изменить ссылки в существующих сценариях ASP). Тогда файл с расширением . inc нельзя будет просто загрузить и посмотреть текст программы, даже если будет точно известно его имя.
■ Удалите с Web-узла все файлы примеров и ненужные функции (что конкретно нужно удалять, описано в списке Secure IIS 5 Checklist). Если существует виртуальный каталог IISADMPWD, удалите его (этот каталог будет в системе, если было выполнено обновление до версии IIS 5 с IIS 4).
■ Остановите службу администрирования Wcb-узла и удалите виртуальные каталоги ilSAdmin и USHelp вместе с их физическими двойниками. Тогда станет невозможным администрирование 1IS на основе Web. Хотя сервер IIS ограничивает доступ
к этим каталогам по умолчанию локальной системой, порт остается доступным для внешних интерфейсов (это TCP-порт, номер которого представляет собой четырехзначное число). Незачем предоставлять хакерам дополнительные инструменты администрирования для использования в своих целях, если они могут получить эти инструменты, используя механизм атаки наподобие ошибки Unicode.
■ Серьезно подумайте, будет ли Web-узел управляться удаленно. Если да, то примите самые строгие меры безопасности и защиты механизма удаленного администрирования. Мы рекомендуем не делать Web-серверы доступными через другие службы (естественно, за исключением самой Web-службы), а вместо этого выделить единственную систему удаленного администрирования, которая находится в одном сегменте сети с Web-сервером и связана с ним. Все удаленное администрирование должно быть ограничено только этой специ­ально назначенной системой. В качестве средств удаленного администрирования рекомендуются программы Terminal Server и Secure Shell, которые обеспечивают защиту и шифрование связи.
■ Для серверов, которые используют протокол SSL, отключите поддержку протокола PCT (Private Communications Technology). Для этой цели создайте или отредактируйте значение "Enabled" (без кавычек) REG_BINARY следующего параметра системного реестра и установите это значение равным "00000000" (без кавычек).
HKLM\SYStem\Cui-rentConcrolSet\Control\SecujrityProviders\ SCHftTJNEL\Protocols\PCT 1. Q\Server.
Более подробно эта тема обсуждается в статьях базы знаний Microsoft 187498 и 260749. Протокол РСТ был предложен компанией Microsoft в 1995 году в качестве 'Улучшенной" версии SSL. Поскольку этот протокол больше не используется, его поддержку следует отключить и этим уменьшить диапазон возможных атак на сервер IIS.
* И последнее, но, конечно, не маловажное замечание: при разработке Web-приложений ставьте безопасность на первое место. Все перечисленные меры противодействия не остановят злоумышленника, который проник на сервер как законный анонимный или авторизованный пользователь. На уровне приложений для дискредитации всех усилий по защите Windows и IIS-сервера достаточно лишь одной ошибки в логике программы. Не сомневайтесь, стоит ли проводить независимую экспертизу в случаях, когда ваша команда Web-разработчиков не очень сильна в вопросах безопасности, обязательно запланируйте проверки дизайна и реатизации программ третьей стороной как можно раньше. Помните, что все данные могут быть введены с неблаговидными намерениями, проверяйте все возможные варианты!
Благодарим Майкла Говарда (Michael Howard), Эрика Шульца (Eric Schultze) и Дэвида ЛеБланка (David LeBlanc) из Microsoft Corp. за существенные и полезные советы по составлению приведенного списка.

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика