Оставьте ModSecurity включенным при установке Symfony W / Cpanel & amp; WHM

Фон

ModSecurity — это брандмауэр веб-приложений (или WAF). Вы можете определить правила, чтобы попытаться идентифицировать и заблокировать незаконные запросы. Хотя WAF не идеальны, и часто используются общие правила, которые работают на «большинстве сайтов», но иногда блокируют законные запросы (известные как ложные срабатывания).

Первое, что нужно понять, это то, что никто не будет знать, какие правила ModSecurity вы установили, кроме вас. ModSecurity не поставляется с какими-либо правилами, хотя есть и доступные для скачивания правила, например, бесплатные OWASP CRS) чтобы заплатить за таких, как атомное) или вы можете написать свой собственный. Итак, первое, что вам нужно объяснить, это то, что никто не сможет рассказать вам, как решить эту проблему, так как она может зависеть от вас в зависимости от вашей установки. Сказать, что мы можем помочь вам найти собственное решение.

Запуск WAF дает дополнительную защиту, но требует большого обслуживания. Хотя мне лично это нравится и я вижу в этом достоинства, большинство сайтов живут без него, если честно, и редко (хотя и не случайно) хакеры делают это в любом случае, если вы обновляете свое программное обеспечение и не устанавливаете программное обеспечение, которое высокая цель (WordPress, например). Вам решать, стоит ли сохранять его в зависимости от того, насколько критичным и безопасным должен быть ваш веб-сайт, но, если вы действительно хотите его использовать, вам нужно будет понять, как он работает для решения подобных проблем.

Твоя проблема.

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

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

Это правило, как я уже обсуждал в комментариях к вашему первоначальному вопросу, является довольно стандартным правилом в большинстве наборов правил, чтобы попытаться предотвратить утечку информации. Все веб-серверы отвечают 3 цифрами код состояния за каждый запрос. Наиболее известным является 404 или «страница не найдена». Значения в диапазоне 500 означают ошибку сервера. Таким образом, это правило гласит, что если сервер отвечает (RESPONSE_STATUS) шаблоном, совпадающим с «^ 5 \ d {2} $» (т. Е. 5XX, где X — это цифра, поэтому 0-9), то что-то пошло не так, и ModSecurity переходит к предотвратить любые сообщения об ошибках, возвращаемые пользователю, и вместо этого отправляет собственное сообщение об ошибке 406.

ModSecurity имеет 5 фаз:

1. Правила, которые сканируют заголовки запроса (REQUEST_HEADERS)
2. Правила, которые сканируют тело запроса (REQUEST_BODY)
3. Правила, которые сканируют заголовки ответа (RESPONSE_HEADERS)
4. Правила, которые сканируют тело ответа (RESPONSE_BODY)
5. Правила, которые влияют на ведение журнала (LOGGING)

Это правило срабатывает на этапе 4, когда запрос отправляется обратно клиенту. Таким образом, на данном этапе что-то пошло не так, чтобы ваше приложение вернуло статус 5XX.

Я подозреваю, что другое правило ModSecurity сработало ранее (правило фазы 1 или фазы 2), которое вызвало ошибку, и вы показали только последнее правило, которое сработало.

Прежде чем я смогу помочь вам в решении вашей проблемы, мне нужно знать:

• ВСЕ Сообщения об ошибках ModSecurity из журналов ошибок Apache.
• Кроме того, было бы полезно узнать, какую версию ModSecurity вы используете (это должно быть в журналах ошибок Apache при запуске).
• Также было бы полезно узнать, какой набор правил вы используете. Это какие-то стандартные, которые обсуждались выше, или написанные специально для вашего сайта? Большинство правил имеют идентификатор правила (на самом деле это является обязательным начиная с ModSecurity 2.7 и далее), поэтому удивлен, что это не указано в фрагменте журнала ошибок, который вы дали ранее.

С этим я или кто-то еще, возможно, смогу указать вам правильное направление.

Как вы можете самостоятельно диагностировать эту проблему (и будущие проблемы!)

На вашем месте я бы предпринял следующие шаги для выявления проблемы:

1. Прочитайте все ваши файлы конфигурации Apache и узнайте, где определены конфигурация и правила ModSecurity. Правила ModSecurity — это просто текстовая конфигурация с использованием языка ModSecurity, добавляемого в стандартную конфигурацию Apache — часто путем добавления внешних файлов, в которых определены правила. Получить понять, что эти правила делают и значат.
2. Найдите строку «SecRuleEngine On» в вашей конфигурации и измените ее на «SecRuleEngine DetectionOnly», затем перезапустите Apache. Это помечает правила в файлах журнала, но НЕ блокирует попытки. Тогда делай, что хочешь, и не принимай правил, которые действуют.
3. Также включите дополнительный механизм аудита для сбора полной информации о запросах, которые блокируются («SecAuditEngine RelevantOnly»).
4. Решите, нужны ли вам эти правила, которые вызывают у вас проблемы, а затем либо закомментируйте их в своей конфигурации, либо есть способы настроить их, чтобы они перестали блокировать законные запросы.
5. После настройки всех правил снова включите ModSecurity.

Справочное руководство по ModSecurity это очень полезный ресурс для понимания ModSecurity.

Я также могу порекомендовать руководство по ModSecurity для дальнейшего чтения. Он был написан первоначальным автором ModSecurity и, хотя он не обновлялся с версии 2.7, он все еще является отличным вступлением.

Надеюсь, это поможет,
Барри