Технологии аутентификации и шифрования

Исходящая фильтрация

ModSecurity поддерживает исходящую фильтрацию для Apache 2. По умолчанию она выключена. Чтобы использовать исходящую фильтрацию, используется директива:

SecFilterScanOutput On

После этого следует просто добавлять фильтры, используя специальную переменную OUTPUT:

SecFilterSelective OUTPUT "credit card numbers"

В следующем примере перехватывается исходящее сообщение об ошибке РНР в теле ответа и заменяется ответ с ошибкой.

SecFilterSelective OUTPUT "Fatal error:" deny,status:500
ErrorDocument 500 /php-fatal-error.html

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

Действия skipnext и chain не работают с выходными фильтрами.

Выходная фильтрация используется только для выхода в виде plain-текста и HTML. Применение регулярных выражений к бинарным данным (например, к изображениям) сильно загрузит сервер. По умолчанию ModSecurity сканирует выходные данные в ответах, в которых не указан Content Type или Content Type есть text/plan или text/html. Это можно изменить, используя директиву SecFilterOutputMimeTypes:

SecFilterOutputMimeTypes "(null) text/html text/plain"

В данной конфигурации ModSecurity будет применять выходные фильтры к файлам в виде plain-текста, HTML-файлам и файлам, чей MIME-тип не указан.

При использовании буферизации ModSecurity держит всю страницу в памяти, независимо от размера страницы.

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

1. Использовать Content-Type, который не просматривается. По причинам, связанным с производительностью, невозможно просматривать все типы содержимого;
2. Некоторым способом перекодировать выходные данные. Даже простейшее перекодирование может обмануть мониторинг.

Поддерживается выходная переменная – OUTPUT_STATUS. Данная переменная определяет код статуса в ответе.

Действия (Actions)

Существует несколько типов действий.

• Первичное действие принимает решение, продолжать обработку запроса или нет. Может существовать только одно первичное действие. Если указано в параметре несколько первичных действий, будет выполняться последнее действие. Первичными действиями являются deny, pass и redirect.
• Вторичные действия будут выполняться, если запрос соответствует фильтру, независимо от решения, принятого первичными действиями. Может быть любое количество вторичных действий. Например, exec является одним из вторичных действий.
• Действия потока (flow) могут изменить последовательность правил, заставляя переходить на другое правило или пропуская одно или несколько правил. Действиями потока являются chain и skip.
• Параметры являются не действиями, а способом присоединения параметров к фильтрам. Некоторые из таких параметров могут использоваться в реальных действиях. Например, status добавляет код ответа к первичному действию deny.

Способы задания действий

Существует несколько мест, в которых могут быть указаны действия. Одним из таких мест является директива SecFilterDefaultAction, в которой указываются действия, которые следует выполнять для правил, следующих за директивой:

SecFilterDefaultAction "deny, log, status:500"

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

SecFilterDefaultAction "deny, log, status:’Hello, World!’"

Замечание. Если указано по умолчанию нефатальное действие (такое как log, pass ), то оно будет игнорироваться при инициализации. Фаза инициализации разработана для получения информации о запросе, не допуская, чтобы не фатальные действия приводили к тому, чтобы некоторая часть запроса пропускалась при обработке в ModSecurity. Следовательно, если ModSecurity должен функционировать в режиме "detect-only", следует запретить все неявные проверки корректности (проверка представления URL, Unicode, формат cookie, диапазон байтов).

Замечание. Действия над метаданными ( id, rev, msg, severity ) и действия, которые управляют последовательностью правил ( skip/skipnext, chain ), не могут появиться в директиве SecFilterDefaultAction.

Действия для правила

Можно также указать действия для каждого фильтра. В обеих директивах фильтрования ( SecFilter и SecFilterSelective ) может быть указано множество действий в качестве дополнительного параметра. Действия, указанные для правила, объединяются с действиями, указанными в директиве SecFilterSignatureAction (значением по умолчанию является log, deny, status:403 ). Объединение происходит по следующим правилам:

1. Разрешается только одно первичное действие для каждого списка правил. Первичное действие для правила перекрывает первичное действие в списке по умолчанию;
2. Действия, указанные в конфигурации для правила, перекрывают эквивалентные действия в списке действий по умолчанию;
3. Когда задан ограниченный режим (см SecFilterActionsRestricted ), только действия над метаданными могут появиться в списке действий для каждого правила;
4. Правила могут объединяться во время конфигурирования (предпочтительней и понятней) или во время выполнения.

Директива SecFilterSignatureAction упрощает поддержку множества правил. В более ранних версиях, если требовалось использовать список действий для правила, каждый список действий должен был быть полным, т.е. следовало указывать первичное действие, коды статуса и т.п. Это делало очень трудным отделение правил (логику определения атак) от политики конфигурирования. Директива SecFilterSignatureAction может появляться много раз внутри одного конфигурационного контекста, и она применяется к правилам, которые непосредственно следуют за ней. Также нужно заметить, что правила, которые не содержат настраиваемых действий, будут наследовать список действий данной директивы. Правило, указанное ниже, будет распространяться на действия, указанные в контексте, в котором оно выполняется. Следует подчеркнуть, что контекст правила, в котором оно выполняется, не обязательно является тем же контекстом, в котором правило было создано. С помощью наследования одно правило может выполняться во многих различных контекстах. Например:

SecFilterDefaultAction log, deny, status:500
SecFilter 000

# Warning rules
SecFilterSignatureAction log, pass
SecFilter 111 id:1
SecFilter 222 id:2

# Error rules
SecFilterSignatureAction log, pass, status:403
SecFilter 333 id:3
SecFilter 444 id:4

При использовании совместно с директивой SecFilterActionsRestricted данная директива позволяет с легкостью включать в конфигурацию набор правил стороннего разработчика.

Замечание. Значение директивы SecFilterSignatureAction не наследуется в дочерних контекстах.

Ограничения в списке действий для каждого правила

Иногда при включении правил стороннего разработчика может потребоваться, чтобы действия также появлялись и в них. Это делается с помощью директивы SecFilterActionsRestricted:

SecFilterSignatureAction log, deny, status:403
SecFilterActionsRestricted On
Include conf/third-party-rules.conf

Единственными действиями, которые разрешены в конфигурации для каждого правила при включении ограниченного режима, являются правила метаданных id, msg, rev и severity. Другие правила игнорируются.