☰

Какое правило можно использовать в ModSecurity для регистрации полезной нагрузки POST для определенного сайта?

tag-icon • tag-icon logging mod-security litespeed
Какое правило можно использовать в ModSecurity для регистрации полезной нагрузки POST для определенного сайта?

Мне нужно проверить полезную нагрузку POST для определенного веб-сайта (сервер довольно загружен, и я бы не стал включать ведение журнала POST для всего сервера).

Сервер — LiteSpeed ​​5.0.7. SecRequestBodyAccess установлен на «Вкл».

Сначала я попробовал создать цепочку правил: первое в фазе 1, чтобы сопоставлять только запросы с нужным мне хостом, но полезная нагрузка поста находится в фазе 2, и я не думаю, что смогу создать цепочку из двух разных фаз.

Затем я попробовал использовать это:

<VirtualHost xxxxx>
    SecRule REQUEST_METHOD "POST" "phase:2,log,id:22222223
</VirtualHost>

Но он ничего не записывает в формате modsec_audit.log.

Я что-то делаю не так или это связано с совместимостью LiteSpeed ​​с ModSec?

В конце концов я также попробовал это правило для записи POST для всех запросов:

SecRule REQUEST_METHOD "POST" "id:22222224,phase:2,ctl:auditEngine=On,log,pass".

Он регистрирует запрос, но не тело запроса ( -C-- group si missing in modsec audit).

решение1

Аналогично этому вопросу:Как заставить mod_security регистрировать все данные POST?

Вы правы, вы не можете объединить два правила в две разные фазы, однако фаза 2 имеет доступ ко всей информации фазы 1, поэтому просто перенесите это в фазу 2, если вы хотите сделать это таким образом.

Это правило, которое вы дали:

SecRule REQUEST_METHOD "POST" "phase:2,log,id:22222223

Это как-то бессмысленно. Это запишет (в основной журнал), что был получен запрос POST, но без тела POST.

Он также будет регистрироваться в AuditEngine в зависимости от того, что выSecAuditEngineзначение установлено на:

  1. Если у вас SecAuditEngine установлен на On, то все регистрируется в журнале аудита, и указанное выше правило не нужно. Это быстро заполняет файлы журналов, поэтому не рекомендуется.
  2. Если для параметра SecAuditEngine установлено значение RelevantOnly, то запись также будет вестись здесь.
  3. Если для параметра SecAuditEngine установлено значение Off, то он никогда не будет зарегистрирован в журнале аудита.

Обычно лучше всего установить SecAuditEngine на RelevantOnly (что, как я подозреваю, у вас уже сделано), но если это не так, то тело может не быть зарегистрировано в AuditLog.

Возможно, лучший способ сделать это — использовать другое правило, которое вы дали,ctlдействие:

SecRule REQUEST_METHOD "POST" "id:22222224,phase:2,ctl:auditEngine=On,log,pass"

Это заставляет AuditEngine быть включенным для запросов post - даже если AuditLog установлен на Off. Это также запишет в журнал, что вы запустили это правило, чтобы включить его, что на самом деле не нужно и не полезно, поэтому я бы изменил "log" на "nolog". Запрос все равно будет записан в журнал (так как auditEngine был установлен на yes), но это правило, вносящее это изменение, не будет. Кстати, когда вы используете ctl, это влияет только на этот запрос, поэтому AuditEngine сбросится обратно для следующего запроса.

Как вы утверждаете, это, кажется, работает, за исключением того, что у вас нет части C. Это устанавливается с помощьюSecAuditLogParts. По умолчанию это включает части C, так что, полагаю, это означает, что вы, должно быть, изменили значение по умолчанию? Была ли для этого какая-то причина?

В любом случае вы можете настроить его так, чтобы он включал части C:

SecAuditLogParts ABCFHZ
SecRule REQUEST_METHOD "POST" "id:22222224,phase:2,ctl:auditEngine=On,nolog,pass"

Или, если вы хотите, чтобы при срабатывании этого правила регистрировались только детали C, вы можете сделать это как часть правила:

SecRule REQUEST_METHOD "POST" "id:22222224,phase:2,ctl:auditEngine=On,ctl:auditLogParts=ABCFHZ,nolog,pass"

Еще одна вещь, о которой следует знать, это то, что запросы POST могут регистрировать конфиденциальные данные (пароли, номера кредитных карт, номера социального страхования... и т. д.). Регистрировать их не рекомендуется, и это также может нарушить политику компании и/или любые стандарты, которым вы следуете (например, соответствие PCI). Поэтому рекомендуется настроить правила очистки, чтобы скрыть эти данные. Подробнее см. здесь:https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#sanitiseArg

решение2

Убедитесь в следующем:

  1. ИметьSecRequestBodyAccess On

  2. Попробуйте использовать «auditlog» вместо «log»

  3. Если у вас есть пользовательские SecAuditLogParts, убедитесь, что они включают тело запроса

Связанный контент