The .yaml file
We’re going to dissect the Suricata YAML file! There’s so much power in Suricata due to its vast array of features, but being able to enable and maximize all of it’s features depends on the configuration of the software. That’s where the YAML file comes into play. So let’s VIM suricata.yaml and see what we see:
This is only the first 53 of 2167 lines! So, we’re only going to hit the most important aspects. Anything not explicitly mentioned should be researched before adjusting, unless it’s a test machine in which you should be messing around and finding out 😉
So firstly, we can see the $HOME_NET AND $EXTERNAL_NET variables defined. Some rules will use these variables, and surprise, surprise, the home net variables are the RFC-1918 defined internal non-routable IP addresses for the most part.
Section 2:
Here we won’t be editing anything , but I want you to see what’s going on here. There’s the fast.log and the eve.log. The fast.log is a brief overview of alerts while the eve.log is a complete capture of network traffic metadata stored in the JSON format.
Notice that there are a bunch of things commented out. These are features you can enable if it suits your enviroment but, it’s not necessary to know or how to implement them.
Next, we’ll jump to line 151. We will be seeing the types of traffic we’ll be viewing, categorizing, and generating alerts on.
A little further down, we can see that there is this large list – essentially, this will identify these types of traffic in the flows, documents and alerts:
Similarly, we have some like “ssh” and “http” that will give more options for what types of characteristics of the traffic will be monitrored and recorded, and this will vary on a protocol by protocol basis.
On line 333 we have logs:
Suricata has a lot options to store logs on lots of different types of traffic. These are cool but have some disadvantages:
- They take up disk space
- They reduce performance
So, if you feel you need them, remember there’s a significant tradeoff.
Let’s jump to line 587:
There are a bunch of logging options available to choose from. The console logging and file logging are standard. The console being the info displayed when running it from the command line and surucata.log file being what’s saved to the log file.
We now move to Section 3 on line 607 and find out how we can configure out capture methods:
We are going to leave everything as is. This area can be configured to make our default modes incredibly efficient for capturing network traffic.
On line 852, we now see the application layer protocols and the breakdowns of those as such.
They are going to be used in rules that specify protocols like TLS, SNMP, Telnet, etc.
Once we go to line 1183, we end up having 1000 lines of “Advanced Settings”
The most important setting we need to touch on is – the rule file
This outlines what rules are going to be parsed. The only other advanced settings we should be aware of are the memcap settings that are scattered throughout the file, also the CPU thread ratio. In the event you experience performance issues, these are values that can be adjusted up or down but would require a lot of tinkering with, and shouldn’t be an issue in this day and age in your small or enterprise organization as CPUs have become incredibly powerful. That’s all for this one folks. Stay tuned 😀 god bless!