Suricata Configuration Profiles¶
The Suricata configuration profiles that IDSTower uses offers a best-practice based configuration that slightly differ from the standard configuration that is shipped with Suricata.
The main differences are:
Each Suricata instance has its own configuration and log directories
IDSTower can run more than one Suricata instance on the same host, so nothing is written to the shared locations that a stock Suricata uses. Every instance gets its own directories, named after the instance:
Contents |
Location |
|---|---|
Configuration |
|
Rules |
|
IP Reputation files |
|
Datasets |
|
Logs and events |
|
[Instance Name] is the name the instance is given in the cluster’s Hosts tab. An instance that has not been given a name uses its position on the host instead, counting from 1, so the first unnamed instance writes to instance-1.
Note
Renaming an instance changes all of these paths. The directories for the new name are created the next time the host’s configuration is updated, so update the host’s configuration after renaming rather than restarting its service.
Each event type is written in a dedicated file
Normally, Suricata will write all of the events/alerts/stats records into a single eve.json file. IDSTower does not produce an eve.json: records are written to three different files instead, inside the instance’s log directory.
suricata-alerts-[timestamp].json: this file contains Alerts generated by Suricata.
suricata-nsm-[timestamp].json: this file contains network transactions (eg: http events) that are generated by Suricata.
suricata-stats-[timestamp].json: this file contains the Suricata’s health stats.
All three are rotated every hour, and [timestamp] is when the file was created, in YYYYMMDD-HHMMSS form. A complete path therefore looks like /var/log/suricata/instance-Sensor1/suricata-alerts-20260827-140000.json.
Suricata’s own engine log is written to the same directory, as suricata.log, and in JSON form as suricata.log.json.
For both suricata-alerts and suricata-nsm files, the “threaded” option is enabled to increase the performance of the record writing, moreover the “community-id” option is enabled as well.
Tip
The Filebeat that IDSTower deploys already reads these files and needs no configuration. If you ship the events yourself instead, point your shipper at /var/log/suricata/instance-*/suricata-alerts*.json and /var/log/suricata/instance-*/suricata-nsm*.json rather than at an eve.json, which is not created.
For Alerts, both the payload and payload-printable options are enabled, this is to give the analyst the ability to better investigate the root cause of the alert.
IP Reputation feature is enabled and used to alert on Indicators of Compromise (IOCs) of IP type.
The “default-rule-path” option is set to the instance’s own rules directory, “/etc/suricata/instance-[Instance Name]/rules/”, and three different rules files are loaded:
idstower_suricata.rules: this file contains all the enabled rules in IDSTower, the file is dynamically updated every 5 minutes so that it reflects any rules changed in IDSTower.
idstower_iprep_indicators.rules: contains the rules used to alert on IP IOCs.
idstower_datasets_indicators.rules: contains the rules used to alert on IOCs (eg: FQDNs, hashes…etc).