ModSecurity (also known as ModSec) is an open-source web application firewall (WAF). It is implemented to protect sites and applications against many common attacks, including XSS, code injection, etc.
70% of all attacks are carried out through the application level of the web. Thus, implementing a WAF would be helpful for organizations in ensuring system security.
It establishes an extra security layer that increases the protection level of web servers, detects, and prevents attacks before they reach web application programs.
Initially, ModSecurity was a module for Apache web servers, and with time, it grew to a full-fledged web application firewall with support for different platforms, including Apache, Nginx, and IIS.
They work on the application layer (the 7th layer in the OSI model).
It examines the incoming requests, compares them to patterns described in the rules in the ruleset, and takes actions on the requests based on the results of the tests. If the check succeeds, the HTTP request is passed to the website to retrieve the content. If not, pre-defined actions are performed.
It has a flexible rule engine to perform simple and complex operations and comes with a Core Rule Set (CRS).
And the most popular one among those is the OWASP ModSecurity Core Rule Set, which is updated regularly and can block a wide range of generic attacks, including OWASP’s top-ten list of critical vulnerabilities.
Installation of ModSecurity with Apache on Ubuntu 18.04
The ModSecurity module for Apache is available in the default Debian/Ubuntu repository.
To install it, run the following commands in the terminal:
sudo apt install libapache2-mod-security2
1. Restart the Apache service:
sudo systemctl restart apache2
2. After restarting the Apache service, you can test it with the following command:
apachectl -M | grep security
3. If everything is fine, see the following output:
security2_module (shared)
4. If not, enable the Apache 2 security2 module by running the following command:
sudo a2enmod security2
5. Restart Apache service for the change to take effect.
sudo systemctl restart apache2
Post-installation configuration of ModSecurity
The default rule of ModSecurity is to log suspicious activity. And we need to change the configuration to detect and block traffic according to our requirement.
Let us have a closer look at the steps involved in configuration.
1. By default, the configuration file is at /etc/modsecurity/modsecurity.conf-recommended and we need to copy this file and rename it as modsecurity.conf
3. Switch to /usr/share/modesecurity-crs directory, and rename the example setup file
cd /usr/share/modsecurity-crs
mv crs-setup.conf.example crs-setup.conf
4. Enable these rules in the security2 configuration file to get it working with Apache by making required edits in the /etc/apache2/mods-enabled/security2.conf file
5. Locate IncludeOptional /usr/share/modsecurity-crs/*.load and change it to:
#### 6. Save the changes #### 7. Test the Apache configuration ```sudo apache2ctl -t ``` #### 8. If the syntax is OK, then restart Apache. If you get an error ```ModSecurity: Found another rule with the same id```, then comment ```IncludeOptional /etc/modsecurity/*.conf``` ``` systemctl restart apache2 ``` ## Testing ModSecurity Post the proper configuration, we can test ModSecurity by sending some malicious requests to a local Apache server and see if the requests are being blocked or not. Let us conduct a test on a local machine by running the following command to test an XSS attack: ```curl 'http://192.168.1.116/test.html?a='``` If ModSecurity has been configured properly and actively blocks, it should return a 403 HTTP-status-code response as shown:
## Conclusion ModSecurity is much beneficial in terms of protecting your websites from generic attacks such as XSS, SQL injection, etc. But being a technology, it has certain potential drawbacks, which the administrators should be aware of. In certain cases, ModSecurity might block the legitimate web traffic (false positives), and it might fail to address CMS-specific vulnerabilities which should be mitigated by updating or patching the CMS. The authoritative administrators are expected to keep an eye on what is being blocked and add exceptions to the rules accordingly to prevent false positives.
Automated human-like penetration testing for your web apps & APIs
Teams using Beagle Security are set up in minutes, embrace release-based CI/CD security testing and save up to 65% with timely remediation of vulnerabilities. Sign up for a free account to see what it can do for you.