Docs were claiming greater than, less than, etc. support even though this was never supported.
Fixes: 51be8f0238 ("doc/dcerpc: add proto keywords")
Ticket: #8330.
(cherry picked from commit 2480f8c038)
Redmine ticket: #8261
According to [1], the within pointer (if combined with distance)
includes the distance pointer, which is not clearly visible in the
graphic.
Fixed this in a new graphic by some GIMP arts.
PS: Special thanks to one of our team members Annika C. for initially
spotting this!
[1] https://forum.suricata.io/t/is-within-affected-by-distance/1688
(cherry picked from commit 69eb567dea)
16384 is used as the max, but a configuration parameter has been
provided. The reason for setting an upper bound is that bit flags can
create a memory amplification as we parse them into individual data
structures.
Ticket: #8181
(cherry picked from commit 3a32bb5743)
Lower the number of unreplied requests from 500 to 32 to consider a
flood. At the very least this is an anomaly given the DNP3 spec mentions
that DNP3 should only have one outstanding request at a time, with an
exception for unsolicited responses, so in practice no more than 2
should be seen.
Additionally make this value configurable by introducing the max-tx
parameter.
Ticket: #8181
(cherry picked from commit a16f087b93)
Ticket: 3220
DetectSslVersionMatch did not handle properly negation.
It could never match on a signatrue with ssl_version: !tls1.3
That is because, if we had such a signature and network traffic
with tls1.1, we were looking into DetectSslVersionData field
for tls1.1, which was not set, instead of looking at field
for tls1.3 which was set with negated flag.
Previous DetectSslVersionData was holding redundant information.
It did not need to have it for each ssl version, but just globally.
Also, it did not need to hold the version as a value in the array,
as it was redundant with the index of the array.
(cherry picked from commit c93e69830a)
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