Documentation #3751
openAlert metadata JSON configs in suricata.yaml.in should match the RTD documentation
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.
Updated by Sascha Steinbiss almost 4 years ago
- Priority changed from Normal to Low
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.
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 :)
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.
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.
Updated by Philippe Antoine 10 months ago
- Assignee set to Community Ticket
- Target version set to TBD