Наши партнеры

UnixForum

Библиотека сайта rus-linux.net

Безопасная эксплуатация Apache, часть 10: модуль mod_security

Оригинал: Securing Apache, Part 10: mod_security
Автор: Arpit Bajpai
Дата публикации: 1 Августа 2011 г.
Перевод: А.Панин
Дата перевода: 12 Февраля 2013 г.

Начиная с части 1 данной серии статей, мы рассматривали основные типы атак в отношении веб-приложений и методы защиты от этих атак. В данной статье я расскажу о потрясающих возможностях модуля Apache под названием mod_security и подробно опишу лишь часть из них.

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

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

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

Среди функций модуля mod_security следует отметить запись в журнал событий сообщений аудита безопасности, доступ к любой части запроса (включая тело запроса) и ответа, гибкий механизм правил на основе регулярных выражений, вмешательство в механизм загрузки файлов, проверку корректности параметров в реальном времени и возможность защиты от атак переполнения буфера.

Принцип работы модуля mod_security

Функции модуля разделены на четыре основных сферы:
  1. Разбор данных: разработанные о оглядкой на безопасность использования, программные механизмы извлекают данные каждого запроса и/или ответа и сохраняют их для использования в соответствии с правилами.
  2. Буферизация: при использовании стандартных настроек и тела запросов и тела ответов подвергаются буферизации, поэтому модуль имеет возможность работы с завершенной формой запросов (перед тем, как они будут переданы для обработки приложению) и завершенной формой ответов (перед тем, как они будут отправлены клиентам). Буферизация важна, так как лишь с помощью нее становится возможной надежная блокировка запросов.
  3. Запись событий в журнал: возможна запись всего HTTP-трафика, причем в этом случае будут записаны все заголовки ответов/запросов и их тела.
  4. Механизм правил: производится проверка данных на соответствие критериям транзакции и, в случае необходимости, выполняются заданные действия.

Способы использования модуля

Модуль mod_security может использоваться двумя способами:
  • В качестве встроенного модуля: в этом случае следует просто добавить запись об использовании модуля mod_security в файл настройки веб-сервера Apache. Однако, в этом случае не будет возможности исследовать содержимое заголовков сервера.
  • В качестве сетевого шлюза: в этом случае модуль mod_security работает в режиме обратного прокси-сервера (см. Рисунок 1). (Данный способ рекомендуется к использованию, так как весь веб-трафик проходит через прокси-сервер.) Если вы планируете использовать этот способ, убедитесь в том, что в файле настроек Apache также включено использование модулей mod_proxy и mod_proxy_http. В этом случае все операции производятся в одной точке, повышается скорость обмена данными и анонимность внутренней сети, а также модуль mod_security получает возможность исследовать заголовки сервера.

Модуль mod_security в качестве обратного прокси-сервера
Рисунок 1: Модуль mod_security в качестве обратного прокси-сервера.

Установка

В общем случае работа модуля mod_security зависит от настроек и правил. Настройки описывают то, как обрабатывать доступные данные; правила описывают то, что делать с обработанными данными.

Директивы настройки могут быть добавлены напрямую в файл httpd.conf, но следует избегать добавления их в этот файл, а вместо этого осуществлять включение отдельного файла настроек с именем modsecurity.conf в файл httpd.conf с помощью следующей директивы: 
Include conf/modsecurity.conf

Процесс установки не достаточно интуитивен и зависит от используемой операционной системы и версии Apache. Но незначительные трудности не существенны по сравнению с теми возможностями, которые предоставляет модуль mod_security. Для получения подробной пошаговой инструкции по установке модуля следует обратиться к документации на сайте modsecurity.org. Версия для Windows вместе с модифицированными версиями Apache и его модулей также доступна.

Настройка

Базовые настройки, описываемые в файле modsecurity.conf, представлены ниже: 
<IfModule mod_security.c>
# Включить (On) или выключить (Off) механизм фильтрации
SecFilterEngine On
# Механизм аудита работает независимо и может быть включен (On) или
# выключен (Off) на уровне сервера или директории
SecAuditEngine RelevantOnly
# Проверка корректности кодирования строк URL
SecFilterCheckURLEncoding On
# Проверка корректности кодирования строк Unicode
SecFilterCheckUnicodeEncoding On
# Диапазон допустимых для использования байт
SecFilterForceByteRange 1 255
# Проверка корректности форматирования кук
SecFilterCheckCookieFormat On
# Имя файла журнала для записи событий аудита
SecAuditLog logs/audit_log
# Должен ли модуль mod_security исследовать данные POST-запросов
SecFilterScanPOST On
# Стандартный набор действий
SecFilterDefaultAction "deny,log,status:500"
<IfModule>
Теперь давайте рассмотрим некоторые основные директивы настроек:
  • SecFilterEngine: При использовании значения On (т.е. SecFilterEngine On) начинается исследование запросов. По умолчанию установлено значение Off (отключено).
  • SecFilterScanPOST: В случае использования значения On производится исследование данных POST-запросов.
  • SecFilterScanOutput: В случае использования значения On также производится исследование данных ответов.

Аналогично, для проверки корректности кодирования строк URL вы можете использовать директиву SecFilterCheckURLEncoding; для управления буферизацией данных запросов можете использовать SecRequestBodyAccess; для управления поведением в случае достижения ограничения объема данных ответа можете использовать SecResponseBodyLimitAction; и для установления ограничения объема данных ответа можете использовать SecResponseBodyLimit.

Полный список директив настроек с примерами их использования и описанием синтаксиса доступен на сайте modsecurity.org.

Правила - основные понятия

Механизм правил модуля mod_security позволяет проверить собранные данные на наличие любого вредоносного или специфического содержимого. Правила являются директивами в файле настроек, описывающими, что делать с данными, полученными на основании других директив. Язык правил является отдельной обширной темой; мы обсудим только базовый синтаксис правил, а также директивы для защиты веб-приложений от атак, которые мы обсуждали ранее.

Главной директивой для создания правил является директива SecRule, синтаксис которой представлен ниже: 
SecRule ПЕРЕМЕННЫЕ ОПЕРАТОР [ДЕЙСТВИЯ]
  • ПЕРЕМЕННЫЕ: Задают области проверок в рамках HTTP-транзакции. Модуль mod_security предварительно обрабатывает данные транзакции, упрощая работу логических выражений правил для определения вредоносного содержимого. На данный момент переменные делятся на переменные запроса, сервера и переменные ответа, флаги разбора и переменные времени. Вы можете использовать несколько переменных в одном правиле с помощью оператора |.
  • ОПЕРАТОРЫ: Задают регулярное выражение, шаблон или ключевое слово для поиска в переменных. Существуют четыре типа операторов: операторы сравнения строк, числовые операторы, операторы проверок и другие операторы. Запись операторов всегда начинается с символа @, а после оператора всегда следует пробел.
  • ДЕЙСТВИЯ: Задают действия, выполняемые в случае успешного выполнения правила (возвращения правилом логического значения "true") - переход к другому правилу, вывод сообщения об ошибке или другие. Действия делятся на семь категорий: разрушительные (disruptive), действия с потоком (flow), действия с метаданными (metadata), действия с переменными (variable), запись событий (logging), специальные (special) и другие действия (miscellaneous).
Ниже приведен простейший пример правила: 
SecRule ARGS|REQUEST_HEADERS "@rx <script" id:101,msg: 'XSS Attack', severity:ERROR,deny,status:404

В данном случае ARGS и REQUEST_HEADERS являются переменными (параметры и заголовки запросов соответственно); @rx является оператором, используемым для поиска шаблона в значениях переменных (в данном случае шаблоном является строка <script); id, msg, severity, deny и status являются действиями, выполняемыми при обнаружении соответствия строк шаблону. Это правило используется для отражения XSS-атак с помощью проверки наличия строки <script в параметрах запроса и заголовке и для генерации сообщения 'XSS Attack'. В данном правиле используется действие id:101; с помощью него любой запрос, предназначенный для проведения атаки, будет отклонен со статусом 404.

Давайте рассмотрим еще один запрос для лучшего понимания: 
SecRule ARGS:username "@streq admin" chain,deny
SecRule REMOTE_ADDR "!@streq 192.168.1.1"

Это пример объединения двух правил и передачи управления второму правилу в том случае, если первое правило возвращает логическое значение "true". Первое правило проверяет наличие строки "admin" в параметре имени пользователя в запросе. В случае обнаружения активируется второе правило, которое запрещает все подобные запросы, осуществленные не с IP-адреса 192.168.1.1. Следовательно, связывание правил позволяет создавать сложные правила.

Исходя из этого, написание правил фильтрации для каждой атаки может быть очень сложной и восприимчивой к человеческим ошибкам задачей. Поэтому модуль mod_security предоставляет пользователям возможность использовать другую директиву, SecFilter. С помощью нее производится поиск ключевого слова в запросе. Оно будет добавлено к первой строке запроса (выглядящего примерно следующим образом: GET /index.php?parameter=value HTTP/1.0). В случае использования запросов POST, данные запросов будут также подвергаться исследованию (в том случае, если буферизация данных запросов включена). Все поиски совпадений производятся по умолчанию без учета регистра. Синтаксис директивы SecFilter: SecFilter КЛЮЧЕВОЕ_СЛОВО.

Продолжение статьи: "Безопасная эксплуатация Apache, часть 10: модуль mod_security (продолжение)"