In this section,
we're going to take a look at essential commands needed to
get you up and running with Suricata.
To start,
we'll take a look at installing Suricata and discuss the
specifics of how the training VM has been configured.
We'll also review networking in the training VM and some of the key
files used by Suricata for output and configuration.
Since our training VM is based off of Ubuntu Linux,
the preferred method of installing Suricata is to use the OISF PPA,
or Personal Package Archive.
This ensures that you will install the latest stable version of Suricata.
You will find full installation instructions under Binary Packages,
Ubuntu in the Suricata user guide on Read the Docs,
as well as a wealth of other information for using Suricata.
You will also find installation instructions for
not only other operating systems, but other methods for installing Suricata.
While some of the specifics will vary,
the installation procedure will be very similar
among supported operating systems.
Now,
for those of you already thinking about your production Suricata installation,
here are some other installation methods.
First, RPM Package Manager repositories for Red Hat Enterprise Linux,
CentOS, and Fedora.
There is an installer for Microsoft Windows.
And you also have the ability to build from source.
And finally,
you may also be able to use the package manager from
your favorite operating system, such as Arch Linux,
FreeBSD, and OpenBSD.
Keep in mind that these package managers may install a version of
Suricata that is well behind the current stable version,
and you may want to check the version of Suricata that is installed.
As you might have guessed,
we recommend running the latest stable version of Suricata for performance,
capabilities, and security.
The Suricata training VM is based off of Ubuntu 20.04 long‑term
support, and Suricata is installed using the OISF PPA.
The primary configuration file for Suricata will be placed in
/etc/suricata and is named suricata.yml,
or yaml.
YAML is a popular way of creating human‑readable configuration files,
and the installation uses an example configuration, so it's
helpful to get to know more about this file and when you
need to make modifications to it.
The logging location for Suricata is /var/log/suricata when Suricata is
running in service mode or listening to live network traffic.
When replaying pcaps, commonly referred to as offline mode,
Suricata will log to the current directory.
This is done to avoid any conflicts with the live logs, and there is a
command line option to define this logging location.
Don't worry, we'll get into the differences in these
two modes later in the course.
Suricata‑Update is the recommended tool for updating the rules that your
Suricata instance is using. Out of the box, Suricata‑Update is configured
to use the Emerging Threats open ruleset and will load these rules from
/var/lib/suricata/rules/suricata.rules. Right now, we just want you to
focus on the default behavior.
We'll also get into managing rules using Suricata‑Update
later in this course. For training purposes,
we have set up the VM to use a dummy network interface.
This will provide a live‑like experience without having the extra
overhead of not only listening to live network traffic, but in
capturing potentially malicious traffic.
This creates an ideal setup in that we can easily share pcaps to provide
network traffic of interest without having to spend the time setting up
Suricata within a real network. By replaying to the dummy interface,
Suricata will see it as live traffic, allowing it to generate metadata,
as well as any alerts.
The use of the dummy interface also prevents other operating
system traffic from showing up in our logs,
keeping us focused on the traffic at hand.
Another mode of operation for Suricata is offline mode in which
Suricata will process network traffic and pcap files.
One of the biggest drawbacks to this approach is that Suricata
will generate data based on the timestamp from the pcap, so if
the pcap is several months old,
we'll have to adjust all of our filters or queries to see
that traffic. By the end of this course,
you'll have a great understanding of Suricata's different modes of
operation and how to set it up based on your needs.
What else does the training VM include? A full Ubuntu
LTS graphical desktop environment, popular text editors, such as vi and nano, jq,
which is a common tool for viewing and processing JSON data. Since Suricata's
main log file is in the JSON format, this tool allows us to efficiently view
and query its contents. And finally, EveBox,
which is a web‑based GUI for viewing and searching Suricata data.
Suricata generates a lot of output,
everything from alerts to network metadata, such as DNS
requests or HTTP request‑response.
In fact,
this is one of the primary reasons to run Suricata, to generate this
output. In a basic production setup, Suricata output can be seen in
/var/log/suricata. You can view this folder in the training VM to get a
sense of what files and what data will be present there. In
/var/log/suricata, there are a few files that are worth pointing out
before we get too far into the course.
The first, and primary, is eve.json. This file, in the JSON format,
contains the data for alerts and other network events.
Don't worry if you're not familiar with JSON,
you'll have plenty of opportunities to gain
experience with it throughout this course.
Fast.log. This is a simple text file that contains only alert data.
This may be familiar to those coming to Suricata from other intrusion
detection systems. Stats.log is a text file in tabular format that
contains metrics about the Suricata engine performance.
Suricata.log is a log file from Suricata itself,
which may include such information as startup errors. Filestore is
a directory where extracted files can be found.
File extraction is not enabled by default,
but we'll cover how to do this in more detail a little bit later on. Now
that you have an idea of where all of this data lives,
let's take a look at it in our training VM in our next demonstration.