Настройка Web-сайта для защиты от угроз

Microsoft потратила не один год на то, чтобы сделать свой Web-сервер, IIS (Internet Information Server), качественным продуктом, и вот IIS 6.0 может считаться действительно надежным и безопасным сервером. Большинство компаний, перечисленных в списке Fortune 1000 за 2005 год, используют сервер IIS 6.0 на своих основных сайтах, согласно исследованиям Port80 Software. С момента выпуска в марте 2003 года поступило только три сообщения об уязвимых местах в системе безопасности сервера IIS 6.0, по данным компании, специализирующейся на проблемах безопасности Secunia IT, в то время как у Apache 2.0 их было 24. Это дает основание предположить, что Microsoft выполняет обещания улучшить систему безопасности Web-сервера.

Тем не менее защита сервера Microsoft IIS, подключенного к Internet, требует значительных усилий. Она начинается с установки Windows Server 2003. Но в реальной ситуации приходится устанавливать и настраивать еще сайты и приложения. Подключение сервера к Internet привлекает внимание хакеров и злоумышленников, которые стремятся попасть на любой сайт в поисках возможности использовать бреши в защите. Помня об этом, я поставил Windows Server 2003, дополняя систему настройками для защиты против атак, а затем загрузил и настроил Microsoft IIS 6.0 в соответствии с руководствами по защите. Процедура, которой я следовал, описана ниже.

Установка Windows 2003

Первым делом я установил Windows 2003 и поставил все исправления до подключения сервера к Internet. Перед запуском IIS мне хотелось сделать основную систему Windows 2003 надежной базой. Задача этого первого шага — убедиться в том, что все встроенные программы оборудования и BIOS имеют последние версии. Система не должна пострадать из-за устаревших драйверов SCSI.

Я ограничил загрузку только дисководом C, чтобы предупредить локальные атаки, которые используют обход загрузки операционной системы, задействуя Knoppix или NTFSDOS. Запрещая несанкционированную загрузку с CD-ROM или флоппи-диска, можно закрыть лазейку для многочисленных программ переустановки или взлома паролей и сделать копирование локальной базы SAM на переносной носитель практически невозможным. Еще я блокировал неиспользуемые порты COM, LPT1, IDE и USB в BIOS, а затем защитил BIOS сложным паролем. Я установил маршрутизатор и брандмауэр перед компьютером-сервером и блокировал все порты TCP маршрутизатора, кроме одного порта RDP, используемого для удаленной установки и настройки. Когда сайт начнет функционировать, потребуется только открыть порт TCP 80.

Затем я установил Windows 2003 Standard Edition и принял настройки по умолчанию для сервера в автономном режиме (домен для автономного публичного Internet-сервера не нужен). После этого я создал два локальных диска, C и D, на жестком диске с RAID. По рекомендациям Microsoft устанавливать операционную систему и Web-сайт IIS надо отдельно, на разных томах, чтобы предупредить возможные атаки от программ из соседних каталогов.

Я переименовал учетные записи администратора и гостя (Administrator и Guest), дав им имена из случайной последовательности символов, и снабдил их сложными паролями, общее число символов в которых было больше 10, чтобы уменьшить вероятность взлома посредством прямого подбора. Хотя взломщик может найти учетную запись администратора через идентификатор SID, анонимный просмотр SID блокируется по умолчанию на системах, которые не являются контроллерами доменов DC (domain controller) в Windows 2003 и Windows XP.

Я оставил Remote Desktop как единственный способ для удаленного администрирования сервером. Выбор пал на Remote Desktop, поскольку Remote Desktop устанавливается (хотя и не запущен) по умолчанию, хорошо функционирует и позволяет удаленно присваивать обозначения накопителям. Это дает возможность устанавливать программное обеспечение и иметь при этом по умолчанию шифрование RC4. Я заменил на другой порт протокола RDP стандартный порт 3389 протокола TCP по инструкции, приведенной в статье Microsoft «How to Change Terminal Server?s Listening Port» (http://support.microsoft.com/?kbid=187623). Этот порт задействован по умолчанию для усложнения поиска хакерами службы Remote Desktop и замедления атак методом перебора на обнаруженный порт RDP.

Идея о необходимости протокола IPsec для доступа к соединению с Remote Desktop показалась мне забавной, и я решил не принимать дополнительных мер предосторожности, пока был уверен, что сервер остается защищенным. Протокол IPsec может предупредить атаки с использованием посредника против Remote Desktop, но мне не хотелось устранять конфликты между Remote Desktop и IPsec на этапе начальной настройки. Переименование учетных записей Administrator и Guest, а также их усложненные пароли могли бы сыграть свою роль в деле защиты сервера от атак с удаленным взломом пароля.

Дополнительно я с помощью групповой политики Group Policy внес следующие изменения в настройки Remote Desktop:

  • отдельно запретил доступ анонимного пользователя к Remote Desktop;
  • установил высокий уровень шифрования;
  • заблокировал применение удаленного управления на соединениях Remote Assistance;
  • ввел принудительное завершение сессии пользователя при отключении;
  • запретил запуск программ в процессе регистрации, в результате рабочий стол всегда показывается сразу после успешного подключения к Remote Desktop;
  • заблокировал отображения всех дисков, кроме отображения буфера обмена (clipboard).

Что касается настроек Remote Desktop на сервере, то я добавил следующее:

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

Я скопировал Windows 2003 Service Pack 1 (SP1) на сервер, установил его и перезагрузил сервер. Затем активизировал Microsoft Baseline Security Analyzer (MBSA), чтобы посмотреть, нужны ли еще исправления. Задача эта оказалась довольно трудной. Ее нужно было выполнить без доступа в Internet, чтобы сервер без исправлений не мог быть атакован злоумышленниками. Для выполнения этой задачи я загрузил базу данных XML для MBSA (mssecure.xml) на свою локальную систему, затем скопировал ее на сервер. Потом я активизировал MBSA, чтобы убедиться, нет ли пропущенных исправлений или известных изъянов. Я активизировал MBSA снова после установки сервера IIS, поскольку MBSA не сканирует исправления и изъяны сервера IIS, если сервер IIS не установлен и не функционирует.

Установка Windows 2003 с SP1 по умолчанию проще, чем шаги в описанной процедуре внесения исправлений на системе до подключения сервера к Internet. Пакет SP1 предотвращает всякий доступ к серверу до завершения процесса установки исправлений, это снижает риск проникновения злоумышленников до того момента, когда начнут функционировать исправления. Однако физическое отключение доступа к Internet и установка исправлений вручную всегда эффективнее. Затем я запустил мастера настройки системы безопасности SCW — Windows 2003 SP1 Security Configuration Wizard, выбрав для роли сервера значение standalone IIS box (изолированный IIS), и заблокировал все другие ненужные функции и службы. Новый мастер Microsoft выполнил большую часть работы и провел процесс настройки, но не заблокировал все, что мне было нужно, поэтому пришлось заблокировать часть служб вручную. Вот что мне пришлось сделать после работы мастера SCW:

  1. На экране мастера роли сервера Server Roles я выбрал только роль Web Server; отменил выделение функций Application Server, File Server и Middle-tier Application Server (COM+/DTC).
  2. На экране мастера свойства клиента Client Features отменил все функции.
  3. На экране мастера установленных дополнений Installed Options выбрал: Backup (NT or Third Party), копирование на локальные аппаратные средства - Backup to local hardware, локальную установку приложения - Local application installation, удаленное администрирование - Remote desktop administration, удаленную настройку и анализ SCW - Remote SCW configuration and analysis, удаленное администрирование системы - Remote Windows administration, брандмауэр Windows Firewall и Windows user mode driver framework; отменил временную синхронизацию Time Synchronization и WPAD.
  4. Заблокировал менеджер загрузок Upload Manager.
  5. Настроил брандмауэр Windows Firewall на разрешение соответствующего порта RDP.
  6. Заблокировал LAN Manager (LM), протоколы аутентификации NTLM и NTLMv2.
  7. Настроил аудит всех удачных и неудачных действий.

Затем я вручную заблокировал следующие службы с консоли Services:

  • Application Experience Lookup Service
  • Automatic Updates
  • BITS
  • Computer Browser
  • DHCP Client
  • Error Reporting Service
  • Help and Support
  • Network Location Awareness
  • Print Spooler
  • Remote Registry
  • Secondary Logon
  • Server
  • Smartcard
  • TCP/IP NetBIOS Helper
  • Workstation
  • Windows Audio
  • Windows Time
  • Wireless Configuration

Открыл редактор политик сервера Local Computer Policy (gpedit.msc) и выполнил следующие изменения:

  1. Установил минимальный размер пароля 12 знаков.
  2. Разрешил требование сложного пароля.
  3. Установил порог блокировки учетных записей на пять неудачных попыток в течение минуты.
  4. Разблокировал проверку событий Success/Failure для всех категорий аудита, кроме Directory Service Access и Process Tracking.
  5. Лишил группу Everyone доступа к этому компьютеру по сети.
  6. Изменил реакцию на поведение неподписанных драйверов из состояния Warn (предупреждение) в Don't Allow (не разрешать).
  7. Разблокировал окно сообщения при регистрации (для затруднения действий программ прямого перебора). Не выбирайте настройку по умолчанию Unauthorized access not allowed.
  8. Заблокировал кэширование данных регистрации (на сервере это не имеет значения).
  9. Разблокировал режим запрета анонимного доступа к учетным записям SAM и общим ресурсам - Do not allow the anonymous access of SAM accounts and shares.
  10. Разблокировал режим запрета хранения учетных данных или данных службы Passports для аутентификации по сети - Do not allow the storage of credentials or Passports for network authentication
  11. Разблокировал режим запрета хранения хеша пароля при смене протокола Lan Man - Do not store Lan Man hash value on next password change option.
  12. Изменил уровень LM Authentication Level на значение NTLMv2 - отказ LM и NTLM.
  13. Разблокировал режим очистки файла подкачки Clear virtual memory page file.
  14. Удалил Posix как дополнительную подсистему Windows.
  15. Заблокировал запуск Windows Messenger - установил Do not allow Windows Messenger to be run.
  16. Заблокировал запуск Windows DRM - установил параметр Do not allow Windows DRM to be run.
  17. Заблокировал запуск Windows Movie Maker - установил параметр Do not allow Windows Movie Maker to be run.
  18. Заблокировал службу Automatic Updates.
  19. Выключил режим обнаружения скорости канала при развертывании GPO.
  20. Запустил сканирование WFP во время старта системы.
  21. Ограничил использование CD-ROM и флоппи только для локально зарегистрированных пользователей
  22. Запретил право локальной регистрации анонимным пользователям сервера IIS.
  23. Включил запрет отображения информации о пользователе в окне регистрации
  24. Удалил DFS$ и COMCFG из совместных ресурсов, поскольку они разрешают анонимную регистрацию.
  25. Заблокировал Active Desktop.

Кроме того, я заблокировал диалог File and Printer Sharing в окне Network Configuration и защитил стек TCP, изменив записи в реестре по совету с сайта http://msdn.microsoft.com/library/default.asp?url=/ library/en-us/secmod/html/secmod109.asp. Затем я перезагрузил сервер, чтобы проверить запуск всех изменений и правильность работы сервера. И вот после этого можно начать разворачивать программное обеспечение Web-сервера.

Установка и настройка IIS 6.0

Сервер IIS был установлен в обычном режиме по умолчанию, когда дополнительно блокируются все Web-расширения и фильтры Internet Server API (ISAPI). Ниже приведены дополнительные шаги для установки и настройки.

  1. Изменить IP-адрес Web-сайта в консоли менеджера IIS Manager - назначить статический частный адрес (static private address) вместо All Unassigned.
  2. Переименовать сайт Default Web site в консоли IIS Manager.
  3. На переименованном сайте мне понадобился заголовок хоста для согласования правильного указателя URL. Это действие предохраняет от многих автоматических инструментов для взлома и "червей", поскольку в них обычно используются только IP-адреса. При доступе пользователей они почти всегда задействуют имя Web-сайта, а не IP-адрес.
  4. Установить разрешение Execute Permissions Web-сайта в значение None в консоли менеджера IIS Manager.
  5. Заблокировать учетные записи IWAM и анонимные по умолчанию IIS в User Manager.
  6. Создать новую анонимную учетную запись IIS. Хотя это необязательный шаг, он позволит лучше управлять параметром, определяющим доступ анонимного пользователя IIS к Web-серверу.
  7. Создать группу Anonymous Web Users, добавить учетную запись нового анонимного пользователя IIS для этой группы и удалить первоначальную учетную запись анонимного пользователя IIS.
  8. С помощью Windows Explorer установить разрешения для группы Anonymous Web Users в значения Deny на папки Windows и System32.
  9. Создать новый каталог Web-сервера IIS на дисководе E.
  10. В консоли менеджера IIS Manager заменить каталог Web-сервера IIS, C:Inetpub на новый каталог на дисководе E. Удаление Web-сайта из корневого каталога блокирует многие атаки.
  11. Присвоить новой группе анонимных пользователей, Anonymous Web Users, разрешение read-only, это помогает предотвратить чтение или создание файлов анонимными пользователями на Web-сайте.
  12. Установить URLScan 2.5. URLScan загружается в качестве программы ISAPI. После успешной ее установки были выполнены следующие изменения:
    • установка UseAllowExtensions в значение 1;
    • установка Set MaxURL в значение 50;
    • установка длины MaxAllowContent Length в значение 1000;
    • установка MaxQueryString в значение 0;
    • установка Set AllowVerbs в GET и HEAD;
    • добавление точки к AllowExtension.

Эти настройки URLScan — особенно короткая длина URL и нулевая длина для запросов — делают сайт устойчивым к известным и будущим атакам переполнения буфера через URL. Хотя эти значения не подойдут для всех коммерческих сайтов, любой сайт заметно выиграет в плане безопасности за счет отказов от избыточно длинных запросов и URL.

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

  1. Добавить разрешения Everyone Deny к файлам в WindowsTemporary Compressed Files.
  2. Удалить все файлы в папке iisadmpwd.
  3. Удалить папку wutemp, оставленную после установки исправлений.
  4. Заблокировать Idle Timeout for Default App Pool.
  5. В консоли IIS Manager заблокировать состояние сессии Session State на новом Web-сайте.
  6. Заблокировать расширения Cache ISAPI.
  7. Изменить учетную запись Default App Pool с NetworkService на LocalService, поскольку для Web-сайта допуск к дополнительным сетевым ресурсам не нужен.
  8. Изменить настройки повторного использования памяти на значение 700 Мбайт для обеих настроек.
  9. Заблокировать быструю защиту от сбоев.
  10. Изменить время выключения Shutdown Time Limit с 90 секунд на 10 секунд.

Потом я остановил и перезапустил IIS, чтобы активизировать новые изменения. Я перезапустил MBSA, чтобы проверить, были ли пропущены исправления, и система сообщила, что пропущенных исправлений нет.

Настройка системных журналов

Сначала я рассматривал возможность применения приложения Network Monitor от Microsoft или IDS (Intrusion Detection System) от других поставщиков, чтобы отслеживать активность хакеров, но позже решил применять серверные инструменты для управления и системные журналы, которые обычно устанавливаются по умолчанию с IIS. Ниже перечислены шаги установки.

  1. Создаем папку C:IISLogfiles для хранения всех системных журналов.
  2. Почасовое формирование журналов IIS, со всеми полями и в C:IISLogfiles.
  3. Настраиваем URLScan на хранение своих журналов в C:IISLogfiles. Заметим, что встроенная функциональность системы безопасности http.sys в IIS 6.0 создает системный журнал по имени HTTPERR (подробнее об этом рассказано в статье "Error logging in HTTP API" на сайте http:// support.microsoft.com/?id=820729). Я не знал, как переместить этот системный журнал, поэтому просто создал его ярлык в C:IISLogfiles.
  4. Задаем настройки брандмауэра Windows Firewall для управления принятыми и пропущенными пакетами и хранения его журнала в C:IISLogfiles. Я узнал, что максимальный размер журнала в брандмауэре Windows Firewall равен 32 Мбайт (очень мало) и что надо останавливать Windows Firewall для копирования системных журналов. Когда мне нужно было копировать системные журналы на внешний компьютер для изучения, я применял для защиты сервера IPsec.
  5. Создаем политику IPsec между Web-сервером и компьютером для удаленного управления, которая будет использоваться для подключения RDP.
  6. Запускаем аудит удачных и неудачных событий. Заметим, что со временем, вероятно, сайты больших размеров будут испытывать затруднения в производительности ввиду больших объемов информации аудита при включении всех разрешенных проверок. После устранения всех сбоев, которые приводят к сообщениям об ошибках, можно оставить только категории, рекомендованные в руководстве IIS 6.0 Resource Kit.

В завершение процесса я очистил корзину, дабы убедиться, что старых файлов больше нигде нет. Затем перезагрузил сервер и открыл на маршрутизаторе и брандмауэре трафик с порта 80 протокола TCP.

Результаты

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

Результат, который показывает мой Web-сайт, означает, что Windows 2003 и IIS 6.0, если принять все необходимые меры предосторожности, могут обеспечить высокий уровень защиты. Большинство мер усиления, описанных выше, взято непосредственно из руководства по укреплению системы безопасности Microsoft IIS. Если следовать им, Web-сайты будут надежно защищены.

Роджер Граймз - Редактор Windows IT Pro и консультант по проблемам безопасности. Имеет сертификаты CPA, CISSP, CEH, CHFI, TICSA, MCT, MCSE: Security и Security+. roger@banneretcs.com