In this demo,
we'll discuss how to use the enable.conf and disable.conf files to
enable and disable rules using multiple techniques.
We'll enable and disable rules using the signature ID,
regular expressions, and group names.
Let's head over to our Suricata server and get started.
The first step we need to take is to move some example
configuration files over to our etc/suricata directory so that
we can use them in the next two demos.
Once this is complete,
you should have the update.yaml file along with the drop.conf,
modify.conf, enable.conf, and disable.conf all in this directory.
Let's take a quick look at the update.yaml file and see how it's constructed.
Within this config file, we can see the different paths to our enable,
disable, drop, and modify.conf files,
as well as a statement to ignore anything that says deleted.rules.
Further down,
we have other options that we could uncomment to
specify a particular test command, reload command,
or hardcoded URLs to different sources and our local.rules files.
Now that we have the files we need,
we're ready to use the enable and disable.conf files to make some rule changes.
Let's start with the enable.conf.
Within this config file,
we see an example of how we can enable rules by signature ID
simply by putting the signature ID in here.
When we were evaluating the emerging threats rule set,
we saw a ProFTPD rule that might be valuable for our environment.
It was actually commented out.
So let's go ahead and enable that one by signature ID.
The signature ID for that rule was 2011994.
Next, let's try enabling a rule by regular expression.
For that,
we use the statement re followed by a colon and then use
a regular expression to enable them.
For this, let's enable any rules that contain the statement Nmap by regex.
Now that we've used two techniques to enable rules,
let's go to our disable.conf file and disable a rule group.
We'll just save that.
Exit.
Now we'll just edit disable.conf.
And following the format of this example, let's disable the group emerging‑info.
This will disable all the info rules within the emerging threats rule set.
So again, we'll save that and exit.
Now we're ready to run a new suricata‑update command.
So let's go ahead and run that and see what happens.
Going through the output,
we see that it found our update.yaml file and used that configuration.
It used our four new config files, disable, enable, modify, and drop.
And it tried to fetch some new rule sources.
Since those local rule files failed,
we'll go ahead and comment those out in a minute to
fix this issue in the future.
We also see a few changes down here.
It disabled 604 rules and enabled 19; whereas before it said 14.
So our new count is 34,066 total rules, 26,119 enabled.
It added 3,885 more from one of our new rule sources and modified 572.
So it looks like it was successful.
Let's go ahead and clean up our update.yaml file to remove some of these errors.
We'll leave the SSL blacklist rules,
but we'll go ahead and comment out these bottom two rules.
But for this local.rules file, we actually have one.
We just need to change the directory to our local.rules file,
which is at this path here, usr/local/share/suricata/rules/local.rules.
Let's now save that, and let's go ahead and run suricata‑update one more
time to make sure that we cleared out most of those errors.
Much better.
Our errors that we saw in the last one are removed, and we
still have our extra source that was added by URL. Now that we
see how to make changes to enable and disable.conf using a
couple of different techniques,
we're ready for the next demo where we'll use modify and drop.conf to
make a few other changes, and then we'll run some tests.