Add flushing logic driven off of the file contexts. This is a simpler
solution that removes the need for logger registration changes.
Overview:
Use the heartbeat-driven thread to periodically flush all registered EVE
contexts via a global flush list.
The global flush list is a mutex-protected TAILQ of LogFileFlushEntry
nodes; each node points to a LogFileCtx. Mutex = log_file_flush_mutex
Periodic flushing performed by a thread according to the
heartbeat.output-flush-interval [1,60]. LogFileFlushAll() is invoked to
initiate flushing of registered LogFileCtx structs; each struct's
fp_mutex is obtained while the flush occurs to synchronize with
LogFileWrite activity.
Interacts with file-rotation via the fp_mutex.
Deadlock prevention: the log_file_flush_mutex must be obtained before
the fp_mutex.
Issue: 8286
Ticket: 8333
Allows to pass on pseudo packets
So, that a ruleset like
pass ssh any any -> any any (geoip:any,US,IN; sid: 1;)
drop ip any any -> any any (flow:established, to_server; sid:2;)
Does not lead to a drop on the pseudo-packet when we flush
because ssh traffic gets encrypted
Simplify statements where there's a conditional statement followed by
return true or return false.
Instead of
if (conditional)
return true;
else
return false;
Use:
return conditional
In some timezones, LogCustomFormatTest01 was failing as we were
specifying the wrong setting for is_dst. Instead set it to -1 so mktime
can make the decision based on the environment. Appears to fix this test
for "Brazil/East" in the summer.
Add GitHub CI tests to test this specific test with a few different
timezones.
Ticket: 8375
logger already read this variable but it was never set, and
the rust compiler did not warn about this
Allows to log the interface uuid when ctx_id > 0
Wireshark filter for related pcaps
dcerpc.cn_ctx_id > 0 && dcerpc.pkt_type == 0
And consistently use the CARGO_ENV for all cargo calls.
This allows a user to point to rust binaries that are not on their
path just during ./configure, for example:
PATH=/usr/lib/rust-1.89/bin:$PATH ./configure ...
The full path to rustc and rustdoc will now be used, as discovered in
the PATH without the user have to carry the path over to the "make"
command. This was already done for cargo.
Related to ticket: #8381
Update the Ubuntu/Debian minimal recommended build to use the
pre-built dist archive instead of building from git, as that is the
type of build this documentation targets.
Also use the ubuntu:22.04 container. The GitHub provided Ubuntu 22.04
VM appears to contain some new additions like a newer Rust that is not
found on a typical Ubuntu 22.04 installation.
When during raw reassembly it is detected that last ack is moved beyond
the progress and also beyond the data retrieved, update progress to the
last ack value.
Bug: #8272.
Ticket: 8289
If stream.reassembly.depth is unlimited,
an attacker controlling the 2 sides of a communication going through Suricata
can send a transition with an infinite number of headers, until suricata OOMs
Solution is to offer a configuration option to bound the number
of HTTP2 frames we store in a HTTP2 transaction, and produce an
anomaly if this bound is crossed
Ticket: 8292
When we have buffered something in ctx.decoded_line,
we already looked for '\n' in it, so we do not need to run it again
Otherwise, callers that supply mime_smtp_find_url_strings with
a few bytes at a time without "\n", have a quadratic
complexity
When libraries add their own -march flags to CFLAGS, let them.
But if -march=native should be added (it should by default),
add it as the last -march flag to "win".
This ensures, that even if a library brings their own minimal -march,
it will not downgrade the instruction set for the whole Suricata.
This happened with DPDK which, when enabled, downgraded the instruction
set to -march=corei7 or -march=haswell.
When building packages with --disable-gccmarch-native, the instruction set
is auto-upgraded to instruction set requested by libraries.
E.g. from RPM builds: `CFLAGS="-march=x86_64" ./configure --enable-dpdk`
upgrades instruction set to DPDK's corei7 architecture.
Ticket: 8169
When mempool size was configured really low (<32), Suricata exhausted
the mempool with the rx_burst call, which led to undefined behavior.
The current fix ensures the burst size is at most the size of the mempool,
if the mempool is smaller than BURST_SIZE macro.
Based on review it seems p->proto should always be set to the same
value as what `PacketGetIPProto` returns. Add a check to validate
in a decoder that the fuzzer executes.