Ticket: 7665
Instead of each keyword calling DetectSetupDirection, use a
new flag SIGMATCH_SUPPORT_DIR so that DetectSetupDirection gets
called, before parsing the rest of the keyword.
Allows to support filesize keyword in transactional signatures
src/util-debug.c:1562:5: warning: Either the condition 'sc_lid!=NULL' is redundant or there is possible null pointer dereference: sc_lid. [nullPointerRedundantCheck]
sc_lid->global_log_level = MAX(sc_lid->global_log_level, max_level);
^
src/util-debug.c:1569:16: note: Assuming that condition 'sc_lid!=NULL' is not redundant
if (sc_lid != NULL)
^
src/util-debug.c:1562:5: note: Null pointer dereference
sc_lid->global_log_level = MAX(sc_lid->global_log_level, max_level);
^
For "stateful rules", don't drop packets after the initial match as long
as the tx state doesn't change.
An example of how this could happen was:
accept:hook ssh:request_started any any -> any any (alert; sid:2000;)
accept:hook ssh:request_banner_wait_eol any any -> any any (alert; sid:2001;)
accept:hook ssh:request_banner_done any any -> any any ( \
ssh.software; content:"OpenSSH_8.2p1"; alert; sid:2002;)
As the ssh session reached the request_banner_done state, it would
remain in this state. So additional packets would again review the rules
for this state. The rule 2002 is stored in the tx state as fully
matched, and would be skipped for the additional packets. This meant
that the `accept:hook` action was not applied and the default drop
policy was triggered.
This is addressed by updating the stateful logic:
If an accept rule has the DE_STATE_FLAG_FULL_INSPECT flag set, and the
tx progress is not progressed beyond the rule, apply the rule accept
acction.
This callback will be called when alert action has been changed due to a
rate filter. The user can then reset or customize the action in their
callback per their own logic.
As the callback is added to the current detection engine, make sure its
copied to the new detection engine on reload.
Ticket: #7673
As #define's like this can't be logically grouped into an enum, try
Doxygen documentation groups, which create a group just of these flag
values and documents them together on a page.
Create a new list of headers for headers that should never be
installed, such as private headers that should only be available
within the Suricata project.
For now, just the util-device-private.h belongs to this set.
util-device.h exposes some details that are particularly problematic
for C++, even when wrapped in 'extern "C"'. To address this, break the
header into public and private parts. The public part exposes
LiveDevice as an opaque data structure, while the private header has
the actual definition.
The idea is that only Suricata C source files should include the
private header, it should not be re-included in any other header
file. And this is the header library users should use, however we
don't enforce it with tecnical means, a library user could still
include the private header, but the clue there is in the name.
When static linking we have a circular dependency between
libsuricata_rust, and libsuricata_c, so we have to list each twice.
An alternative is to use "-Wl,--start-group", but that isn't portable
outside the GNU toolchain.
Philippe Antoine
Jason Ish
Victor Julien
dependabot[bot]