Security
  • Announcements
  • Promotions
  • Products and Services
  • Company News
  • Tips and Tricks
  • Security
October 4 2017
Security
ModSecurity - Protection Through Patterns
PostedWednesday October 4th 2017

Today I want to talk about some security features we have enabled on all of our servers. The logical place to start is ModSecurity. I know many customers who have read the ominous words ‘modsec’ in eTickets and shudder at it’s very thought.

But once you understand a bit about what it is, how it works, and why it is so powerful in the battle for keeping malicious attacks at bay, you may grow to love it!

What is ModSecurity?

ModSecurity (also known as ‘mod_security’ or ‘modsec’) is an open source ‘Web Application Firewall’ which is an Apache module.

What the hell is  ‘Web Application Firewall’?

Good question, a Web Application Firewall (also known as a WAF) really is dedicated to doing one thing: Looking at HTTP requests and trying to prevent malicious ones from getting through to the server.

So, back onto modsec, it exists on the web server and inspects requests that are made to the server. It looks at the traffic and compares the traffic against a number of regular expressions and rules.

These regular expressions are written with the intention of matching common attacks that are made to a web server. A lot of attacks share the same sequence of code, special words or other similarities. We can then make a comprehensive list of these similarities to try and detect them. When these added to the rules, modsec becomes aware of them and knows to look out for specific requests being made.

Therefore, if modsec finds a match between a request being made and a rule it has active, it will block the request thinking it is malicious.

A very important note is the way modsec executes the checking of rules, it will start at the top of the list and check each rule, once it hits a rule, it stops checking the rest of the list.

For example, let’s say it matches rule 25 of 1,000, It throws 403 Forbidden. The user whitelists rule 25, so it won’t trigger again. The user performs the same function… but they are blocked again. This time, the rule that was triggered was 566.

Many of the modsec rules share some of the same expressions and many rules overlap.

This becomes important later when trying to whitelist rules to stop you from being blocked!

What DOES ModSecurity Protect Against?

Modsec is designed primarily to block code injections that are malicious.

Alongside a massive rule set that we use, we also have some of our own rules that we have implemented to further protect our customers from common threats.

Let’s look at some examples of an attack modsec would help with:

A very popular and common form of attack is SQL injection – if code is not written with security in mind, SQL injection can be very damaging:

http://mysite.com.au/login.php?username=tom">DROP%20TABLE%20users--

This injection would attempt to DROP (delete) the ‘users’ table from the database and you would lose all information inside of that table. With modsec running, it would detect this request and block it.

An example of this is a Reflected XSS  (Cross Site Scripting) due to a vulnerable WordPress plugin: WP Custom Fields Search v.0.3.2.

If the WordPress site is running this plugin on that version, an attacker would be able to execute Javascript using a specific form of URL:

http://mysite.com/?search-class=DB_CustomSearch_Widget-db_customsearch_widget&widget_number=2&cs-all-0=’>&cs–1=&search=Search

So, the attacker would craft a specific URL, send the link in spam asking people to click the link. Once clicked and a user visits the site, the Javascript would execute and attack the visitor, Modsec would protect against this attack.

There are thousands of rules and different protections that are in place with modsec, these are just a few samples of something simple to demonstrate what it can protect from.

What DOESN’T ModSecurity Protect Against?

It won’t protect you against:

  • Out of date plugins or content management systems
  • Weak passwords
  • Poor code with security flaws
  • Already compromised sites with malicious code
  • Every variation of code injection and XSS
  • Zero-Day exploits

How to Recognise a ModSecurity Rule Trigger?

Most of the time, it is fairly easy to recognise. Say you have just spent some time editing some code through your WordPress backend. You hit save and bang ‘403 Forbidden’…you have just triggered a modsec rule (exciting right?).

But why? I was just saving some changes to WordPress, this wasn’t an attack!

Well, when you make changes through the backend of WordPress, you are actually submitting a request to the server, this request will often contain a whole bunch of code about formatting, links, and various other bits and pieces it will add behind the scenes.

Modsec doesn’t like code being sent through the browser, as noted above, it is commonly used by attackers to compromise your site.

So your request in some way must’ve matched a rule and therefore modsec rejected the request from reaching the web service.

Sometimes, it isn’t so obvious. Same situation, you hit save and then… nothing, the page just loads and loads and loads until you get bored. In this situation it is handy to open your browser’s ‘console’ to see if any errors are being thrown there:

  • Chrome:
    • (Windows) F12
    • (Mac) Cmd + Opt + I
  • Firefox:
    • (Windows) Ctrl + Shift + I
    • (Mac) Cmd + Opt + I
  • Safari:
    • (Windows) Ctrl + Shift + I
    • (Mac) Cmd + Opt + I

You should see a ‘Forbidden’ error inside the console if it was modsec.

Lastly, we have a special tool within VIPControl > Action > Mod Security. This will show a log of any hits that have been detected. So if you get a 403 and aren’t certain it was modsec, you can come in here to check for yourself.

If you aren’t sure, feel free to get in touch with the Technical Support team, we are more than happy to try and determine the cause for you and check if it is indeed modsec.

What to do if I Trigger a Rule?

So if you have triggered a modsec rule, the fastest way to resolve it is to get in touch with our 24/7 100% Australian Technical Support team through an eTicket.

To help us find the rule as quickly as possible, you can start off by giving us a few things:

  • Your IP address
    • Just Google ‘What is my IP’. Most modsec rules are logged to a corresponding IP address, we can quickly and easily search these logs using your IP to find the rule being hit.
  • Steps to replicate
    • How did you get the 403 to appear? As mentioned earlier, there can be multiple rules being triggered. I have had customers who triggered 5-7 rules, rather than going back and forth, it is often better to let the Technical Support team replicate and monitor the logs live.

Once we have whitelisted the rule, you will be able to submit your form, or save your code!

Summary

Modsec isn’t a silver bullet, it won’t protect against every attack. But it does a good job of protecting against a large variety of attacks that bots and inexperienced attackers are trying to use. That is why we are proud to be running it across all of our servers to protect our customers as best we can!

We always recommend leaving modsec on, the negatives of occasionally having to whitelist some rules, far outweigh the positive protection it offers your sites.

If you would like to know more about Mod Security and want to know the nitty-gritty technical details, have a look at their website

Share this article
As Chief Business Development Officer, Maddison oversees the sales, marketing, and business development efforts here at ...
Who are VentraIP Australia?
VentraIP Australia is the largest privately owned web host and domain name registrar in Australia, backed by a team of industry veterans and local technical professionals.
View website