Feature #796
closed
stream: deal with multiple different SYN/ACK's better
Added by Victor Julien over 12 years ago.
Updated over 12 years ago.
Description
Currently we accept the first SYN/ACK and reject (+set event on) new ones that are different. Ran into some streams where the 2nd is accepted.
As there is no way to distinguish between them we'll have to wait for the client to ACK one. For this we'll use a simple list in the TCP ssn. Also a limit will be used to make sure we won't get vulnerable to a resource starvation attack.
Code will only be used in slow path.
What do you mean "slow path"?
What would be the limit for a resource starvation attack - a time based limit?
In the case that you are referring to, the client received 2 SYN/ACKs and choose to accept the second one - correct?
Peter Manev wrote:
What do you mean "slow path"?
That we won't touch this code in the normal case (fast path), which would be the normal 3whs.
What would be the limit for a resource starvation attack - a time based limit?
No just absolute. Defaulting to 5 now. So more than 5 different SYN/ACKs in a single session will lead to rejected packets, stream event being set.
In the case that you are referring to, the client received 2 SYN/ACKs and choose to accept the second one - correct?
We can't be sure the client received both. We can only see which one it ACKs.
- Status changed from Assigned to Closed
- % Done changed from 0 to 100
Addressed by:
commit 4c6463f3784f533a07679589dab713096137a439
Author: Victor Julien <victor@inliniac.net>
Date: Sat Apr 6 20:54:25 2013 +0200
stream: handle extra different SYN/ACK
Until now, when processing the TCP 3 way handshake (3whs), retransmissions
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, this is wrong. If the client missed the SYN/ACK, the server
may send a different one with a different SEQ. This commit deals with this.
As it is impossible to predict which one the client will accept, each is
added to a list. Then on receiving the final ACK from the 3whs, the list
is checked and the state is updated according to the queued SYN/ACK.
-----------------------------------------------------------------------
Summary of changes:
rules/stream-events.rules | 4 +-
src/decode-events.h | 1 +
src/detect-engine-event.h | 1 +
src/stream-tcp-private.h | 21 ++-
src/stream-tcp.c | 568 +++++++++++++++++++++++++++++++++++++++++++--
src/stream-tcp.h | 1 +
suricata.yaml.in | 5 +-
7 files changed, 582 insertions(+), 19 deletions(-)
Also available in: Atom
PDF