Назад | Перейти на главную страницу

mod_security: В чем смысл аудита действий?

Я возился с mod_security, чтобы регистрировать полезные данные POST-запроса для определенного URI.

Как указано в этом ответе https://serverfault.com/a/729079/292993 на аналогичный вопрос AuditEngine mod_security работает так:

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

  1. Если для параметра SecAuditEngine установлено значение «Вкл.», Тогда все регистрируется в журнале аудита, и указанное выше правило не требуется. Это быстро заполняет файлы журнала, поэтому не рекомендуется.
  2. Если для параметра SecAuditEngine установлено значение RelevantOnly, тогда он будет регистрировать в системе аудита только определенные коды возврата (как определено вашим SecAuditLogRelevantStatus). Обычно это делается только для ошибок (5xx) или отказа в доступе (4xx - хотя обычно без ошибок 404). Поскольку вы не запрещаете доступ (и, предположительно, не хотели бы!), Это не будет записано в журнал аудита.
  3. Если для параметра SecAuditEngine установлено значение Выкл., Он никогда не будет записываться в журнал аудита.

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

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

Это заставляет AuditEngine быть включенным для почтовых запросов - даже если запрос завершается успешно, что обычно не регистрируется.

Имея это в виду, в чем смысл действия auditlog если мне нужно работать с ctl включить AuditEngine на уровне запроса, чтобы что-то записывать в журнал аудита?

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

После некоторых экспериментов я обнаружил следующее:

  • Если для SecAuditEngine установлено значение На, то журнал аудита не будет иметь реального эффекта, так как запрос все равно будет зарегистрирован.

  • Если для SecAuditEngine установлено значение Выключено, то журнал аудита не будет иметь никакого эффекта, так как запрос в любом случае не будет зарегистрирован.

  • Если для SecAuditEngine установлено значение RelevantOnly, то auditlog приведет к регистрации срабатывания правила. Даже если вы не запрещаете доступ (это ошибка в приведенном выше ответе).

Так в чем разница между auditlog и ctl:auditEngine=On? Ну, немного, но я вижу два основных отличия:

  1. Auditlog не будет работать, если SecAuditEngine выключен. В то время как ctl:auditEngine=On буду работать.

  2. ctl:auditEngine=On можно использовать для включения аудита без отображения фактического правила. Например, если у вас есть следующее:

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

    Тогда запрос будет зарегистрирован в журнале аудита, но не будет упоминания о правиле 22222224 (поскольку оно установлено на nolog). Это может быть полезно или нет: наличие правила 22222224 может добавить путаницы, поскольку с этим правилом нет реальной проблемы безопасности (оно просто используется для включения AuditEngine), и, возможно, вы хотите, чтобы в журнале аудита и ошибок регистрировались только настоящие правила безопасности. . С другой стороны, это может сбить с толку людей, почему что-то находится в журнале аудита, а не срабатывает очевидное правило, которое могло бы его туда поместить.

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