In this section,
we're now going to turn our attention to Suricata's core functions
and start with its ability to generate alerts.
Generating alerts is one of the first activities that can be undertaken
to ensure that Suricata is in fact up and running.
One of the easiest ways to do this is to create a simple rule that you can
then generate the appropriate traffic to use it to alert.
Recall that eve.json is the primary output file for
Suricata and is located at var/log/suricata.
After generating an alert,
we can query the contents of the eve.json file using cat and jq.
The screenshot shows an example of an event type of alert in the eve.json file.
The following is an example of a simple rule that can be
used to verify Suricata is up and running.
It is designed to generate an alert when an ICMP echo, or ping, is detected.
Adding custom rules is fairly straightforward.
You can define additional rules files in the configuration file,
which is located at etc/suricata/suricata.yml by default,
or you can include a custom rules file via a command line argument.
While adding rules files can be straightforward,
there is a bit more to writing good rules,
and we'll begin to scratch the surface of that art and science here.
All of the data that Suricata generates will be output to the primary log file,
eve.json,
so in this scenario we've created a custom rule and issued a ping command.
Now we want to verify that our alert worked.
Fast.log's an alternative log file that allows you to
quickly check for generated alerts.
You can view the contents of this file wherever Suricata is storing output data.
This file will only contain abbreviated information
about alerts that have been generated.
As fast.log is intentionally limited in data,
you can use eve.json to not only get alert
information but also quite a bit more.
For example,
viewing the event type record for the alert
generated also shows much information, such as the flow id,
which we'll discuss a bit later.
All of the JSON log types will share a common structure in the eve.json file.
Some of the common data includes the timestamp of the event.
If reading from a pcap,
this is from the time the pcap was created and not
during ingestion into Suricata.
Pcap_cnt is added when processing a pcap and contains the packet number.
App_proto, or application layer protocol.
This data is generated when an application layer protocol event is detected,
such as TLS or HTTP.
There are several additional fields that are important to point out.
To start, most records will include source and destination IP,
source and destination port, and flow id,
which uniquely identifies traffic based on the 5‑tuple,
IPs, ports, and protocol.
Some additional fields include the interface that captures the traffic,
this is only relevant in service mode; the event type,
such as alert; the network protocol; data specific to the event,
for example, if an alert is generated,
there will be additional information about the alert,
such as the signature id, category, and priority; and then flow‑related stats,
such as number of packets and bytes exchanged.
Since we're focusing on alerts right now,
let's take a closer look at some of the alert‑specific fields.
Action determines what Suricata did with the traffic once the rule matched.
Allowed means that Suricata generated the alert but
took no steps to stop the traffic.
If it was blocked, then the rule syntax uses a keyword of drop or reject.
And Suricata not only generated the alert but also blocked the traffic.
Suricata can block traffic while in intrusion prevention,
or IPS mode The signature is a terse value provided by the rule author.
The signature's often displayed in dashboards and other
tools used to manage these alerts.
It is usually very short and to the point,
so some signatures may require that you have to dig into the rule syntax
a bit to understand exactly what it is telling you.
The signature identifier, also known as the sig_id or simply the sid,
is a unique value assigned to the rule and should not be
duplicated across the rules that Suricata is loading.
If Suricata determines that more than one rule is using the same signature ID,
it will emit an error during rule parsing.
A few more alert‑specific fields, category,
which provides further classification; severity,
which prioritizes which rule Suricata checks first; and metadata,
which will contain optional information such as resources to the
traffic that inspired the rule in the first place.
I've mentioned flow id a couple of times now, so what does it really provide?
Well,
a flow is considered a bidirectional flow of packets with
the same 5‑tuple elements: protocol,
source IP, destination IP, source port, destination port.
Suricata produces very detailed transaction records, and through this we can
use flow id to correlate on a variety of different events.
This helps you to build context during an investigation or when triaging
alerts, as you can step back from the alert and view events that led up
to and after what you are investigating.
Let's now take a look at how we can generate and
investigate this data in our next demonstration.