Following commit 5379b52af2
rules that use multiple times the keyword tls.cert_subject
will result in
Warning: detect: duplicate instance for tls.cert_subject
These rules likely meant to use a multi-buffer which is not the
case for tls.cert_subject (even if it was documented so).
Ticket: 7890
This is put in a new section of upgrade notes for
upgrading to 8.0.1
Added a page that explains how rules are prioritized by Suri, as well
as what main different types of inspection happen and what elements are
involved when ordering rules.
Task #5449
CC unix-manager.o
unix-manager.c:258:13: warning: Use of memory after it is freed [unix.Malloc]
258 | if (item->fd == fd) {
| ^~~~~~~~
1 warning generated.
see jq 'paths( objects | (.type == "object" and (has("additionalProperties") | not) )) | join(".")' etc/schema.json
fix and complete bittorrent on the way
Explain briefly the internals of inspection of raw data in the following order:
- Stream Engine
- Stream reassembly
- Role of Detection Engine and Applayer Parsers
- High level communication between Stream and Detection Engine
- Relevant suricata.yaml settings
alongwith some diagrams.
Ticket 4351
Add information about:
- available tables, default policies and rule ordering
- Packet layer and applayer tables and hooks
- engine analysis output
- commandline options available
- how to load firewall rules
Also, reorganize sections and content to assist the definitions.
stream-tcp.c:1938:16: warning: Access to field 'next' results in a dereference of a null pointer (loaded from variable 'tail') [core.NullDereference]
1938 | tail->next = old_head;
| ~~~~ ^
1 warning generated.
stream-tcp.c:1982:5: warning: Potential leak of memory pointed to by 'q' [unix.Malloc]
1982 | ssn->queue_len++;
| ^~~
1 warning generated.
RFC 7323 forbids a server to respond with a timestamp option in the
SYN/ACK when the SYN didn't have a timestamp option:
A TCP MAY send the TSopt in an initial <SYN> segment (i.e., segment
containing a SYN bit and no ACK bit), and MAY send a TSopt in
<SYN,ACK> only if it received a TSopt in the initial <SYN> segment
for the connection.
Once TSopt has been successfully negotiated, that is both <SYN> and
<SYN,ACK> contain TSopt, the TSopt MUST be sent in every non-<RST>
segment for the duration of the connection, and SHOULD be sent in an
<RST> segment (see Section 5.2 for details).
However, in the real world this pattern happens on benign traffic. This
would lead to missing logs and detection, and in IPS mode such sessions
would be blocked.
This patch allows this pattern when the `stream.liberal-timestamps` is
enabled (enabled by default).
Bug #4702.
Take SEQ and ACK into account for more scenarios.
SYN on SYN_SENT
In this case the SYN packets with different SEQ and other properties are
queued up. Each packet updates the ssn to reflect the last packet to
come in. The old ssn data is added to a TcpStateQueue entry in
TcpSession::queue. If the max queue length is exceeded, the oldest entry
is evicted. The queue is actually a single linked list, where the list
head reflects the oldest entry.
SYN/ACK on SYN_SENT
In this case the first check is if the SYN/ACK matches the session. If
it doesn't, the queue is checked to see if there SYN's stored. If one is
found that matches, it is used and the session is updated to reflect
that.
SYN/ACK on SYN_RECV
SYN/ACK resent on the SYN_RECV state. In this case the ssn is updated
from the current packet. The old settings are stored in a TcpStateQueue
entry in the TcpSession::queue.
ACK on SYN_RECV
Checks any stored SYN/ACKs before checking the session. If a queued
SYN/ACK was sound, the session is updated to match it.
Ticket: #3844.
Ticket: #7657.
After upgrading from 7.0.6 to 7.0.8, regular ppp packets are getting
dropped when ppp rules in decoder-events.rules were set as drop.
This was caused by commit a8f35806 ("detect: fix decoder only events").
Previously these rules would not be alerted or dropped.
It turns out several PPP protocols in a switch statement were falling
into the PPP_UNSUP_PROTO case. This has always been the case, I assume
the intention was that they don't get further inspected for size and
other decode errors hence unsupported.
But really some of the protocols are fundamentally required for a PPP
connection to take place.
Change some types that we know should be allowed to pass this.
Ticket: 7651
To support alternative cargo and rustc programs (such as cargo-1.82),
respect CARGO and RUSTC environment variables during ./configure much
like CC.
RUSTFMT is also respected as that is required for the tests, and Cargo
can't figure this out like it can for rustc (perhaps a bug in the
packaging).
For cbindgen, we have also have to make sure the cargo environment
variable is set for each invocation.
To build with Ubuntu's Rust 1.82 packaging:
CARGO=cargo-1.82 RUSTC=rustc-1.82 RUSTDOC=rustdoc-1.82 \
./configure
Note that setting RUSTDOC is only required for commands like "make
check" to pass.
Ticket: #7877
As a part of the commit d096b98 a defensive check was added stating that
the stream must have EOF flag set if it is in TCP_CLOSING state or
above. However, this led to a false positive reported by oss-fuzz whose
analysis showed that this does not hold true for TCP_CLOSING state. It
does hold true only for TCP_CLOSED or if packet has PKT_PSEUDO_STREAM_END
set.
TCP_CLOSING state correspond to an established flow hence the correct
course of action is to remove the assertion.
Bug 7636
Co-authored-by: Philippe Antoine <pantoine@oisf.net>
Victor Julien
Philippe Antoine
Juliana Fajardini
Shivani Bhardwaj
Shivani Bhardwaj
Jeff Lucovsky
Thomas Winter
Jason Ish
dependabot[bot]
Tommy Wang