Конфигурация тестовой платформы приложения

Резюме

Правильная конфигурация отдельных элементов архитектуры приложения важна для предотвращения ошибок, которые могут скомпрометировать безопасность всей системы.

Ревизия и тестирование конфигурации — это критическая задача при создании и поддержке архитектуры. Обычно множество систем поставляется с универсальными конфигурациями, которые могут не подходить для конкретного использования.

Часто стандартная установка веб-сервера или сервера приложений включает множество функций (таких как примеры приложений, документация, тестовые страницы), которые следует удалить перед развертыванием, чтобы избежать эксплуатации уязвимостей после установки.

Цели тестирования

Убедиться, что все стандартные и известные файлы были удалены.
Проверить, что в рабочем окружении не осталось отладочного кода или расширений.
Провести ревизию механизмов логирования, настроенных для приложения.

Как тестировать

Тестирование методом "чёрного ящика"

Образцы и известные файлы и директории

Многие веб-сервера и серверы приложений в стандартной установке предоставляют образцы приложений и файлов для разработчиков, чтобы проверить корректность работы сервера сразу после установки. Однако многие из этих образцов известны как уязвимые. Например, это касается уязвимости CVE-1999-0449 (отказ в обслуживании IIS при установке примера сайта Exair), CAN-2002-1744 (уязвимость обхода каталогов в Microsoft IIS 5.0) и других.

CGI-сканеры могут содержать список известных файлов и директорий, предоставляемых различными серверами. Однако единственным способом полностью убедиться в отсутствии таких файлов является полный аудит содержимого веб-сервера.

Анализ комментариев

Программисты часто оставляют комментарии при разработке крупных веб-приложений. Однако комментарии в HTML-коде могут раскрыть внутреннюю информацию, недоступную для злоумышленников. Иногда даже части исходного кода остаются закомментированными, и эти комментарии могут быть случайно переданы пользователям через HTML-страницы.

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

Системная конфигурация

Для оценки соответствия системы стандартам конфигурации можно использовать различные инструменты, документы и чек-листы. Среди них:

CIS-CAT Lite
Анализатор поверхности атак от Microsoft
Национальная программа чек-листов от NIST

Тестирование методом "серого ящика"

Проверка конфигурации

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

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

Логирование

Логирование — важная часть безопасности приложения, так как с его помощью можно обнаружить уязвимости и атаки. Однако необходимо проверить:

Содержат ли логи конфиденциальную информацию?
Хранятся ли логи на отдельном сервере?
Могут ли логи создать уязвимость типа "отказ в обслуживании"?
Как часто логи пересматриваются администраторами?

Конфиденциальная информация в логах

Некоторые приложения могут записывать в логи чувствительные данные, например, логины и пароли, что представляет угрозу в случае доступа к логам злоумышленников через уязвимости сервера. Логи могут содержать:

Отладочную информацию
Имена пользователей
IP-адреса
Личные данные
Коммерчески значимую информацию

Необходимо убедиться, что конфиденциальная информация не сохраняется в логах или должным образом защищена.

Расположение логов

Если сервер скомпрометирован, злоумышленники могут удалить логи, скрывая следы атаки. Поэтому рекомендуется хранить логи на отдельном сервере, чтобы предотвратить их удаление и упростить анализ.

Хранение логов

Неправильное хранение логов может привести к отказу в обслуживании, если заполнится весь доступный диск. Логи должны храниться на отдельном разделе и регулярно пересматриваться для предотвращения переполнения.

Ротация логов

Серверы должны выполнять ротацию логов, чтобы предотвратить их переполнение. Это необходимо протестировать, чтобы:

Логи сохранялись на период, указанный в политике безопасности.
После ротации файлы логов сжимались для экономии места.
Права доступа к ротационным файлам логов были более строгими, чем к активным логам.

Доступ к логам

Информация из логов не должна быть доступна конечным пользователям и даже администраторам сайта. Убедитесь, что схема управления доступом защищает сырые логи и приложения для их просмотра.

Обзор логов

Администраторы должны анализировать ошибки сервера и выявлять попытки атак. Особое внимание стоит уделить ошибкам с кодом 40x или 50x, которые могут указать на потенциальные уязвимости.