In this demonstration, we're going to learn how to start,
stop, and restart Suricata.
We'll then take a closer look at how to use Suricata's
offline mode to ingest the pcap.
This mode is in contrast to the method we previously
discussed in which we use tcpreplay to replay the pcap
against the dummy interface we have set up.
We'll also discuss Suricata output in more detail and begin to explore how
to use the jq utility to work with this output directly.
In the training VM,
Suricata is already installed and set up as a service
to start when the system boots up, but to check the status of Suricata,
you can use the command systemctl status suricata.service.
The output will show you the status of the service.
Green indicates that it is active or running.
If you see white, that indicates that the service is inactive,
while a red color indicates that the service is in an error state.
After the initial information about the service,
you will also get the first few lines from the log files,
which may help with troubleshooting should an issue ever arise.
To exit, you can now press the Q key.
To stop the Suricata service,
we use the command sudo systemctl stop suricata.service.
Since this requires administrative privileges,
you will need to use sudo to run this command.
After stopping the service,
we can use the status command to verify that it is indeed stopped.
We can now see a white dot which indicates that the service is now inactive.
To start the service again, we can simply use the start command,
and then check the status to make sure that everything is back on track.
While you should still see no issues with the Suricata service at this point,
if you do get to a point where you're modifying the configuration,
you will want to verify it was able to start as errors in the
configuration can prevent Suricata from running.
Now, let's take a look at Suricata's offline mode.
We previously explored how to replay pcaps to
Suricata using the dummy interface.
This utilizes Suricata in service mode.
For offline mode,
we'll be able to use Suricata to process the pcap itself and
will not depend on other utilities for replay.
Let's take a look at this script by opening
suri‑ingest‑pcap in your favorite text editor.
This script is also fairly straightforward.
The beginning checks that you are running as a root user and then
also checks that you've provided a path to a file.
Take note, it does not validate that that file that you provided is a pcap
so always doublecheck if you run into any issues. Next, the script will
clear the logs at Suricata's default log location,
var/log/suricata.
Now,
this is a slight deviation from what we discussed in the
slides. Suricata's default behavior is to use the directory it
was executed in to place log files.
So if we run this script from home/suricata/training,
then that is the location where the logs will be created.
However,
you can define a log location using the ‑l command when invoking Suricata.
When we invoke Suricata in the script,
we override this default behavior to use the path,
var/log/suricata.
Now you may be asking why we do this. Well,
the reason is to keep the training VM as simple as possible. This
way ensures that no matter how you replay a pcap,
we're using consistent log locations throughout.
If you'd like to experiment,
feel free to, I would just suggest making a backup of
anything you modify first though.
Next, the script restarts the evebox service.
Now we haven't gotten to evebox quite, yet but suffice it
to say that this helps ensure that there are no remnants
from previously ingested pcaps.
Finally,
Suricata is told to ingest the pcap. To get only alert data, the
script uses grep to filter alert entries from eve.Jason, and
then jq to filter the resulting JSON, as well as to provide much
prettier looking output.
Let's now run this script to see how it all comes
together. To test this script out,
our command will be sudo ./suri‑ingest‑pcap.sh and then the pcap that
we want to execute so demo‑s02‑04. Now where the replay script will
take time based on the size of the pcap, this script will require an
additional delay as the Suricata engine has to load. This overhead is
avoided when running in service mode. You'll also see output from the
engine itself, such as the version and any initialization information.
And just as we expected based off of our analysis of the script,
we have our results and it's specifically filtered the eve.json file
to provide us with any alerts that were generated.
Now while the script only queries for alert data,
there is a lot more available in the eve.json file, so let's spend a couple
extra minutes scratching the surface on that data. To help further highlight
Suricata output, let's run Suricata in offline mode without the help of the
script we just discussed. We'll use the same pcap,
but we'll adjust our command to be sudo suricata ‑r that tells the
engine to run in offline mode so we have to provide the path to our
pcap and then ‑l, this is a new log location.
So in the current directory,
I created a temp folder using the make dir command, and we'll provide that
then as the value for the ‑l argument. As with the previous command, we'll
get the same type of information being generated by Suricata as it's loading
the engine and parsing the rulesets.
We also get confirmation that it was able to process the pcap file
that we provided in the last line of output in that it's indicated
that it not only read a pcap file, but the number of packets and
bytes that it processed.
We can now change to the temp directory, and looking inside the content,
see all of our primary output files,
eve.json, fast.log, stats.log, and suricata.log.
Let's focus on exploring data from the eve.json outside of those
alerts. The command we'll use is to grep for event_type http from
eve.json. We'll then use the vertical pipe to redirect that output to
jq. After executing that command,
you'll get quite a bit of output and this output now shows all of the HTTP
data, as well as some additionally generated data that Suricata has
produced. Some of that additionally generated data could be the community ID
which can be used to correlate different data sources, and we'll explore a
little bit later in the course.
Other information comes from what was available from the original HTTP request,
particularly in the headers, as well as the request and response body content.
As valuable as alerts are, you will often need to build context by viewing
other network activity around the same time an alert is generated, and
Suricata provides you with the data to do just that.
This is just a small example of the data Suricata outputs.
We'll continue to explore what data is there and how you can
utilize it throughout this course.