Защита IIS: распространенные мисконфигурации и связанные с ними риски
Введение
Веб‑сервер — один из фундаментальных компонентов IT‑инфраструктуры. Он обеспечивает доступ к веб‑приложениям, сайтам и сервисам для внутренних, корпоративных и внешних пользователей, а также отвечает за доставку контента и управление пользовательскими сессиями. Поэтому безопасность веб‑серверов должна быть приоритетом для отделов кибербезопасности и IT. Даже небольшая уязвимость или ошибочная настройка хостинга могут привести к утечке конфиденциальных данных, компрометации приложений и нарушению работы всей сети. Количество целенаправленных кибератак на веб‑серверы постоянно растет, так что их защита требует системного, проверенного и документированного подхода.
На платформах Windows самый распространенный веб‑сервер — IIS (Internet Information Services). Это компонент операционной системы, тесно интегрированный с ее ядром и службами, поддерживающий технологии ASP.NET, PHP, HTTP/HTTPS, FTP и другие. По данным сервиса BI.ZONE TDR, в 89% российских компаний используется IIS: масштаб распространения делает его привлекательной целью для злоумышленников. Это подтверждается и данными открытого поисковика по сетевым сервисам Shodan: в России обнаружено более 70 000 публичных серверов, работающих на IIS.
На Unix- и Linux‑системах больше всего распространены веб‑серверы Apache и Nginx. Их функциональные возможности сопоставимы с IIS, но защита требует немного иного подхода. Его мы подробно рассмотрели в другой статье — «Механизмы защиты и усиления безопасности веб‑серверов Nginx и Apache».
В этом тексте мы подсветим основные риски, возникающие при неправильной конфигурации IIS, и предоставим проверенные практики его харденинга — укрепления защиты. Особое внимание уделим типичным конфигурационным ошибкам, которые злоумышленники используют, чтобы получить несанкционированный доступ, обойти механизмы защиты и скомпрометировать конфиденциальные данные или сам сервер. В отдельном гайде покажем, как на практике обнаружить, проанализировать и устранить такие ошибки, а также автоматизировать их мониторинг с помощью решения BI.ZONE EDR. Изучение обоих материалов позволит узнать риски, связанные с мисконфигурациями IIS, а также исправить эти ошибки.
Установка, структура конфигурации и архитектура развертывания
Чтобы установить IIS в ОС Windows, нужны только встроенные средства, загрузка дополнительного ПО не требуется. В статье мы ориентируемся на работу с веб‑сервером IIS версии 10.0 — текущий стандарт для всех современных серверных и клиентских платформ Windows (Windows Server 2016/2019/2022/2025, Windows 10/11). Установка одинакова для всех этих версий ОС, различается только способ запуска. Перед работой удостоверьтесь, что у вас есть права локального администратора.
Установка IIS на клиентских версиях Windows
На клиентских версиях Windows (Windows 10, Windows 11) IIS устанавливается через встроенные компоненты ОС.
Порядок действий
- Нажать клавиши Win + R → откроется окно Выполнить (Run).
- Ввести
controlв поле поиска → нажать Enter → запустится Панель управления (Control Panel). - Выбрать раздел Программы (Programs).
- Выбрать раздел Программы и компоненты (Programs and Features).
- Выбрать на боковой панели слева Включение или отключение компонентов Windows (Turn Windows features on or off).
- Установить галочку напротив Internet Information Services (службы IIS).
- При необходимости развернуть дерево компонентов, выбрать дополнительные модули в соответствии с требованиями развертывания.
- Нажать OK.
Система начнет загружать файлы и настраивать IIS. Это займет несколько минут в зависимости от производительности компьютера. После установки может потребоваться перезагрузить ОС для завершения конфигурации.
Установка IIS на Windows Server
На серверных версиях Windows установка IIS немного отличается и выполняется через «Диспетчер серверов» (Server Manager).
Порядок действий
- Нажать клавиши Win + R → откроется окно Выполнить (Run).
- Ввести
servermanagerв поле поиска → нажать Enter → запустится Диспетчер серверов (Server Manage). - Нажать Управление (Manage) в верхней части окна.
- Выбрать Добавить роли и компоненты (Add Roles and Features).
- Убедиться, что выбран вариант Установка ролей или компонентов (Add Roles and Features Wizard) → нажать Далее (Next).
- Выбрать целевой сервер, на который будет установлен IIS → нажать Далее (Next) → откроется этап выбора ролей.
- Отметить галочкой роль Веб‑сервер (IIS) (Web Server (IIS)) → откроется системное добавление дополнительных компонентов, нужных для работы этой роли.
- Нажать Добавить компоненты (Add Features) → при необходимости выбрать дополнительные компоненты IIS в соответствии с требованиями развертывания.
- Нажать Установить (Install).
Начнется загрузка файлов и настройка компонентов IIS. Затем может потребоваться перезагрузить сервер, чтобы параметры конфигураций применились.
Проверка установки
После установки перейдите в любом браузере по адресу http://localhost/. Если IIS установлен корректно, отобразится его приветственная страница. Значит, основной компонент веб‑сервера успешно запущен и готов к работе.
Чтобы управлять веб‑сервером и его настройками, откройте Диспетчер служб IIS (Internet Information Services (IIS) Manager): нажмите Win + R и введите inetmgr. Так вы сможете создавать веб‑сайты, управлять приложениями, настраивать параметры безопасности и проводить другие конфигурационные операции.
Файлы конфигурации IIS
В IIS используется иерархическая система конфигурации, которая позволяет управлять параметрами на разных уровнях: от всего сервера до конкретных приложений и директорий. Понимать эту структуру необходимо для корректного харденинга, так как из‑за неправильного размещения настроек некоторые параметры безопасности не применятся ко всем сайтам или будут переопределены локальными конфигурациями.
Основной файл конфигурации IIS — applicationHost.config, расположен в директории C:\Windows\System32\inetsrv\config. Этот файл на языке XML содержит все глобальные настройки веб‑сервера:
- определения веб-сайтов,
- пулы приложений,
- модули и обработчики HTTP‑запросов,
- параметры безопасности.
Все веб-сайты на сервере по умолчанию наследуют настройки из файла applicationHost.config, если эти параметры не переопределены локально. При редактировании applicationHost.config создайте резервную копию файла и тестируйте изменения в ней перед применением на продакшен‑серверах.
Каждый веб‑сайт или приложение в IIS может иметь собственный файл конфигурации web.config (тоже в формате XML), обычно расположенный в корневой директории веб‑приложения (например, C:\inetpub\wwwroot\web.config). Этот файл позволяет переопределять глобальные настройки для конкретного сайта или приложения. Для безопасного редактирования файлов конфигурации рекомендуется использовать «Диспетчер служб IIS» вместо прямого редактирования XML, чтобы предотвратить ошибки синтаксиса и автоматически проверить корректность конфигурации.
IIS загружает настройки в следующем порядке:
applicationHost.config(глобальные настройки).web.configна уровне веб‑сайта.web.configв корневой директории приложения.web.configв конкретных поддиректориях.
Каждый следующий уровень может добавлять новые параметры или переопределять параметры из предыдущих уровней. При этом более специфичные уровни конфигурации имеют приоритет над глобальными настройками.
Архитектурное расположение IIS
При развертывании IIS в производственной среде, доступной в интернете, критически важна правильная архитектура безопасности. Лучше всего размещать IIS за многоуровневой защитой: между клиентами и веб‑сервером должны быть промежуточные системы безопасности. Типовая архитектура защиты выглядит следующим образом:
Трафик из интернета поступает на Anti‑DDoS, затем — на Web Application Firewall (WAF) и только после двух этапов защиты достигает веб‑сервера. DDoS‑атаки часто используются как прикрытие для целевых атак на уровне приложений, таких как SQL‑инъекции или эксплуатация уязвимостей. Связка Anti‑DDoS и WAF позволяет эффективно распределить нагрузку защиты и организовать комплексную оборону против различных типов киберугроз.
BI.ZONE AntiDDoS обеспечивает защиту от DDoS‑атак на всех уровнях модели OSI (L3—L7). Сервис гарантирует непрерывную работу ресурсов с показателем доступности до 99,9%, обнаруживает и блокирует ботнет‑активность, фильтрует HTTPS‑трафик с поддержкой алгоритмов шифрования ГОСТ. Вредоносный трафик блокируется, что позволяет экономить на обработке атакующего трафика (не нужно переплачивать за RPS (requests per second) на следующих уровнях защиты). Также это снижает нагрузку на следующие системы безопасности.
Затем защиту веб‑приложений на прикладном уровне
- SQL- и NoSQL‑инъекции,
- межсайтовый скриптинг (XSS),
- удаленное выполнение кода (RCE),
- выход за пределы рабочей директории веб‑сервера (path traversal),
- внедрение внешних сущностей XML (XXE),
- перехват сессий (session hijacking),
- полный перебор паролей и ключей (брутфорс‑атаки),
- попытки использовать утекшие учетные данные (credential stuffing) и ботнет‑активности.
Чтобы выявить подозрительные запросы, сервис использует функции внедрения безопасных HTTP‑заголовков и поведенческие проверки (JS Challenge, CAPTCHA).
Только после прохождения обоих уровней защиты проверенные запросы достигают веб‑сервера IIS. Такое разделение помогает централизованно логировать и мониторить весь входящий трафик.
Дополнительное использование BI.ZONE TDR позволит быстро реагировать на подозрительную активность, применять политики ограничения скорости доступа и принимать обоснованные решения по защите, ориентируясь на собранные данные об атаках и поведении веб‑приложения.
Основные мисконфигурации
Основное внимание мы уделим уровню applicationHost.config, так как на нем определяются параметры, которые применяются ко всему серверу и гарантированно наследуются всеми сайтами. Этот уровень позволяет обеспечить единую, согласованную политику безопасности для всей инфраструктуры IIS без необходимости настраивать каждый сайт отдельно. Рекомендуется устанавливать базовые параметры безопасности глобально в applicationHost.config, чтобы не ослаблять защиту из‑за неправильной конфигурации отдельных сайтов. При этом локальные настройки web.config могут использоваться для дополнительного усиления безопасности на уровне конкретных веб‑приложений.
Ниже — основные мисконфигурации, а рекомендации, как их устранить, — в отдельном гайде, который можно получить за подписку на наши рассылки. Подробнее, как это сделать, — в конце материала.
Утечки информации в ответах сервера
По умолчанию IIS отдает значительный объем технической информации в HTTP‑ответах сервера: версию сервера, установленные модули и типы обработчиков и т. д. Эта информация не требуется для корректной работы веб‑приложений, но помогает злоумышленникам при планировании целевых атак и киберразведке. Чтобы обеспечить грамотную защиту и существенно уменьшить поверхность атаки на веб‑сервер, необходимо минимизировать объем технической информации, передаваемой в ответах.
Далее рассмотрим основные источники утечек.
Отображение стандартной страницы IIS
Когда IIS устанавливается впервые, для проверки работоспособности сервера по умолчанию на него добавляется приветственная страница. По ней злоумышленники смогут определить сервер IIS и его версию, получив дополнительную информацию для планирования атак и подбора эксплоитов. Поэтому после установки IIS рекомендуется сразу скрыть эту страницу.
Серверные заголовки
Каждый HTTP‑ответ от веб‑сервера содержит заголовок Server, в котором указана информация о типе и версии сервера. По умолчанию IIS отправляет в этом заголовке строку вида Server: Microsoft-IIS/10.0, которая раскрывает тип сервера и его версию.
Злоумышленники могут использовать номер версии для поиска известных уязвимостей, специфичных для этой версии IIS, и быстро выбирать подходящий эксплоит. Удаление заголовка Server — одна из базовых мер харденинга, так как это не нарушает функциональность приложения, но значительно затрудняет разведку. Киберпреступники не смогут легко определить точную версию сервера и будут вынуждены использовать более сложные методы для идентификации уязвимостей.
Заголовок X-Powered-By
IIS отправляет дополнительный заголовок X‑Powered‑By, который по умолчанию содержит информацию об используемых технологиях, например X‑Powered‑By: ASP.NET. Он помогает злоумышленникам понять, какие технологии и фреймворки установлены на сервере, а также определить, какие уязвимости удобно использовать. Так, если заголовок указывает на конкретную версию ASP.NET, атакующие сосредоточатся на известных проблемах этой версии. Удаление заголовка — это простая, но эффективная мера харденинга, которая скрывает информацию о технологическом стеке сервера и затрудняет целевые атаки.
Подробные ошибки для удаленных клиентов
Когда возникает ошибка на веб‑приложении, IIS отправляет ее подробное описание удаленным клиентам. Иногда в нем содержится критически важная информация: названия файлов, пути к директориям, версии используемых библиотек, SQL‑запросы и даже фрагменты исходного кода приложения. Эти данные помогают злоумышленникам понять архитектуру приложения, найти уязвимости и спланировать целевую атаку.
Необходимо настроить режим отображения ошибок так, чтобы информацию о них видели только локальные администраторы.
Слабая фильтрация запросов и файлов
Избыточно длинные URL, строки запроса и загрузка файлов опасных типов — частые векторы атак, которые используются, чтобы обойти ограничения приложения и выполнить вредоносный код на сервере. Настройка фильтров на уровне IIS предотвращает такие попытки, перехватывая опасные запросы до их обработки приложением. Рассмотрим основные параметры фильтрации: ограничение длины URL, ограничение длины строки запроса и блокировку неразрешенных расширений файлов.
Большая длина URL
Слишком длинные URL могут привести к переполнению буфера или другим уязвимостям. Ограничение длины веб‑адреса в HTTP‑запросах, которые принимает сервер, — один из важных механизмов защиты IIS. Атрибут maxUrl в элементе <requestLimits> задает максимальную длину URL (в байтах) без учета строки запроса (query string). Это позволяет ограничить размер обрабатываемых сервером запросов, снижая риски атак.
Большая длина строки запроса
Другой важный параметр безопасности в IIS — ограничение длины строки запроса (query string) в URL. Атрибут maxQueryString в элементе <requestLimits> задает максимальную длину строки запроса (в байтах), которую сервер будет обрабатывать. Это ограничение помогает контролировать объем данных, передаваемых через строку запроса, и также снижает риски кибербезопасности.
Неразрешенные расширения файлов
Фильтр fileExtensions в IIS позволяет четко определить, какие расширения файлов сервер разрешает обрабатывать. За обработку всех остальных расширений, не указанных явно в списках, отвечает атрибут allowUnlisted.
Рекомендуется запретить все расширения, кроме необходимых, чтобы минимизировать поверхность атаки. Часто под запретом должны оставаться расширения вроде .config, .bat, .exe и другие потенциально опасные.
Использование ненадежных алгоритмов шифрования
Важный шаг к защите данных при работе любого веб‑сервера — включение HTTPS и использование только защищенных протоколов для передачи информации между клиентом и сервером. HTTPS, основанный на SSL/TLS, обеспечивает шифрование трафика, защищая все передаваемые данные от перехвата, изменения и подделки. Шифрование также позволяет защититься от атак типа Man‑in‑the‑Middle (MITM).
Но не все алгоритмы шифрования одинаково надежны. Устаревшие версии протоколов содержат известные уязвимости, которые могут быть использованы для дешифрования трафика. Слабые алгоритмы шифрования также не обеспечивают достаточного уровня защиты.
Устаревшие протоколы
Протокол SSL 2.0 считается криптографически небезопасным, поэтому не должен использоваться. Устаревшими и слабыми считаются SSL 3.0, TLS 1.0 и TLS 1.1. Их отключение помогает обеспечить конфиденциальность и целостность передаваемых данных, а также снижает риски перехвата и атак посредника (MITM).
Слабые алгоритмы шифрования
Алгоритм шифрования Null Cipher не обеспечивает конфиденциальность и целостность данных, поэтому его рекомендуется всегда отключать. Устаревшие и уязвимые алгоритмы DES и RC4 с различной длиной ключей также представляют серьезную угрозу безопасности. Отключение этих слабых методов шифрования повышает шансы сохранить конфиденциальность и целостность передаваемой информации. Отключение устаревших и слабых механизмов на сервере гарантирует, что клиенты смогут подключиться только с использованием современных, криптографически стойких протоколов и алгоритмов.
Уязвимость ESC8 (NTLM Relay to AD CS Web Enrollment)
ESC8 позволяет реализовать NTLM‑relay‑атаку на веб‑службы для регистрации сертификатов Active Directory Certificate Services (AD CS). При успешном исходе злоумышленник может перехватывать и перенаправлять запросы аутентификации, чтобы получить сертификаты от имени других пользователей. Это приводит к компрометации корпоративной сети и даже к контролю над доменом. Эта уязвимость особенно опасна, если веб‑службы AD CS неправильно настроены и принимают аутентификацию по протоколу NTLM без надлежащей защиты.
Подробнее об этой уязвимости читайте в статье «ESC8. Как один HTTP‑интерфейс может стоить вам домена».
Отключенное расширенное логирование
Модуль расширенного логирования в IIS значительно расширяет возможности стандартного журналирования веб‑сервера. Этот модуль позволяет гибко настраивать, какие поля и параметры запросов следует записывать в логи. В отличие от базового логирования расширенное дает возможность сохранять детальную информацию, включая HTTP‑заголовки, переменные сервера и другие клиентские данные. Это особенно важно для выявления уязвимостей, анализа поведения пользователей и обнаружения подозрительных активностей в режиме реального времени.
Ненужные компоненты
Каждый активный компонент — это потенциальная точка входа для злоумышленников. Для повышения безопасности сервера и снижения риска атак на IIS рекомендуется отключать все компоненты и модули, которые не используются в инфраструктуре.
Несмотря на разнообразие альтернативных платформ, IIS остается одним из наиболее популярных и надежных решений для размещения веб‑приложений в Windows‑среде. Занимать значительную долю рынка удается благодаря глубокой интеграции с экосистемой Microsoft, Active Directory и корпоративными инструментами управления. Однако популярность платформы означает, что неправильная конфигурация IIS может стать серьезным источником уязвимостей и рисков кибербезопасности.
Методы харденинга IIS, описанные в статье, составляют комплексный подход к повышению безопасности веб‑серверов. Эти практики значительно снижают поверхность атаки и затрудняют эксплуатацию известных и 0-day-уязвимостей.
Чтобы управлять безопасностью сотен и тысяч IIS в распределенной инфраструктуре, требуется автоматизированный подход. На помощь приходят специализированные решения мониторинга и управления (например, BI.ZONE EDR), которые позволяют быстро идентифицировать неправильно настроенные серверы, выявить отклонения от политик безопасности и своевременно отреагировать на мисконфигурации. Благодаря возможности собирать инвентаризационные данные и анализировать реестр такие решения позволяют полностью обозревать состояние безопасности IIS‑инфраструктуры.
Регулярный аудит настроек веб‑сервера, применение основных принципов харденинга и использование средств мониторинга обеспечат долгосрочную защиту веб‑приложений от эволюционирующих угроз. Постоянная поддержка актуальной конфигурации IIS и контроль над настроенными параметрами сервера позволят снизить риски инцидентов кибербезопасности и поддержать стабильную работу критических сервисов организации.