Project

General

Profile

Actions

Documentation #3751

open

Alert metadata JSON configs in suricata.yaml.in should match the RTD documentation

Added by Sascha Steinbiss almost 4 years ago. Updated 10 months ago.

Status:
New
Priority:
Low
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

It would be nice if the suricata.yaml.in file -- and hence the default configuration file -- contained at least a commented out version of the detailed alert metadata configuration, i.e. the

- alert:
    #payload: yes             # enable dumping payload in Base64
    #payload-buffer-size: 4kb # max size of payload buffer to output in eve-log
    #payload-printable: yes   # enable dumping payload in printable (lossy) format
    #packet: yes              # enable dumping of packet (without stream segments)
    #http-body: yes           # Requires metadata; enable dumping of http body in Base64
    #http-body-printable: yes # Requires metadata; enable dumping of http body in printable format

    # metadata:

      # Include the decoded application layer (ie. http, dns)
      #app-layer: true

      # Log the the current state of the flow record.
      #flow: true

      #rule:
        # Log the metadata field from the rule in a structured
        # format.
        #metadata: true

        # Log the raw rule text.
        #raw: false

The ReadtheDocs documentation shows it (https://suricata.readthedocs.io/en/latest/output/eve/eve-json-output.html#alerts) but the suricata.yaml.in only shows the metadata: yes/no switch (https://github.com/OISF/suricata/blob/master/suricata.yaml.in#L152). For someone who uses the example fileand its comments as option documentation (such as me) that's a bit inconvenient.

Actions #1

Updated by Sascha Steinbiss almost 4 years ago

  • Priority changed from Normal to Low
Actions #2

Updated by Jason Ish almost 4 years ago

How about a link to the documentation? I think the idea here, and in other parts of the configuration is that the documentation should be the reference, while we try to keep the default configuration a little smaller. But I do struggle a bit with this myself. I often want to log the full rule and get it wrong the first time.

Actions #3

Updated by Sascha Steinbiss almost 4 years ago

A link to the documentation is the minimum, I think. I always considered the suricata.yaml as a snapshot of what the complete configuration would look like in the default state (which is also helpful to diff between versions to find out what to update). Only having a subset of the possible configuration items in there would hide good functionality from users. Just my 2 cents :)

Actions #4

Updated by Jason Ish almost 4 years ago

Sascha Steinbiss wrote in #note-3:

Only having a subset of the possible configuration items in there would hide good functionality from users. Just my 2 cents :)

Yeah, its an active area of discussion. A complete suricata.yaml is pretty daunting for new users, given most of it doesn't need to be touched. I think Andreas is actively looking into better ways here.

Actions #5

Updated by Andreas Herz almost 4 years ago

I would go with the doc link as a first quick win and include the other issue within the whole discussion. We still struggle to find the best solution to that.

Actions #6

Updated by Philippe Antoine 10 months ago

  • Assignee set to Community Ticket
  • Target version set to TBD
Actions

Also available in: Atom PDF