Нужна помощь с логами Modsecurity – DetectionOnly vs On (Enforce)

Question

Мне нужна помощь с логами ModSecurity в нашей среде Kubernetes. У нас есть контроллер входящего трафика, и весь трафик проходит через него. Я включил ModSecurity/OWASP с помощью конфигурационных карт, и конфигурация работает как положено. Я получаю логи с кодами состояния 200 и 403, где это применимо.

В настоящее время я установил ModSecurity в режиме DetectionOnly. Однако я пытаюсь выяснить, какие запросы будут блокироваться, когда я переключу SecRuleEngine на On (режим Enforce). После просмотра логов мне трудно определить разницу.

Например, предположим, что запрос к https://abc.myhost.com/xyz отмечен как тот, который должен быть заблокирован, когда SecRuleEngine включен, но не блокируется из-за режима DetectionOnly. Как я могу это различить, используя логи? Я привел пример ниже для DetectionOnly. Единственное различие, которое я вижу, когда DetectionOnly изменяется на ON, это “secrules_engine”:”Enabled”,

Находясь в режиме DetectionOnly, я хочу понять, какие запросы будут блокироваться, когда я переключу его на ON. Но логи не дают мне отличительных признаков.

{
    "transaction":{
       "client_ip":"103.x.x.x",
       "time_stamp":"Wed Feb 19 13:48:56 2025",
       "server_id":"97a0d4c73dd",
       "client_port":62482,
       "host_ip":"10.x.x.x",
       "host_port":8444,
       "unique_id":"17399729.475138",
       "request":{
          "method":"POST",
          "http_version":2.0,
          "uri":"/suite/JSON-RPC?appian_environment=tempo"
       },
       "response":{
          "http_code":200
       },
       "producer":{
          "modsecurity":"ModSecurity v3.0.12 (Linux)",
          "connector":"ModSecurity-nginx v1.0.3",
          "secrules_engine":"DetectionOnly",
          "components":[
             "OWASP_CRS/4.4.0\""
          ]
       },
       "messages":[
          {
             "message":"Тип содержимого запроса не разрешен политикой",
             "details":{
                "match":"Совпадение \"Operator `Within' с параметром `|application/x-www-form-urlencoded| |multipart/form-data| |multipart/related| |text/xml| |application/xml| |application/soap+xml| |application/json| |application/cloudevents+json| |application/cloudev (16 characters omitted)' against variable `TX:content_type' (Value: `|text/plain|' )",
                "reference":"o0,10v383,10t:lowercase",
                "ruleId":"920420",
                "file":"/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf",
                "lineNumber":"993",
                "data":"|text/plain|",
                "severity":"2",
                "ver":"OWASP_CRS/4.4.0",
                "rev":"",
                "tags":[
                   "application-multi",
                   "language-multi",
                   "platform-multi",
                   "attack-protocol",
                   "paranoia-level/1",
                   "OWASP_CRS",
                   "capec/1000/255/153",
                   "PCI/12.1"
                ],
                "maturity":"0",
                "accuracy":"0"
             }
          },
          {
             "message":"Превышен лимит входной аномалии (общий счёт: 5)",
             "details":{
                "match":"Совпадение \"Operator `Ge' с параметром `5' against variable `TX:BLOCKING_INBOUND_ANOMALY_SCORE' (Value: `5' )",
                "reference":"",
                "ruleId":"949110",
                "file":"/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf",
                "lineNumber":"222",
                "data":"",
                "severity":"0",
                "ver":"OWASP_CRS/4.4.0",
                "rev":"",
                "tags":[
                   "anomaly-evaluation",
                   "OWASP_CRS"
                ],
                "maturity":"0",
                "accuracy":"0"
             }
          }
       ]
    }
 }

configmap

  modsecurity-snippet: >-
    SecRule REQUEST_URI "@contains suite/JSON-RPC"
      "id:100001,phase:1,pass,t:none,nolog,ctl:ruleRemoveById=920420,chain"

    SecRule REQUEST_HEADERS:Host "@contains myhost.com" "t:none"

    SecRequestBodyAccess On

    SecAuditLogParts AHKZ

    # Отклонять, если больше (мы также могли бы позволить пройти с ProcessPartial)
    SecRequestBodyLimitAction Reject

    # Отправлять аудиторские логи ModSecurity в stdout (только для отклоненных запросов)
    SecAuditLog /dev/stdout

    # формировать логи в JSON
    SecAuditLogFormat JSON

    # может быть On/Off/RelevantOnly
    SecAuditEngine RelevantOnly

    SecAction "id:900000,phase:1,nolog,pass,t:none,setvar:tx.paranoia_level=2"
    SecAction "id:900200,phase:1,nolog,pass,t:none,setvar:tx.allowed_methods=GET HEAD POST OPTIONS PUT PATCH DELETE"

    SecRule REQUEST_HEADERS:Content-Type "@rx application/vnd.appian.tv\+json" "id:100002,phase:1,allow,log"

    # Правило имеет уровень серьёзности 4, поэтому не было заблокировано
    SecRule REMOTE_ADDR "@ipMatch 127.0.0.1" "id:10000,phase:1,pass,nolog,chain"
    # Не используем ipMatch, так как не поддерживает порты
    SecRule REQUEST_HEADERS:Host "@streq 127.0.0.1:10246" "ctl:ruleRemoveById=920350"

    SecRuleEngine DetectionOnly

Нужна помощь с логами Modsecurity – DetectionOnly vs On (Enforce)

Вопрос или проблема

Ответ или решение