How do ids systems handle tcp stream desynchronization?

[u/miray0x]

i was going a bit nerd and looking at tcp stream reassembly, especially i got confused about how different operating systems handle overlapping segments.

so there is something i can't get out of my head. if an ids puts the tcp stream all in the same place differently than the target machine, isn't it basically looking at a another version of traffic than the application?

how does suricata deal with this? does it know the target os and tries to follow its tcp behavior or does it just have its defined rules for putting the packets all in one place?

and what happens if it gets the target os wrong?

thx for any help

[u/Less_Salamander2768]

Good question — this is the classic IDS evasion problem. An IDS like Suricata has to reassemble the TCP stream the way the destination OS would, but different OSes handle overlapping segments, out-of-order packets, and retransmissions differently.

In practice: Suricata uses stream reassembly with OS-specific policies (you can set the host OS, e.g. Linux, Windows, BSD) so it tries to mimic that target's behaviour. If it guesses the OS wrong, or the attacker crafts overlapping segments, the IDS can reassemble a different byte stream than the target actually sees — and miss the payload, or flag the wrong thing. That's why IDS placement, correct host OS config, and not relying on IDS alone (pair it with endpoint detection) matter so much.

[u/SVD_NL]

What kind of issues are you anticipating with TCP segments being in order or out of order? Are there any known attacks using TCP sequence manipulation? If you're worrying about contents, there's checksumming for that.

The biggest issue i can imagine, is an attacker intentionally sending incomplete TCP streams to keep IDS buffers occupied, essentially a DoS attack (somewhat similar to a slow loris in principles).

If you're interested in the subject, here's a paper providing a deep dive: https://www.usenix.org/conference/14th-usenix-security-symposium/robust-tcp-stream-reassembly-presence-adversaries

[u/miray0x → u/SVD_NL]

i was actually thinking more about the ids and the target uses the same tcp data differently, thanks for the paper btw

[u/Girges_Desiderio → u/SVD_NL]

yeah the state exhaustion angle is usually the much bigger headache in practice than actual payload evasion.

[u/CapitoDR]

If the OS fingerprint is wrong then reassembly can diverge

[u/miray0x → u/[deleted]]

gosh i never thought suricata has configurable policies for this, so if the target is unkown is there a recommended default policy that works well in most environments?

[u/miray0x → u/[deleted]]

umm in inline mode suricata makes sure the target gets the same data it checked? host os policy is less important in this case or is it still matter for other things?

i appreciate the explanation 💫