Securing a webserver using modsecurity: tips and a few considerations

So, I’ve been commissioned to create a website, I was given quite a big infrastructure to work with, and I have lack of experience in that.

So as a self-reminder I’m writing down a few notes about what I did or can be done in general.

What is ModSecurity?

ModSecurity is an Apache module (although it can be used as a standalone), that helps you securing your website using a set of rules. The most common set of rules used by default is the OWASP ruleset.

It is defined as a Web Application Firewall (WAF), meaning that analyze and filter traffic at HTTP level. And this aspect dictates its strong points and weaknesses.

Set it up

There is an installation detailed description in the wiki of the repository: here. But I should admint I don’t remember using it, looks too complicated.

This looks like the kind of installation process that I like. That we can resume with the following key commands:

sudo apt update -y
sudo apt install libapache2-mod-security2
sudo systemctl restart apache2 

And that’s it.

Make it work

That was a little less intuitive, it requires a lot of research and study to master it, luckily I just have to make it work.

I installed the OWASP ruleset from here (at least if I remember it correctly).

Then I had to tune a few configuration files:

the modsecurity.conf

This one requires to change from:

SecRuleEngine DetectionOnly

to

SecRuleEngine On

Then, depending on the web application you’re trying to protect you may want to uncomment one of the following:

setvar:tx.crs_exclusions_cpanel=1,\
setvar:tx.crs_exclusions_drupal=1,\
setvar:tx.crs_exclusions_dokuwiki=1,\
setvar:tx.crs_exclusions_nextcloud=1,\
setvar:tx.crs_exclusions_wordpress=1,\
setvar:tx.crs_exclusions_xenforo=1"

This is basically what I did so far, and it looks like it’s applying some basic rules redirecting potential attackers to a 403 page (not authorized). It’s a bare minimum, and it actually requires some customizations to make it work properly.

Excluding a specific rule

Modsecurity (modsec for the friends), does allow you to exclude a specific rule, or a list of them, depending on how you write it:

SecRuleRemoveById 999001
SecRuleRemoveById 999002
SecRuleRemoveById 999003
SecRuleRemoveById 999004

Or as a single line list:

SecRuleRemoveById 999001 999002 999003 999004

Where do you write that?

Well, a configuration file (.conf), where is the file located? Well depends on your configuration, I checked first below the apache2 folder in mods-enabled inside the security2.conf file you should find the following:

<ifModule security2_module>
# Default Debian dir for modsecurity's persistent data
SecDataDir /var/cache/modsecurity
# Include all the .conf files in /etc/modsecurity.
 # Keeping your local configuration in that directory   
# will allow for an easy upgrade of THIS file and 
# make your life easier
 IncludeOptional /etc/modsecurity/*.conf
# Include OWASP ModSecurity CRS rules if installed
IncludeOptional /usr/share/modsecurity-crs/*.loadz
</ifmodule>

That file tells you where you can create your custom (excluded) ruleset, in this case it’s inside the path

/etc/modsecurity/*.conf

The file doesn’t need the <ifmodule> tag, just the list of rules you want to exclude.

This worked well for me, let me know if you found other ways of dealing with modsec rules.

Considerations

I have a load balancer between my servers and users, that means I can’t harness certain useful features such as being able to integrate fail2ban with it.

Apparently, even if modsec (actually is apache) can detect the original IP trough the X-Forwarded-for header, iptables cannot block the original IP. A real showstopper.

Posted in Web Development and tagged , , , , , , , .

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.