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

Проверка диапазона байтов

Часто следует проверять, что запрос состоит из количества байтов, принадлежащих определенному диапазону. Это может быть полезно для того, чтобы избежать атак переполнения стека (так как они обычно содержат "случайные" биты). Например, для того, чтобы разрешить запрос, состоящий из значений байтов от 32 до 126 (включительно), следует использовать директиву:

SecFilterForceByteRange 32 126

Значениями диапазона по умолчанию являются 0 и 255, т.е. все значения байтов разрешены.

Замечание. Данная директива не проверяет содержимое POST -запросов при использовании представления multipart/form-data. Если это делать, то невозможно будет загружать бинарные файлы. Однако, после того, как параметры извлечены из такого запроса, оставшаяся часть проверяется на корректность диапазона.

Правила (Rules)

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

Простая фильтрация

Самая простейшая форма фильтрации выглядит следующим образом:

SecFilter KEYWORD [ACTION]

Для каждого простого фильтра ModSecurity ищет KEYWORD в запросе. Поиск ведется очень широко; он применяется к строке запроса, которая выглядит некоторым аналогичным образом: GET /index.php?parameter= value HTTP/1.0. В случае POST -запросов тело запроса также будет просматриваться.

Первое, что следует отметить: KEYWORD – это не простой текст. Это регулярное выражение.

Нормализация пути

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

SecFilter /bin/sh

Но атакующий может использовать строку /bin/./sh (которая приведет к тем же самым действиям), чтобы обойти фильтр. ModSecurity автоматически применяет следующие преобразования:

• в Windows преобразует \ в /;
• понижает /./ до /;
• понижает // до /;
• декодирует символы URL.

Можно также установить или запретить проверку представления URL, а также разрешать использовать только байты из некоторого диапазона

Предотвращать null byte атаки

Атаки null byte пытаются обмануть ПО, написанное на C/C++, заставляя его считать, что строка заканчивается раньше, чем это есть на самом деле. Данный тип атак обычно предотвращается с помощью фильтра SecFilterByteRange. Если не отфильтровать null byte, то это может повлиять на последующую фильтрацию. Например:

SecFilter hidden

Но при этом слово hidden не будет определено в случае такого запроса:

GET /one/two/three?p=visible%00hidden HTTP/1.0

Выборочное фильтрование

SecFilterSelective LOCATION KEYWORD [ACTION]

Позволяет точнее указать условия поиска. KEYWORD и ACTION аналогичны SecFilter. Параметр LOCATION состоит из набора идентификаторов, разделенных вертикальной чертой.

SecFilterSelective "REMOTE_ADDR | REMOTE_HOST" KEYWORD

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

• REMOTE_ADDR
• REMOTE_HOST
• REMOTE_USER
• REMOTE_IDENT
• REQUEST_METHOD
• SCRIPT_FILENAME
• PATH_INFO
• QUERY_STRING
• AUTH_TYPE
• DOCUMENT_ROOT
• SERVER_ADMIN
• SERVER_ADDR
• SERVER_PORT
• SERVER_PROTOCOL
• SERVER_SOFTWARE
• TIME_YEAR
• TIME_MON
• TIME_DAY
• TIME_HOUR
• TIME_MIN
• TIME_SEC
• TIME_WDAY
• TIME
• API_VERSION
• THE_REQUEST
• REQUEST_URI
• REQUEST_FILENAME
• IS_SUBREQ

Существует несколько специальных идентификаторов:

• POST_PAYLOAD – фильтр тела POST-запроса
• ARGS – аргументы фильтра, то же самое, что и QUERY_STRING | POST_PAYLOAD
• ARGS_NAMES – только имена переменных и параметров
• ARGS_VALUES – только значения переменных и параметров
• COOKIES_NAMES – только имена cookie
• COOKIE_VALUES – только значения cookie
• SCRIPT_UID
• SCRIPT_GID
• SCRIPT_USERNAME
• SCRIPT_GROUPNAME
• SCRIPT_MODE
• ARGS_COUNT
• COOKIES_COUNT
• HEADERS
• HEADERS_COUNT
• HEADERS_NAMES
• HEADERS_VALUES
• FILES_COUNT
• FIELS_NAMES
• FILES_SIZES

Существуют и более специальные идентификаторы:

• HTTP_header – запрос поиска заголовка
• ENV_variable – поиск переменной окружения
• ARG_variable – поиск переменной / параметра запроса
• COOKIE_name – поиск cookie с данным именем
• FILE_NAME_variable – поиск имени файла
• FILE_SIZE_variable – поиск размера загружаемого файла

В Apache 2 существует ограниченное число переменных, специфичных для вывода (только когда доступна буферизация вывода).

• OUTPUT – все тело ответа
• OUTPUT_STATUS – код статуса ответа

Исключение фильтрования аргументов

Для фильтрования можно указать инверсию некоторой переменной. Например:

SecFilterSelective "ARGS | !ARG_param" KEYWORD

Будет осуществляться поиск всех аргументов, за исключением названного параметра.

Cookies

ModSecurity обеспечивает полную поддержку cookies. По умолчанию cookies обрабатываются как формат версии 0. Однако версия 1 cookies (как определено в RFC 2965) также поддерживается. Для того чтобы включить поддержку cookie версии 1, надо использовать следующую директиву:

SecFilterCookieFormat 1

По умолчанию ModSecurity не пытается нормализовать имена и значения cookies. Однако, так как некоторые приложения и платформы (например, РНР) выполняют декодирование содержимого cookie, можно выбрать применение нормализации к cookies. Это делается следующим образом:

SecFilterNormalizeCookies On