Actions
Bug #9271
open
JZ
Suricata: rule direction conflicts with synthetic response content (SID 43750; behavior question)
Bug #9271:
Suricata: rule direction conflicts with synthetic response content (SID 43750; behavior question)
Affected Versions:
Effort:
Difficulty:
Label:
Description
Hello Suricata maintainers,
I am asking about a reproducible detection-behavior difference from a local synthetic test. This is not an assertion of a vulnerability or production impact.
- Observation
For synthetic TCP traffic associated with SID 43750, the rule header requires [1;3mto_server,established[0m while the packet content under test is in the response ([1;3mto_client[0m) direction. In the archived baseline run Suricata did not alert. In a controlled comparison changing only the target direction qualification produced an alert (0 to 1). This appears consistent with the rule's direction eligibility, but I would appreciate confirmation of the expected behavior and whether the case belongs in a regression test.
- Reproducer and environment
Attached ZIP contains the synthetic PCAP, target rule, and runtime request. The recorded experiment used Suricata in an offline container with networking disabled and [1;3m/etc/suricata/suricata.yaml[0m; image digest: [1;3msha256:858787010d0b11328b93a60b9b1abde09d54735ba038f9d852b0dd2e65dcd612[0m. The PCAP/rule hashes are in the runtime request. This is a historical controlled result dated 2026-09-17; the ZIP was assembled 2026-10-25 and has not itself been independently replayed. The container image is not included and may only be locally available.
The traffic is synthetic and was tested offline only; no production system or third-party target was involved. Could you confirm whether the no-alert outcome is expected for this rule/input and advise on the preferred Suricata-Verify regression format if useful?
Thank you.
Files
No data to display
Actions