Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

next/706/20250130/v1 #12507

Merged
merged 9 commits into from
Jan 30, 2025
Merged

Conversation

victorjulien
Copy link
Member

inashivb and others added 9 commits January 30, 2025 10:52
If alproto for the current direction was not detected but the opposite
side was successfully detected, if the Pattern Matching and Pattern
Probing on the flow was also successfully done and the current
direction's alproto is still unknown, a decoder event is set to indicate
that the protocol detection only happened in one direction.

This event is set after having sent the current data to the applayer
parser. Now, the respective applayer parser may or may not successfully
parse the data. However, the alproto on flow is already set from the
other direction so there will be a flow event generated by Suricata. In
order to keep this consistent with the stats, also make sure to
increment the flow counter when the decode event is set so that the flow
counter is incremented irrespective of the parsing status reported by
the applayer parser.

This patch makes stats for several specific applayer flow count equal to
the number of flow events logged for those specific applayer protocols.

Bug 7238
TCP data can be presented to the protocol parser in any way e.g. one
byte at a time, single complete PDU, fragmented PDU, multiple PDUs at
once. A limit of 1MB can be easily reached in some of such scenarios.
Remove the check that rejects data that is more than 1MB.
to make it available for logging.
Instead of own internal mechanism of buffering in case of fragmented
data, use AppLayerResult::incomplete API to let the AppLayer Parser take
care of it. This makes the memory use more efficient.
Remove any unneeded variables and code with the introduction of this
API.

Ticket 5699
With the introduction of AppLayerResult::incomplete API, fragmented data
is no longer handled fully in the dcerpc code. Given that these code
paths are already covered by the following s-v tests, these tests can now be
safely removed.
- dce-gap-handling
- dcerpc-dce-iface-*

Ticket 5699
- remove unneeded variables
- remove unnecessary tracking of bytes in state
- modify calculations as indicated by failing tests
as it is now covered by the suricata-verify test
dcerpc-request-http-response.
Frames of the following types have been added for toserver direction:
1. Pdu: The entire Protocol Data Unit
2. Hdr: Header of the request
3. Data: PDU data

Feature 4904
Copy link

codecov bot commented Jan 30, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 80.68%. Comparing base (cfbf8fd) to head (c00e137).
Report is 9 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #12507      +/-   ##
==========================================
+ Coverage   80.56%   80.68%   +0.12%     
==========================================
  Files         925      925              
  Lines      259292   258916     -376     
==========================================
+ Hits       208906   208914       +8     
+ Misses      50386    50002     -384     
Flag Coverage Δ
fuzzcorpus 56.81% <97.22%> (+0.66%) ⬆️
livemode 19.40% <5.55%> (+<0.01%) ⬆️
pcap 44.17% <91.66%> (-0.03%) ⬇️
suricata-verify 63.37% <97.22%> (-0.02%) ⬇️
unittests 58.37% <82.69%> (-0.07%) ⬇️

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

@victorjulien victorjulien added the needs baseline update QA will need a new base line label Jan 30, 2025
@suricata-qa
Copy link

WARNING:

field baseline test %
SURI_TLPR1_stats_chk
.app_layer.flow.tls 624191 645259 103.38%
.app_layer.flow.dcerpc_tcp 43 7339 17067.44%
.app_layer.flow.sip_tcp 0 2 -

Pipeline 24445

@victorjulien
Copy link
Member Author

@ct0br0 can you prep a baseline update for this?

Copy link
Contributor

@catenacyber catenacyber left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consistent with approved PRs, with right SV branch and green CI

@victorjulien victorjulien merged commit c00e137 into OISF:master Jan 30, 2025
60 checks passed
@victorjulien victorjulien deleted the next/706/20250130/v1 branch January 30, 2025 20:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs baseline update QA will need a new base line
Development

Successfully merging this pull request may close these issues.

4 participants