CID: 1645545
PatternDatabaseGetCached frees cd on success
So, we should NULL it, so that in case PatternDatabaseGetSize fails
and we goto error, we do not free cd again.
Issue: 3436
Remove duplicate register of the rotation flag. Eventually, this will
cause corruption when the file context has been freed and the rotation
flag is deregistered.
email.received matches on MIME EMAIL Received
This keyword maps to the EVE field email.received[]
It is a sticky buffer
Supports multiple buffer matching
Supports prefiltering
Ticket: #7599
For firewall mode, set the pseudo table in the rule and use this
in alert queue ordering, so that rule actions are applied in the
expected order:
packet:filter -> packet:td -> app:filter -> app:td
This makes sure that a packet:td drop is applied before a app:filter
accept.
If for the same a packet a drop rule and a pass rule would match,
the applying of actions could be contradictionary:
- the drop would be applied to the packet
- the pass rule would also be considered, not overriding the drop,
but still setting the flow pass flag.
This would lead to the packet being dropped, but the rest of the
flow getting passed, including retransmissions of the dropped
packet.
This patch only sets drop/pass actions if no conflicting action
has been set on the packet before. It respects the action-order.
Bug: #7653.
email.url matches on URLs extracted from an email
This keyword maps to the EVE field email.url[]
Supports multiple buffer matching
Supports prefiltering
Ticket: #7597
** CID 1646448: Null pointer dereferences (NULL_RETURNS)
/src/detect-engine-prefilter.c: 944 in SetupNonPrefilter()
________________________________________________________________________________________________________
*** CID 1646448: Null pointer dereferences (NULL_RETURNS)
/src/detect-engine-prefilter.c: 944 in SetupNonPrefilter()
938 const DetectBufferType *buf = DetectEngineBufferTypeGetById(de_ctx, list_id);
939 /* for now, exclude app-layer-events, as they are not tied to a specific
940 * progress value like other keywords. */
941 SCLogDebug("list_id %d buf %p", list_id, buf);
942 if (list_id == app_events_list_id)
943 continue;
>>> CID 1646448: Null pointer dereferences (NULL_RETURNS)
>>> Dereferencing "buf", which is known to be "NULL".
944 if (buf->packet) {
945 SCLogDebug("packet buf");
946 /* packet is handled below */
947 pkt_non_pf = true;
948 } else if (buf->frame) {
949 for (DetectEngineFrameInspectionEngine *f = de_ctx->frame_inspect_engines;
Use the Rust logic to parse FTP response lines with the goal to support
multi-buffer matches better.
A side effect is that the completion codes are no longer strings; the
schema update reflects this.
Issue: 4082
This module uses the sawp-pop3 crate to parse POP3 requests and responses
Features:
- eve logging
- events for parsable but non-RFC-compliant messages
Ticket: 3243
Config:
Firewall rules are like normal rule, with some key differences.
They are loaded separate, and first, from:
```yaml
firewall-rule-path: /etc/suricata/firewall/
firewall-rule-files:
- fw.rules
```
Can also be loaded with --firewall-rules-exclusive: Mostly for QA purposes.
Allow -S with --firewall-rules-exclusive, so that firewall and threat detection
rules can be tested together.
Rules:
Differences with regular "threat detection" rules:
1. these rules are evaluated before threat detection rules
2. these rules are evaluated in the order as they appear in the rule file
3. currently only rules specifying an explicit hook at supported
a. as a consequence, no rules will be treated as (like) IP-only, PD-only or
DE-only
Require explicit action scope for firewall rules. Default policy is
drop for the firewall tables.
Actions:
New action "accept" is added to allow traffic in the filter tables.
New scope "accept:tx" is added to allow accepting a transaction.
Tables:
Rulesets are per table.
Table processing order: `packet:filter` -> `packet:td` -> `app:*:*` -> `app:td`.
Each of the tables has some unique properties:
`packet:filter`:
- default policy is `drop:packet`
- rules are process in order
- action scopes are explicit
- `drop` or `accept` is immediate
- `accept:hook` continues to `packet:td`
`packet:td`:
- default policy is `accept:hook`
- rules are ordered by IDS/IPS ordering logic
- action scopes are implicit
- actions are queued
- continues to `app:*:*` or `alert/action finalize`
`app:*:*`:
- default policy is `drop:flow`
- rules are process in order
- action scopes are explicit
- `drop` is immediate
- `accept` is conditional on possible `drop` from `packet:td`
- `accept:hook` continues to `app:td`, `accept:packet` or `accept:flow`
continues to `alert/action finalize`
`app:td`:
- default policy is `accept:hook`
- rules are ordered by IDS/IPS ordering logic
- action scopes are implicit
- actions are queued
- continues to `alert/action finalize`
Implementation:
During sigorder, split into packet:filter, app:*:* and general td.
Allow fw rules to work when in pass:flow mode. When firewall mode is enabled,
`pass:flow` will not skip the detection engine anymore, but instead
process the firewall rules and then apply the pass before inspecting threat
detect rules.
New facility to allow a user to specify where to hook a rule
into the engine. This patch adds this for packets, adding two
hooks:
- `all`: to let a rule be evaluated by all rules
- `flow_start`: to have a rule be evaluated only for the first
packet in both directions
Implemented by adding a hook flags field in the packet.
Generic:
<app_proto>:request_started and <app_proto>:response_started
<app_proto>:request_complete and <app_proto>:response_complete
Per protocol, it uses the registered progress (state) values. E.g.
tls:client_hello_done
A rule ruleset could be:
pass tls:client_hello_done any any -> any any (tls.sni; content:"www.google.com"; sid:21; alert;)
drop tls:client_hello_done any any -> any any (sid:22;)
The pass rule is evaluated when the client hello is parsed, and if it
doesn't match the drop rule will be evaluated.
Registers each generic lists as "<alproto>:<progress state>:generic"
(e.g. "tls:client_hello_done:generic").
Ticket: #7485.
Use `request_started` for HTP_REQUEST_NOT_STARTED as when data is
received, the request parsing has started. The request line isn't
complete yet.
Similar for `response_started`.