Securing Apache Server Using ModSecurity OSWAF
In This Post We Will Teach You How To Use ModSecurity: Open Source Web Application Firewall To Secure Apache Server From Top Ten OWASP Most Critical Web Applications Security Risks.
ModSecurity: Free & Open-source Web Application Firewall
ModSecurity is a Free & Open-source Web Application Firewall for Apache. It started out as an Apache module; it still is but you’ll see why I’m saying it’s extremely powerful. It’s grown into almost a fully-fledged Web Application Firewall.
So, how exactly does a WAF work or really how does any Firewall work? Well, it does this by inspecting a request that is being sent to your web server in real time then ofc using predefined rules to actually decide or come to a judgment that’s too whether or not this request is malicious or not.
So, for example If I request a webpage on a web server & it’s a standard webpage, nothing wrong with it then the web server responds & allows me to view the particular web page. Now with modSecurity in place, if an attacker starts performing attacks like Cross Site Scripting Attack, SQL Injection Attack, modSecurity is analyzing these requests and it’s going to be looking for these particular requests & it’s going to be blocking them. This will work in conjunction with particular core rule sets that will be used. In this particular case we’ll be using the OWASP core rule set.
Installation: sudo apt install libapache2-mod-security2 -y
Activating Header Modules: a2enmod headers
When we talk about modSecurity or Firewall in general, we need to have rules.
Rules essentially control what happens and what doesn’t happen. In this case it will control what requests get accepted and what requests get blocked based on whether or not they are malicious.
The rules that we’re going to be using are the OWASP modSecurity Core Rule Set:
Top Ten Web Application Security Risks:
By Default, we have some default core rule set:
ls -ahl /usr/share/modsecurity-crs/
In this particular case we need to remove this particular rule set & replace this with our own OWASP modSecurity Core Rule Set:
Now, we need to rename the Core Rule Set configuration file:
We can take a look at /rules. The Rules essentially contains a list of exclusions for particular web applications. All of these rules are targeted for particular web applications. These rules here pretty much guarantee a good level of security for your web server.
Now, we need to take a look at the actual configuration for ModSecurity, we need to rename it. We can also modify it based on our needs.
This is the default modSecurity configuration file. In order to enable Active Blocking or Active Exclusions using ModSecurity, we need to change the Security Rule Engine to On instead of DetectionOnly.
In its current state, when the attacker sends malicious requests the only thing ModSecurity will do is it’s going to detect it, it’s not going to block it & we want to enable the Security Rule Engine by typing On.
That should enable the Security Rule Engine within modSecurity.
Now we’ve already set up the OWASP modSecurity core rules set now we need to enable modSecurity within Apache.
We need to modify the default Apache configuration file, this already is explained within GitHub repo if we take a look at the Install options,
That’s what we’re gonna do now, we need to include the directory of the Core Rule Set cause we’re loading it into the default Apache configuration.
PS: In our case, we’ve put CRS into /usr/share/modsecurity-crs/, So we’ll be using this location.
We’re going to load the Core Rule Set setup configuration file & the rules.
Now we’ve included this also. Typically, we want to include this in our default Apache directory configuration for our enabled sites if we’ve more than one site on the web server.
Within this, we also want to include the SecRuleEngine inclusion here.
Now we should be able to restart Apache without any problem,
Now, we can actually get started by testing modSecurity because we’ve pretty much guaranteed that we’ve everything running & we’re using OWASP Core Rule Set so there’s tons of tests we can actually do.
Now Testing The ModSecurity with Apache:
1. Local File Inclusion Attack:
Security Rule Engine On:
Security Rule Engine Off:
2. SQL Injection Attack / Cross Site Scripting Attack:
Security Rule Engine On:
Security Rule Engine Off:
So, there’s multiple ways you can use modSecurity to protect your web application. This is very comprehensive; the rule set is excellent.
That’s pretty much it regards modSecurity. I’ll share one regarding NGINX soon, till then #SharingIsCaring ;)
Thank You.
