Hello everybody! It is Simon Davis from the TMDHosting Genius Support Team and it is #TechWednesday :) In today’s article I will want to talk about one of the roads we have recently taken to secure our clients’ web-sites and respectively their intellectual property which is the most important thing over the web these days. If you have been keeping an eye on us recently, you should have heard about our so-called web firewall. So, here is some info behind the curtains regarding it!
Lets face the statistics provided by the professionals!
12 to 14 millions of search queries performed by Google each and every day return warnings that some of the results are related to malicious contents or in other words are compromised by one way or another.
Pretty bad isn’t it?!
Another even worst statistic is that each day Google finds over 9000 newly infected websites with malicious contents over the web – viruses, phishing pages or even redirects to other infected web-sites.
Here in TMDHosting we don’t want our Customers to be part of that statistic and each day our security specialists are fighting the malicious activity on our servers causing the same to be progressively reduced to its minimum.
For the past year we have been developing several options (features, improvements) to protect our clients websites no matter if the websites (usually opensource applications) are already using built-in protection or not. We are aiming at not only to improve that already developed protection from the authors of the used scripts but to add completely new and separate layer of security which is individually unique and most importantly reliable.
The sunset of malicious activity!
In a pretty cloudy day over the past year we have saw the sun at the horizon and we took the long and dusty road to the sunset of malicious activity, hacked websites and stolen intellectual property. No one though that the road was gonna be clear and carefree, instead we were prepared for every obstacle that we can face up to our goal – to build universal security tool using already released opensource security features without actually affecting the existing websites in a manner which will affect their access rate and functionality.
With all this being said I am proud to present you with the cutting edge in our latest security advancement – apache® ModSecurity .
What exactly is ModSecurity and why it is a mandatory these days?
Behind the short and self explanatory name there is a powerful, opensource, web requests analyzing Firewall (or in short WAF – Web Application Firewall) which is essentially checking each and every request performed to the web service on our servers. By default ModSecurity is released in two major distributions:
- As standalone Firewall – Usually this distribution is used when the web service running on the server does not support the dynamic load of modules such as the Nginx web service. In that case ModSecurity can be compiled with the source code of the main server. More information on the matter can be found at the official page ModSecurity for Nginx .
- As a module for the widely distributed and most commonly user web service Apache® - This is the way we are using for the implementation of the ModSecurity WAF and we find it most useful and beneficial. It allows each and every request made to the server to be processed and checked for malicious contents which is exactly what ModSecurity is capable of.
As mentioned earlier in this post ModSecurity is an Web Application Firewall capable of providing great level of security for the websites of our clients . The way ModSecurity works is quite straight and it depends entirely on the rules set created in this case by our security specialists. That is right I said “Rules”.
As every Firewall type of feature ModSecurity needs a way to filter the incoming data (in our case web request) . Here the rule engine used by ModSecurity comes pretty handy as it allows for every element of the incoming requests to be filtered and checked for malicious contents.
The way we have configured ModSecurity is in close relation with the data submitted via the URL (GET requests) and the data submitted to the server via the Forms(POST requests) of our clients websites.There are few most common principles used when a hacking attempt is performed and bellow I will cover some of them along with the way how ModSecurity is preventing these.
- SQL Injections- By definition SQL Injection is the process of injecting a code via POST or GET request to the target data driven(MySQL type of database using) script which are currently most of the opensource applications. The result from such type an attack is that a certain query performed to the database of your website is changed.The purpose of this change can vary from certain information on the website being changed to a complete control of the client website.The way ModSecurity protects your website from such type of attacks is that it filters the parameters passed via POST or GET requests. If any the parameters contain most commonly used phrases by the Injection technique ModSecurity automatically terminates the requests before it reach the server and send an error page to the client browser performing the request.
Here is an example of the SQL Injection performed via the URL of your website:
Original URL: http://domain.com/blogposts.php?id=1
SQL Injection included in the URL: http://domain.com/blogposts.php??id=-130 union select all 1,username(username,0x3a,password),3,4,5,6 from username
Since the id parameter is used for an SQL request to the database it is directly included in the query via GET request. When the URL with the SQL injection is submitted the script which is handling the request will not only accept the SQL code in the URL but it will perform a legit request to the database displaying the Username and the Password as the above SQL injection statement is requesting these.
Of course the above example has only demonstration purpose and it cannot be used for anything else.
ModSecurity will fetch the id parameter and check it for any “Union” statements for example. Since none of the known opensource applications and custom scripts are actually performing SQL queries via their URL(GET request) it is quite suspicious that this one does. So instead of passing the request to the server ModSecurity will automatically terminate the request returning a 406 Not Acceptable error page.
- Malicious User-Agents - This is basically a list of malicious user agents we have gathered over the years and also found over the web from major security experts and search engines. Each and every User Agent from these has proven that in one way or another it performs malicious activities with the requests it sends to the server. Such activities for example are:
spamming your websites with comments
creating fake registrations with spamming purpose
flooding the server with connections (DDoSrelated)
and many more. What ModSecurity do is to check every User-Agent accessing your website and if it matches one of the malicious User-agents in our list (which is quite big actually) it will automatically terminate the request and return a 406 Not Acceptable Error page to the source of the request.
- Malicious File uploads – This is usually a technique used to upload an malicious script directly on the web space where the files and folders of the website are stored. This is actually the attack that succeed most of the times it is performed due to the fact that many of the scripts used currently (not to say all of them) offers the option for registered users to upload picture for avatar of their profile.Well not every picture uploading form is used straight with its purpose. Many of the forms mostly provided from plugins and templates used for client’s website are offering the option for file uploads which are not additionally checked for the file type uploaded via the same. This allows the hackers to easily create profile and upload a script which is stored in a temporary or common upload folder which is accessible over the web .The result of such attack is that the uploader of the file get control of entire web-site. From this point on the website’s files/folders and overall content depend on the mercy of the attacker. In most of the cases the attackers are ONLY changing the index.php file and by inserting traces (usually text and pictures) that the website has been hacked. But in rare cases they are deleting all of the files and folders of the client’s website and leave no tracethat such deletion has been performed.ModSecurity not only checks the uploaded files for malicious contents but also it checks the names of these files and match them with quite a huge I can say database of malicious file names and their hashes. When such file has been uploaded and ModSecurity detects it, the file not only get permanently deleted but an 406 Not Acceptable error page is returned to the uploader.Even if lets say, ModSecurity miss such a file and it has been actually uploaded on the server it cannot be accessed. Another great skill of ModSecurity is that it checks the output of each and every request.What I mean in regards to the uploaded file is that when such file is accessed ModSecurity matches its contents with a increasingly huge list of malicious stings used by the hackers in such scripts. If even one word in the output after the execution of the uploaded malicious script matches with a word in the list checked by ModSecurity the output of the request is terminated and instead a 406 Not Acceptable error page is displayed.
- Bruteforce attacks - This type of attacks target mostly the username and the password used for logging into the admin area of a website. It is quite successive type of attack due to the fact that it can be performed either as a Dictionary attack or as a simple symbol matching attack.The general scenario of that attack is that a remote connection from the attacker to the server has been performed and a script (or usually a bot) is performing login attempts until it finds the correct one.The way ModSecurity protects your website from such type of attacks is that it matches the login attempts from a single IP address in certain period of time. For example – it counts the login attempts from a single IP address for 10 seconds and if the number of login attempts is greater than 5 (1 login attempt per 2 seconds) ModSecurity will block the IP address of the attacker PERMANENTLY.Since it is quite impossible for a single user to perform 1 login attempt each 2 seconds even if the password and the username are saved by the user’s browser ModSecurity will consider such behavior as an attack and the IP address will be automatically blocked.
As you can understand from the above type of attacks we are trying to cover almost every aspect of how your web-site can be hacked/defaced and to respectively reduce the possibility of that to happen to 0. This is not an easy task and each day we find newer type of attacks which we are inspecting in details and respectively we are updating our rules accordingly.
My last words but only in today’s article will be related to the logging strength ModSecurity has. As every Firewall type of software ModSecurity provides the option for logging. To be able to have some idea what malicious requests are performed on our servers and respectively denied by ModSecurity, we are provided with a local log in which all the matches of our rules are logged. This allows us not only to monitor the malicious activity on the servers but also to block the source of that activity.
At this point that log is available only for our VPS and Dedicated Servers users requested the installation of ModSecurity on their services with us. It can be found in their WHM control panels under the link ”Mod Security” .
In a conclusion I would like to say that ModSecurity offers individuality and flexibility which makes it unpredictable for hackers and users with malicious purposes the same as trusted with the millions of options for filtration it offers.
We are proud that we have chosen to protect your blogs, forums, e-commerce application (online store) or social network with the help provided by ModSecurity.