Now, let's turn our attention to common Suricata operations.
Regardless of how you intend to deploy or set up Suricata,
there are a few common tasks you will need to know.
This includes starting and stopping the engine,
as well as getting to know how to update the rules it is using.
And finally, how to reload those rules.
The last two operations really just boil down to managing rule sets.
When running in service mode, which is how the training VM is set up,
you can use systemd to start and stop the engine.
To start, run the following command with the privileges from a terminal,
systemctl start suricata.
If you are not using the root account,
make sure to preface this command with sudo.
Similarly, you can use systemd with the stop command to stop the engine,
systemctl stop suricata.
Oftentimes,
you won't want to have to worry about manually starting
or stopping Suricata as a Service, for example,
after restarting a system.
You can also use systemd to disable the Suricata service
using the command systemctl disable suricata.
To enable Suricata to start as a service on system boot,
use the command systemctl enable suricata.
Similar to starting and stopping,
you will need root privileges to execute these commands successfully.
While many see Suricata as a tool to use on live network traffic,
it can also be used to process PCAP files.
This can be helpful when experimenting, learning,
performing malware analysis, or executing proactive threat hunting.
To run Suricata in offline mode, that is to process a PCAP,
use the ‑r argument and provide a path to a PCAP file or even a
directory containing PCAPs you want to process.
Since you will be manually invoking Suricata,
the current directory you are in will become the default log location.
It is quite common to have multiple instances of Suricata set up for testing
or experimentation along with the production deployments.
The training VM is set up to minimize the time you
have to spend configuring Suricata.
Out of the box,
you should be able to follow along with all the demos and
labs without further modifications; however,
when you begin experimenting with Suricata in your own environment,
you may need to tell Suricata which interface to listen on.
This can be done one of two ways.
The first is interactively through command line arguments.
The other is through Suricata's primary configuration file suricata.yaml.
In this example,
the ‑i argument is provided and defines an interface named dummy0.
This tells Suricata to listen on the interface dummy0.
When running Suricata to listen on live network traffic,
this is also known as system mode.
The Suricata configuration file contains a lot of options,
so to get started,
there are only a couple of really important pieces of
information that we need to ensure are in place.
The most important is the HOME_NET variable.
This is defined at the beginning of the configuration
file and uses all uppercase letters.
This variable defines what IP addresses you expect to be in your internal
network and by default uses the RFC1918 address space.
The most important aspect of this variable is that it
accurately represents your network.
Now this is already taken care of in the training VM,
but one of the first deployment considerations you need to make
when you start rolling out your own Sakata setup.
There are other variables worth considering as well,
such as EXTERNAL_NET, which is the negation of HOME_NET.
This makes sense. Any IP not considered internal will therefore be external.
You can also set other variables such as the IP address of web or HTTP_SERVERS.
As you'll see, these variables play a crucial role in when alerts are generated.
Let's now take a look at some of these common
operations in our next demonstration.