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)
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)
Victor Julien
Juliana Fajardini