By Josh Williams.
The release of Snort 3 brings with it some exciting changes in rule syntax and capabilities. These changes will make our rules easier to read and understand and will increase in speed. Before we get into these new changes, let's talk about what's staying the same. Cisco Talos will continue our current rule release schedule of Tuesdays and Thursdays with periodic additional releases when major vulnerabilities or malware appear in the wild.
While moving to Snort 3 comes with a lot of improvements, we also understand that not everyone can switch over right away. We plan to continue releasing Snort 2 versions of rules until seven to 10 years after Snort 2's end of life. This will allow any users who can't upgrade quickly plenty of time to get everything in order. The only downside is that they'll be missing out on Snort 3's improvements.
Now that we've discussed how things are staying the same, we can dig into the exciting ways we'll be using the new rule syntax and engine to improve detection.
The first major improvement I want to talk about is in the rule header. Previously, a rule header would look something like:
"alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any ("
This is fine if the traffic is always traveling in the same direction to/from specific ports. But with malware and vulnerabilities that involve files, we need multiple rules to cover all the different ways that a user could receive files. That's no longer an issue with Snort 3. A new file-based detection rule header will look like:
"alert file ("
Not only is this much easier to read and write but it will slim down the ruleset substantially. On top of saving space, this will also enable Snort 3 to run more quickly, since it will have fewer rules to parse and consider. This example also points out that nets and/or ports can be omitted from rule headers when they aren't needed. This will further decrease the size of rules.
Another improvement that I'm fond of is sticky buffers. In the past, when specifying buffers for a specific content match or other rule option, you would have to specify the appropriate buffer after each match. This could often lead to errors in rule creation and make rules harder to read. Now, a buffer is specified before the series of rule options that use it and is the buffer in use until otherwise specified. Instead of:
content:"foo"; http_uri;
content:"bar"; http_uri;
content:"key"; http_client_body;
content:"value"; http_client_body;
Snort 3 rules look like:
http_uri;
content:"foo";
content:"bar";
http_client_body;
content:"key";
content:"value";
While the second example uses more lines for readability, you no longer need to keep repeating the buffer that concerns you — just specify it once and move on. Not only are buffers now sticky, but we've increased the available buffers to help anchor our rules to what’s important. This includes the ability to specify fields in an HTTP header rather than just checking the header. For example:
http_header:field user-agent
content:"Malware";
While this might seem like a simple change, it will alleviate some headaches moving forward.
The final thing I want to mention about changes to our rules is the inclusion of file decompression. Snort 3 will decompress files before inspecting them, which is just another thing that will improve our detection capabilities.
If you're interested in learning more about writing Snort 3 rules have a look at the excellent video created by Brandon Stultz over on Talos’ YouTube page.