Differences

This shows you the differences between two versions of the page.

--- pfsense:suricata:alerts:suricata_stream_3way_handshake_synack_with_wrong_ack [2020/02/28 20:59] – peter
+++ pfsense:suricata:alerts:suricata_stream_3way_handshake_synack_with_wrong_ack [2021/01/15 00:59] (current) – created peter
@@ Line 1: / Line 1: @@
 ====== PFSense - Suricata - Alerts - SURICATA STREAM 3way handshake SYNACK with wrong ack ======
 The best solution is to disable that rule.
@@ Line 6: / Line 5: @@
 ----
-When processing the TCP 3 way handshake (3whs), Suricata’s TCP stream engine will closely follow the setup of a TCP connection to make sure the rest of the session can be tracked and reassembled properly.  Re-transmissions of SYN/ACKs are silently accepted, unless they are different somehow.  If the SEQ or ACK values are different they are considered wrong and events are set.  The stream events rules will match on this.
+When processing the TCP 3 way handshake (3whs), Suricata’s TCP stream engine will closely follow the setup of a TCP connection to make sure the rest of the session can be tracked and reassembled properly.
+Re-transmissions of SYN/ACKs are silently accepted, unless they are different somehow.  If the SEQ or ACK values are different they are considered wrong and events are set.  The stream events rules will match on this.
 In some cases where not the initial SYN/ACK was used by the client, but instead a later one.  Suricata however, had accepted the initial SYN/ACK.  The result is that every packet from that point will be rejected by the stream engine.