Bug #7318
openflow: flow timeout pseudo packet triggers unexpected alert
Description
Given the following rules:
alert tcp any any -> $EXTERNAL_NET 443 (flow: to_server; flags: S,CE; flowbits:set, tls_tracker; flowbits: noalert; sid:09901001; ) alert tcp any any -> $EXTERNAL_NET 443 (flowbits:isset, tls_tracker; content: "|15 03 01 00 02 02|"; startswith; flowbits:set, tls_error; sid:09901031; rev:1; msg:"TLS 1.2 Fatal Alert (outgoing packet)"; ) alert tcp $EXTERNAL_NET 443 -> any any (flowbits:isset, tls_tracker; content: "|15 03 01 00 02 02|"; startswith; flowbits:set, tls_error; sid:09901032; rev:1; msg:"TLS 1.2 Fatal Alert (incoming packet)"; ) alert tcp any any -> $EXTERNAL_NET 443 (flow: to_server; flowbits:isset, tls_error; sid:09901033; rev:1; msg:"Allow TLS error handling (outgoing packet)"; ) alert tcp $EXTERNAL_NET 443 -> any any (flow: to_client; flowbits:isset, tls_error; sid:09901034; rev:1; msg:"Allow TLS error handling (incoming packet)"; )
and the attached PCAP, the last alert in the output is for SID 9901033, but with a timestamp of the first packet in the stream. This is a pseudo-packet generated for the purpose of finishing up any transactions on flow end, as it is determined the TLS transaction is not yet complete.
However, the alert, given the timestamp being reported doesn't make much sense and likely shouldn't be triggered.
A SV test to show this behavior has been created: https://github.com/OISF/suricata-verify/pull/2080
Updated by Philippe Antoine about 1 month ago
Is not there potentially 2 bugs ?
- first the timeout of the alert with a pseudo packet timing out
- do we want the second alert at all ? Like should flowbits
set SIG_FLAG_REQUIRE_PACKET
?
Updated by Jason Ish about 1 month ago
Philippe Antoine wrote in #note-1:
Is not there potentially 2 bugs ?
- first the timeout of the alert with a pseudo packet timing out
- do we want the second alert at all ? Like shouldflowbits
setSIG_FLAG_REQUIRE_PACKET
?
Possibly, but I haven't looked into those possibilities yet.
Updated by Juliana Fajardini Reichow about 1 month ago
It seems that the pcap was not attached to the ticket. Is it the same as seen in the SV test?
Updated by Jason Ish about 1 month ago
Philippe Antoine wrote in #note-1:
- do we want the second alert at all ? Like should
flowbits
setSIG_FLAG_REQUIRE_PACKET
?
Naively setting this flag for flowbits does appear to work for this specific case but does break a number of S-V tests.
However, setting the mask SIG_MASK_REQUIRE_REAL_PKT doesn't result in any test breakage and fixes the issue, but I'm not sure if there are any edge cases I'm missing given this mask is used for tests on real packets, where I think flowbits could apply to re-assembled data as well.
Updated by Victor Julien 17 days ago
- Status changed from New to Assigned
- Assignee changed from OISF Dev to Victor Julien
- Target version changed from TBD to 8.0.0-beta1
- Label Needs backport to 7.0 added