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
Remove the authors field as it is deprecated.
Update the repository page to the Suricata repository.
Remove the homepage, it can be found via the reposistory page.
As the "suricata" crate depends on htp, we need to publish htp to
crates.io first, however "htp" name is already taken. So rename "htp" to
"suricata-htp".
On a normal project where the Cargo.lock is checked in, it would be
normal to see an updated Cargo.lock in git status and the like. As we
use autoconf to generate this file, we should just copy it back to the
input file so we get the same convenience of seeing when it is
updated, which usually means it needs to be checked in.
However, to satisfy "make distcheck", only copy it if the input
template exists, if the input template does not exist we are in an out
of tree build.
** 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;
ldap.responses.attribute_type matches on LDAP attribute type/description
This keyword maps the eve field ldap.responses[].search_result_entry.attributes[].type
It is a sticky buffer
Supports multiple buffer matching
Supports prefiltering
Ticket: #7533
ldap.request.attribute_type matches on LDAP attribute type/description
This keyword maps the following eve fields:
ldap.request.search_request.attributes[]
ldap.request.modify_request.changes[].modification.attribute_type
ldap.request.add_request.attributes[].name
ldap.request.compare_request.attribute_value_assertion.description
It is a sticky buffer
Supports multiple buffer matching
Supports prefiltering
Ticket: #7533
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
Move handling of FTP responses to Rust to improve support for FTP
keyword matching. Parsing the response line when encountered
simplifies multi-buffer matching and metadata output.
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.
James
Victor Julien
Alice Akaki
Jason Ish
Shivani Bhardwaj
Jeff Lucovsky
Juliana Fajardini
Alex Savage
Eric Leblond
Philippe Antoine