В продолжение Web Application Firewall (ModSecurity) в действии
1.1 Понятие регулярных выражений
Регулярное выражение является мини языком программирования, разработанным для поиска на соответствие образцу.
Замечание. В Apache 1.x и Apache 2.x используются различные инструментальные средства для регулярных выражений. В Apache 2.x обработка регулярных выражений совместима с Perl. В Apache 1.x обработка регулярных выражений совместима с POSIX.
В регулярных выражениях используются специальные символы. Приведем краткую семантику некоторых из них в таблице 1.1.
Таблица 1.1 – Семантика специальных символов, используемых в регулярных выражениях.
1.2 Конфигурирование
Директивы конфигурирования ModSecurity непосредственно добавляются в конфигурационный файл (обычно httpd.conf). Если заранее не известно, включен ли данный модуль, директивы следует заключить в тег . Это позволит Apache игнорировать конфигурационные директивы, когда модуль не активен.
Так как Apache допускает, чтобы конфигурационные данные были расположены более чем в одном файле, существует возможность сгруппировать конфигурационные директивы в один файл (например, modsecurity.conf) и включить его в httpd.conf с помощью директивы Include.
Include conf/modsecurity.conf
1.3 Включение фильтрации
По умолчанию фильтрация выключена. Для того чтобы модуль начал анализировать запросы, следует добавить в конфигурационный файл SecRuleEngine On.
Синтаксис данной команды представлен ниже.
SecRuleEngine On|Off|DetectionOnly
Возможные значения параметров:
On – анализировать каждый запрос;
Off – не делать ничего;
DetectionOnly – анализировать каждый запрос, но не предпринимать никаких активных действий (таких как блокировка запроса).
1.4 Сканирование содержимого тела запроса
Сканирование содержимого тела запроса по умолчанию выключено. Для выполнения сканирования содержимого запросов необходимо указать:
SeqRequestBodyAccess On
Синтаксис: SeqRequestBodyAccess On|Off
1.5 Список действий по умолчанию
Всякий раз, когда запрос соответствует правилу, выполняется одно или более действий. Каждый фильтр может иметь свои собственные действия, но можно определить множество действий по умолчанию для всех фильтров. При желании всегда можно задать действие для каждого правила.
Например, следующим образом конфигурируется занесение в лог каждого правила, для которого выполнено соответствие, и запрос отвергается с кодом статуса 404:
SecDefaultAction «phase:2,deny,log, status:404»
Синтаксис данной команды: SecDefaultAction Значения по умолчанию «phase:2,log,auditlog,pass»
Директива SecDefaultAction имеет только один параметр – разделенный запятыми список действий. Действия будут выполняться для каждого фильтра, для которого выполнено соответствие, за исключением правил, которые имеют свои собственные списки действий.
Замечание. Если указан нефатальный список действий по умолчанию (список, который не вызовет ситуацию, при которой запрос может быть отвергнут, например, log, pass), то такой список действий будет игнорироваться на фазе инициализации. Фаза инициализации предназначена для того, чтобы получить информацию о запросе. Разрешение нефатальных действий будет приводить к тому, что некоторые части запроса могут быть пропущены. Поскольку данная информация требуется для внутренней обработки, такие действия не могут быть разрешены. Если ModSecurity должен выполняться в «detect-only» режиме, необходимо запретить все неявные проверки корректности (проверку корректности представления URL, проверку корректности представления Unicode, проверку корректности формата cookie) [1].
Замечание. Действия над метаданными (id, rev, msg, severity) и действия, которые управляют последовательностью правил (skip/skipAfter, chain), не могут появиться в директиве SecFilterDefaultAction.
1.6 Правила (Rules)
Когда фильтрация включена, каждый входящий запрос анализируется перед тем, как он будет передан по назначению. Анализ начинается с серии встроенных проверок, предназначенных для проверки действительности формата запроса. Этими проверками можно управлять, используя директивы конфигурирования. На второй стадии запрос проходит через серию определенных пользователем фильтров, на соответствие которым проверяется запрос. Всякий раз, когда существует соответствие, выполняются определенные в правилах действия.
Команда разработчиков во главе с Иваном Ристиком основной упор делает на усовершенствование кода ModSecurity, оставляя создание правил пользователям, поэтому оригинальный конфигурационный файл имеет всего несколько правил. Существует несколько субпроектов (например OWASP ModSecurity Core Rule), целью которых является создание и тестирование правил. Для их использования необходимо скачать и подключить требуемый файл правил в конфигурационном файле ModSecurity директивой Include. Некоторые из правил требуют редактирования, кроме того, следует учитывать особенности rexeс и PCRE, поэтому правила, созданные для Apache 2.x, могут неправильно работать с первой версией сервера. Кроме того, существуют специальные скрипты, преобразующие правила систем обнаружения вторжений и сканеров безопасности в правила для ModSecurity. Например скрипт snort2modsec.pl, преобразующий правила IDS Snort в правила ModSecurity и скрипт nessus2modsec.pl, предназначенный для преобразования NASL правил сканера безопасности Nessus/GNessUs. Базовые правила фильтрации позволяют защитить Web-сервер от широкого спектра атак, однако они не могут считаться абсолютной защитой для конкретного Web-приложения.
1.7 Простая фильтрация
Самая простейшая форма фильтрации выглядит следующим образом:
SecRule SecRule – это директива, которая используется для создания правил в ModSecurity.
Для каждого простого фильтра ModSecurity ищет operators в variables и выполняет действия указанные в actions.
Variables определяет местонахождение искомой строки. Здесь может быть использовано регулярное выражение, IP-адрес, имя, идентификаторы, включая CGI-переменные
Доступ к серверным переменным осуществляется через ключевые слова, к примеру REQUEST_LINE, REQUEST_PROTOCOL, REQUEST_METHOD и т.д.
Доступ к переменным из запроса, осуществляется через ключевые слова, к примеру QUERY_STRING, а так же к массиву переменных ARGS.
Параметр Variables может состоять из набора идентификаторов, разделенных вертикальной чертой.
Список доступных для использования при написании правил переменных (variables).
Имена большинства из них описывают себя сами. (для ознакомления с другими обратитесь к документации).
Для фильтрования можно указать инверсию некоторой переменной. Например:
SecRule «ARGS | !ARG_param» Будет осуществляться поиск всех аргументов, за исключением названного параметра.
Операторы (operators) определяют методы и данные о сравнении. По умолчанию, если другие операторы не определены, используется оператор @rx. Это означает, что строка, следующая за оператором, будет интерпретироваться как регулярное выражение. Данную строку будут искать в соответствующей переменной (variables)
1.8 Действия (Actions)
Существует несколько типов действий.
Первичное действие принимает решение, продолжать обработку запроса или нет. Может существовать только одно первичное действие. Если указано в параметре несколько первичных действий, будет выполняться последнее действие. Первичными действиями являются deny, pass и redirect.
Вторичные действия будут выполняться, если запрос соответствует фильтру, независимо от решения, принятого первичными действиями. Может быть любое количество вторичных действий. Например, exec является одним из вторичных действий.
Действия потока (flow) могут изменить последовательность правил, заставляя переходить на другое правило или пропуская одно или несколько правил. Действиями потока являются chain и skipAfter.
Параметры являются не действиями, а способом присоединения параметров к фильтрам. Некоторые из таких параметров могут использоваться в реальных действиях. Например, status добавляет код ответа к первичному действию deny.
Подробнее рассмотрим синтаксис действий в таблице 1.2.
Таблица 1.2 — Действия, выполняемые при совпадении запроса
1.9 Фазы и выполнение правил
Важно понимать, на какой фазе ModSecurity применяет правила. Это будет для вас удобным при создании новых правил и позволит избегать ситуаций, при которых действия были неожиданно заблокированы или наоборот, разрешены, при том, что ваши ожидания были противоположны.
Логика работы ModSecurity делит запросы на 5 фаз:
1. REQUEST_HEADERS (phase 1);
2. REQUEST_BODY (phase 2);
3. RESPONSE_HEADERS (phase 3);
4. RESPONSE_BODY (phase 4);
5. LOGGING (phase 5).
Правила выполняются последовательно в каждой фазе, это означает, что ModSecurity сначала оценивает все правила в phase 1 («заголовки запроса»), затем возобновляет на phase 2 — 5 (если правила не заставляет остановить обработку запроса).
1.10 Функции нормализации
ModSecurity обеспечивает поддержу множества функций нормализации. Эти преобразования делаются раньше, чем любые правила начинают применяться. Функции нормализации полезны для множества целей. Данные функции позволяют обнаружить и предотвратить многие виды атак, например межсайтовое выполнение сценариев, инъекцию кода JavaScript, независимо от места их нахождения.
В документации к ModSecurity 2.x описано следующие функции нормализации:
Имена большинства из них описывают себя сами. (для ознакомления с другими обратитесь к документации). По умолчанию ModSecurity 2.x для входящего потока выполняет функции lowercase, replaceNulls и compressWhitespace. Если вам требуются другие действия, то вы можете их настроить, используя новое действие «t». Как и раньше, для задания списка действий по умолчанию для всех правил, вы можете использовать SecDefaultAction, например:
SecDefaultAction log,auditlog,deny,status:403,phase:2, t:lowercase,t:replaceNulls,t:compressWhitespace
Этот пример взят из стандартной конфигурации. Также вы можете устанавливать действия для каждого правила отдельно, либо задавая их полностью, либо добавляя или удаляя их из стандартной конфигурации. Вот пример, где удалено действие compressWhitespace и добавлено replaceComments:
SecRule t:-compressWhitespace,t:replaceComments
Для полного удаления всех нормализирующих функций просто добавьте специальное слово: none.
SecRule t:none,t:normalisePathWin
А если встроенных функций нормализации вам не хватает, тогда в этом случае вы можете использовать новый API, который позволяет добавлять новые функции нормализации без изменения исходного кода [4].
1.11 Сканирование содержимого тела ответа
ModSecurity поддерживает исходящую фильтрацию для Apache 2. По умолчанию она выключена. Чтобы использовать исходящую фильтрацию, используется директива
SecResponseBodyAccess On
Синтаксис: SecResponseBodyAccess On|Off
Если сканирование содержимого тела ответа включено, то это позволяет анализировать тело ответа в соответствии с правилами использую аргумент RESPONSE_BODY.
Следует заметить, что хотя и можно перемешивать выходные и входные фильтры, они не выполняются одновременно. Входные фильтры выполняются перед тем, как запрос будет обработан Apache, в то время как выходные — после того, как Apache завершит обработку запроса.
Действия skipAfter и chain не работают с выходными фильтрами.
Выходная фильтрация используется только для выхода в виде plain-текста и HTML. Применение регулярных выражений к бинарным данным (например, к изображениям) сильно загрузит сервер. По умолчанию ModSecurity сканирует выходные данные в ответах, в которых не указан Content Type или Content Type есть text/plan или text/html. Это можно изменить, используя директиву SecResponseBodyMimeType:
SecResponseBodyMimeType (null) text/html text/plain
Синтаксис: SecResponseBodyMimeType В данной конфигурации ModSecurity будет применять выходные фильтры к файлам в виде plain-текста, HTML-файлам и файлам, чей MIME-тип не указан.
При использовании буферизации ModSecurity держит всю страницу в памяти, независимо от размера страницы.
Исходящий мониторинг является полезной возможностью при определенных обстоятельствах. При этом следует гарантировать, что его нельзя обойти. Если атакующий имеет полный контроль над обработкой запроса, он может обойти исходящий мониторинг двумя способами.
• Использовать Content-Type, который не просматривается. По причинам, связанным с производительностью, невозможно просматривать все типы содержимого.
• Некоторым способом перекодировать выходные данные. Даже простейшее перекодирование может обмануть мониторинг.
1.12 Неявная проверка корректности
Неявная проверка корректности запроса (если она сконфигурирована), выполняется только в начале обработки запроса. Эта проверка состоит из проверок строки запроса и заголовков.
Замечание. Проверка корректности Unicode не применяется к содержимому заголовка Referer как часть начальной неявной проверки корректности запроса. Это делается потому, что данный заголовок часто содержит информацию о других Web-сайтах, и их кодирование обычно отличается от кодирования, используемого на защищаемом Web-сайте.
1.13 Наследование фильтра
Фильтры, определенные в родительских каталогах, обычно наследуются во вложенных контекстах Apache. Такое поведение приемлемо (и требуется) в большинстве случаев, но не всегда. Иногда необходимо ослабить проверки для некоторой части сайта. Используя директиву SecRuleInheritance Off можно указать ModSecurity не учитывать родительские фильтры, тем самым начать задавать правила заново. Данная директива влияет только на правила. Конфигурация всегда наследуется от родительского контекста, но ее можно перекрыть, используя соответствующие конфигурационные директивы.
Замечание. По умолчанию всегда выполняется наследование конфигурации и правил. Если контекст расположен ниже того, в котором наследование разрешено, следует явно запретить наследование снова, когда это необходимо.
1.14 Cookies
ModSecurity обеспечивает полную поддержку cookies. По умолчанию cookies обрабатываются как формат версии 0. Однако версия 1 cookies (как определено в RFC 2109) также поддерживается. Для того чтобы включить поддержку cookie версии 1, надо использовать следующую директиву:
SecCookieFormat 1
Синтаксис данной команды: SecCookieFormat 0|1
1.15 Взаимодействие ModSecurity c пакетным фильтром
В некоторых случаях после обнаружения конкретной опасной атаки или серии атак может возникнуть желание предотвратить дальнейшие атаки, исходящие из определенного источника. Это можно сделать, модифицировав firewall таким образом, чтобы он отвергал весь трафик, приходящий с конкретного IP-адреса [3].
Данный метод может быть очень опасным, так как его результатом может стать DoS-атака. Например, атакующий может использовать прокси для запуска атак. Отвержение всех запросов от прокси-сервера может очень опасным, поскольку это повлияет также и на всех законных пользователей.
Так как большинство прокси посылает информацию, описывающую исходного клиента, можно попытаться определить реальный IP-адрес. Рассмотрим следующий сценарий.
Атакующий хочет получить непосредственный доступ к приложению, но пытается выступать в качестве прокси, указывая случайный (или действительный) IP-адрес в качестве реального IP-адреса источника. Если мы начнем отвергать запросы, основываясь на этой полученной информации, атакующий может просто изменить IP-адрес и продолжить атаку. В результате может быть запрещен доступ для законных пользователей, в то время как атакующий может продолжить поиск уязвимостей в приложении.
Следовательно, данный метод может использоваться только тогда, когда не разрешен доступ к приложению через прокси или разрешен доступ только через те прокси, которые являются доверяемыми.
Если все-таки существует необходимость запрещать запросы на основе IP-адреса, необходимо использовать скрипт, который будет выполняться при соответствии запроса фильтру. Скрипт должен извлекать IP-адрес атакующего из переменных окружения и затем вызывать пакетный фильтр, чтобы запретить доступ с данного IP-адреса.
1.16 Специальные возможности
Поддержка загрузки (upload) файла
ModSecurity имеет возможность перехватывать файлы, загружаемые с помощью POST-запросов и multipart/form-data кодирования или с помощью PUT-запросов.
ModSecurity всегда загружает файлы во временный каталог. Это можно изменить, используя директиву SecUploadDir:
SecUploadDir /tmp
Для хранения файлов лучше использовать директорию, к которой разрешен доступ только пользователям Web-сервера. В противном случае, другие пользователи сервера также могут получить доступ к файлам, загруженным через Web-сервер.
Хранение загруженных файлов
Существует возможность загружать файлы через Web-сервер. Для этого следует просто добавить следующую строку в конфигурацию
SecUploadKeepFiles On
Каталог, в котором хранятся файлы, определяется с помощью директивы SecUploadDir.
Скрытие идентификации сервера
Одной из технологий, которая позволяет запутать атакующих, является изменение идентификации Web-сервера. Web-серверы обычно посылают свою идентификацию в каждом НТТР-ответе в заголовке Server.
Для изменения идентификации Web-сервера можно найти его имя (например, «Apache») в исходном коде, заменить его и перекомпилировать сервер. Тот же самый результат можно получить, используя директиву SecServerSignature:
SecServerSignature «Microsoft-IIS/5.0»
SecServerSignature «Apache/2.2.4 (Fedora)»
Следует заметить, что, хотя эта процедура работает достаточно хорошо, квалифицированные атакующие (и инструментальные средства) могут использовать другие технологии для получения «fingerprint» Web-сервера. Например, файлы по умолчанию, сообщение об ошибке, последовательность заголовков в ответе, способ, которым сервер отвечает на некоторые запросы и т.п., – это все может дать правильную идентификацию.
Поддержка chroot
Стандартный подход
ModSecurity включает поддержку изоляции файловой системы Apache или выполнение chroot. После того как операция chroot выполнена, приложение не может иметь доступа вне указанной директории.
К сожалению, это не всегда бывает просто сделать. Проблема в том, что приложениям обычно требуются разделяемые библиотеки и различные другие файлы для корректного функционирования.
Подход ModSecurity
В ModSecurity добавлена специальная директива, которая позволяет успешно выполнить chroot.
SecChrootDir /chroot/apache
Кроме простоты, такой подход имеет и другие преимущества. В отличие от выполнения внешнего chroot, при выполнении chroot ModSecurity не требуется, чтобы существовали дополнительные файлы в указанной директории. Вызов chroot делается после того, как Web-сервер инициализирован, но перед выполнением fork. В результате этого все разделяемые библиотеки уже загружены, все модули Web-сервера инициализированы и лог-файлы отрыты. В указанной директории должны быть только данные.
Тем не менее существует несколько случаев, когда в этой директории должны быть размещены дополнительные файлы. Это необходимо, если требуется выполнение CGI-скриптов или других систем.
1.17 Решение общих проблем безопасности
Возможности ModSecurity могут использоваться для определения и предотвращения наиболее общих проблем, связанных с безопасностью. Более подробно защита от атак на приложения Web рассмотрены в специализированной литературе [4, 5]. Рассмотрим некоторые из них.
1.17.1 Перемещение по директории
Если некоторый скрипт должен иметь доступ к файловой системе, то следует обратить внимание на некоторые метасимволы и конструкции. Например, комбинация символов ../ в пути означает переход на один уровень вверх в директории. Такая последовательность символов не должна возникать в запросах и должна быть запрещена с использованием следующего фильтра:
SecRule REQUEST_URI ".../" «t:urlDecode,deny»
1.17.2 Нормализация пути
Фильтры не применяются к исходным данным запроса – первым делом выполняется их нормализация. Это делается потому, что атакующий может применить различные технологии скрытия определенной последовательности символов, чтобы избежать обнаружения атаки. ModSecurity автоматически может применять следующие преобразования:
в Windows преобразует в /;
понижает /./ до /;
понижает // до /;
декодирует символы URL.
Для нормализации пути используются 2 функции: normalisePath и normalisePathWin.
Данное правило демонстрируется возможности ModSecurity для нормализации пути.
SecRule REQUEST_URI «pass,t:- normalisePathWin „
1.17.3 Предотвращение null byte атак
Атаки null byte пытаются обмануть ПО, написанное на C/C++, заставляя его считать, что строка заканчивается раньше, чем это есть на самом деле. Данный тип атак обычно предотвращается с помощью функции нормализации removeNulls и replaceNulls. Если не отфильтровать null byte, то это может повлиять на последующую фильтрацию. Возможный синтаксис команды, фильтрующей атаки null byte:
SecDefaultAction “phase:2,deny,log,status:403,t:removeNulls»
SecRule ARGS:data «pass,t:-removeNulls»
1.18 Протоколирование событий
Если ваш сервер атакуют, очень важно получить картину того, что нападающий пытается сделать. Использует ли он предварительно упакованный скрипт, чтобы попытаться войти на ваш сервер? Или кто-то пытается взломать ваш сервер, использую SQL инъекции через иностранный прокси-сервер?
Просмотр журналов аудита ModSecurity на регулярной основе важен, чтобы обладать информацией о том, какие действия пробуют предпринять против вашего сервера. В некоторых случаях на основании этих данных вы можете обнаружить новые уязвимости вашего сервера и предпринять необходимые меры защиты против этих действий.
Стандартные журналы аудита сервера Apache не могут дать больше информации о событиях, чем время и дата запроса, его тип (Post или Get). ModSecurity вводит журналы аудита, которые позволяют серверу регистрировать намного более подробную информацию о запросах, обращенных к вашему серверу. Используя журналы аудита, вы можете получить информацию о заголовках и теле запроса, также информацию о заголовках и теле ответа и всех правилах, применяемых к запросу.
1.18.1 Включение механизма протоколирования событий
Протоколирование событий по умолчанию выключено. Вы можете включить механизм протоколирования событий, помещая директиву SecAuditEngine в конфигурационный файл ModSecurity. Вот возможные значения для директивы SecAuditEngine.
1) SecAuditEngine On
Включает протоколирование событий для всех операций.
2) SecAuditEngine Off
Выключает протоколирование событий.
3) SecAuditEngine RelevantOnly
Включает протоколирование только событий, соответствующих правилу или у которых имеется код состояния, соответствующий регулярному выражению, формируемому через директиву SecAuditLogRelevantStatus.
В большинстве случаев наиболее оптимально использовать директиву SecAuditEngine RelevantOnly для регистрации операций, которые фактически считаются релевантными (т.е. соответствующие правилам ModSecurity и имеющие соответствующий код состояния HTTP). Использование директивы SecAuditEngine On позволит регистрировать все операции, но при этом будет расходоваться много дискового пространства и нагружаться сервер.
Директива SecAuditLogRelevantStatus берет в качестве параметра регулярное выражение, которое подобрано против кода ответа HTTP для операции. Так для регистрации операций, которые производят ошибку HTTP (код состояния 400-599), вы можете использовать следующее:
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus ^ [1]
1.18.2 Формат регистрации
Существуют два типа контрольных форматов регистрации, которые могут использоваться: последовательный (serial) и параллельный (concurrent). Последовательная регистрация регистрирует все контрольные события в единственный файл, параллельная регистрация событий помещает данные о регистрации для каждого запроса в отдельный файл. Тип формата регистрации формируется через директиву SecAuditLogType. Преимущества есть у каждого формата регистрации. При параллельной регистрации файлы системного журнала помещаются в отдельные журналы, соответствующие времени регистрации событий. Используя параллельный формат регистрации, мы должны формировать директорию, где ModSecurity создаст отдельные файлы системного журнала. Это делается использованием директивы SecAuditLogStorageDir.
При параллельном формате регистрации событий ModSecurity создает определенную структуру каталогов, в которую помещены отдельные файлы журнала аудита. Структура каталогов выглядит следующим образом
/logs/data/
|-- 20090331
| |-- 20090331-1530
| | |-- 20090331-153030-Cei44F5MziQAAFKTAIcAAAAA
| | |-- 20090331-153030-Cei5115MziQAAFKUAM0AAAAB
| | |-- 20090331-153030-CgEmHV5MziQAAFKVAS0AAAAC
| | |-- 20090331-153054-C1JA815MziQAAFKoBfIAAAAV
| | `-- 20090331-153054-C1JIqV5MziQAAFKVAS4AAAAC
| |-- 20090331-1531
| | |-- 20090331-153100-C6skpV5MziQAAFKUAM4AAAAB
| | |-- 20090331-153105-C@gA6F5MziQAAFKgBD0AAAAN
| | |-- 20090331-153109-DBTxLV5MziQAAFKhBKAAAAAO
| | `-- 20090331-153118-DLyqv15MziQAAFKeA8AAAAAL
| |-- 20090331-1532
|-- 20090401
| |-- 20090401-0208
| | |-- 20090401-020802-8H1Ox15MziQAAFPGEv4AAAAI
| | |-- 20090401-020802-8esmr15MziQAAF0tGXAAAAAD
| | |-- 20090401-020805-8RWbIF5MziQAAFNbCN8AAAAy
…
ModSecurity производит новую директорию в течение каждого дня (например, журнал, имеющий название 20090331 содержит файлы журнала аудита, произведенные 31-ого марта 2009). Каждый из этих журналов содержит отдельные подкаталоги с записями событий произведенных в определенное время (например, журнал имеющий название 20090331-1530 содержит все файлы журнала аудита для запросов, произведенных в 3:30 днем 31-ого марта).
1.18.3 Директива SecAuditLogParts
Директива SecAuditLogParts определяет, какая информация будет включена в каждый журнал аудита. Каждая часть представлена параметром, описанным в таблице 1.3.
Синтаксис: SecAuditLogParts <части>
Пример: SecAuditLog ABCFHZ
Таблица 1.3 – Описание параметров директивы SecAuditLogParts
1.18.4 Типовая конфигурация протоколирования событий
Ниже представлен пример типичной конфигурации, позволяющей протоколирование событий и параллельный формат регистрации событий.
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4d[^4])"
SecAuditLogType Concurrent
SecAuditLogParts ABCDEFHZ
SecAuditLogStorageDir logs/data/
SecAuditLog bin/mlogc.exe
SecAuditLog "|bin/mlogc.exe bin/mlogc.conf"
1.18.5 Журналы аудита
Теперь, давайте посмотрим на то, на что похожи журналы аудита. Запись следующих событий был произведен с вышеупомянутой конфигурацией.
--ae720000-A--
[11/Nov/2011:14:19:17 +0500] TrzolcCoCgIAAAsYBPwAAAD5 192.168.10.5 65004 192.168.10.2 80
--ae720000-B--
GET /webgoat/images/buttons/hint.jpg HTTP/1.1
Host: 192.168.10.2
Connection: keep-alive
Referer: 192.168.10.2/webgoat/attack
Authorization: Basic Z3Vlc3Q6Z3Vlc3Q=
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.112 Safari/535.1
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.3
Cookie: JSESSIONID=CD7576D71A7DD34291918F65FD215FCD
If-None-Match: W/«563-1257685080000»
If-Modified-Since: Sun, 08 Nov 2009 12:58:00 GMT
--ae720000-F--
HTTP/1.1 304 Not Modified
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 05:00:00 GMT
ETag: W/«563-1257685080000»
Content-Length: 0
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Content-Type: text/plain
--ae720000-E--
--ae720000-H--
Message: Warning. Pattern match "^[\d.:]+$" at REQUEST_HEADERS:Host. [file «C:/Apache2/conf/rules/base_rules/modsecurity_crs_21_protocol_anomalies.conf»] [line «98»] [id «960017»] [rev «2.2.2»] [msg «Host header is a numeric IP address»] [severity «CRITICAL»] [tag «PROTOCOL_VIOLATION/IP_HOST»] [tag «WASCTC/WASC-21»] [tag «OWASP_TOP_10/A7»] [tag «PCI/6.5.10»] [tag «technet.microsoft.com/en-us/magazine/2005.01.hackerbasher.aspx»]
Message: Warning. Operator LT matched 5 at TX:inbound_anomaly_score. [file «C:/Apache2/conf/rules/base_rules/modsecurity_crs_60_correlation.conf»] [line «33»] [id «981203»] [msg «Inbound Anomaly Score (Total Inbound Score: 2, SQLi=, XSS=): Host header is a numeric IP address»]
Apache-Handler: proxy-server
Stopwatch: 1321003157121875 31250 (- — -)
Stopwatch2: 1321003157121875 31250; combined=0, p1=0, p2=0, p3=0, p4=0, p5=0, sr=0, sw=0, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.6.2 (http://www.modsecurity.org/); core ruleset/2.2.2.
Server: Apache/2.2.21 (Win32) proxy_html/3.1.2
--ae720000-Z--
Каждая регистрация события начинается и заканчивается с уникальной шестнадцатеричной последовательностью вида --ae720000-A--. Данная последовательность идентифицирует данное событие. Прописная буква перед последними двумя чертами соответствует параметру директивы SecAuditLogParts.
В данном случае журнал аудита поясняет, что доступ клиенту, пришедшему с адреса 192.168.10.5, запрещен модулем ModSecurity, потому что сработали правила фильтрации «C:/Apache2/conf/rules/base_rules/modsecurity_crs_21_protocol_anomalies.conf — »PROTOCOL_VIOLATION/IP_HOST" и «C:/Apache2/conf/rules/base_rules/modsecurity_crs_60_correlation.conf» «Inbound Anomaly Score (Total Inbound Score: 2, SQLi=, XSS=): Host header is a numeric IP address»]
В журнале modsec_debug.log можно найти информацию обо всех использованных при запросе правилах.
11/Nov/2011:11:21:34 +0500] [192.168.10.2/sid#5e5148][rid#4aec970][/webgoat/attack][2] Warning. Found 1 byte(s) in ARGS:Screen outside range: 1-255. [file «C:/Apache2/conf/rules/base_rules/modsecurity_crs_20_protocol_violations.conf»] [line «353»] [id «960901»] [rev «2.2.2»] [msg «Invalid character in request»] [severity «WARNING»] [tag «PROTOCOL_VIOLATION/EVASION»] [tag «WASCTC/WASC-28»] [tag «OWASP_TOP_10/A1»] [tag «OWASP_AppSensor/RE8»] [tag «PCI/6.5.2»] [tag «i-technica.com/whitestuff/asciichart.html»]
[11/Nov/2011:11:21:34 +0500] [192.168.10.2/sid#5e5148][rid#4aec970][/webgoat/attack][2] Warning. Pattern match "^[\d.:]+$" at REQUEST_HEADERS:Host. [file «C:/Apache2/conf/rules/base_rules/modsecurity_crs_21_protocol_anomalies.conf»] [line «98»] [id «960017»] [rev «2.2.2»] [msg «Host header is a numeric IP address»] [severity «CRITICAL»] [tag «PROTOCOL_VIOLATION/IP_HOST»] [tag «WASCTC/WASC-21»] [tag «OWASP_TOP_10/A7»] [tag «PCI/6.5.10»] [tag «technet.microsoft.com/en-us/magazine/2005.01.hackerbasher.aspx»]
Все события с блокировкой событий записываются в cистемный журнал Web-сервера ErrorLog.
[Tue Nov 29 16:57:03 2011] [error] [client 192.168.10.5] ModSecurity: Warning. Pattern match "\\bacunetix-product\\b" at REQUEST_HEADERS_NAMES:Acunetix-Product. [file «C:/Apache2/conf/rules/base_rules/modsecurity_crs_35_bad_robots.conf»] [line «22»] [id «990901»] [rev «2.2.2»] [msg «Request Indicates a Security Scanner Scanned the Site»] [severity «WARNING»] [tag «AUTOMATION/SECURITY_SCANNER»] [tag «WASCTC/WASC-21»] [tag «OWASP_TOP_10/A7»] [tag «PCI/6.5.10»] [hostname «192.168.10.2»] [uri "/lessons/RoleBasedAccessControl/images/"] [unique_id «TtTIj8CoCgIAAAgcQw8AAADj»]
[Tue Nov 29 16:57:03 2011] [error] [client 192.168.10.5] ModSecurity: Warning. Operator GE matched 5 at TX:inbound_anomaly_score. [file «C:/Apache2/conf/rules/base_rules/modsecurity_crs_60_correlation.conf»] [line «37»] [id «981204»] [msg «Inbound Anomaly Score Exceeded (Total Inbound Score: 5, SQLi=, XSS=): Request Indicates a Security Scanner Scanned the Site»] [hostname «192.168.10.2»] [uri "/lessons/RoleBasedAccessControl/images/"] [unique_id «TtTIj8CoCgIAAAgcQw8AAADj»]
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
1. Barnett, Ryan C. Preventing Web Attacks with Apache. USA: Addison-Wesley Publishing, 2006. 240 с.
2. Magnus Mischel ModSecurity 2.5.Securing your Apache installation and web applications. England: Published by Packt Publishing, 2009. 280 c.
3. ModSecurity Reference Manual // www.modsecurity.org/documentation/modsecurity-apache/2.2.4/modsecurity-manual.html
4. Ryan Barnett Center for Internet Security Benchmark for Apache Web Server v2.1. USA: The Center for Internet Security (CIS), 2009. 50c.
5. Securing WebGoat Using ModSecurity. USA: OWASP Foundation, 2008. 130 c.
Автор: drais
