There's more to learn about Suricata's metadata logging and how you
can change the configuration to suit your needs.
As we've already explored,
there are several ways to configure how Suricata generates its outputs,
and you'll find this information in the suricata.yaml
file under the outputs section.
The configuration file lets you not only decide which outputs you want enabled,
but also which parsers.
As you saw in the previous demonstration,
this isn't always as easy as just enabling and disabling these capabilities.
It's a good idea to have an environment to test Suricata on before
going straight to production. With outputs, several of them will
have additional and even unique settings.
Most of these settings are described right there in
the suricata.yaml file for you.
One such output type is flows, and it's worth revisiting here.
There are two types of flows to consider. Flows themselves are
bidirectional and consists of a 5‑tuple or 7‑tuple in the case of
VLANs This 5‑tuple is the protocol, source IP, destination IP, source
port, and destination port, and for the 7‑tuple, the VLAN IDs.
Netflow is another type of flow.
It is unidirectional instead of bidirectional.
So for each flow record,
there is in, fact two, netflow records. As flow is generally the more
useful, netflow is disabled by default. In this slide, you can see an
example of a flow. In the training VM, you can also grep for the event
type of flow in the eve.json file to get an idea of how these records
are structured.
The flow_id is an important field as it allows us to see other
records associated with this flow. You can also see source and
destination IP, ports, protocols,
application layer protocols, just to name a few fields.
There is also the flow‑specific section, which includes stats about the flow,
such as bytes to and from, start and end time, and number of packets. In the
suricata.yaml file under outputs, eve‑log, types,
you'll find all of the protocol‑specific loggers. Some may
provide additional or extended information, in which case it
may or may not already be enabled.
You can experiment with enabling and disabling these,
then compare the appropriate records of each to see if the
additional information is something of value to you. Since you
already know how to modify Suricata's configuration, this becomes a
fairly straightforward exercise. This is an example TLS record. It
has an event_type of tls.
There is a flow_id to correlate on, and under the tls‑specific section,
plenty of useful data extracted from the TLS certificates, such as the
subject, the fingerprint, and the version, just to name a few.
Here's another example from the SMB protocol, often used for
activities like file transfer over a network.
This is another great protocol to be able to have this
visibility into. If you haven't started to,
you should be thinking about how this data not only helps during an incident,
but how you can use this data through visualizations and dashboards to
monitor your network for a wide variety of use cases,
not just malicious activity.
Each protocol requires some understanding of how it works, and we
won't get into all the details with SMB. Suffice it to say, you may
have to do a little research as you dig into the different
protocols that Suricata supports.
Suricata can also generate anomaly records, which it does when it
encounters packets with unexpected or anomalous values.
These anomalies can help when hunting encrypted network
traffic, such as the use of common TLS port 443,
but for unencrypted traffic. You can also enable anomaly logging under the
outputs, eve‑log section. Under types, the commented values decode,
stream, and applayer represent the default value.
To change those,
you would need to uncomment that line and change the
value from yes to no or vice versa.
As previously discussed,
networks with a high number of anomalies may experience packet processing
degradation, and we suggest using an approach that limits when anomaly
logging is enabled to get a sense of what is going on in the network, then
disabling and attempting to troubleshoot.
You may also find that leaving some of the anomaly logging enabled,
such as for the applayer, does not result in a degradation and also
provides valuable insight into the network.
This is one of our recurring themes. You'll have to experiment with your
network to find out what is your optimal settings.
Let's now take a look at some of these configuration
items in our next demonstration.