With a growing understanding of how Suricata uses rules and
the data that it generates, the next step is to figure out how
to begin to tune out the noise.
What do we mean by noise?
We'll use this term to describe excessive output in the form of alerts and
metadata that makes identifying actionable issues more difficult.
Suricata produces rich metadata, but sometimes too much can simply be too much.
Not all alerts are of sufficient value to have enabled, and
some data is not relevant to your environment. Rules can be
noisy in the sense of too many alerts.
Perhaps the rule is not specific enough and generates false alarms too often.
Always keep in mind, the data that's Suricata is generating and its
relevance to why you are setting it up in the first place.
If data is taking away from your ability to monitor your environment,
consider making some configuration changes.
You can limit, or even exclude, parts of the network by using a
Berkeley Packet Filter, or BPF. For example,
BPFs can be used for further refinement to the home net and external
net values in your Suricata configuration file.
Suricata's anomaly logs report unexpected conditions such as truncated packets,
and packets with incorrect protocol length values, and other events that
render the packet invalid for further processing. Additionally,
unexpected behaviors on established network streams during TCP's
three‑way handshake. The noise level can be high, and not all
anomaly log records require action.
Thus a workflow that involves using anomaly logging for a defined
period to discover issues, and provide a list of actionable items to
remediate, followed by periodic refreshes should be considered. Then,
disable anomaly logging and only re‑enable for periodic refreshes, to
view what's going on in the network and discover any lingering or
possibly new issues.
This process can then be repeated as needed. In the suricata.yml
file,, you can enable/disable logging under outputs, eve‑log, anomaly,
by setting the enabled value to yes or no.
As you've seen,
you have a set of rules for your Suricata deployment, which can
include thousands of individual rule files.
This can become a problem.
Each time an alert is generated, it should be triaged and investigated.
You want to avoid getting into the habit of simply ignoring them.
If a rule has no value, figure out why, and either modify it,
change how Suricata handles it, or disable it. But how can you
separate the high‑value alerts from the low‑value alerts?
This is a step that depends on your network deployment, assets within
your organization, and even organizational goals. There is no easy guide
to follow, since each environment is unique.
Events that your organization may find critical to be alerted to,
other organizations may want to ignore outright.
When you first consider deploying Surikata,
you may want to limit the amount of time or even the
amount of the network it is monitoring.
This can allow you to figure out what data to include alerts will be
generated. Then, you can take Suricata offline and begin to fine tune the
configuration and how alerts work in your environment.
If you don't do this,
you may become overwhelmed with everything that Suricata is
generating. Some steps you can take are to disable low‑value
alerts with suricata‑update.
This can prevent them from even being loaded.
You can also suppress alerts by adding suppression rules for specific hosts
or networks. Keep in mind, this may be reducing your visibility in the long
term, though. You can use rule threshold keywords to reduce alert
generation, and suppressing rules can reduce alert value and make sure no
alerts are generated for a host.
This is really not efficient, as they are evaluated after
the rule has been evaluated. So consider a capture filter
if performance is a factor.
Not all rules are created equal. A rule may be too general and alert too
often, increasing the volume at which alerts must be triaged.
One of our primary goals is to fine‑tune our Suricata
deployment to only generate high‑quality alerts, only when
there is an event worth investigating.
We don't want to waste someone's time with false‑positive noise.
One way to do this is to refine the rule, which we've already begun to
explore. If you have trusted hosts and/or network ranges,
you can eliminate traffic involving them from being evaluated against rules
using a pass rule. Another approach is to create thresholds that can tell
Suricata when to generate an alert for specific rules.
The bypass keyword can be used to exclude traffic from further evaluation.
The classic example is large flows from YouTube or
other content‑streaming services.
The challenge with fine‑tuning is that your network is unique, and only you
will be able to understand exactly what you can suppress,
eliminate, or modify.
We'll discuss how to use tools like suricata‑update to
help you with your fine‑tuning efforts.
Suricata can create logs for application‑layer protocols such
as HTTP, DNS, and TLS, just to name a few.
The logs contain valuable information for reporting and/or forensic
purposes, but may not be necessary for your site.
Consider disabling protocols that are not relevant
to your deployment, for example, MODBUS or Industrial Control Systems protocols.
You may also have other security tools creating log information
and overlap in the data that is being generated.
If this is the case, you could evaluate which tool provides you the best data,
the best integration, and also performance, and begin to reduce
output, or even streamline your deployment. Bottom line, if
you're not using it in your environment,
there is likely no value in telling Suricata to log it.
Some protocols, for example,
TLS, provide configuration settings to increase or
decrease each log record's content.
TLS configuration includes an extended field with a default value of yes.
This could be disabled by changing the value to no, and the amount of
content in each log record will be slightly reduced.
While this may seem like a trivial change, if you're
monitoring a high volume of traffic,
this can have a significant impact on the data that Suricata is generating.
Here's an example in the suricata.yml showing the eve‑log section
and how protocol‑specific logs can be enabled,
disabled, and even refined as to what data is being generated.
For example,
the extended fields for http and tls, and the type of DNS
records such as a, aaaa, male, or txt.
Suricata's primary output is the eve.json file, which is in the JSON format.
Suricata provides extensive control over logging and granular control over most
of the settings. You can enable or disable classes of logging, or reduce the
amount of logging by class. By class, we're referring to the type of data that
a logger is responsible for generating.
Here's an example of the different types of logging in the configuration file.
You can toggle the logging status of application‑layer parsing, stats
logging, and file extraction through file store settings.
There is a variety of other configuration changes to consider, and the
best place to start is by reading the documentation. Here are just a few
more ideas. Stream.reassembly.depth indicates how much of a stream
should be reassembled and inspected.
This can have a performance impact, as it will limit how much content Suricata
tries to reassemble and inspect. File‑store is very similar.
Files sent over a network can be quite large, and this tells Suricata how much
of the file to inspect. Remember when we looked at file info events, and in
particular, the file hashes that were generated? Well,
this also has an effect on those, in that if Suricata
doesn't read the whole file stream, the hashes are simply not valid.
So there is much to consider with each change as to how Suricata runs. Now
that you have some ideas on how to control how Suricata works, let's take a
look at some example traffic and how we can apply these different techniques
to fine‑tune Suricata's performance.