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.
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.
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.
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.
Clean up host mode tracking, which is used by reject to control how
rejects are sent. Before this patch there were 2 modes: sniffer only
and router. This patch introduces a bridge mode that is automatically
set by the bridge modes. In bridge mode the `Packet::livedev` is used.
Ticket: #8390.
Ticket: 8336
At the end of a TLS handshake, in IDS mode, the client acks,
and we parse the server hello and use tls.encryption-handling
to know what to do next (for example bypass)
Everything is parsed, but we have not run detection yet on neither
side.
So, in IDS mode, we need to first flush the client side, as the
comment on the function already stated.
Ticket: 8336
When a packet has flag PKT_PSEUDO_DETECTLOG_FLUSH, we do not
expect to rerun detection on the same tx and direction again
So, do not set mpm_in_progress whose purpose is to not store
the state as we will run again.
Allows transactional bidirectional signatures to work on
thse log+flush pair of packets
When an alert is generated from firewall context, add an engine value of
"fw", otherwise "td" (for threat detect).
The engine field is only added when firewall mode is enabled.
Ticket: #8456
Ticket: 7929
Builds a vector of the reason code in a tx to do so,
except if we use the default "any", where we do not append
to the vector, but just run detection while iterating
The first version of the event set done=true on state->curr_tx and
returned NULL when the limit hit. curr_tx is usually the active
command just received — marking it done mid-request throws off
response matching, and subsequent commands in the flow stop getting
logged.
SMB behavior is mirrored here:
Walk the tx list, find the oldest tx that isn't done, mark
it done and tag it with the event, then fall through and
create the new tx so the flow parsing continues. One stale tx gets
reaped per overflow so memory stays bounded.
Issue: 8489
Other parsers (SMB, POP3, ENIP) already raise a too_many_transactions
event when a flow exceeds its per-flow transaction limit. FTP had
the limit wired up through app-layer.protocols.ftp.max-tx but just
dropped the excess transaction on the floor with a "FTP does not set
events yet..." TODO, so no event was raised when the limit was
reached.
Add the FtpEventTooManyTransactions variant, a stock rule at
sid 2232002, and raise the event from FTPTransactionCreate when the
live-tx count goes past ftp_config_maxtx.
Issue: 8489