Well, we've come to the end of this course on writing Snort rules.
I hope you enjoyed each of the topics and demos and are feeling more
comfortable writing your own rules and leveraging the additional options.
Before we get into the course summary, I thought it might be helpful to provide
a few guidelines to consider when writing your rules.
A good Snort rule will not only match the traffic you're targeting,
it will accomplish this while maximizing speed and
efficiency and minimizing false positives.
The first guideline for accomplishing this is to use
the content option whenever possible.
This option is incredibly flexible.
Leveraging it and all of its associated features
could be a course in and of itself.
I think that it's far easier to learn by exploring it on your
own with specific vulnerabilities in mind.
This option not only reduces false positives,
it makes detection and packet processing more efficient.
The next guideline is related,
and that is to focus on the vulnerability you're protecting
rather than the specific exploit for it.
Focusing on a single exploit just makes it a little
more challenging for hackers,
but still possible for them to find another way to exploit your vulnerability.
We saw a very,
very basic example of this with the FTP backdoor rules we
wrote. We could have written a rule that checked for a full
username with a smiley face on the end,
focusing on what most guidelines for exploiting this vulnerability use.
Instead, we focused on the vulnerability itself, the smiley face.
If we wanted to improve it further,
we would try to isolate the packet where usernames are
sent and ignore all other transmissions.
The last guideline is that order matters. Due to the way Snort processes,
content matching and detects attempts to evade these rules, their manual
recommends placing the non‑payload detection options first. Without digging too
far into the details, this minimizes its recursive checks for content and
improves rule performance. Now that we covered the rule writing guidelines,
we're ready to move on to our course summary.
We began this course simply by discussing the purpose of writing our own
custom rules and a few scenarios where this is valuable.
We then wrote our first Snort rules based on security objectives to take a
few different actions for incoming remote access traffic.
Once we had the basic rule structure down, we leverage content
for payload detection and blocked attempts to trigger the back
door on the vulnerable FTP server.
We also added non‑payload detection options to discover
traceroute attempts and large ICMP packets.
Then we switch gears to Snort version 3 and introduced the active
response and appid capabilities into our process.
After writing a total of 11 custom rules,
we departed from our local.rules file completely and configured file
processing to detect and block known malicious payloads.
Before you go,
I want to leave you with the next steps on your journey to mastering Snort.
To really understand the rule writing process and improve your capabilities,
I recommend continuing to refine and test your rules.
The rules that we built in this course was created
exclusively to show some of the capabilities.
We certainly didn't cover it all. These were meant to build your confidence,
establish a process, and inspire you to explore what Snort can really do.
I would also recommend that you explore each version of Snort.
I built this course using the newer version at the time,
but Snort version 2 is still primarily being used as
version 3 continues to develop.
If you use version 2 to follow along,
I hope that the section on version 3 got you curious about its capabilities.
Besides,
it's always a good move in the IT or security field to
become familiar with the latest versions,
even if you don't use them every day.
Finally,
I recommend that you introduce new options that you'll find
in Snort's manual, find an associated exploit, and try to
configure Snort to detect it.
To maximize the usefulness of this course,
I couldn't dive deep into features like bite tests or bite
jump as the associated exploits would be too complex and
take the focus away from Snort.
I also firmly believe that the best way to learn is to try out
these more complex features on your own.
I hope you enjoyed this course on writing Snort rules,
and if nothing else,
I hope you're eager to learn more about Snorts features and configuration.
If you enjoyed running the few exploits used to test the traffic,
I'd also recommend watching the red team tools short courses
or Pluralsight's ethical hacking paths.
Good luck on your information security journey, and I'll see you out there.