Create httpd fingerprinting detection plugin

[fzipi]

Background

Following the discussion in coreruleset/coreruleset#4297 and the related PR coreruleset/coreruleset#4302, @theseion proposed that rules aimed at preventing httpd fingerprinting and blocking URL-encoded reserved characters in request paths would be better suited as a dedicated CRS plugin rather than being included in CRS core.

Problem

Requests containing URL-encoded reserved characters (e.g., %2F) in the request path serve no legitimate purpose in most environments and are commonly used by scanners and attackers to:

• Fingerprint the backend web server (e.g., triggering Apache default error pages)
• Exploit parser confusion between frontends and backends
• Bypass phase-1 protections that don't perform URL decoding

While these rules provide real security value, they don't fit well into CRS core because:

• They are more relevant to specific web server configurations (particularly Apache httpd)
• They may cause false positives in edge cases (e.g., resources with %2f in filenames)
• Behavior varies across web servers (Nginx, Caddy/Coraza, Envoy, etc.)

Proposal

Create a new CRS plugin, e.g., httpd-fingerprinting-detection-plugin, that groups rules serving this purpose. This would:

1. Group related rules — Collect rules that detect and block fingerprinting/reconnaissance patterns specific to httpd
2. Avoid false positives in CRS core — Keep CRS core clean of rules that may cause unexpected FPs depending on the deployment
3. Avoid issues with other web servers — Rules targeting httpd-specific behavior won't affect users running other engines
4. Allow iterative growth — New fingerprinting detection rules can be added to the plugin over time

Candidate rules

• Blocking %2F (URL-encoded slash) in request paths (#4297)
• Blocking other URL-encoded reserved characters that have no legitimate reason to appear encoded in request paths (#4302)
• Potentially, response body inspection rules for detecting stock error pages

Considerations

• Rules should use REQUEST_URI_RAW to ensure the URI hasn't already been decoded
• Paranoia level 2 is recommended as a starting point to stay safe with respect to false positives
• Rules should be categorized under protocol enforcement

References

• PR feat: add 920630 to prevent fingerprinting coreruleset#4297 — feat: add 920630 to prevent fingerprinting
• PR feat: add 921500 - Nonstandard urlencode characters in path coreruleset#4302 — Broader rule for URL-encoded reserved characters
• RFC 2396 — URI Generic Syntax (slash is in the "reserved" set)
• RFC 2616 §3.2.3 — URI Comparison

[EsadCetiner]

imo for the plugin we should write response rules that block stock error pages instead of writing rules in phase 1/2, it's more effective than enumerating every single possible method to trick a http server's parser into serving it's stock error page instead of the configured one. This would also help in cases such as misconfigurations.