Hello! I hope you did your homework in the Introduction to Suricata lesson. If you have not completed that yet, don’t continue with this post until you have!

We’ll be dissecting the Suricata YAML file today.

Suricata has endless features, but the real power for a Cybersecurity professional comes from configuring it to best suit your needs. This is why understanding the YAML file is key, as it’s where the configurations take place.

Let’s get to it!

Head to the /etc/suricata directory and vim the suricata.yaml file:

There are thousands of lines, but we’ll focus on the highlights.

The first thing we see is the $HOME_NET and the $EXTERNAL_NET variables defined. These are the RFC-1918 defined internal non-routable IP addresses.

• That’s a fancy way to say they’re private IPs (notice that they begin with 192 or 172.)

One thing to note is that some internal networks use external addressing schemes. If that’s happening, update the $HOME_NET variable to represent their actual network.

Scroll down to “Step 2: Select outputs to enable”

This section configures two logs: the fast log and the eve log. The fast log is a concise overview of alerts, whereas the eve log is all of the recorded network traffic metadata stored in json.

Many lines are commented out. These are features you can enable if it suits your organization.

Now onto line 151. This covers the type of traffic we’ll view, categorize, and generate alerts on.

If you scroll down to line 266, you’ll see a list that highlighting which types of traffic will be recorded in the flows, documents, and alerts.

Some types, like SSH and HTTP, have more options for how the traffic will be monitored and recorded. It varies by the protocol.

Starting on line 304, the file deals with logs:

Suricata has endless options for storing logs on all types of traffic. If you feel they’re important to use, go for it.

Don’t forget that there’s always a tradeoff, though. These options take up disk space and reduce performance.

Jump to line 562:

These are the logging options available. The console logging and file logging options are standard.

• The console log shows information when running Suricata from the command line
• The file log shows what’s saved to the suricata.log file.

If you choose to daemonize a Suricata instance, the suricata.log file is a key tool for debugging. You will check it to see what errors are occurring with your daemon.

Now head to “Step 3” on line 581. This shows how we can configure our capture methods.

Here, I suggest leaving this exactly as it is. We’re going to specify —af-packet when running packet captures and —interface(equals)br0 when using a transparent bridge to capture traffic (check this lesson for more information.) These settings are extremely efficient, and they’ll work better than any custom configurations for 99% of networks.

Head to line 705. This covers the application layer protocols:

These settings are used in rules designed for protocols like SNMP and TLS.

One thing that’s disabled, but that I do recommend enabling, is JA3. It’s a tool that determines a site’s legitimacy based on its TLS signature. It’s susceptible to generating false positives, but it’s a good tool nonetheless.

Now head to line 1004. This is the beginning of the “Advanced Settings.”

There’s a lot we could touch on, but we must address line 1919- the rules Suricata uses.

This covers which rules Suricata will apply. When you add open source rules, you download the rule set’s file and add it to the rule-files list.

The other advanced setting you should know about are the memcap settings and CPU thread ratio. If you have performance issues, you can adjust those values up or down.

I hope you learned something valuable. Thanks for reading!