Writing your own Snort rules can be a lengthy process.
You need to determine what traffic you want to generate an alert,
the features of Snort you want to leverage, and how to configure
those features to detect specific threats.
When hundreds of preconfigured rules are available,
you might be asking yourself, why would I want to write my own rules anyway?
Well, in this clip,
we're going to cover a few examples of why you
would want to write your own rules, as well as a scenario where this is applied.
Before we do that, let's do a quick review of the preconfigured rule sources.
You can obtain Snort rules directly from snort.org
in three different categories.
The first set, community rules,
can be loaded into Snort for free without registering for an account.
These rules are written for a variety of threats and are
mostly commented out when you obtain them.
Another free set of rules are registered rules. These air obtained by
setting up a Snort account and getting an oinkcode,
which you can use to download the rules to your server.
The last rule category is subscriber rules,
which are available by paying a regular fee and downloading them to your server.
With all these options,
you can get a Snort server running that will detect a variety of threats.
So why write your own rules, especially if this can be a difficult process? Well,
to start with,
you may want to configure rules that are not in the
Community, Registered, or Subscriber Rulesets.
These are good lists,
but they're not necessarily composed of all the potential threats.
The cybersecurity field is an ever‑escalating arms race with
new threats under continued development.
Being able to write your own rules to respond to a new threat
quickly will help keep your network more secure.
You also need to detect threats specific to your organization
that are not covered by these rulesets.
Another reason why you should learn this skill is that the community and
registered rules generate numerous false positives.
That's why most of the rules are commented out when you first
load them into Snort. Knowing how to rewrite these rules or
create a better custom rule is valuable in maximizing your time
spent following up on each alert.
Finally,
you can write your own custom rules for your organization's
internal acceptable use policies and monitor the traffic from
your internal out to your external network.
These can include alerts on specific applications.
Let's take a look at an example scenario where a custom rule was useful.
In this scenario, an attacker generates malicious traffic,
which is sent to our network and generates an alert based on a
Snort rule as expected. The problem arises when legitimate traffic
is also destined for our internal network, matches the same rule,
and also generates an alert.
Although we detected the malicious traffic,
we should minimize these instances where alerts are
generated on legitimate traffic.
This is an example of a false positive alert.
We want to avoid these kinds of alerts if possible, because although
we did see an alert on genuinely malicious traffic,
we will now have to follow up on this false positive as well,
only to find out that the traffic was fine.
Most traffic destined for our network is going to be legitimate,
and depending on the type of traffic generating this alert,
we'll likely find ourselves in two situations in the future.
Either we will be continually chasing down the false positive alerts, or
we'll become complacent and start to ignore the alert,
making it ineffective.
No matter the outcome,
this rule needs to be refined, or a new one should be written that leverages
additional options to specifically target the malicious content we are hoping
to detect. Throughout this course we'll be creating custom rules to detect
specific traffic based on our security goals.
We'll start with the basics in the next clip and build to
rules that leverage options in both Snort version 2 and
later the new features in version 3.
These features will allow us to create custom rules for specific
traffic types and avoid situations like this scenario where
numerous false positives are generated.