This can be used to implement alert then pass logic.
Add support for alert-then-pass to alert handling routines.
Ticket: #5466.
(cherry picked from commit d5fb8204b6)
Replaces default "alert" logic and removed SIG_FLAG_NOALERT.
Instead, "noalert" unsets ACTION_ALERT. Same for flowbits:noalert and
friends.
In signature ordering rules w/o action are sorted as if they have 'alert',
which is the same behavior as before, but now implemented explicitly.
Ticket: #5466.
(cherry picked from commit 92581dbc06)
DETECT_FLOWBITS_CMD_NOALERT is misleading as it gives an impression that
noalert is a flowbit specific command that'll be used and dealt with at
some point but as soon as noalert is found in the rule lang, signature
flag for noalert is set and control is returned. It never gets added to
cmd of the flowbits object.
(cherry picked from commit 75471dd69b)
When a Tracker is set up for a IPID, frags come in for it and it's
reassembled and complete, the `DefragTracker::remove` flag is set. This
is mean to tell the hash cleanup code to recyle the tracker and to let
the lookup code skip the tracker during lookup.
A logic error lead to the following scenario:
1. there are sufficient frag trackers to make sure the hash table is
filled with trackers
2. frags for a Packet with IPID X are processed correctly (X1)
3. frags for a new Packet that also has IPID X come in quickly after the
first (X2).
4. during the lookup, the frag for X2 hashes to a hash row that holds
more than one tracker
5. as the trackers in hash row are evaluated, it finds the tracker for
X1, but since the `remove` bit is not checked, it is returned as the
tracker for X2.
6. reassembly fails, as the tracker is already complete
The logic error is that only for the first tracker in a row the `remove`
bit was checked, leading to reuse to a closed tracker if there were more
trackers in the hash row.
Ticket: #7042.
New warning from rustc.
The other option is to allow dead code, however this is more explicit,
and when they are read, its obvious they should be renamed.
Addresses this warning from the Rust compiler:
warning: `../rust/.cargo/config` is deprecated in favor of `config.toml`
note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml`
(cherry picked from commit 8560564657)
When replaying a pcap file, it is not possible to get rules
profiling because it has to be activated from the unix socket.
This patch adds a new option to be able to activate profiling
collection at start so a pcap run can get rules profiling
information.
(cherry picked from commit eecb3440e2)
When splitting the field over commas, skip the commas
which are innside quotes
Ticket: 7060
Not a direct backport, but heavily inspired by new rust code
handling it
This commit allows ja4 hashes to be logged iff enabled in the tls/quic
section of the outputs.
With the default setting ("off"), ja4 hashes will only be logged in
alerts when the signatures uses the ja4.hash keyword.
When enabled, ja4 hashes will be inclued in quic and tls logs.
- tls:
ja4: on
- quic:
ja4: on
Issue: 7010
EVE logging has a direction parameter that can cause the logging
of an application layer to be done in a direction that is not linked
to the packet. As a result the source IP addres could be assigned the
MAC address of the destination IP and reverse.
This patch addresses this by propagating the direction to the ethernet
logging function and using it there to define the correct mapping.
Issue #6405
(cherry picked from commit 21916b9743)
In certain conditions, it can take a long time for threads to start up.
For example in af-packet, setting up the socket, rings, etc has been
observed to take close to half a second per thread, and since the
threads go one by one in a preset order, this means the start up can
take a lot of time if there are many threads. The old logic would just
allow a hard coded 60s. This was not always enough when the number of
threads was high.
This patch makes the wait time take the number of threads into account.
It adds a second of time budget to the base 60s for each thread.
So as an example, if a system has 112 af-packet threads, it would wait
172 seconds (60 + 112) for the threads to get ready.
Ticket: #7048.
(cherry picked from commit 41b9836b11)
When starting a large amount of threads, the loop was inefficient. It
would loop over the threads and if one wasn't yet ready it would sleep a
bit and then reevaluate all the threads. This reevaluation of threads
already checked was inefficient, and could lead to the time budget
running out.
This patch splits the check, and keeps track of the threads that have
already passed. This avoids the rescanning of already checked threads.
(cherry picked from commit 85fd4b2ec7)
The functions in detect-engine-port.c are only being used at the time of
parsing the ports from rules initially. Since there are no SGHs at that
point, remove the ops related to them too.
(cherry picked from commit e14fefe24a)
So far, if a port was found to be single which was earlier a part of the
range, port + 1 was added to the list to honor the range that it was a
part of. But, this is incorrect in case the port is 65535 or if the port
was found to be of range when it was earlier a single port.
Bug 6896
(cherry picked from commit 4227e52c4b)
If a single port happens before a range port, the port groups created
were incorrect. Fix it to use smarter range check.
For example, given,
80:80 - SGH1
100:120 - SGH2
Range created should be
80:80 - SGH1
100:120 - SGH2
Bug 6881
(cherry picked from commit 7d937db5cb)
If a port point is single but later on also a part of a range, it ends
up only creating the port groups for single points and not the range.
Fix it by adding the port next to current single one to unique points
and marking it a range port.
Bug 6843
(cherry picked from commit 632ca75dd3)
Fix Coverity warning
** CID 1592992: Incorrect expression (COPY_PASTE_ERROR)
/src/util-port-interval-tree.c: 255 in SCPortIntervalFindOverlaps()
________________________________________________________________________________________________________
*** CID 1592992: Incorrect expression (COPY_PASTE_ERROR)
/src/util-port-interval-tree.c: 255 in SCPortIntervalFindOverlaps()
249 * will be sorted, insert any new ports to the end of the list
250 * and avoid walking the entire list */
251 if (*list == NULL) {
252 *list = new_port;
253 (*list)->last = new_port;
254 } else if (((*list)->last->port != new_port->port) &&
>>> CID 1592992: Incorrect expression (COPY_PASTE_ERROR)
>>> "port" in "(*list)->last->port2 != new_port->port" looks like a copy-paste error.
255 ((*list)->last->port2 != new_port->port)) {
256 DEBUG_VALIDATE_BUG_ON(new_port->port < (*list)->last->port);
257 (*list)->last->next = new_port;
258 new_port->prev = (*list)->last;
259 (*list)->last = new_port;
260 } else {
The code does not generate two port ranges that are same other than the
cases where port == port2 which is why it worked so far. Fix it.
Bug 6839
(cherry picked from commit 2d6708f1ff)