Detect log alert tx one 7199 v8.2

[catenacyber]

Link to ticket: https://redmine.openinfosecfoundation.org/issues/
https://redmine.openinfosecfoundation.org/issues/7449
https://redmine.openinfosecfoundation.org/issues/7199

Describe changes:

• document more guess-applayer-tx
• improves guess-applayer-tx for unidirectional protocol such as DNS

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

SV_BRANCH=OISF/suricata-verify#2180

#12266 with suricata.yaml.in changes as proposed in #12260

[codecov]

Codecov Report

Attention: Patch coverage is 92.30769% with 1 line in your changes missing coverage. Please review.

Project coverage is 83.22%. Comparing base (0e4faba) to head (5de2e64).
Report is 17 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #12269   +/-   ##
=======================================
  Coverage   83.22%   83.22%           
=======================================
  Files         912      912           
  Lines      257311   257322   +11     
=======================================
+ Hits       214154   214169   +15     
+ Misses      43157    43153    -4     

Flag	Coverage Δ
fuzzcorpus	61.07% <7.69%> (-0.01%)	⬇️
livemode	19.40% <0.00%> (-0.13%)	⬇️
pcap	44.34% <7.69%> (-0.02%)	⬇️
suricata-verify	62.83% <92.30%> (-0.01%)	⬇️
unittests	59.18% <7.69%> (-0.01%)	⬇️

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

[suricata-qa]

Information: QA ran without warnings.

Pipeline 23921

[catenacyber]

@jufajardini @jasonish remind me, why do we want to test with SV task-7018-dns-ips-stream-rule that oisf.net gets logged when you want to alert on suricata ? This looks wrong to me.

Rule is https://github.com/OISF/suricata-verify/blob/master/tests/dns/task-7018-dns-ips-stream-rule/test.rules

The third and fourth alert https://github.com/OISF/suricata-verify/blob/master/tests/dns/task-7018-dns-ips-stream-rule/test.yaml#L138 (lines 121 - 141)

I understand why the code does that but I do not understand why we want to enforce this behavior with the test...

[jufajardini]

@jufajardini @jasonish remind me, why do we want to test with SV task-7018-dns-ips-stream-rule that oisf.net gets logged when you want to alert on suricata ? This looks wrong to me.

Rule is https://github.com/OISF/suricata-verify/blob/master/tests/dns/task-7018-dns-ips-stream-rule/test.rules

The third and fourth alert https://github.com/OISF/suricata-verify/blob/master/tests/dns/task-7018-dns-ips-stream-rule/test.yaml#L138 (lines 121 - 141)

I understand why the code does that but I do not understand why we want to enforce this behavior with the test...

I see your point. I think I created a test that was descriptive of what we had, and that was the result.

I wonder if at some point we could have a more precise processing, and then we wouldn't even have that mismatch. In which case removing this check makes sense.

Indeed, when working on these tests, we wanted to showcase the current (undesirable) behavior: OISF/suricata-verify#1902 (comment)

[jasonish]

@jufajardini @jasonish remind me, why do we want to test with SV task-7018-dns-ips-stream-rule that oisf.net gets logged when you want to alert on suricata ? This looks wrong to me.

Rule is https://github.com/OISF/suricata-verify/blob/master/tests/dns/task-7018-dns-ips-stream-rule/test.rules

The third and fourth alert https://github.com/OISF/suricata-verify/blob/master/tests/dns/task-7018-dns-ips-stream-rule/test.yaml#L138 (lines 121 - 141)

I understand why the code does that but I do not understand why we want to enforce this behavior with the test...

If I recall correctly, this was confusing behavior. Your alerting on suricata, but get an alert with oisf.net in the metadata. We're not necessarily enforcing it with a test, we're just capturing current behavior so we know when it changes, as that is important and should be explained/documented by updating a test at least.

[catenacyber]

Thanks, next version in #12306

I put a comment in the SV check that this was not the desired behavior and added a reference to the ticket 7004 about it...