Libmodsecurity — один из компонентов проекта ModSecurity v3. Кодовая база библиотеки служит интерфейсом для коннекторов ModSecurity, принимая веб-трафик и применяя к нему традиционную обработку ModSecurity. В целом она предоставляет возможность загружать и интерпретировать правила, написанные в формате ModSecurity SecRules, и применять их к HTTP-содержимому, предоставляемому вашим приложением через коннекторы.

Если вы ищете ModSecurity для Apache (также известный как ModSecurity v2.x), он по-прежнему поддерживается и доступен: здесь.

В чём разница между этим проектом и старым ModSecurity (v2.x.x)?

• Все зависимости от Apache удалены
• Более высокая производительность
• Новые возможности
• Новая архитектура

Libmodsecurity — это полная переработка платформы ModSecurity. Изначально проект ModSecurity задумывался как просто модуль для Apache. Со временем, в ответ на широкий спрос, проект был расширен для поддержки других платформ, включая (но не ограничиваясь) Nginx и IIS. Чтобы удовлетворить растущий спрос на поддержку дополнительных платформ, стало необходимо удалить зависимости от Apache, лежащие в основе этого проекта, сделав его более независимым от платформы.

В результате этой цели мы переработали архитектуру Libmodsecurity так, что она больше не зависит от веб-сервера Apache (как при компиляции, так и во время выполнения). Одним из побочных эффектов этого является то, что на всех платформах пользователи могут рассчитывать на повышенную производительность. Кроме того, мы воспользовались этой возможностью, чтобы заложить основу для некоторых новых функций, которых пользователи давно ждали. Например, мы планируем обеспечить нативную поддержку журналов аудита в формате JSON, а также множество других возможностей в будущих версиях.

Это больше не просто модуль.

Ветка 'ModSecurity' больше не содержит традиционную логику модуля (для Nginx, Apache и IIS), которая традиционно поставлялась в едином пакете. Вместо этого данная ветка содержит только библиотечную часть (libmodsecurity) этого проекта. Эта библиотека используется тем, что мы назвали «коннекторами»: эти коннекторы взаимодействуют с вашим веб-сервером и предоставляют библиотеке данные в понятном ей общем формате. Каждый из этих коннекторов поддерживается как отдельный проект на GitHub. Например, коннектор для Nginx поставляется проектом ModSecurity-nginx (https://github.com/owasp-modsecurity/ModSecurity-nginx).

Разделение этих коннекторов позволяет каждому проекту иметь собственные циклы выпуска, отслеживание проблем и деревья разработки. Кроме того, это означает, что при установке ModSecurity v3 вы получаете именно то, что вам нужно, без лишних компонентов, которые вы не будете использовать.

Компиляция

Перед началом процесса компиляции убедитесь, что все необходимые зависимости установлены.
Дополнительную информацию см. в разделах Зависимости и Git-подмодули.

После компиляции убедитесь, что в вашей сборке/платформе нет проблем.
Мы настоятельно рекомендуем запустить модульные тесты и регрессионные тесты. Эти тестовые утилиты находятся в подпапке tests/.

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

Unix (Linux, macOS, FreeBSD, …)

В Unix-подобных системах проект использует autotools для процесса компиляции.

Если вы работаете с git-репозиторием, убедитесь, что клонировали репозиторий рекурсивно или инициализировали все подмодули перед сборкой.
См. также раздел Git-подмодули.

git clone https://github.com/owasp-modsecurity/ModSecurity ModSecurity
cd ModSecurity

Этот репозиторий использует git-подмодули. После клонирования обязательно инициализируйте и загрузите все подмодули:

git submodule update --init --recursive

Проверить, что все подмодули правильно инициализированы, можно с помощью:

git submodule status

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

Затем вы можете запустить процесс сборки:

./build.sh
./configure
make
sudo make install

Информацию о сборках для конкретных дистрибутивов можно найти в нашем Wiki: Compilation Recipes

Windows

Информацию о сборке для Windows можно найти здесь.

Зависимости

• Эта библиотека написана на C++ с использованием стандарта C++17.
• Для создания парсера «Sec Rules Language» используются Flex и Bison (Yacc).
• К обязательным зависимостям относится YAJL, поскольку ModSecurity использует JSON для логирования и в своём фреймворке тестирования.
• libXML2 (опционально) используется для разбора XML-запросов.

Движок регулярных выражений (PCRE2 / PCRE)

• Обработка регулярных выражений в SecRules реализована через утилиту Regex (src/utils/regex.*).

• По умолчанию ModSecurity использует PCRE2 для работы с регулярными выражениями.

• Это используется такими операторами, как @rx, @rxGlobal и @verifyCC.

• Поведение при сборке:

  • По умолчанию: PCRE2 обнаруживается и используется.
  • Резервный вариант: устаревший PCRE может использоваться, если явно указан --with-pcre (WITH_PCRE).

• Иными словами, текущие сборки предполагают использование PCRE2, если явно не задано иное.

• @rx и @rxGlobal по умолчанию компилируют шаблоны с флагами DOTALL | MULTILINE: DOTALL позволяет . соответствовать символам новой строки, а MULTILINE позволяет ^/$ привязываться к каждому внутреннему разрыву строки, а не только к началу/концу всей строки. Передайте --enable-regex-dollar-endonly=yes, чтобы компилировать их с DOTALL | DOLLAR_ENDONLY вместо этого: без MULTILINE ^/$ привязываются только к началу/концу всей строки, а DOLLAR_ENDONLY дополнительно ограничивает $ совпадением только там, а не также непосредственно перед завершающим символом новой строки. DOTALL в любом случае не меняется, поэтому шаблоны по-прежнему могут совпадать через внутренние разрывы строк с помощью .. Это соответствует поведению @rx в ModSecurity v2. Флаг отключён по умолчанию; см. issue #3295.