For Linux-based web servers, ModSecurity is an open-source web application firewall (WAF) that protects websites from specific threats. Most threats take advantage of poorly coded web applications either through cross-site scripting (XSS), SQL injection (SQLi), header exploits, session hijacking, and code injection. Web-based exploits are distinctive from network and protocol layer attacks, so they need different technology -- such as a WAF -- to stop them. Most applications have at least one bug, and it could be just one bug that creates a vulnerability. A WAF will help you stop exploits on these vulnerabilities. This articles provides more information about the following topics:
Any HTTP-based attack is monitored and blocked based on the site owner’s configurations, but it also provides analysis and review so that a site owner is aware of the attacks targeting the website. What gets blocked and what is allowed on the site is fully configurable through ModSecurity, so administrators can whitelist specific actions if necessary. For administrators unfamiliar with ModSecurity, it works out-of-the-box with few configurations needed so that sites are protected automatically.
Rules for ModSecurity can be downloaded and installed to make configuration of web server security easier, but administrators can also create their own rules. These rules will define the way a web server responds to requests. Configuration of ModSecurity rules is critical for protection of web application data, and without them or with a misconfiguration, the web application could be exploited using numerous known vulnerabilities.
Since ModSecurity is a WAF, the rules cover most of the OWASP Top 10. The OWASP Top 10 is a list of common vulnerabilities used by penetration test applications, and they also set a foundation for administrators so that they can set up WAFs such as ModSecurity to block common web-based attacks.
In the examples listed in this article, Apache .conf files will be added to the /etc/httpd/conf/modsecurity.d/rules/ directory, but you aren’t limited to Apache. ModSecurity also works with NGINX and other web servers.
XSS vulnerabilities can result in a loss of data, session hijacking, and other account takeover attacks. It’s a critical issue that should be addressed throughout the entire application. cPanel has a default set of rules that can be enabled for ModSecurity, but Imunify360 offers enhancements for more advanced detection and remediation of XSS threats.
Bots eat up server resources, and they can be used to find vulnerabilities and sensitive data on your server. After a while, you might notice that bots are causing performance issues on the server. Some bots are benign (e.g., Googlebot for search engine indexing), but others are unnecessary and do nothing but cost money in server resources.
When any request is made from a user browser, a user agent is sent to the server to identify the browser being used. This value can be spoofed, so you should not use this value to validate legitimate users. However, bots will send a user agent so that you can identify them. If you don’t want to allow a bot to access content, you can block it with ModSecurity.
The ModSecurity tool has a feature that allows you to block specific bots, but user-agents can be spoofed by an attacker to bypass any protection. Good protection should not be based on basic user-agent headers, as many of the attacks used from bots will use spoofed headers to trick monitoring systems into thinking it’s a legitimate user. Monitoring software such as Imunify360 uses more advanced procedures to detect bots with bad or spoofed user agents.
Instead of writing your own ModSecurity rule for the many permutations of SQL injection, a better way to block this attack is to enable the rules already created in the tool. Imunify360 protects from SQL injection out-of-the-box, so you do not need to create or install any complex rulesets that define suspicious queries and block them.
When users connect to a website and authenticate, the server identifies the user by a session ID. This session ID is typically stored in a cookie, which means that the cookie contains a token that essentially represents the user on the application.
If an attacker can obtain the session cookie, they have access to the user’s token and can perform actions on the web application as the targeted victim user. This means the attacker can change the user’s password, make requests on behalf of the user, and have access to any data available to the user.
The HttpOnly cookie setting helps stop this attack, but an additional layer of security using ModSecurity is helpful. After you enable the ModSecurity rules from the previous section, you will also have protection against session hijacking. Sessions should be expired after a specific amount of time, and they should be expired on the server side and not just removed client-side. One common mistake in application development is deleting the cookie client-side on the user’s browser, but the session on the server remains active. Should an attacker steal the session, a user would be unable to access their account.
ModSecurity should not be used as a sole security layer, but it adds HTTP-based protection against your application. You should use ModSecurity as a layer of defense, but web application server configurations should be reviewed, any web applications penetration tested, and code reviewed for vulnerabilities. Other security measures are still important to reduce risk of threat and stop attacks from successfully breaching the application or server.
Instead of working with OWASP rulesets, Imunify360 offers rulesets that will cover numerous threats along with monitoring and real-time reports. You could use the default ModSecurity rules to manage your web applications, but Imunify360 takes your security a step further.
Before you can use Imunify360, you must turn off ModSecurity Vendors in cPanel, except for Imunify360.
Imunify360 gives you more coverage of your web application and protects from the threats that could lead to a data breach. It’s important that you disable the other third-party rulesets to avoid conflicts.
Threats continually evolve, so Imunify360 developers make updates to combat changes. You must enable updates on your server. For Apache, run the following command:
/usr/local/cpanel/scripts/modsec_vendor enable-updates imunify360-full-apache
To read the full documentation on Imunify360 and its configuration, read the documentation.
Using Imunify360 over the default ModSecurity rulesets has several benefits. The first one is that Imunify360 uses heuristic data to detect and stop attacks. This means that the tool takes past information and applies it to the way it detects ongoing attacks. Attackers are forced to continually change their methods of attack and come up with new zero-day exploits. However, the second advantage to Imunify360 is in the way it can detect zero-day attacks based on heuristic data.