[Autogenerated] So for this demo,
I'm remotely connected to a Linux server which has the Apache web
server installed and is configured as a reverse proxy.
I've also compiled and installed mod security and the Apache connector.
I generally recommend compiling versus using packaged versions of mod security.
Since you can update the software much faster if there's a public
vulnerability instead of waiting on the vendor to update the package,
notice that I've also enabled mod security and created a rules file
that currently points to the recommended mod security,
default configuration file.
We will take a look at this file a bit later.
I left most of the defaults for this installation except for what I
need to change for a reverse proxy configuration.
Keep in mind that mod security on its own does not
protect your web applications.
You need to either add your own custom rules or use rules
developed by a third party for this demo,
I will show you how to leverage the open web application security project.
Core rule set First,
I'll use w get to download the current version of the rules and extract it.
Then I will change to the extracted directory and rename a
copy of the example Core rule set setup file.
Now I'll open the setup file so you can see some of the configuration options.
This main configuration file will allow you to control how the cRS will
perform some of the features you can control with this file.
Our mode of detection anomaly scoring severity levels,
anomaly scoring threshold levels, paranoia levels and alert login.
The mode of detection choices are traditional and anomaly scoring where
the latter is the default and the more advanced system,
The traditional mode, also known as self contained,
is the most basic mode where each rule is used in isolation or self contained.
There is no special logic or intelligence in this mode.
If a real triggers it takes the designated action
without regard for the previous events,
anomaly scoring uses collaborative detection and delayed blocking.
What that means is that when a rule matches,
it also looks at the full context of the HTTP transaction that have happened,
including previous rules that have matched and uses a scoring
system to determine when to block the traffic.
The scoring system uses severity levels that can be adjusted and
eventually a scoring threshold will be hit.
That triggers the blocking functionality.
I should mention that there is a threshold level for inbound
traffic and one for outbound traffic alert,
logging control allows you to have mod security log its
audit messages to the web servers,
error log a separate mod security audit file or a combination of the two.
I will believe in most of the settings in the default configuration.
So you can see that it provides pretty good coverage out of box.
Let's scroll down a bit further and we'll find that the default
setting logs to a separate mod security audit file and the web
server error log since the default mode is anomaly scoring the
last instruction is passed.
If we continue our journey down this configuration file,
we arrive at the paranoia levels which range from one to the default level four.
Each level will increase the number of rules that get enabled.
You may be tempted to increase the paranoia level to four
for the most protection but this can introduce false
positives or service disruption.
You need to test it in your environment and see
what level is appropriate for you.
This is where you would update the paranoia settings.
This is where you update the severity levels and if
you want to update the thresholds, this is where that is done.
The last configuration I'll cover here is for application specific exclusions.
For instance, if you have a wordpress site,
the core rule set has already defined some exclusions that could benefit you
and all you need to do is enable the appropriate settings.
Okay,
now let us look at the rules file we saw referenced
at the beginning of this clip.
This is a file I created to make the different mod security,
configuration and rule files easier to manage.
The first line I added immediately after installing mod security.
Now I'm going to add the configuration lines necessary to allow
mod security to utilize the core rule set.
The first line is the setup file we viewed a few moments ago and the
last line points to all the rules if you have engineers that can
develop custom rules for your organization,
then those can be placed below.
The last thing we'll look at is changing mod security's default behavior.
I'm going to open up mod securities configuration file at the top.
There's a configuration directive that places mod
security in a detection only mode We need to change this
to on then restart the web server.
Now we're ready to test mod security.
I'm going to switch to a Cali box and run a curl command that will try
to connect to a web app I have in the lab environment but remember all
requests will go through the reverse proxy,
which is the Apache web server using mod security.
So for this curl command using dash S will clean up the
output so we don't see the progress meters.
The dash L will tell curl to follow the redirect from the proxy.
I'm adding the slash bin slash bash portion to the URL to
simulate a command injection attack.
Okay.
We can see from the output that we got a 403 as expected.
Let's switch back to the proxy server and look at the audit log.
Great.
So things are working as expected.