To accompany the Exception Policy stats, also add information about any
Exception Policy triggered and for which target to the flow log event.
Task #6215
(cherry picked from commit 08e928988f)
The stats for exception policies are only logged/ present when any of
the exception policies are enabled (which means any value other than
"auto" or "ignore" in IDS mode, or "ignore" in IPS mode).
This wasn't clearly stated in the docs.
(cherry picked from commit a9b2a62ee4)
Some exception policies can only be applied to entire flows or
individual packets, for some exception scenarios. Make this easier to
read, in the documentation.
Related to
Task #5816
(cherry picked from commit 94b111283d)
We will register stats counters for all policies, even though for now
Suri only uses one possible configuration policy at a time. The idea is
that this could change in the near future, so we want to have this
ready.
Task #5816
(cherry picked from commit 657419b53e)
A flow with IPv4 IP in IP traffic won't handle this tunneling case
properly.
This leads to potential malicious traffic not triggering alerts, as well
as other inaccuracies in the logs.
Bug #7725
(cherry-picked from commit e3e24cfb3d)
Add section label and doc reference, add another term to Common terms
section.
Tried to also improve readability for the Midstream behavior tables:
- Highlight key-words when differences are only in `do` vs `no`.
- Change order of sentences in certain descriptions, to align with the
steps those happen for the engine.
(cherry picked from commit 95560f0966)
Following the discussion on #7396, use those symbols for to keep the
standard.
Remove the repeting `Exception Policies` section header, too.
Related to
Task #7396
(cherry picked from commit e5c1e5f792)
The terms 'inspection' and 'detection' were being used to signify
different engine actions in this document, while throughout the
documentation and code they're many times interchangeable.
Replace 'inspection' with 'parsing' or even 'decoding and parsing' as
more appropriate.
Add a small glossary to clarify what we mean with those terms.
(cherry picked from commit 0256ce51eb)
To avoid possible upgrade issues, allow higher defaults than in the
master branch. Add some upgrade guidance and a note that defaults will
probably be further reduced.
Ticket: 7613
Avoids potential large per-thread memory allocation. A buffer with the
size of the largest decode_base64 buffer size setting would be allocated
per thread. As this was a u32, it could mean a per-thread 4GiB memory
allocation.
64KiB was already the built-in default for cases where bytes size wasn't
specified.
(cherry picked from commit 32d0bd2bbb)
Describe the change of behavior between the stream.checksum-validation
setting and checksum-based rule keywords.
(cherry picked from commit cfbf8fda94)
Uncomment in default config. This will make the policy "inline",
which is the same behavior as prior to the urgent policy support.
Add line to docs that this is an experimental feature.
Ticket: 7199
Uses a config parameter detect.guess-applayer-tx to enable
this behavior (off by default)
This feature is requested for use cases with signatures not
using app-layer keywords but still targetting application
layer transactions, such as pass/drop rule combination,
or lua usage.
This overrides the previous behavior of checking if the signature
has a content match, by checking if there is only one live
transaction, in addition to the config parameter being set.
(cherry picked from commit f2c3776314)
Similar keywords use `isnotset`, while `flowint` only accepted `notset`
Opted to change the code, not only the regex, to keep the underlying
code also following the same patterns.
Task #7426
(cherry picked from commit 6e4a501e7c)
The new behavior in 8, and backported is to treat unknown requirements
as unsatisfied requirements.
For 7.0.8, add a configuration option, "ignore-unknown-requirements"
to completely ignore unknown requirements, effectively treating them
as available.
Ticket: #7434
For example, "requires: foo bar" is an unknown requirement, however
its not tracked, nor an error as it follows the syntax. Instead,
record these unknown keywords, and fail the requirements check if any
are present.
A future version of Suricata may have new requires keywords, for
example a check for keywords.
Ticket: #7418
(cherry picked from commit 820a3e51b7)
Ticket: 7191
So as to avoid quadratic complexity in libhtp.
Make the limit configurable from suricata.yaml,
and have an event when network traffic goes over the limit.
(cherry picked from commit bb714c9178)
This ensures that the correct spelling of the `security_result` EVE
field for RFB (as opposed to `security-result`) is also reflected in the
documentation.
Ticket: #7210
(cherry picked from commit cb14e44780)
This commit allows ja4 hashes to be logged iff enabled in the tls/quic
section of the outputs.
With the default setting ("off"), ja4 hashes will only be logged in
alerts when the signatures uses the ja4.hash keyword.
When enabled, ja4 hashes will be inclued in quic and tls logs.
- tls:
ja4: on
- quic:
ja4: on
Issue: 7010
By default, when Sphinx generates the man pages, the current date will
be embedded in them. This can be set to a specific date with the
"today" variable. Typically the date embedded in manpages in the
release date.
To achieve this, attempt to use the environment variable, RELEASE_DATE
to set the "today" variable, reverting back to the empty string if not
set. It is up to our build system to properly set this date.
Ticket: #6911
(cherry picked from commit 51bf1c3510)
When the packet load is low, Suricata can run in interrupt
mode. This more resembles the classic approach of processing
packets - CPU cores run low and only fetch packets
on interrupt.
Ticket: #6696
(cherry picked from commit 2a2898053c)
Our code handles Uint ranges as exclusive, but for bsize, our
documentation stated that they're inclusive.
Cf. from uint.rs:
DetectUintMode::DetectUintModeRange => {
if val > x.arg1 && val < x.arg2 {
return true;
}
}
Task #6708
(cherry picked from commit 244a35d539)