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

Заголовки запроса, добавляемые mod_security

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

Список добавляемых заголовков следующий:

• mod_security-executed – вместе с путем к выполняемому файлу.
• mod_security-action – вместе с возвращаемым кодом статуса.
• mod_security-message – сообщение, касающееся обнаруженной проблемы; то же самое сообщение добавляется в лог ошибок.

Занесение в лог тела запроса

ModSecurity экспортирует тело запроса с помощью mod_security-body. Это можно использовать для создания логов.

LogFormat "%h %l %u %t \" %r \" %>s %{mod_security-body}n

Замечание. Если запрос является multipart/request-data типом (например, загрузка файла), реальное тело запроса будет заменено эмулированным содержимым application/x-www-form-urlencoded.

Взаимодействие ModSecurity c пакетным фильтром

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

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

Так как большинство прокси посылает информацию, описывающую исходного клиента, можно попытаться определить реальный IP-адрес. Рассмотрим следующий сценарий.

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

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

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

Специальные возможности

Поддержка загрузки (upload) файла

ModSecurity имеет возможность перехватывать файлы, загружаемые с помощью POST -запросов и multipart/form-data кодирования или с помощью PUT-запросов.

Выбор местоположения для загружаемых файлов

ModSecurity всегда загружает файлы во временный каталог. Это можно изменить, используя директиву SecUploadDir:

SecUploadDir /tmp

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

Проверка файлов

Можно выполнять внешний скрипт для проверки файла перед тем, как разрешить ему проходить через web-сервер к приложению. Директива SecUploadApproveScript делает доступной данную функцию:

SecUploadApproveScript /full/path/to/the/script.sh

Скрипт получает один параметр из командной строки – полный путь к файлу, который должен быть загружен. После того как скрипт выполнит его обработку, он должен записать ответ в стандартный вывод. Если первый символ ответа есть "1", то файл принимается. В противном случае ответ отвергается. Скрипт может использовать остаток строки для записи более информативного сообщения об ошибке. Данное сообщение будет храниться в логах отладки.

Хранение загруженных файлов

Существует возможность загружать файлы через web-сервер. Для этого следует просто добавить следующую строку в конфигурацию

SecUploadKeepFiles On

Каталог, в котором хранятся файлы, определяется с помощью директивы SecUploadDir.

Взаимодействие с другими демонами

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

Ограничение памяти, используемой для загрузки

В Apache 2.х можно определить количество памяти, которое может быть использовано для обработки multipart/form-data запросов. Если запрос больше, чем доступная память, то может использоваться временный файл. Значением по умолчанию является 60 Kб но данный лимит может быть изменен с помощью директивы SecUploadInMemoryLimit:

SecUploadInMemoryLimit 125000

Скрытие идентификации сервера

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

Для изменения идентификации web-сервера можно найти его имя (например, "Apache") в исходном коде, заменить его и перекомпилировать сервер. Тот же самый результат можно получить, используя директиву SecServerSignature:

SecServerSignature "Microsoft-IIS/5.0"

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

Поддержка chroot

Стандартный подход

ModSecurity включает поддержку изоляции файловой системы Apache или выполнение chroot. После того как операция chroot выполнена, приложение не может иметь доступа вне указанной директории.

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

Подход mod_security

В ModSecurity добавлена специальная директива, которая позволяет успешно выполнить chroot.

SecChrootDir /chroot/apache

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

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