Suricata

Make outputs.1.eve-log.types.6.files.force-hash=sha256 simpler for the user

Philippe Antoine wrote in #note-4:

Make outputs.1.eve-log.types.6.files.force-hash=sha256 simpler for the user

Probably makes sense for the types under eve-log to be a simple map. As the following doesn't really make sense:

outputs:
  - eve-log:
      types:
        - alert
        - alert
        - anomaly

outputs:
  - eve-log:
      types:
        alert:
        anomaly:

Note: Its a little odd when not a list as you have to create empty objects for entries with no options.

This may also conflict with some ideas here: https://redmine.openinfosecfoundation.org/issues/3636

This would change the override notation to outputs.1.eve-log.types.files.force-hash=sha256 which makes a lot more sense.

Further simplication could be made by removing the one object object by modifying the YAML to be like:

outputs:
  - type: fast
    enabled: yes
    filename: fast.log
  - type: eve-log
    enabled: yes
    filename: eve.json
    types:
      alert:
      anomaly:

Further reducing the notation to outputs.1.types.files.force-hash=sha256.

Would it make sense to do a variant of

outputs:
  eve:
    filename: eve.json
    ...

    additional:
    - filename: eve1.json
      ...
    - filename: eve2.json

Jason Ish wrote in #note-5:

Philippe Antoine wrote in #note-4:

Make outputs.1.eve-log.types.6.files.force-hash=sha256 simpler for the user

Probably makes sense for the types under eve-log to be a simple map. As the following doesn't really make sense:
[...]
so it makes more sense like:
[...]

Note: Its a little odd when not a list as you have to create empty objects for entries with no options.

This may also conflict with some ideas here: https://redmine.openinfosecfoundation.org/issues/3636

This would change the override notation to outputs.1.eve-log.types.files.force-hash=sha256 which makes a lot more sense.

Further simplication could be made by removing the one object object by modifying the YAML to be like:
[...]

Further reducing the notation to outputs.1.types.files.force-hash=sha256.

I should note that specifying the "type" of output is actually an idea from Filebeat: https://www.elastic.co/guide/en/beats/filebeat/current/configuration-filebeat-options.html

Victor Julien wrote in #note-7:

Would it make sense to do a variant of
[...]
This would have a clean and simple default case, while supporting the flexible additional instances as well.

Not a bad idea. I think I'd simplify a bit by allowing both of the following:

outputs:
  eve:
   - filename: just-dns.json
     types:
      dns:
   - filename: just-alerts.json
     types:
       alert:

outputs:
  eve:
    filename: eve.json
    types:
      alert:
      dns:

Testing a runtime if eve is a list or a map is rather trivial. And clears up confusion, at least for me as to what configuration applies to the additional, what does it inherit from the upper object, etc.

Does it make sense for any of the other outputs to be specified for that once?

At least partially addressed in
https://github.com/OISF/suricata/pull/13333