Today I want to talk about some website 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 its 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 website security?
ModSecurity (also known as ‘mod_security’ or ‘modsec’) is an open-source ‘Web Application Firewall’, 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 webserver and inspects requests made to the server. It looks at the traffic and compares the traffic against several regular expressions and rules.
These regular expressions are written to match 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 are 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 an active rule, it will block it thinking it is malicious.
A critical note is a 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 malicious code injections.
Alongside a massive rule set that we use, we also have some of our own rules that we have implemented to protect our customers from common threats further.
Let’s look at some examples of an attack modsec would help with:
A prevalent 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 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 saving some changes to WordPress. This wasn’t an attack!
When you make changes through the backend of WordPress, you are actually submitting a request to the server. This request will often contain a 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. In the same situation, you hit save and then… nothing. The page 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 contact 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 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 submit your form or save your code!
Summary
Mods aren’t a silver bullet; they 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.
