This avoids long lasting inactive flows because in the most likely
case the RST did in fact end the connection. However Suricata may
still consider it to be "established".
The flow manager scans the hash table in chunks based on the flow timeout
settings. In the default config this will lead to a full hash pass every
240 seconds. Under pressure, this will lead to a large amount of memory
still in use by flows waiting to be evicted, or evicted flows waiting to
be freed.
This patch implements a new adaptive logic to the timing and amount of
work that is done by the flow manager. It takes the memcap budgets and
calculates the proportion of the memcap budgets in use. It takes the max
in-use percentage, and adapts the flow manager behavior based on that.
The memcaps considered are:
flow, stream, stream-reassembly and app-layer-http
The percentage in use, is inversely applies to the time the flow manager
takes for a full hash pass. In addition, it is also applied to the chunk
size and the sleep time.
Example: tcp.reassembly_memuse is at 90% of the memcap and normal flow
hash pass is 240s. Hash pass time will be:
240 * (100 - 90) / 100 = 24s
Chunk size and sleep time will automatically be updated for this.
Adds various counters.
Bug: #4650.
Bug: #4808.
For connections that use TCP timestamps for which the first SYN packet
does not reach the server, any replies to retransmitted SYNs will be
tropped.
This is happening in StateSynSentValidateTimestamp, where the timestamp
value in a SYN-ACK packet must match the one from the SYN packet.
However, since the server never received the first SYN packet, it will
respond with an updated timestamp from any of the following SYN packets.
The timestamp value inside suricata is not being updated at any time
which should happen. This patch fixes that problem.
Bug: #4376.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
When trying to propegate the depth/offset, within/distance chains
a logic error would set too a restrictive depth on a pattern that
followed more than one "unchained" patterns.
Bug: #5162.
Use a macro to validate the ranges for overflows. This removes
the clutter of all the checks and warnings, and also no longer
puts the state machine in an undefined state when hitting such
a condition.
So 'alert dcerpc' also matches if the DCERPC is over SMB.
Explicitly refuse smb keywords for the 'dcerpc' app proto setting:
`alert dceprc ... smb.share; ...` is rejected.
Remove a now useless special case in the stateless rule processing
matching for dcerpc/smb.
Bug: #5208.
Otherwise, if we log a first app_layer_event, then reset
with AppLayerDecoderEventsResetEvents for a new packet,
then get another event, it does not get logged
Ticket: #5391
Bug introduced by https://github.com/OISF/suricata/pull/7111
Nom's count begins by allocating a Vector, which leads to arbitrary
allocation due to flavors_cnt coming from network, and not even
being checked against i.len()
Ticket: #5237
Due to the TIMEVAL_DIFF_SEC calculating the delta into an unsigned
integer, it would underflow to a high positive value leading to
and incorrect result if the packet timestamp was below the timestamp
for the threshold entry. In normal conditions this shouldn't happen,
but in offline mode each thread has its own concept of time which
might differ significantly based on the pcap. In this case the
overflow would be very common.
Changing it to a signed value calculation triggered fuzz undefined
behavior if the packet timeval was very high, so this patch takes a
new approach where it no longer calculates a diff but sets up the
"seconds" value we compare against as a timeval itself, and uses
that to compare.
Fixes: 9fafc1031c ("time: Add TIMEVAL_EARLIER and TIMEVAL_DIFF_SEC macros.")
Fixes: 82dc61f4c3 ("detect/threshold: Refactor threshold calculation to handle by_rule and by_both.")
Uses add `timeradd` specific version where available.
Bug: #5386.
In the case of midstream SYN/ACK pickup, we reverse the flow based on
the SYN/ACK. If we then later get traffic that appears to be in the
reverse direction based on the app-layer, we would reverse it again.
This isn't correct. When we have the SYN/ACK we know the flow's real
direction.
AF-Packet bypass function in some situations allocates EBPF bypass data
for an already bypassed flow and assigns it to the flow without any checks
Issue: #5368