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.
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?