Skip to content

detect: investigation on single-pkt flows inspection (5180) - v4#14752

Open
jufajardini wants to merge 4 commits intoOISF:mainfrom
jufajardini:bug-5180-01-single-pkt/v4
Open

detect: investigation on single-pkt flows inspection (5180) - v4#14752
jufajardini wants to merge 4 commits intoOISF:mainfrom
jufajardini:bug-5180-01-single-pkt/v4

Conversation

@jufajardini
Copy link
Contributor

Link to ticket: https://redmine.openinfosecfoundation.org/issues/
https://redmine.openinfosecfoundation.org/issues/5180

Previous PR: #14747

Describe changes:

  • better commit separation
  • rebase

To consider: what to do about what was mentioned on #14747 description? (should something be done?)

Provide values to any of the below to override the defaults.
SV_BRANCH=OISF/suricata-verify#2901

During initialization, the engine reports how many rules were loaded, as
well as which types. Pkt-only or stream-pkt rules would cause a "hole"
in such stats, as they're not counted.
Commit 497394e removed inspection of app-proto txs for packets
without an established TCP connection. But this meant that the
first packet seen in a session pick mid-stream could go without
inspection (previous bug 5510 seemed to point towards this behavior,
too).
If a flow has more packets, the stream will be inspected as part of
the upcoming packets and this would go unnoticed. In a single-packet
flow, however, the inspection for the packed would be skipped. Although
this might not affect alerts -- as they could be processed as part of
the flow timeout logic, the actual traffic could be evaded in IPS, in
case of a drop rule.

From the above, the most visible scenario is when there is only one packet on the flow,
as then the engine doesn't have "more time" to pick-up real-packets to
inspect for that given flow. But certain tests show that this can also
happen for more than one packet scenarios: there will be one less drop
event, or traffic from a packet that should have been already dropped
will be logged.

This led to the possibility of a real packet not being blocked, in IPS,
or matched against rules, as the corresponding portion of the stream
was only inspected later, as part of the stream/flow-timeout logic.

To ensure that we correctly flag the first packet seen for a given mid-stream
session, we must check for the session state *after* we have dealt with
TCP flags and state.

Related to
Bug OISF#5510

As part of
Bug OISF#5180
Since we're doing this further down in the same function, in a branch
that will also cover this case.

Related to
Bug OISF#5180
@codecov
Copy link

codecov bot commented Feb 4, 2026

Codecov Report

❌ Patch coverage is 90.00000% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.15%. Comparing base (69eb567) to head (b8dee45).

Additional details and impacted files
@@           Coverage Diff           @@
##             main   #14752   +/-   ##
=======================================
  Coverage   82.15%   82.15%           
=======================================
  Files        1003     1003           
  Lines      263643   263657   +14     
=======================================
+ Hits       216586   216602   +16     
+ Misses      47057    47055    -2     
Flag Coverage Δ
fuzzcorpus 60.19% <90.00%> (+<0.01%) ⬆️
livemode 18.73% <75.00%> (+0.02%) ⬆️
netns 18.53% <90.00%> (-0.01%) ⬇️
pcap 44.62% <90.00%> (+0.02%) ⬆️
suricata-verify 65.47% <90.00%> (+0.02%) ⬆️
unittests 59.23% <90.00%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@suricata-qa
Copy link

Information: QA ran without warnings.

Pipeline = 29442

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants