Understanding Suricata Config – append

Config Example

  - fast:
    enabled: yes
    filename: fast.log
    append: no


Suricata generates multiple log files e.g.

 -rw-r--r--. 1 root root 4.3G Aug 13 12:47 eve.json
 -rw-r--r--. 1 root root  17K Aug 13 15:01 suricata.log
 -rw-r--r--. 1 root root 1.8G Aug 13 18:11 stats.log
 -rw-r--r--. 1 root root 2.0M Aug 13 18:11 fast.log

When we restart or re-run suricata deamon it has to decide what to do with the existing files. It has two options to decide from.

Overwrite: purge the log files and start writing logs from start.
Append: add the new logs to the file retaining the previous logs.

We can dictate the behavior by using the append config. The accepted values are yes, and no.

Default Bahavior

This isn’t a mandatory configuration. In the absence of this value the default behavior is to append the new logs in existing files.

Should I append or not?

It makes sense to not append if we are running individual pcaps through suricata and need to capture the unique logs against each pcap. For continuous NIDS operations appending logs help retain logs when suricata restarts.

Associated Concerns

Log files will keep growing indefinitely until we run out of disk space. Suricata as of version 4.1 only supports log rotation. It’s still the our responsibility to purge old logs using logrotate or other means.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.