Ticke: 8651
Uses it in place when we dereferenced the value straight away
after checking SCConfGet result but not its value
(cherry picked from commit 6bb271cee9)
to deal with the failure due to cbindgen updates and mismatches in
generated bindings.
detect-bytemath.c:61: error: "DETECT_BYTEMATH_ENDIAN_DEFAULT" redefined [-Werror]
61 | #define DETECT_BYTEMATH_ENDIAN_DEFAULT (uint8_t) BigEndian
|
In file included from rust.h:34,
from detect-bytemath.c:32:
./../rust/gen/rust-bindings.h:5071: note: this is the location of the previous definition
5071 | #define DETECT_BYTEMATH_ENDIAN_DEFAULT BigEndian
|
(cherry picked from commit 0345b91ddd)
LTE support depended on registered hook names, but did not support the
built-in names. This commit adds the support.
Ticket: #8645.
(cherry picked from commit d154484cc6)
For rules that specify an explicit app-layer hook,
e.g. http1:request_headers, don't register inspect engines for
other protocols like HTTP/2. These have their own progress tracking,
so should be excluded from these rules.
(cherry picked from commit d64954a873)
Break out the 3 options: match, partial match, no match for firewall
into separate functions.
Additionally, handle the re-match case for matches on a hook where the
progress value didn't yet progress further. In this case the continue
inspection logic revisits the rule and the accept needs to be
re-applied.
(cherry picked from commit 68885e75e1)
For the last for progress case we can just break on a firewall drop.
For the accept:flow and accept:tx cases the next sig (if any) will check
the flow/tx flag and manage flow control from there.
(cherry picked from commit 9c76480ac3)
Simplify pre-check logic. Pre-check takes care of enforcing
FLOW_ACTION_ACCEPT, APP_LAYER_TX_ACCEPT and default policy enforcement
before the current rule's hook. This should be done in firewall mode for
each rule regardless whether it is a firewall or TD rule.
No need to track verdict state anymore.
(cherry picked from commit bb7aff36a8)
If default policy is invoked because of missing rules for next hooks,
make sure to inject an alert before the next hook policies might do so.
(cherry picked from commit 247c6a2333)
In TD mode the drop action also includes alert.
In firewall mode it should not to stay in line with accept.
Ticket: #8601.
(cherry picked from commit 57b16c964e)
More clearly define the relationship between PacketAlerts for firewall
and threat detection events.
Also no longer count firewall_discarded if drop rule came before a
another rule, causing the later rule to not be evaluated/alerted.
When packet:filter and app:filter alert appear in a single alert queue,
handle accept:hook by keeping track of the detect_table.
(cherry picked from commit 485f5243d5)
Support `alert` as a secondary action in packet firewall policies.
To implement this a Signature object is created per policy that uses
alert, and this is stored in a array table. When the policy is applied
the signature is looked up and used in the PacketAlert.
Ticket: #8566.
(cherry picked from commit dc4c22e906)
Support `alert` as a secondary action in app-layer firewall policies.
To implement this a Signature object is created per policy that uses
alert, and this is stored in a hash table. When the policy is applied
the signature is looked up and used in the PacketAlert.
Ticket: #8566.
(cherry picked from commit 2d4f1968b8)
Allow a single rule to accept a hook and the hooks prior to it.
Example:
accept:flow tls:<client_hello_done ... \
tls.sni; content:"suricata.io"; endswith;
This will evaluate the SNI at the client_hello_done hook, but will
act as if there is a `accept:hook tls:client_in_progress ...` as well.
Implementation is currently specific to this `<` operator. During
parsing the sig gets flagged for this case. During setup this has 3 main
effects:
1. prefilter is disabled as we need to eval this right at the first
state (0)
2. for state 0 a non-PF "prefilter" engine is setup to make sure the
rule is flagged for evaluation
3. In the Signature::app_inspect list a dummy inspect engine is
registered per state before Signature::app_progress_hook
The matching logic is building on the stateful rule handling. The
stateful rule handling can now tell the inspection loop that a partial
match occured. For this rule type the partial match will act as a match
with action accept:hook.
Next app updates will then use the continue detection logic to continue
the stateful match. When that fully matches, the final actions are
applied, like accept:flow or accept:tx.
Ticket: #8472.
(cherry picked from commit 651afba883)
In last_for_progress handling set accept only on packet if it was also
triggered on the last tx.
If there are more transactions, the accept can be set later (if policy
allows).
(cherry picked from commit f6dc772677)
Philippe Antoine
Andreas Dolp
Victor Julien
Shivani Bhardwaj
dependabot[bot]
Juliana Fajardini