Add payload-only-classtypes filtering to suricata conf to filter payl…

[Aboussejra]

…oad dump by classtype if needed

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

Contribution style:

• I have read the contributing guide lines at
  https://docs.suricata.io/en/latest/devguide/contributing/contribution-process.html

Our Contribution agreements:

• I have signed the Open Information Security Foundation contribution agreement at
  https://suricata.io/about/contribution-agreement/ (note: this is only required once)

Changes (if applicable):

• I have updated the User Guide (in doc/userguide/) to reflect the changes made
• I have updated the JSON schema (in etc/schema.json) to reflect all logging changes
  (including schema descriptions)
• I have created a ticket at
  https://redmine.openinfosecfoundation.org/projects/suricata/issues

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

Describe changes:

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

• To use a 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#2895
SU_REPO=
SU_BRANCH=

[catenacyber]

I wonder if we should use a hashtable here... What do you think ?

[Aboussejra]

I suppose that is doable, do you think it is mandatory ? As we are not in a particular hot code path for alert logging I am not sure if that is needed. I could do it if you think that is necessary.

[catenacyber]

This looks like an interesting feature.
I wonder if we could have something more generic for conditional payload logging, like a dedicated keyword...

Thoughts ?

[codecov]

Codecov Report

❌ Patch coverage is 77.77778% with 14 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.15%. Comparing base (81572cb) to head (30fdc66).

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #14726      +/-   ##
==========================================
- Coverage   82.17%   82.15%   -0.02%     
==========================================
  Files        1008     1008              
  Lines      263916   263978      +62     
==========================================
+ Hits       216868   216872       +4     
- Misses      47048    47106      +58     

Flag	Coverage Δ
fuzzcorpus	60.18% <17.46%> (-0.02%)	⬇️
livemode	18.72% <20.63%> (+<0.01%)	⬆️
netns	18.52% <12.69%> (+<0.01%)	⬆️
pcap	44.60% <22.22%> (-0.02%)	⬇️
suricata-verify	65.26% <77.77%> (-0.10%)	⬇️
unittests	59.34% <9.52%> (-0.02%)	⬇️

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.

[Aboussejra]

@catenacyber

Indeed something more generic could have been envisionned. Our use case was in an environment where we did not control the rule but did control the suricata configuration. Thus we could add this parameter to filter payload logging. But as we could not easely rewrite the rule, the path of a dedicated keyword was not considered. (Even if I think some specific flag on Packet structure on match callback on the keyword could work indeed). To be fair, I think a keyword could be interesting too but that would not solve the personal use case where my company used it.

[Aboussejra]

Fixed clang-format problem in v4 of branch here:

#14737

[catenacyber]

Our use case was in an environment where we did not control the rule but did control the suricata configuration.

Thanks for this insight, should be in the commit message ;-)