Matched \"Operator `Eq' with parameter `0' against variable `REQUEST_HEADERS:Host' (Value: `0' )

[MorrowxD]

ModSecurity does not recognize the Host header when using HTTP/3. I believe I have the correct versions of ModSecurity, the connector, and the rules. Is any custom configuration necessary to handle HTTP/3 requests?

{
  "transaction": {
    "client_ip": "XXXXXX",
    "time_stamp": "Wed Dec 18 15:52:34 2024",
    "server_id": "a53237e5ec8faf273b2ea40bcca024979fdaed7f",
    "client_port": 46779,
    "host_ip": "XXXXXX",
    "host_port": 443,
    "unique_id": "173453355437.118418",
    "request": {
      "method": "GET",
      "http_version": 3,
      "uri": "/",
      "headers": {
        "sec-fetch-user": "?1",
        "sec-ch-ua": "\"Chromium\";v=\"129\", \"Not=A?Brand\";v=\"8\"",
        "sec-fetch-dest": "document",
        "sec-fetch-mode": "navigate",
        "user-agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36",
        "sec-fetch-site": "cross-site",
        "sec-ch-ua-platform": "\"Linux\"",
        "upgrade-insecure-requests": "1",
        "sec-ch-ua-mobile": "?0",
        "accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7",
        "cache-control": "max-age=0",
        "accept-encoding": "gzip, deflate, br, zstd",
        "accept-language": "en-US,en;q=0.9",
        "priority": "u=0, i"
      }
    },
    "response": {
      "body": "",
      "http_code": 200,
      "headers": {
        "Server": "nginx/1.26.2",
        "Date": "Wed, 18 Dec 2024 14:52:34 GMT",
        "Content-Type": "application/octet-stream",
        "Connection": "keep-alive",
        "Alt-Svc": "h3=\":443\"; ma=86400"
      }
    },
    "producer": {
      "modsecurity": "ModSecurity v3.0.13 (Linux)",
      "connector": "ModSecurity-nginx v1.0.3",
      "secrules_engine": "DetectionOnly",
      "components": [
        "OWASP_CRS/4.9.0\""
      ]
    },
    "messages": [
      {
        "message": "Request Missing a Host Header",
        "details": {
          "match": "Matched \"Operator `Eq' with parameter `0' against variable `REQUEST_HEADERS:Host' (Value: `0' )",
          "reference": "",
          "ruleId": "920280",
          "file": "/usr/local/nginx/conf/crs4/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf",
          "lineNumber": "574",
          "data": "",
          "severity": "4",
          "ver": "OWASP_CRS/4.9.0",
          "rev": "",
          "tags": [
            "application-multi",
            "language-multi",
            "platform-multi",
            "attack-protocol",
            "paranoia-level/1",
            "OWASP_CRS",
            "capec/1000/210/272",
            "PCI/6.5.10"
          ],
          "maturity": "0",
          "accuracy": "0"
        }
      }
    ]
  }
}

[airween]

Hi @MorrowxD,

Is any custom configuration necessary to handle HTTP/3 requests?

No, there is no any custom configuration which needs to handle HTTP/3. And libmodsecurity3 logs all headers that it gets in the request.

What I can assume is that HTTP/3 is not necessary to have host header, and you faced off with that scenario.

[MorrowxD]

How can I prevent the logs from growing excessively? Should this rule be disabled for HTTP/3?

[airween]

@MorrowxD,

I think this is more a Coreruleset issue than ModSecurity.

Anyway, it's interesting why do you have an audit log entry with response code 200? ModSecurity's default config file contains SecAuditLogRelevantStatus with value "^(?:5|4(?!04))", this means audit.log entry is generated only when the status code is 5XX or 4XX except 404.

For the solution: you can create an exclusion against that rule. For more information, please take a look at this page. A quick explanation:

SecRule REQUEST_PROTOCOL "^HTTP/3(\.0)$" \
    "id:10000,\
    phase:1,\
    pass,\
    t:none,\
    ctl:ruleRemoveById=920280"

This will prevent to execute rule 920280 if the protocol is HTTP/3 or HTTP/3.0.

[airween]

@MorrowxD any news around here? Can we close this issue?

[off-circuit]

@airween Just a quick update, because I just stumbled onto this with the same issue: Your exclusion role fixes the warning, thanks. The root problem remains, though. But as you pointed out, this is rather a CRS problem.