Skip to content

Conversation

jlucovsky
Copy link
Contributor

Continuation of #13591

Use unique variable names for each flowvar as they come from a global
namespace. The chosen name is: <sticky_buffer>_<sid>_<occurrence>

Describe changes:

  • Use a unique name for flowvar by appending the signature id to the name and the occurrence value. The occurrence values start from 1 and are significant if multiple entropy values are used in a single rule. They start from 1.

Updates:

  • Add a config setting to control whether unique names are generated: logging.entropy.make-unique
  • Document new configuration setting and how output is affected.
  • Disambiguate entropy output by adding the occurrence numer.

Issue: 7814

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

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#2588
SU_REPO=
SU_BRANCH=

Issue: 7814

Support unique flow variable names for entropy-related values.

Since this is a breaking change from Suricata 8, unique names
are configurable (default value on) with this setting

        logging:
          entropy:
            make-unique: on

When `make-unique` is on, entropy-related flow variable names are
structured as:
     <sticky_buffer>_<sid>_<occurrence>

Occurrence is a small integer value corresponding to the number of
entropy values in the rule. The first entropy usage will create a flow
variable with an occurrence value of 1; the second will use 2, and so
on. This is necessary to disambiguate the flow variable names.

When `make-unique` is off (default = on), this format is used:
     <sticky_buffer>
Discuss the new configuration variable that provides unique
names for entropy values in logging output: logging.entropy.make-unique

Issue: 7418
Copy link

codecov bot commented Jul 19, 2025

Codecov Report

❌ Patch coverage is 95.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 83.70%. Comparing base (2e69e0d) to head (225880f).
⚠️ Report is 36 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #13621      +/-   ##
==========================================
+ Coverage   83.69%   83.70%   +0.01%     
==========================================
  Files        1011     1011              
  Lines      275071   275089      +18     
==========================================
+ Hits       230210   230256      +46     
+ Misses      44861    44833      -28     
Flag Coverage Δ
fuzzcorpus 62.81% <15.00%> (+0.06%) ⬆️
livemode 19.01% <0.00%> (-0.12%) ⬇️
pcap 44.69% <0.00%> (-0.05%) ⬇️
suricata-verify 65.10% <95.00%> (-0.01%) ⬇️
unittests 59.18% <0.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 = 27036

Copy link
Contributor

@jufajardini jufajardini left a comment

Choose a reason for hiding this comment

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

Added notes related to the docs side, but think that Philippe or maybe Shivani would be better equipped to judge if this better addresses their concerns...

below will amend the sticky buffer name with the signature id of the rule that caused
the entropy value calculation. Additionally, if multiple ``entropy`` keywords are used
within a rule, the occurrence number is included in the log output.
The default value is ``on``. We strongly recommend changing using the default value of ``on``.
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm a bit confused. Strongly recommend turning it off? Disabling, maybe?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will clarify.


# Ensure that logged entropy values have unique names by appending the signature_id
# of the rule where used, e.g., file_data_12345. When off: file_data
# The default value is on
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we also add the note here that we strongly advise the default value to be changed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will clarify.

~~~~~~~

When a rule causes an entropy value to be calculated for a flow, output for the flow will include
the calculated entropy value. The log output contains the sticky buffer name for which the
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder : have you considered adding a entropy event to eve.json ? (or even entropies)

That should better work for a flow with multiple transactions where you would like to know the entropy for a sticky buffer in each transaction (thinking like DNS or HTTP CnC)

Also, side question : if multiple rules need the entropy for the same sticky buffer, is it computed once and cached ? Or is it computed for each rule wanting it ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Also, side question : if multiple rules need the entropy for the same sticky buffer, is it computed once and cached ? Or is it computed for each rule wanting it ?

The entropy values are not cached.

@jasonish
Copy link
Member

jasonish commented Aug 1, 2025

Is this intended for 8.0.1?

@jlucovsky
Copy link
Contributor Author

Is this intended for 8.0.1?

Yes.

@jlucovsky
Copy link
Contributor Author

Continued in #13722

@jlucovsky jlucovsky closed this Aug 15, 2025
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.

5 participants