Stream_size vs flow bytes_toserver

Rules
1

I’m attempting to use stream_size to limit the match within the first “few” packets of a session as follows:

alert tcp any any -> any any (msg:"test"; flow:established,to_server; stream_size:server,<,5; content:"foo"; sid:1;)

As I understand it, I would expect the rule to only fire within the first 4(ish) bytes (as determined by seq numbers) being sent server → client while the content is being sent from the client → server. Which should be just after the initial 3WHS.

However, we are encountering reports where the rule alerts and the eve log alert contains flow details which indicate the rule alerted much later within the stream.

"timestamp":"2021-10-12T12:08:43.367522-0700"...[SNIP]...flow":{"pkts_toserver":218,"pkts_toclient":322,"bytes_toserver":23956,"bytes_toclient":266718,"start":"2021-10-12T12:08:11.494477-0700"},

Here you can see the alert is generated 32 seconds after the flow.start, and the pkts_toclient/bytes_toclient reflect the alert did not occur within the first few packets of the session.

This post - Alert on bytes_toserver > N or pkts_toserver > N ask the questions, which I’m not sure were ever answered.

Can anyone clarify the relation between bytes_toserver and the stream_size alert keyword? I am hoping to be able to identify all sorts of egress traffic (shells!) that exceed a certain threshold.

Is stream_size something that could be significantly lower than bytes_toserver / toclient because of some difference in the code logic?

In addition to those questions, is it possible that due to a high value being randomly selected for an initial sequence number causes the 32-bit value to wrap resulting in low stream_size values existing outside of the “early stages” of the stream?

What is the behavior, as it relates to the stream_size keyword, when the sequence numbers wrap?

Thanks!

2

Incomplete answer, but here are a few considerations

  • seq wrapping should work
  • flow byte count will contain all packets with a payload. TCP tracking will exclude retransmissions, packet overlaps, out of order packets
  • packets might be rejected by the stream engine (so not added to the reassebled stream), while still counted for flow bytes
  • I don’t know how how the TCP session reuse case affects all this. It will for sure lead to a “reset” of the stream depth, but maybe not the flow bytes. Needs more investigation

Think it would be good to generate a set of SV tests for all these scenarios.

3

Just a quick follow up - this continues to produce reports of FPs. I still haven’t received a pcap that I can share, but if there is anything I can do beyond a pcap, let me know.

Not a week goes by that I don’t see FPs reported with these same symptoms.

4

I think we need a comprehensive set of pcaps to test all the things I mentioned. This would probably be done best using specially crafted pcaps using scapy or similar. That way we won’t have to hope for a random occurrence in a shareable pcap.