protodetect: overwrite rflow flag detected by PM

[ilya-bakhtin]

rflow flag initially detected by PM must be overwritten by the results from PP if alproto from PP is finally taken.

Make sure these boxes are signed before submitting your Pull Request -- thank you.

• I have read the contributing guide lines at
  https://docs.suricata.io/en/latest/devguide/contributing/contribution-process.html
• I have signed the Open Information Security Foundation contribution agreement at
  https://suricata.io/about/contribution-agreement/ (note: this is only required once)
• I have updated the user guide (in doc/userguide/) to reflect the changes made (if applicable)
• I have created a ticket at
  https://redmine.openinfosecfoundation.org/projects/suricata/issues
  (if applicable)

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

Describe changes:
Currently, when rflow condition is initially detected by PM, and then alproto is updated by PP, the rflow is never reverted.
If alproto detected by PP is finally used then rflow detected by PP must be taken.

Provide values to any of the below to override the defaults.

• To use an LibHTP, Suricata-Verify or Suricata-Update pull request,
  link to the pull request in the respective _BRANCH variable.
• Leave unused overrides blank or remove.

SV_REPO=
SV_BRANCH=OISF/suricata-verify#1837
SU_REPO=
SU_BRANCH=
LIBHTP_REPO=
LIBHTP_BRANCH=

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.09%. Comparing base (b728916) to head (0c845b5).

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #11100      +/-   ##
==========================================
+ Coverage   84.08%   84.09%   +0.01%     
==========================================
  Files         925      925              
  Lines      250562   250561       -1     
==========================================
+ Hits       210687   210714      +27     
+ Misses      39875    39847      -28     

Flag	Coverage Δ
fuzzcorpus	64.20% <100.00%> (-0.01%)	⬇️
livemode	19.57% <0.00%> (-0.01%)	⬇️
pcap	46.49% <100.00%> (+0.05%)	⬆️
suricata-verify	62.79% <100.00%> (+<0.01%)	⬆️
unittests	62.22% <0.00%> (-0.01%)	⬇️

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

[catenacyber]

Thanks @ilya-bakhtin

Could you please create a redmine ticket for this ?
I think a better fix may be to improve the DCERPC/UDP probing parser.

diff --git a/rust/src/dcerpc/dcerpc_udp.rs b/rust/src/dcerpc/dcerpc_udp.rs
index 2007c867bf..0b4b30e2bf 100644
--- a/rust/src/dcerpc/dcerpc_udp.rs
+++ b/rust/src/dcerpc/dcerpc_udp.rs
@@ -299,7 +299,8 @@ fn probe(input: &[u8]) -> (bool, bool) {
             let is_dcerpc = hdr.rpc_vers == 0x04 &&
                 (hdr.flags2 & 0xfc == 0) &&
                 (hdr.drep[0] & 0xee == 0) &&
-                (hdr.drep[1] <= 3);
+                (hdr.drep[1] <= 3) &&
+                (hdr.fragnum == 0);
             return (is_dcerpc, is_request);
         },
         Err(_) => (false, false),

This way, we would no longer need the so-descrobed HACK in AppLayerProtoDetectGetProto

[catenacyber]

Needs a ticket, and also a response to the above question

[ilya-bakhtin]

I'm on vacation since the end of May. I hope i'll take care of the requests in a week or so.

[ilya-bakhtin]

https://redmine.openinfosecfoundation.org/issues/7111

[ilya-bakhtin]

Improving the DCERPC probing parser is a good idea.
After that, we can simplify logic in the applayer-detect-proto and remove dependency on ALPROTO_ in a module that normally must not use explicit alproto id numbers.
I'll be thinking about how to make changes less intrusive.

[catenacyber]

Thanks Ilya, will wait for the next version

[catenacyber]

Replaced by #11541