Bug #9270
openSuricata: synthetic HTTP content direction conflicts with rule header direction (behavior question)
Description
Hello Suricata maintainers,
I am asking whether this narrow detection-behavior difference is expected. This is not an assertion of a vulnerability or production impact.
- Observation
For synthetic TCP/HTTP cases fuzzing-results_4_pass1-RCA-000049/50/51/56 (SIDs 45002, 45003, 45004, and 45015), the recorded cross-engine baseline was 1/1/0; Suricata did not alert. Packet-direction instrumentation recorded the original endpoints, ports, and effective direction, and Suricata was rejected before rule-header eligibility. In an archived controlled comparison, aligning only direction/endpoint orientation in the detection view while preserving payload and rule content conditions changed Suricata from no alert to alert (0 to 1); the cross-engine result became 1/1/1. These results are limited to this synthetic input and rule setup and do not establish a product defect or real-network impact.
- Reproducer and environment
Attached is a ZIP with the synthetic PCAP, one target rule, and runtime request. The recorded run used Suricata in an offline container with networking disabled, `/etc/suricata/suricata.yaml`, and pinned image digest `sha256:270c62837ee2ac9078c0538e35eddf5229bdfbba326c5f3a7ca25fdeb1a33677`. PCAP and rule SHA-256 values are in the runtime request. The archived experiment is dated 2026-09-17; this ZIP was assembled 2026-10-25 and has not itself been independently replayed. The image is not included and may be local-only. No live network or production system was involved.
Could you confirm whether the direction eligibility and resulting no-alert behavior are expected for this rule/input, and point me to the preferred Suricata-Verify regression format if this warrants a test?
Thank you.
Files
No data to display