Jason Ish [Mon, 5 Jun 2023 19:56:59 +0000 (13:56 -0600)]
doc/userguide: generate eve documentation
Add EVE documentation for QUIC and Pgsql to their respective sections of
the userguide.
Also add a complete EVE reference as an appendix.
Other protocols can be done, but its a manual process to document in the
schema, then add the glue to pull them into the documentation.
The documentation is generated during "make dist", or if it doesn't
exist, "conf.py" will attempt to generate the eve documentation for
building on Readthedocs.
Liam Wilson [Wed, 25 Sep 2024 21:31:31 +0000 (09:31 +1200)]
configure: clear cached header value
Unset ac_cv_header_hs_h before checking for header. This allows
hyperscan to be included in compilation when switching from a non-hs
build to a hs build.
Jason Ish [Thu, 26 Sep 2024 17:08:57 +0000 (11:08 -0600)]
threads: don't drop capabilities for packet threads
Remove the call to SCDropCaps for packet processing threads. This
logic in this function is required to setup packet processing even
when the thread is provided by a library user, in which case Suricata
should not be touching is capabilities.
As SCDropCaps is currently a no-op its clear this feature needs to
be (re)designed properly, taking into consideration library users as
well.
Related ticket: https://redmine.openinfosecfoundation.org/issues/2375
Ilya Bakhtin [Sat, 31 Aug 2024 11:44:25 +0000 (13:44 +0200)]
detect: pseudo-packets inherit inspect flags from parent packet
Instead of inheriting from flow, because encrypted protocols like TLS
and SSH may have just set the flow flags to indicate rest of stream is
encrypted and does not need to run stream inspection. But inspection
still needs to be run detection on this last flushing packet.
So as to avoid quadratic complexity in libhtp.
Make the limit configurable from suricata.yaml,
and have an event when network traffic goes over the limit.
Victor Julien [Fri, 20 Sep 2024 07:54:57 +0000 (09:54 +0200)]
stream: improve 3whs completed by ACK with data
If the ACK packet completing the 3whs is received, the stream engine will
transition to "established". However, the packet itself will not be tagged
as "established". This will only happen for the next packet after the 3whs,
so that `flow:established` only matches after the 3whs.
It is possible that the ACK packet completing the 3whs was lost. Since the
ACK packets themselves are not acknowledged, there will be no retransmission
of them. Instead, the next packet can have the expected ACK flag as well as
data.
This case was mishandled in a subtle way. The stream engine state transition
was done correctly, as well as the data handling and app-layer updates.
However, the packet itself was not tagged as "established", which meant
that `flow:established` would not yet match.
This patch detects this case and tags the packet as established if ACK
with data is received that completes the 3whs.
Noah Liu [Mon, 23 Sep 2024 03:07:47 +0000 (11:07 +0800)]
stream/reassembly: optimize GetBlock
Current GetBlock degrees the sbb search from rb tree to
line, which costs much cpu time, and could be replaced by
SBB_RB_FIND_INCLUSIVE. It reduces time complexity from
O(nlogn) to O(logn).
Without any mode setting, the test would take up the mode to be 0 which
used to be the relax mode for base64 decoder in C. However, there was no
code corresponding to that mode and it was never used so nothing
happened when this test was run.
Add an explicit strict mode as per the expectation of the test from its
comments.
Add a pure rust base64 decoder. This supports 3 modes of operation just
like the C decoder as follows.
1. RFC 2045
2. RFC 4648
3. Strict
One notable change is that "strict" mode is carried out by the rust
base64 crate instead of native Rust. This crate was already used for
encoding in a few places like datasets of string type. As a part of this
mode, now, only the strings that can be reliably converted back are
decoded.
Jeff Lucovsky [Tue, 9 Jul 2024 13:39:17 +0000 (09:39 -0400)]
detect: Clear errno before strtoul
Per the notes for strtoul, since 0 or ULONG_MAX is a legitimate return
value, errno must be cleared before the call so an error can be checked
after the call by testing errno.
pgsql: trigger raw stream reassembly at tx completion
Once we are tracking tx progress per-direction for PGSQL, we can trigger
the raw stream reassembly, for detection purposes, as soon as the
transactions are completed in the given direction.
PGSQL's current implementation tracks the transaction progress without
taking into consideration flow direction, and also has indirections
that make it harder to understand how the progress is tracked, as well
as when a request or response is actually complete.
This patch introduces tracking such progress per direction and adds
completion status per direction, too. This will help when triggering
raw stream reassembly or for unidirectional transactions, and may be
useful when we implement sub-protocols that can have multiple requests
per transaction, as well.
CancelRequests and TerminationRequests are examples of unidirectional
transactions. There won't be any responses to those requests, so we can
also mark the response side as done, and set their transactions as
completed.
Philippe Antoine [Fri, 31 May 2024 12:06:55 +0000 (14:06 +0200)]
detect: safety for app-layer logging of stream-only rules
If a stream-only rule matches, and we find a tx where we
want to log the app-layer data, store into the tx data that
we already logged, so that we do not log again the app-layer metadata
Although the `prune-flows` option was removed with a5587fec2eb,
when documentation for the suricata.yaml config file was added with b252b0d, this option was also included - as has remained until now.
Jeff Lucovsky [Mon, 10 Jun 2024 20:04:38 +0000 (16:04 -0400)]
config: Update reference keys
Issue: 4974
1. Use https instead of http everywhere
2. Organize and annotate references by
- Referenced by ET/Open and ET/Pro
- URL resolves and works as intended (to provide supplemental
information regarding a reference value, e.g., bug id, cve
value)
- URL no longer resolves
- URL resolves but doesn't work as intended (to provide
supplemental information)
- Not referenced by ET/Open nor ET/Pro
- URL resolves and works as intended (to provide supplemental
information regarding a reference value, e.g., bug id, cve
value)
- URL no longer resolves
- URL resolves but doesn't work as intended (to provide
supplemental information)
DCERPC/TCP tends to return the same values for invalid and incomplete
headers. As a result of this, invalid headers and any traffic following
it is buffered and processed later on assumed to be valid DCERPC traffic.
Fix this by clearly defining error and incomplete data and taking
appropriate actions.
warning: first doc comment paragraph is too long
--> src/detect/iprep.rs:57:1
|
57 | / /// value matching is done use `DetectUintData` logic.
58 | | /// isset matching is done using special `DetectUintData` value ">= 0"
59 | | /// isnotset matching bypasses `DetectUintData` and is handled directly
60 | | /// in the match function (in C).
| |_
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#too_long_first_doc_paragraph
= note: `#[warn(clippy::too_long_first_doc_paragraph)]` on by default
help: add an empty line
warning: you seem to be trying to use `match` for destructuring a single pattern. Consider using `if let`
--> src/dcerpc/log.rs:36:33
|
36 | DCERPC_TYPE_BIND => match &state.bind {
| _________________________________^
37 | | Some(bind) => {
38 | | jsb.open_array("interfaces")?;
39 | | for uuid in &bind.uuid_list {
... |
51 | | None => {}
52 | | },
| |_____________^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#single_match
= note: `#[warn(clippy::single_match)]` on by default
Philippe Antoine [Wed, 14 Aug 2024 14:17:36 +0000 (16:17 +0200)]
frames: do not rely on FRAME_STREAM_ID
As it is not always the first frame to be created :
if it is not enabled, it does not get created, and other enabled
frames may be created first. see use of FrameConfigTypeIsEnabled
This resulted that this other frame got its length updated
on stream end, which led to false positives.
Resorting on FRAME_STREAM_TYPE is more consistent.
Victor Julien [Wed, 31 Jul 2024 11:58:29 +0000 (13:58 +0200)]
dcerpc: don't reuse completed tx
In the DCERPC over TCP pcap, logging and rule matching is disrupted by adding a simple rule:
alert tcp any any -> any any (flow:to_server,established; \
dce_iface:5d2b62aa-ee0a-4a95-91ae-b064fdb471fc; dce_opnum:1; \
dce_stub_data; content:"|42 77 4E 6F 64 65 49 50 2E 65 78 65 20|"; \
content:!"|00|"; within:100; distance:97; sid:1; rev:1; )
Works: alert + 3 dcerpc records.
But when adding a trivial rule:
alert tcp any any -> any any (flow:to_server,established; \
dce_iface:5d2b62aa-ee0a-4a95-91ae-b064fdb471fc; dce_opnum:1; \
dce_stub_data; content:"|42 77 4E 6F 64 65 49 50 2E 65 78 65 20|"; \
content:!"|00|"; within:100; distance:97; sid:1; rev:1; )
alert tcp any any -> any any (dsize:3; sid:2; rev:1; )
The alert for sid:1 disappears and also there is one dcerpc event less.
In the single rule case we can aggressively free the transactions, as there
is only an sgh in the toserver direction.
This means that when we encounter the 2nd REQUEST, the first 2 transactions
have already been processed and freed. So for the 2nd REQUEST we open a new
TX and run inspection and logging on it.
When the 2nd rule is added, it adds toclient sgh as well. This means that we
will now slightly delay the freeing of the transactions.
As a consequence we still have the TX for the first REQUEST when the 2nd REQUEST
is parsed. This leads to the 2nd REQUEST re-using the TX. Since the TX is
already marked as inspected, it means the toserver rule now no longer matches.
Also we're not logging this TX correctly now.
This commit fixes the issue by not "finding" a TX that as already been
marked complete in the search direction.
Victor Julien [Fri, 6 Sep 2024 11:14:48 +0000 (13:14 +0200)]
detect/app-layer-proto: don't run detection on ALPROTO_UNKNOWN
The `app-layer-protocol` keyword inconsistently checks whether the
alproto is ALPROTO_UNKNOWN. In the regular match function it isn't
checked, in the prefilter function its checked for all but the "either"
mode.
This leads to false positives for negated matching, as an expression
like "!tls" will match if checked against ALPROTO_UNKNOWN.
This patch adds the checking everywhere. The keyword returns no match as
long as the alproto is ALPROTO_UNKNOWN.
Shivani Bhardwaj [Thu, 29 Aug 2024 08:08:57 +0000 (13:38 +0530)]
rust/base64: upgrade crate to latest
base64 crate is updated to the latest version 0.22.1. This came with
several API changes which are applied to the code. The old calls have
been replaced with the newer calls.
This was done following the availability of better fns to directly
decode into slices/vectors as needed and also that previous version was
too old.
Along with this change, update the Cargo.lock.in to reflect all changes
in the package versions.
Jason Ish [Thu, 29 Aug 2024 20:35:50 +0000 (14:35 -0600)]
log-tlslog: remove ThreadExitPrintStats callback
Remove the ThreadExitPrintStats callback, this is the only logger that
was actually using it, and this logger is marked for deprecation. This
allows us to remove the callback from the registration signature.
Jason Ish [Thu, 29 Aug 2024 20:33:42 +0000 (14:33 -0600)]
tlsstore: remove ThreadExitPrintStats callback
Remove the callback to print stats on thread exit. The counter value
was never being used and this helps us get rid of this callback
altogether as their is only one other usage of it.
Jason Ish [Wed, 28 Aug 2024 23:17:50 +0000 (17:17 -0600)]
output-tx: use void * instead of OutputCtx
Using OutputCtx results in the low level output-tx packet logger being
aware of Suricata's higher level loggers that use OutputCtx, for the
low level logger this is purely opaque data that may not be an
OutputCtx for custom loggers.
projects / thirdparty / suricata.git / log
