In this demonstration,
we're going to take a look at making changes to Suricata's configuration.
First up, let's disable the fast.log.
We'll assume that nothing is consuming it,
and therefore, it doesn't need to be generated.
You can cap the content of fast.log.
We'll be looking at service mode logs, and you'll find those in var/log/suricata.
You'll likely see alert messages from our previous pcap replace.
If for some reason you don't,
feel free to use the replay script to replay a pcap, almost
all of them should generate alert data.
Next,
let's simply empty this file by echoing an empty string
and redirecting to the fast.log file.
Since these are service mode logs, you'll need to be root to do this.
Cat again and you should see that the alert messages are now gone.
Before we make any changes to the configuration file,
it's a good idea to save a copy of it.
This way, you have something to not only compare against,
but also restore to in case you make a mistake.
How you do this is up to you.
To keep things simple though,
I'll just copy the file and append a .bak extension to it.
Next,
open surakarta.yaml with a text editor and with root
privileges using the sudo command.
Search for the fast.log section under outputs and then
modify the enabled value from yes to no.
We can now save our file and exit out of our text editor.
When making config changes,
it's a good idea to test those changes to ensure that nothing will break.
If you've noticed,
Suricata update does this as one of the last items during the update process.
To test the config, you can use the ‑T argument, uppercase T.
This will use the default configuration file and let you
know if any errors were encountered.
Also notice how long it takes Suricata to initialize.
Before it is done, it's not ready to process traffic and generate data.
When you restart Suricata as a service, which we'll do shortly,
you need to give it a couple of minutes to initialize before
you can expect it to process your traffic.
Keep this in mind as you make changes and go to replay pcaps.
If you aren't seeing any data,
it may be that Suricata just isn't quite ready for you.
Looks like we're all set.
No errors were printed and we received a message indicating that
the configuration file was successfully loaded.
After we've made changes to the configuration file,
in order to apply those changes, we'll need to restart the Suricata service.
Let's use systemd to do that.
And as I mentioned,
let's give Suricata a couple of minutes to
reinitialize before we replay our next pcap.
Now we're ready to replay a pcap that generates alerts.
We'll use the replay script along with the demo pcap.
And there are the alert events from the eve.json file.
However, if you cat fast.log, it should remain empty,
and that's it, our first configuration change.
Let's move onto something a bit more complex now.
Let's now take a look at the difference between logging and parsers.
From the previous pcap, there are several DNS event records,
and we can grab grep the log file and pipe the results through
jq to get a sense of what data is there,
but how does Suricata decide what data to log?
Open the configuration file in a text editor and
navigate to the eve‑log section.
This will be located right under where we just disabled the fast.log.
Under this section defines what data will be logged in the eve.json file.
Let's say that we want to disable logging of DNS.
You can disable logger output by commenting out the
line‑space and then the protocol, in this case,
DNS.
By commenting it out, we just add a hashtag.
After making the change, just as we did with the fast.log,
you can save the file and then go ahead and restart Suricata using systemd.
If we replay the previous pcap, we'll still see alerts,
but won't find any DNS records in the eve.json file.
Using the same grep command, we no longer get any results.
So why was an alert still generated?
Well, this is due to the fact that the DNS parser is still enabled.
Let's look at this rule and do so by modifying our jq to
show the signature and signature ID.
Now let's grep the rule file based on this sid 2022918.
As a reminder,
Suricata update will write the rules file to
var/lib/suricata/rules/suricata.rules.
This rule uses the dns.query content modifier to match on a .duckdns.
string.
So if the string shows up in the DNS query,
then it will generate the alert, but what happens if we disabled the DNS parser?
We can always try.
In the Suricata YAML, you'll find all the parsers under the app layer section.
DNS parsing can be done over both TCP and UDP and each can be enabled/disabled
by changing the enabled value from yes to no and vice versa.
Let's open up the Suricata configuration file and make some modifications.
As you can see,
we are at the app‑layer section of the Suricata configuration file.
We can scroll down until we find the protocol that
we're interested in modifying, in this case,
DNS.
You'll notice that some protocols simply have an enabled option,
enabled yes or enabled no.
Others like DNS provide additional configuration such as
what protocol to enable DNS parsers on, TCP or UDP.
While we could disable the DNS parser under both protocols,
this actually will impact the use of Suricata update,
which you'll see in just a moment.
So instead, we'll add an enabled no under the main protocol.
This will override the other enabled values under
the protocol specific sections.
Let's save the file and exit.
Now, if we test the config, you'll see a bunch of errors.
Testing the configuration in this way is very strict and not all error
messages mean that Suricata won't run just fine. In this case,
since the rules were trying to load depend on this parser,
Suricata is letting you know there is a problem.
The good news is that this won't actually prevents Suricata from running.
All we need to do now is run Suricata update. Suricata update
will recognize this change in the config file and disable any
rules that it impacts for us.
As you can see, a Suricata update is running,
it's already notified us that it's disabled a considerable number of rules.
Once it finishes, we can restart Suricata and now the DNS parser logs
and any resulting data will no longer be available.
So it looks like Suricata update says we're ready to go.
We've gone ahead and restarted the Suricata service.
We can now run the previously analyzed pcap through Suricata again, and this
time, we should not see any alerts, and there are results.
No alerts were generated since we had no DNS parsers.
This is just to give you some ideas as to how Suricata
works and how you can customize your setup.
Keeping DNS records is usually very valuable data to have
for not only alerting, but for incident response or
investigating network activity.
Ultimately, it will be up to you to get to know your network and decide what
data you need and what parsers you should or could disable.
The last thing we'll look at is the BPF filter.
Let's start with an example.
We'll play a pcap using the ingest script that has UDP traffic.
Not only will this generate flow records,
but also several alerts, and there are those alerts I mentioned. You can
also grep the eve.json file and see the flow records. To create our
filter and ignore this traffic, let's create a sample file in the
training directory called bpf.example.
The name is really arbitrary. In this file,
I'll tell it to not monitor UDP traffic on the local /24 network.
This will match the pcap we'll replay,
but in a real‑world scenario, it would present a segment of your network.
You can read about the BPF syntax online.
This is just to show you how to use this with Suricata,
Save the file and close. Next, we'll modify the suri ingest
pcap script to include this BPF filter.
I'm going to avoid modifying our service mode instance as that would take just
a little more tweaking, but be very similar in approach.
We're going to add the argument ‑F and the path to your BPF file.
Now save and close this file.
You can now run the ingest script again with the
same pcap and you'll see no alerts.
This is that BPF filter in action.
You can also grep the eve.json file and there will be no flow records either.
So now you have a better understanding about Suricata's loggers and
parsers and how you can begin to customize those based on your
environment, we're now ready to move on and continue to explore the
metadata that Suricata generates.