Internals
---------
Suricata's stream engine returns data for inspection to the detection
engine from the stream when the chunk size is reached.
Bug
---
Inspection triggered only in the specified chunk sizes may be too late
when it comes to inspection of smaller protocol specific data which
could result in delayed inspection, incorrect data logged with a transaction
and logs misindicating the pkt that triggered an alert.
Fix
---
Fix this by making an explicit call from all respective applayer parsers to
trigger raw stream inspection which shall make the data available for inspection
in the following call of the stream engine. This needs to happen per direction
on the completion of an entity like a request or a response.
Important notes
---------------
1. The above mentioned behavior with and without this patch is
affected internally by the following conditions.
- inspection depth
- stream depth
In these special cases, the inspection window will be affected and
Suricata may not consider all the data that could be expected to be
inspected.
2. This only applies to applayer protocols running over TCP.
3. The inspection window is only considered up to the ACK'd data.
4. This entire issue is about IDS mode only.
FTP parser can handle multiple command lines per direction. Appropriate calls
to trigger raw stream inspection have been added on succesful parsing of each
request line and response line.
Bug 7742
Ticket: 8413
RFC 6455 Section 5.4 states
Control frames (see Section 5.5) MAY be injected in the middle of
a fragmented message.
Control frames are identified by opcodes where the most significant
bit of the opcode is 1.
`alert pkthdr` was initially just an alias for `alert ip`, as that was
really just a way of stating that "any" should be matched. However with
the Ethernet matching in place, it no long makes sense to treat `alert
ip` as "any". Since `pkthdr` is used to match on decoder events, also
for packets that completely failed to parse, it should no longer be
treated as `alert ip` but rather as it's own distinct logic.
Sticky buffer to inspect the ethernet header.
Example rule:
alert ether any any -> any any ( \
ether.hdr; content:"|08 06|"; offset:12; depth:2; \
sid:1;)
Ticket: #8327.
Make `Signature::proto` an optional member, meaning that if it is
NULL we can skip the check. This can be done for `alert ip`, as no check
is needed, and for `alert tcp` and `alert udp` as having a rule in a sgh
for those means that the protocol matches.
Some exceptions are rules that require:
- ipv4/ipv6 specific matching
- frames, due to sharing prefilter between tcp and udp
- ip-only rules, due to those not being per sgh
unicode-segmentation (used by rustyline) was updated from 1.12.0 to
1.13.1 earlier and requires a newer version of Rust. Pin to 1.12.0 which
works with Rust 1.75.0.
So that we can log and detect on interface uuids, even if
AlterContext packets change one of the contexts, but other contexts
are still used after it in request/responses
Ticket: 8378
Apply zero-padding to Napatech worker threads so alphanumeric sorting
displays workers in proper order.
Set padding for thread names according to stream count:
1-9 streams: no padding, e.g, nt1, nt9
10-99 streams: use padding, e.g, nt01, nt99
100-999 streams: use padding, e.g, nt001, nt099, nt999
This will insure that thread names, when sorted alphanumerically,
maintain thread worker id order.
Issue: 8337
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