We've covered deployment modes and discussd network placement, now
let's revisit rule management and ways that you can customize the rules
in your environment using suricata‑update.
It's a common task to modify rules in your environment to fit your
needs. In this video, we're not talking about creating custom
rules, but modifying rules you want to consume from sources like
emerging threats or other vendors.
Before you can begin modifying rules,
you first have to know which rules you want to modify
and how you want to modify them.
Let's start by discussing how to match on rules.
This can be accomplished by Signature ID, regular expression,
rule group, and filename. First is by Signature ID. This is
quite straightforward and you can determine the Signature ID by
looking at the rules file.
The ID will be defined by the SID keyword.
Next is by regular expression, everyone's favorite.
This will match a regular expression over the complete rule. In this example,
if the rule contained the string heartbleed,
it would match. Group matching is also available.
Group matching provides matches against the group the rule
was loaded from. This is essentially the file name without
the leading path or file extension.
Finally, you can match via filename.
The filename matcher matches against the filename the rule was loaded from,
taking into consideration the full path. Shell wildcard patterns are
allowed. In this example, any file with deleted in its name would match.
Once you've determined how you want to match on your rules, you're ready to
modify them. Modification comes in the form of a basic pattern utilizing
regular expression's search and replace. The basic format is which rules you
want to match,
which we just discussed. From is what you want to match in the
rule, to is what you want to replace it with.
Here is an example that uses a regular expression that
changes all rules from alert to drop. Configuration files
also have an order of application.
This determines how modifications are applied to rules,
as well as to give you a heads up that a later change may
override an earlier change.
The order is disable.conf, enable.conf, drop.conf, and finally, modify.conf.
Going in the order of application,
we'll look at disable.conf first. Disable.conf will disable
any matching rules from your rule sources.
Here's an example of disabling a rule by SID, or signature ID. This example
matches directly by signature ID. Keep in mind that the hashtag comments out
the line, so you would also need to remove those or create new lines without
them for the changes to take effect. Enable.conf is also very similar, it just
does the opposite of the previous by enabling rules. You can use the same
methods of matching rules that we discussed previously. Here we have a couple
of examples.
The first is using the SID, while the second is an
example of using regular expressions.
Drop.conf changes rules to drop rules,
which drops the traffic at the sensor. Here are similar examples using the
SID and regexs. Modify.conf modifies rules and uses the modification pattern
match from two that we discussed previously.
Here are a few examples. In the first, it uses the SID to match the rule,
then regex to change the seconds' value to 3,600.
You can also see examples of changing all alert rules to drop,
and drop rules with no alerts back to alert.
Noalert is a keyword that allows a rule to match,
but does not generate an alert.
These are often used with flow bits.
Once you're ready to change your rules,
you just need to run suricata‑update again.
Don't forget, you may want to test your modification in a QA environment first.
Now that you know how to make rule modifications,
let's go through a quick demonstration.