Bug #7004
Updated by Jason Ish 5 months ago
[Private as it discusses an issue where DNS transactions are missed] In IDS mode, transaction handling appears to be off, and there exists a discrepancy between IDS and IPS modes. While pointed out in PGSQL, I believe DNS presents a simpler reproduction case just being a simpler protocol with less state. The test PCAP (@dns-tcp-multi.pcap@) contains 1 TCP session with 3 DNS requests/responses, in order. - 1) Request/response for suricata.io - 2) Request/response for oisf.net - 3) Request/response for suricata.org One rule is used: <pre> alert dns any any -> any any (msg:"DNS suricata"; content:"suricata"; sid:1; rev:1;) </pre> *Issue 1. IDS Mode* Using a default Suricata configuration: <pre> suricata -S test.rules -r dns-tcp-multi.pcap </pre> Observations: - There are only two alerts for the "suricata.org" request and response, which is the 3rd request/response in the PCAP. - There is no alert for the first request/response for "suricata.io", but one is expected. This could be considered an evasion or false negative. "suricata.io" - All @dns@ app-layer events are logged as expected. Issue: - The first transaction is not matched against rules correctly. This is very similar to what is being seen in #7000. *Issue 2. IPS Mode* Run the same test above, but in IPS simulation mode: <pre> suricata -S test.rules -r dns-tcp-multi.pcap --simulate-ips </pre> Observations: - Alert for "suricata.io" request/response: OK - Alert for "oisf.net" request/response: NOT OK - Alert for "suricata.org" request/response: OK Issue: - An alert is being generated for transactions that should not match. *Summary* There appears to be a discrepancy somewhere in @tx id@ handling where the transactions being matched on, are not the transactions being logged on TCP protocols. At least in DNS, UDP DNS works correctly, but has simpler state management.