Register known eve output file types during eve registration. This
removes the function to load internal plugins as they are not really
plugins and moves the registration of them into their respective
subsystem.
With internal code using the plugin API to register an Eve
filetype, the name plugin no longer makes sense. This is
part of my idea that internal plugins aren't plugins at all,
and the plugin interface should be an abstraction over
internal APIs.
Along that idea, this is the start of a refactor of the plugin
file types to be internal, where the plugin API is just an external
interface to that internal API.
This commit adds an interface for loading plugins that are internal to
Suricata. These are always loaded and are in a modified format from
external pliguns.
This value is used as a sentinel to determine if the configured
eve.json filetype was located.
First, the built-in and internal output plugins are checked. If the
sentinel value remains set, the external plugins are searched for the
filetype.
The callback for FileInfo was returning the wrong value, resulting
in loss of some tuple values for one calling SCFileInfo in a script.
The documentation comment wasn't mentioning the sha items that are
pushed.
If the default port is set via the Rust registration table but the probe
fns to server and to client are set to None, the port is never used.
Setting port in such a case is useless so error out.
Allow progress values in the range 0-47 so we have 48 bits to track
prefilter engines.
Mark bits 48-62 as reserved explicitly.
Add debug validation checks to make sure the reserved space isn't used.
Fix FNs in case of too many prefilter engines. A transaction was tracking
which engines have run using a u64 bit array. The engines 'local_id' was
used to set and check this bit. However the bit checking code didn't
handle int types correctly, leading to an incorrect left shift result of
a u32 to a u64 bit value.
This commit addresses that by fixing the int handling, but also by
changing how the engines are tracked.
To avoid wasting prefilter engine tracking bit space, track what
ran by the progress they are registered at, instead of the individual
engine id's. While we can have many engines, the protocols use far
fewer unique progress values. So instead of tracking for dozens of
prefilter id's, we track for the handful of progress values.
To allow for this the engine array is sorted by tx_min_progress, then
app_proto and finally local_id. A new field is added to "know" when
the last relevant engine for a progress value is reached, so that we
can set the prefilter bit then.
A consquence is that the progress values have a ceiling now that
needs to fit in a 64 bit bitarray. The values used by parsers currently
does not exceed 5, so that seems to be ok.
Bug: #4685.
SigTestDropFlow04 was incorrectly expecting an alert in the packet
following a "drop" packet. The first drop is applied to the flow, so
it should lead to the 2nd packet being dropped before inspection is
run.
Clean up the test as well.
Unify handling of signature matches between various rule types and
between noalert and regular rules.
"noalert" sigs are added to the alert queue initially, but removed
from it after handling their actions. This way all actions are applied
from a single place.
Make sure flow drop and pass are mutually exclusive.
The above addresses issue with pass and drops not getting applied
correctly in various cases.
Bug: #4663
Bug: #4670
Simplify and clean up header buffer management. The code was designed
to track buffers for several transactions in parallel, from when the
detection engine wasn't aware of transactions.
For http.start and http.header_names use generic mpm and inspect
functions.