Bug #7004
Updated by Jason Ish 6 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-5.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 google.com 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-5.pcap dns-tcp-multi.pcap </pre> Observations: - 2 alerts, logged matching on There are only two alerts for the "suricata" "suricata.org" request and response, which is the 3rd request/response in the DNS stream PCAP. - The transaction in both alerts contain the data from the 3rd transaction, which There is no alert for "google.com", which the first request/response for "suricata.io", but one is misleading. expected. - All @dns@ app-layer events are logged as expected. Issue: - The wrong first transaction data is logged. not matched against rules correctly. This is very similar to what is being seen in #7000. [Update] If @dns-tcp-multi.pcap@ is updated to use the hostnames @suricata.io@, @oisf.net@ and @google.com@, the rule above will still alert, but with the transaction data for @google.com@. This does suggest that the match is being done. Expected behavior: - alert for DNS request to suricata.io, with correct tx data (or no tx data) - alert for DNS response for suricata.io, with correct tx data (or no tx data) - alert for DNS request to suricata.org, with correct tx data (or no tx data) - alert for DNS response to suricata.org, with correct tx data (or no tx data) *Issue 2. IPS Mode* Run the same test above, but in IPS simulation mode: <pre> suricata -S test.rules -r dns-tcp-multi-5.pcap dns-tcp-multi.pcap --simulate-ips </pre> Observations: - 6 alerts logged, one Alert for each request and response "suricata.io" request/response: OK - Given the alert, and pcap_cnt, the tx data seems to be correct. TX data Alert for each request and response is seen. "oisf.net" request/response: NOT OK - Alert for "suricata.org" request/response: OK Issue: - One might expect to get only 2 alerts in this scenario. An alert is being generated for transactions that should not match. *Summary* Being There appears to be a stream rule there is no direct correlation between discrepancy somewhere in @tx id@ handling where the match and the transaction logged. Generally logging the wrong data is worse than transactions being matched on, are not logging it at all, so one idea would be to not log the transaction data transactions being logged on TCP protocols. At least in this case. For DNS, most TCP UDP DNS sessions contain one transaction, so maybe in some cases we know we're going to log the correct tx, works correctly, but in others we know it might not be the correct transaction. I'm not sure about the IPS issue, I brought it up as it differs from IDS mode, but may be a separate issue. has simpler state management.