Manage Suricata Rule Sources¶
Stage connected or offline rule updates with provenance, validation, and a known-good rollback copy.
Choose and record a source¶
Record the source name, licence, retrieval time, engine compatibility, archive filename, and SHA-256 checksum. Enable only sources whose terms and detection scope fit the environment.
sudo suricata-update list-sources
sudo suricata-update update-sources
sudo suricata-update enable-source <SOURCE_NAME>
sudo suricata-update
sudo suricata -T -c /etc/suricata/overview.yaml -v
Back up the known-good generated rules before an update. Do not activate new content if validation reports a parser error or incompatible keyword.
Connected update procedure¶
The demonstrated connected workflow includes source discovery, common licence categories, source enablement, and ruleset generation.
Running suricata-update with internet connection simplifies the process of downloading and installing rulesets.
You can also list sources and download rules from a specific source
Summary of different license types:
- MIT is very permissive, allowing almost any use, even commercial.
- Commercial requires you to pay or subscribe for usage rights, often with strict terms.
- CC-BY-SA-4.0 requires you to give credit and share any modifications under the same license.
- GPL-3.0 requires sharing modifications under the same open-source license and offering the source code.
- Non-Commercial restricts usage to personal or non-commercial contexts.
To download the ruleset from a specific source, run:
If required, update sources
Prepare an offline rules package¶
On a connected preparation machine, obtain the approved rules archive and create a transfer manifest:
After approved transfer, verify the checksum and extract to a staging
directory. Prefer suricata-update with a supported local source or input path
for the installed version. Consult its help before running the exact command:
suricata-update --help
sha256sum --check rules-transfer.sha256
mkdir -p "$HOME/suricata-rules-staging"
tar -xzf <RULE_ARCHIVE> -C "$HOME/suricata-rules-staging"
find "$HOME/suricata-rules-staging" -type f -name '*.rules' -print | sort
Do not append repeatedly to /var/lib/suricata/rules/suricata.rules. If a
historical manual merge is required, create a new staging file, retain the
sorted source-file list, check duplicate SIDs, validate the complete
configuration, then replace the active file once.
Demonstrated offline update procedure¶
The following procedure preserves the expected disconnected update error, manual ET Open extraction, and original merge command. Its warning explains why repeated appends are unsafe; use the staged workflow above for a new build.
Run suricata-update to update rules and create /var/lib/suricata folder
Note it is expected to get the error “Failed to fetch https://rules.emergingthreats.net/open/suricata-7.0.6/emerging.rules.tar.gz:”
Make a folder called suricata-rules and extract emerging.rules.tar.gz to that directory
sudo mkdir suricata-rules
sudo tar -xvzf emerging.rules.tar.gz -C /opt/suricata-offline/suricata-rules/
The demonstrated procedure appended the extracted rules to the generated rule file. Repeating this command creates duplicate content and its input order is not controlled. Prefer the maintained offline rule-staging workflow. Run the command below only when reproducing the demonstrated PoC from a fresh known-empty target.
sudo bash -c 'find /opt/suricata-offline/suricata-rules/rules/ -name "*.rules" -exec cat {} + >> /var/lib/suricata/rules/suricata.rules'
Validate before activation¶
sudo cp -a /var/lib/suricata/rules/suricata.rules \
/var/lib/suricata/rules/suricata.rules.known-good
sudo suricata -T -c /etc/suricata/overview.yaml -v
sudo systemctl restart suricata
sudo systemctl is-active suricata
The demonstrated validation output is retained below, including the observed signature-count difference between connected and disconnected updates.
#Example output
Notice: suricata: This is Suricata version 7.0.6 RELEASE running in SYSTEM mode
Info: cpu: CPUs/cores online: 2
Info: suricata: Running suricata under test mode
Info: suricata: Setting engine mode to IDS mode by default
Info: exception-policy: master exception-policy set to: auto
Info: logopenfile: fast output device (regular) initialized: fast.log
Info: logopenfile: eve-log output device (regular) initialized: eve.json
Info: logopenfile: stats output device (regular) initialized: stats.log
Info: detect: 1 rule files processed. 39802 rules successfully loaded, 0 rules failed, 0
Info: threshold-config: Threshold config parsed: 0 rule(s) found
Info: detect: 39805 signatures processed. 1158 are IP-only rules, 4116 are inspecting packet payload, 34321 inspect application layer, 108 are decoder event only
Notice: suricata: Configuration provided was successfully loaded. Exiting.
Note the difference in number of signatures processed, inspecting packet payload and inspect application layers when suricata-update was executed without internet access:
Info: detect: 39669 signatures processed. 1158 are IP-only rules, 4110 are inspecting packet payload, 34193 inspect application layer, 108 are decoder event only
Notice: suricata: Configuration provided was successfully loaded. Exiting.
Generate a local benign fixture with a dedicated test SID rather than relying on an uncontrolled public test site. The demonstrated ET Open SID 2100498 exercise is included on the local-rules page, since both the public endpoint and rule revision can change.
Roll back a failed update¶
Restore the known-good generated file, validate, restart, and confirm capture:
sudo cp -a /var/lib/suricata/rules/suricata.rules.known-good \
/var/lib/suricata/rules/suricata.rules
sudo suricata -T -c /etc/suricata/overview.yaml -v
sudo systemctl restart suricata