To better control stats counters.
(cherry picked from commit 8a8574b149)
Cherry-pick note: moved PKT_DROP_REASON_EP_FLOW_DROP to the last
non fw stop to keep the non-fw values the same.
To track flow drops triggered by the firewall.
Add flow drop by firewall as drop reason.
As part of
Ticket #7699
(cherry picked from commit 312967f291)
Add a `firewall` stats counter aggregator for all firewall-related
stats.
De-overload "detect.alert_queue_overflow", by adding
"firewall.discarded_alerts" to account for discarded drops in
Firewall mode.
Add Debug statements for tracking corner cases where it can be
difficult to know where a drop is coming from.
Added counters:
- stats.firewall.blocked
- stats.firewall.accepted
- stats.firewall.rejected
- stats.firewall.drop_reason.default_app_policy
- stats.firewall.drop_reason.default_packet_policy
- stats.firewall.drop_reason.flow_drop
- stats.firewall.drop_reason.pre_flow_hook
- stats.firewall.drop_reason.pre_stream_hook
- stats.firewall.drop_reason.rules
- stats.firewall.discarded_alerts
Ticket #7699
(cherry picked from commit 5b488feef5)
Cherry-pick notes:
- moved counter to keep struct layout the same as much as possible.
- moved the FLOW_ACTION_BY_FIREWALL to aux_flags and renamed to
FLOW_AUX_ACTION_BY_FIREWALL
Flow::flags field ran out of space, and for ABI compatibility the move
to u64 like in main isn't possible. So add a `aux_flags` field in an
alignment hole to facilitate the coming flags.
For protocols using default 0-1 states, add support.
For others, print 'unknown' if no name is yet supported.
Ticket: #8514.
(cherry picked from commit b29226c7ea)
Allow configurable policies, including accept. For app-layer this
requires looping all available hooks to apply the policies.
Support configurable policies for packet-filter, pre-stream, pre-flow.
If there are no rules there is also no rule group (sgh). Make sure
the app hooks policies are correctly handled in this case by allowing
a NULL sgh to be handled as well.
For tx rule match actually apply drop directly. Previously this was
always handled by the default drop:flow policy.
Ticket: #7701.
(cherry picked from commit 7134592fea)
Cherry-pick note: moved the DetectEngineCtx member to the end of the
struct to keep the struct layout the same.
For firewall rules, allow multiple actions to be specified in a list
accept:flow,pass:flow,alert
accept:flow,alert
accept:flow,pass:flow
It is mandatory to make the first action the primary firewall policy
action: accept, drop, reject.
Ticket: #8480.
(cherry picked from commit e76728a536)
Previously a `accept:flow` action would act as both a firewall "accept" and
a threat detection "pass" for the rest of the flow.
This patch changes that. The `accept:flow` action now only accepts the
rest of the packets for the firewall ruleset, but does still continue
threat detection rule evaluation.
Ticket: #8444.
(cherry picked from commit eaacb41aaf)
For non-UDP (so TCP), don't allow `accept:packet` or `drop:packet` as
this makes the evaluation of other rule hooks unpredictable.
Ticket: #8497.
(cherry picked from commit 33b3793372)
If a ruleset would use `dns:request_complete` but not have a rule for
`dns:request_started`, the `request_started` hook default policy would
not get invoked.
Add a check to make sure it is invoked.
Ticket: #8495.
(cherry picked from commit 900ae89ed8)
Ticket: 8619
Do not wait to run inspection on the other side of transactions
as we do not run any tx detection on passing flows.
Avoids accumulating txs
(cherry picked from commit 2eede11195)
Ticket: 8537
Otherwise, it may cause a use-after-free, in case of reallocated
buffer and we used the buffer inspect which was freed.
(cherry picked from commit 6d437956e2)
Ticket: 8536
Otherwise, it may cause a use-after-free.
So, need to allocate the temporary vector, before calling
SCInspectionBufferCheckAndExpand
(cherry picked from commit 2b20a436e7)
Ticket: 8513
Suricata decides at 2 levels if a http2 flow is doing a compression
bomb.
There is a direct computation when one chunk of TCP data
is being parsed.
In this case, do not take the ratio into account, just use the size
of the decompressed data, so that if we get a big chunk of TCP data
like 1 MiB, and a not so high ratio of 200, we do not trigger
the debug assertion in util-file.c about 64MiB
The other case stays unchanged : when accumulating over the lifetile of
a flow with multiple txs, take into account the compression ratio,
so that a flow of many txs, having a super high (brotli) compression
ratio, ends up classified as a compression bomb.
(For example, having 100 txs each turning a 100 byte input into a 700 KiB
one)
(cherry picked from commit bf64b52b95)
Ticket: 8529
When Suricata handles a HTTP1 response body, it does so with a
file, and tries to get the filename from the Content-Disposition
header if any, then from the uri.
If it failed to find a file name, it tried again every time
there was new data from the response body, even if there was
no new data to find a file name in either the header nor the uri.
This causes a slowdown in the case the Content-Disposition header
is big.
Fix is to set the flag on the first call of the callback, to be
sure that we will parse the Content-Disposition header for a
filename header only once per http1 response.
(cherry picked from commit 9aaa6f7854)
Ticket: 8513
During decompression, fail early if we have a big decompression
ratio, and enough data.
Track this data also during a tx lifetime, and even a flow/state
lifetime, so that we set event and fail also if the compression
bomb is split over multiple packets
(cherry picked from commit 7bf48b02be)
Decoding the reassembled packet inside DefragInsertFrag while holding
the tracker mutex creates a deadlock situation if the reassembled packet
contains tunneled fragments: two threads could each hold one tracker
mutex and deadlock on the other. Move the decode in Defrag() after
DefragTrackerRelease() so no lock is held during decode (and possibly
re-entering the defrag system).
Make sure to fetch tracker->ip_hdr_offset after DefragInsertFrag since
it may be written during that call if the first fragment arrives last.
Issue: 8550
(cherry picked from commit 1dc629d978)
So that we can write a final zero without overflowing the array
and relying on padding to avoid further problems
Ticket: 8448
(cherry picked from commit 38d41e6fa6)
Ticket: 8526
As some C protocols accepted case-insensitive frame names,
a rule using the same frame twice with different cases,
ended up using 2 different buffers,
which ended up in triggering a buffer overflow
(cherry picked from commit c977b2f31b)
Ticket: 8510
Without this check, in case of a hash collision, and the other
fields are equal, we could end up consider adding an IPv6 packet
to a IPv4 tracker (or vice versa).
Doing so, we end up interpreting an IPv6 packet as an IPv4 one,
and we do not benefit from the bounds checks from ipv4/ipv6 decoder.
(cherry picked from commit 24527d662a)
Juliana Fajardini
Victor Julien
Philippe Antoine
Shivani Bhardwaj
Jeff Lucovsky
Jason Ish