ModSecurity Rules 2023: How to Guide

Modsecurity-Rules-How-to-Guide

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:

What is ModSecurity?
What is a ModSecurity rule?
Should I Use ModSecurity?
Imunify360 ModSecurity Ruleset
Protect Your Web Applications Now
Recommended Articles

What is ModSecurity?

what is modsecurity modsecurity rules examples One reason ModSecurity is popular with web hosts and site owners is because it lets you decide which features are important to you and allows you to enable and disable them at will. At the core, the ModSecurity tool is a WAF that blocks web-based attacks. It blocks many of the common attacks in the wild, and it works even if the site owner is unaware of how a vulnerability can be exploited.

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.

What is a ModSecurity Rule?

what is a modsecurity rule Not every web server needs the same rules for HTTP requests. You might want to block specific traffic on one application but not another. You might want to control responses sent to external users to add a layer of security to data. Rules can also be set up for monitoring so that administrators will be aware of ongoing attacks targeting their applications. The set of rules really depends on applications running on the server.

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.

Cross-Site Scripting (XSS)

cross-site scripting modsecurity rules xss When users can send special characters used to manipulate rendered pages, your site could be vulnerable to XSS. XSS covers two types: reflected and persistent. Persistent XSS happens when attackers can store malicious content in the database. The content is then rendered later when other users request pages that query the database and return the malicious content. Reflected XSS occurs when user-generated input is sent to a server, and the response includes the unsanitized input. Usually, reflected XSS happens in a GET request, but it’s possible to perform reflected XSS in a POST request.

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.

Bad User Agent

modsecurity rules bad user agent

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.

SQL Injection (SQLi)

SQL Injection (SQLi) modsecurity rules Most dynamic pages have a backend database that stores data. The queries executed on the database are written in SQL, which is a language for databases with specific syntax. If attackers can run altered SQL on the database, it can be used to steal data, destroy tables, or elevate privileges on the server.

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.

Session Hijacking

session hijacking modsecurity rules

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.

Should I Use ModSecurity?

should I use modsecurity Without ModSecurity, web applications are open to numerous attacks. The four examples listed in the previous section are just a few threats that could take advantage of a web application without proper security. Having tools in place to stop attacks, especially if you’re using third-party applications and plugins, helps stop attacks even if code could be vulnerable to exploits.

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.

Imunify360 ModSecurity Ruleset

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.

manage modsecurity vendors

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.

Protect Your Web Applications Now

Modsecurity & imunify360 protect your web applications now Imunify360 will protect your site from exploits and attacks. To learn more about technical details and installation - sign up for a trial or contact us directly at sales@cloudlinux.com