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.
Sometimes a single flow pcap would log 2 flows. It turns out FlowWorkToDoCleanup
ran before all the packet threads had processed their "wire" packets. It then
removed a flow that a wire packet would still have needed, leading to the worker
thread creating a new flow for it.
This could happen due to the logic in TmThreadDisableReceiveThreads which calls
TmThreadDrainPacketThreads to made sure it only returns when all autofp-workers
have processed all the packets the autofp-capture thread fed to them.
However, the way it checked this is by checking the size of the autofp-worker's
input queue. If 0, it assumes it is done.
What this missed, is that a worker thread could have just taken the last packet
from the input queue, but it is not yet done processing it. If then the
FlowWorkToDoCleanup is ran as well, it would race the worker thread to the flow
handling logic. When it won, the flow was evicted and the packet thread
created a new flow.
This patch improves the shutdown logic to force the worker threads to
enter a "flow loop" (THV_FLOW_LOOP) state before moving on to the
FlowWorkToDoCleanup step. This makes sure that any in progress packets
in the worker threads have been processed.
Bug: #7681.
Use checkudata, instead of testudata which won't return in case of
NULL, but raise an error in the Lua script.
Fixes:
** CID 1646748: Null pointer dereferences (NULL_RETURNS)
/src/util-lua-flowvarlib.c: 89 in LuaFlowvarValue()
Ticket: 7667
And prefix SCDetectBufferSetActiveList to be exported
Allows less use of suricata crate in plugin as we get the functions
prototypes from suricata_sys and they are more correct.
New Lua lib, "suricata.flowvar" for working with flowvars from Lua.
Replaces functions:
- SCFlowvarGet (and ScFlowvarGet)
- SCFlowvarSet (and SCFlowvarSet)
Of note, the DetectLuaData has been made available to the init and
thread_init methods, instead of just the match. This is due to an
issue that if a flow variable is not registered in init, it will not
be logged, registering in thread_init is too late.
Ticket: #7486
Issue: 7504
Add implementation of the ftp.dynamic_port rule keyword. The
implementation uses the U16 integer matching/parsing and thus supports
the comparison operations such as <, >, <=, >=, !, !=, and range (-).
Jason Ish
Victor Julien
dependabot[bot]
Philippe Antoine
Jeff Lucovsky