What is ModSecurity? It’s a toolkit designed for real-time web application monitoring, logging, and access control. If it sounds complex, don’t worry. Anyone with experience of ModSecurity will attest that it’s a flexible toolkit, with no hard and fast rules telling you how you should use it.
Generally, ModSecurity leaves you free to decide how you take advantage of the features available instead. This flexibility is a core element of ModSecurity’s identity, and complements its open source structure. In fact, you can enjoy complete access to its source code, which empowers you to customize the tool to suit your unique needs.
And that’s crucial for anyone who wants tools to enable them to achieve what they have to with minimal restrictions. Which is probably all of us, right? ModSecurity is a versatile creation ideal for numerous usage scenarios. Let’s look at some of the most important:
- Security monitoring and access control for applications
- Comprehensive logging of HTTP traffic
- Hardening web applications
- A more personal solution
- Continuous passive security assessments
- ModSecurity’s Core Principles
- Choices of Deployment
- Understanding ModSecurity and Plesk
- Final Notes for Nginx and ModSecurity on Linux Systems
Security monitoring and access control for applications
ModSecurity provides you with the ability to access and inspect streams of HTTP traffic, so you can monitor application security in real-time.
ModSecurity’s persistent storage mechanism allows you to keep track of system elements and conduct event correlation over time. You can also implement blocks efficiently, if you need to, thanks to ModSecurity’s full request and response buffering.
Comprehensive logging of HTTP traffic
When logging for security reasons, web servers are generally known to do less than first-timers may expect. Actually, they tend to log little fundamentally — so you may still struggle to get all that you’re looking for even with some adjustments here and there.
But with ModSecurity, you can log whatever you need to (such as raw transaction data for forensics) and you can determine:
- what transactions will be logged
- which aspects of transactions will be logged
- which elements undergo sanitization
Hardening web applications
One of the most impressive ModSecurity uses is attack surface reduction: here, you can streamline HTTP features you’re happy to accept, such as content types, request methods, etc.
ModSecurity will help you to enforce numerous similar reductions, through additional Apache modules (collaboratively or directly). This is all under the umbrella of web application hardening.
A more personal solution
ModSecurity’s immense flexibility comes to the fore when you’re faced with an unexpected problem. This could be a security issue, for example, or something entirely different.
For instance, some users utilize it as an XML web service router by blending its capabilities to parse XML and apply XPath expressions with its proxy-request abilities. That might not occur to some users, which only shows the deep flexibility at ModSecurity’s core.
Basically, it may prove helpful to you in ways you can’t predict until you start to truly explore.
Continuous passive security assessments
Traditionally, security assessment can be viewed as an active event which is scheduled in advance, involving an independent team trying to undertake a fake attack. But a continuous passive security assessment is a variation on real-time monitoring that concentrates on system behavior rather than that of outside parties.
Continuous passive security assessments serve as a form of early warning system, capable of detecting security weaknesses before attackers can take advantage.
ModSecurity’s Core Principles
ModSecurity is based on four main principles:
Passiveness
If you’re concerned about letting tools make decisions for you, particularly when conducting transactions, ModSecurity makes things a little easier for you.
Why? Because it’ll never initiate changes to transaction data without you instructing to do so first.
Of course, it’ll provide you with a wealth of information. But it’ll leave choices up to you, for your complete peace of mind.
Flexibility
As we’ve already mentioned, ModSecurity is remarkably flexible. It’s actually fairly mind-blowing in its flexibility, to be frank.
That’s because it was created by a security expert who wanted to intercept and analyze HTTP traffic for safety purposes, yet realized that everyone had to do things their own way sometimes. Not everything has to work exactly the same for each user.
So, ModSecurity offers such high flexibility by providing a rule language that enables you to achieve what you need to, along with the freedom to apply rules only where necessary.
Quality, not quantity
During the lengthy development and fine-tuning of ModSecurity, the team explored numerous ideas for what it could actually do. They chose not to act on a lot of these, and put them aside for a later time.
They did so because they knew they had fewer resources than they needed to make those ideas a reality effectively. So, they decided to limit the functionality available to users, but to focus on making the ideas they actually implemented the best they could be.
Predictability
We all know the “perfect” tool doesn’t exist, and possibly never will. But a predictable tool could be the next best thing — and that’s where ModSecurity shines yet again.
When you’re equipped with the crucial facts, you’ll be able to understand ModSecurity’s weakest areas and find workarounds yourself.
However, let’s be clear: certain aspects of ModSecurity can be considered to be beyond the scope of these guiding principles.
For instance, ModSecurity is capable of adjusting the way in which Apache identifies itself to others, keeping the ModSecurity Apache process contained, and implementing an efficient plan to deal with that well-known XSS weakness in Adobe Reader.
It’s fair to say, though, that these features could be seen as a distraction from the core intent behind ModSecurity’s creation: to serve as a predictable tool for inspecting HTTP traffic efficiently.
Choices of Deployment
Two different deployment options are supported by ModSecurity: embedded deployment and reverse proxy deployment. But there’s no single correct or incorrect approach.
Just pick the most appropriate option based on your goals, requirements, and situation.
Let’s look at the benefits and drawbacks of each:
Embedded deployment
You can add ModSecurity to any version of Apache that’s compatible, as it’s an Apache module. At the present time, this means that a fairly recent version of Apache from the 2.0x branch should suffice (though a more up-to-date 2.2x is the typical recommendation).
Embedded deployment is terrific for users who have already established their architecture and are reluctant to make changes. It’s the only option if you want to keep a high number of web servers protected, even hundreds of them.
In a situation like this, though, it’s not practical to create a separate proxy-based security layer. Not only are new failure points not introduced with embedded deployment, but ModSecurity also offers seamless scaling to match the underlying infrastructure as it scales.
With embedded ModSecurity deployment, the primary obstacle is that server resources will be shared between ModSecurity and the web server.
Reverse proxy deployment
A reverse proxy is basically an HTTP router made to sit between a web server and its clients. Installing a Apache reverse proxy with ModSecurity added will bring you an effective network web application firewall. You can implement this to safeguard any amount of web servers all running on a shared network.
A lot of security professionals opt to initiate a separate security layer, as you’ll enjoy total isolation from those systems being protected.
In terms of performance, a standalone ModSecurity has resources dedicated to it, which enables you to get more out of it (such as utilizing rules that are more complex).
However, there’s a big potential disadvantage to consider with this deployment approach: the new point of failure. This will have to be addressed using a high-availability configuration of at least two reverse proxies.
Understanding ModSecurity and Plesk
ModSecurity is switched on by default starting from the early versions of Plesk Obsidian. In the same time, if you install Plesk using the images provided by your hoster, situation may be different.
To identify and defend web applications against attacks, ModSecurity will run checks on any request to the web server and all associated responses from the server against the set of rules.
Should checks succeed, the HTTP request will be sent to the website to retrieve the relevant content. But if checks fail instead, the appropriate predefined actions will be initiated.
Both Plesk for Windows and Linux offer support for ModSecurity. This functions as a web server (IIS or Apache) module.
How to turn on ModSecurity
To activate the web application firewall, follow these steps:
- Navigate to Tools & Settings > Web Application Firewall (ModSecurity) (located within the Security group).
Don’t see this link? Don’t panic. Just install the ModSecurity component here: Tools & Settings > Updates > Add/Remove Components > Web hosting group.
- Switch the web application firewall mode to either On or Detection only, to make sure all incoming HTTP requests and associated responses are checked against a rule set. When checks succeed, the HTTP request will be directed to the website to retrieve the necessary content. Alternatively, the event will be logged if checks fail. When in the Detection only mode, no additional actions will be undertaken. But in the On mode, HTTP responses will be given with a suitable error code.
Firewall modes for web applications can only be set on the server and domain levels. But the domain level mode can’t be higher than that of the mode set for the web server. So, if the firewall is running in Detection only mode on the server level, you’ll be unable to switch it to On for domains — just Off and Detection only modes will be displayed.
Choose the set of rules to be checked by the firewall engine for every HTTP request incoming, or feel free to upload your own set of rules instead. You can opt for one of these rule sets:
- Atomic Basic ModSecurity: This is a free version of the Atomic ModSecurity rules for beginners, packaged with Plesk. It includes key security features and bug fixes are released monthly.
- OWASP ModSecurity Core Rule Set (CRS): This gives you generic defense against unknown weaknesses that can be found in many web applications. It’s shipped free, but it’s recognized as being restrictive, so much so that additional tuning is necessary for production use. When you choose this set of rules, WordPress partly won’t work, nor will webmail and fire sharing. You can take advantage of the Comodo or Atomic rule sets instead.
- Advanced ModSecurity Rules by Atomicorp: This is the most recent version of the rules, including all the performance improvements, bug fixes, and latest security features created by Atomicorp GotRoot every day. This commercial set of rules is supported completely and advised for production use. Plesk offers the Security Core Complete by Atomicorp extra feature, which enables you to implement this set of rules in Plesk. You can access this in multiple ways:
- Purchase the Atomicorp Advanced ModSecurity Rules available in the Plesk Online Store
- Have a Plesk license already? You can implement the extra feature through the Plesk Partner Central UI or the Partner API.
- If you hold a Plesk license but you can’t access the Plesk Partner Central, please contact your provider.
If you have an account on the Atomic website already, you’ll be able to simply enter your username and password to activate this set of rules.
Linux users please be aware: If you choose the Atomic set of rules, follow these steps to make sure your ModSecurity performs as it should. Start by running the aum -u command on the server, and the Plesk modsecurity package will be switched for that from Atomic’s repository. Next, run these commands:
plesk sbin modsecurity_ctl --disableplesk sbin modsecurity_ctl --enableservice httpd restart
- Comodo ModSecurity Rule Set (Linux): This rules-based traffic control system is easy to use and can be tailored. It offers effective protection for your web applications and combats emerging hacking methods, through a rules database that receives regular updates. This set of rules is shipped for free, and you can activate it in Plesk by following these steps: register on the Comodo site, and once there, submit the username and password you use on this website. It’s easy.
- Custom: You have the ability to upload custom web application firewall rule sets, such as an Atomic trial package or a Comodo free package. The following formats are supported: zip; tar.gz; tgz; tar.bz2; conf.
- Pick the Update rule set checkbox and choose the relevant update period to update your selected set of rules automatically.
- Choose a predefined range of parameters or specify your bespoke ModSecurity directives. The following preset parameter sets are available:
- Fast: For when the HTTP request URI and parts of the headers undergo analysis. The least CPU is required for this mode.
- Tradeoff: For when the HTTP request URI, headers, and request POST data will be subject to analysis. This is a solid balance between performance and quality.
- Thorough: For when full HTTP request headers, request POST data, and HTTP response body content will be analyzed. This mode does consume the biggest range of CPU resources, though it can be an effective option for websites demanding special security protections (such as online stores facilitating card transactions).
Please note: Web application firewalls need a local DNS server with request caching enabled to provide the best performance. Without this, your websites will be more likely to load slowly when the firewall is in effect.
Finding Log Files on Linux Systems
ModSecurity utilizes two locations for logging on Linux systems:
- Modsecurity audit log, which can be found in /var/log/modsec_audit.log. This is a highly-detailed option used by the entire Plesk server. An entry in the audit log file will be generated when ModSecurity recognizes that an event has taken place. You can view the ModSecurity audit log for yourself if you navigate to Tools & Settings > Web Application Firewall (ModSecurity) > click the Logs Archive link located within the ModSecurity audit log You can explore (and download) the log files and modification dates here.
- The Apache error log for a domain, which can be found in /var/www/vhosts/DOMAIN.TLD/logs/error_log. This offers just brief details about site errors, but you can check out the error log for specific websites in the Customer Panel on the Websites & Domains > <domain_name> > Logs > choose Apache error and nginx error rather than All logs positioned on the right.
Finding Log Files on Windows Systems
ModSecurity audit logs are domain-specific on Windows. They’re found in %plesk_dir%\ModSecurity\vhosts\<domain’s GUID>\logs ( %plesk_dir% is Plesk’s default installation directory).
How to Switch Rules Off
Once you switch the web application firewall mode from Off or Detection Only to On, a website could start functioning in an unexpected way. You can check error codes (404s, 403s, 500s) in the site error log, and they’ll stop displaying once you switch the firewall mode back to Off or Detection Only.
In this event, check the ModSecurity audit log to identify the cause. You’ll be able to deactivate excessively-restrictive rules or tweak the website as required.
Follow these steps to determine why a site’s HTTP requests can’t be completed:
- Check the audit log file for the site.
When using Plesk for Linux systems, you can take view the log through Plesk’s UI: navigate to Tools & Settings > Web Application Firewall (ModSecurity), then click on the ModSecurity Log File link to start downloading the relevant audit log. This will open in a new window in your browser.
- To find events for a website (domain name) that may be responsible for issues, leverage the Search function (just hit Ctrl+F in the majority of browsers) — such as your_domain.tld. Your browser will then highlight certain entries, e.g. HOST: your_domain.tld. Look for a string such as –eece3116-B– in the three lines positioned above the highlighted entry. Those symbols between the hyphens show you the ID of the event which was triggered by the HTTP request.
- Look deeper for additional entries with the identical event ID, specifically an entry featuring a H after the event ID. This carries the ID and description of the security rule that was activated while checking the relevant HTTP request. The security rule ID is an integer number positioned with quotation marks. It will begin with a 3 and will be displayed with the prefix ID in square brackets. This may look something like [id “340003”].
- Locate a security rule ID in the event with the substring [id “3. You can use this ID when you turn rules off.
To deactivate a rule:
- Make your way to Tools & Settings > Web Application Firewall (ModSecurity)
- Once you’re in the Switch off security rules area, choose the security rule based on its ID (e.g. 340003), its tag (such as CVE-2013-4589), or a standard expression (e.g. XSS) and hit OK.
Final Notes for Nginx and ModSecurity
Let’s end by covering the issue of request checks with NGINX and ModSecurity, and how it connects to ModSecurity Apache issues.
ModSecurity is an Apache module on Linux systems, and it can run checks on HTTP requests reaching Apache only. But you can supplement Apache with an alternative web server, specifically nginx.
If you switch on the ‘Process PHP by NGINX option’ of the NGINX web server for dynamic website content (in a site’s Apache and NGINX settings), the web application firewall will be unable to check any HTTP requests as they’ll never actually reach Apache.
In the case of static content, HTTP requests won’t reach Apache if the ‘serve static files directly by NGINX option’ is switched on. That means ModSecurity won’t be able to check them.
We hope this detailed guide gave you a clear answer to “what is ModSecurity?” and helps you understand how it works. Because now it’s time to explore its possibilities for yourself!
ModSecurity offers a lot of advantages, so follow the tips and steps covered above to find out what ModSecurity can do for you.
with
No comment yet, add your voice below!