I asked Perplexity to explain the Plesk Web Application Firewall rules by Comodo.
I’m adding the response here because I’m expecting that I’ll need to reference this at various times and so will others.
https://www.perplexity.ai/search/i-m-using-plesk-with-the-mod-s-c5tiuzOaT_a2_sJuUGgpaQ
Here’s an example of the Rules I’m talking about:
Comprehensive Guide to Comodo ModSecurity Rule Categories in Plesk
Based on your Plesk ModSecurity configuration using Comodo’s free ruleset, you’re seeing a comprehensive collection of rule categories designed to protect web applications from various attack vectors. These categories represent different types of security threats and application-specific protections that ModSecurity monitors for incoming HTTP requests.
Attack Detection and Prevention Rules
Generic represents the foundational layer of Comodo’s Web Application Firewall protection, containing rules that detect common attack patterns including system command injection, remote file inclusion attacks, session fixation attempts, and various vulnerability exploits. These rules form the backbone of the security system by identifying fundamental attack methodologies that don’t fall into more specific categories.
SQLi (SQL Injection) provides comprehensive protection against database manipulation attacks, including blind SQL injection, benchmark and sleep injection attempts, MySQL charset switch attacks, and MSSQL code execution attempts. This category is particularly crucial for any website that interacts with databases, as SQL injection remains one of the most common and dangerous web application vulnerabilities.
XSS (Cross-Site Scripting) focuses on detecting and preventing client-side script injection attacks that could compromise user sessions or steal sensitive information. These rules are essential for protecting both your website and your visitors from malicious script execution in web browsers.
Bruteforce implements protection against automated attack attempts, specifically targeting multiple username violations and excessive authentication attempts. This category helps prevent unauthorized access attempts through repeated login failures and credential stuffing attacks.
Information Disclosure Prevention
FilterPHP addresses PHP-specific information leakage, including source code exposure and configuration details that could reveal sensitive information about your server environment. This category is likely what caused issues with your WordPress site, as it monitors for PHP version information and other details that could be inadvertently exposed in error messages or debug output.
FilterGen provides generic information disclosure protection, monitoring for directory listings, file or directory name leakage, potential obfuscated JavaScript, and statistical information exposure. These rules prevent attackers from gathering reconnaissance information about your server structure and configuration.
FilterSQL specifically targets SQL-related information leakage that could reveal database structure, error messages, or query details to potential attackers. This complements the SQLi category by focusing on information disclosure rather than active injection attempts.
FilterASP and FilterOther protect against ASP/JSP source code leakage and information disclosure from various other applications including Zope, Cold Fusion, Microsoft Office documents, and WebLogic servers.
Protocol and Request Validation
Protocol enforces proper HTTP protocol compliance by detecting various protocol violations including invalid URI formats, malformed multipart requests, invalid character encoding, and other protocol-level anomalies. These rules ensure that incoming requests conform to established web standards and help prevent protocol-based attacks.
Request validates HTTP request parameters by checking argument lengths, values, total request size, and uploaded file sizes. This category helps prevent resource exhaustion attacks and ensures requests stay within acceptable limits for your server configuration.
HTTP provides general HTTP protection including method validation, content type restrictions, protocol version enforcement, and header validation. This category works in conjunction with Protocol rules to ensure comprehensive HTTP-level security.
HTTPDoS specifically targets Denial of Service attacks including Slowloris attacks and various overflow vulnerabilities that could compromise server availability.
Application-Specific Protection
WordPress and WPPlugin provide specialized protection for WordPress installations and their plugins, addressing common vulnerabilities specific to the WordPress ecosystem. Given your WordPress access issues, these categories work alongside FilterPHP to protect WordPress while potentially blocking legitimate administrative functions if rules are too restrictive.
Joomla and JComponent offer similar protection for Joomla content management systems and their components.
Drupal provides Drupal-specific security rules.
WHMCS protects the popular web hosting billing and automation platform.
PHPGen implements generic PHP protection beyond information disclosure, focusing on PHP-specific vulnerabilities and attack patterns.
RORGen provides protection for Ruby on Rails applications.
Specialised Detection Categories
Agents identifies security scanners, rogue web crawlers, and automated reconnaissance tools attempting to probe your website This category helps detect when your site is being systematically examined for vulnerabilities.
Backdoor monitors for backdoor access attempts and detection of potentially injected trojans or unauthorized access mechanisms. This is crucial for identifying compromised websites or attempts to establish persistent unauthorized access.
Domains checks for malicious domain names in requests and response bodies, helping identify connections to known malicious infrastructure.
Incoming and Other handle inbound attack targeting and various miscellaneous security checks that don’t fit into more specific categories.
Infrastructure and Framework Categories
FilterInFrame specifically monitors for potentially malicious iframe tags in output, including combinations with JavaScript that could indicate cross-site scripting or clickjacking attempts.
FiltersEnd represents the final correlation and scoring phase where ModSecurity evaluates accumulated threat points and determines overall risk levels.
CWAF serves as a general Comodo Web Application Firewall tag that may be applied across multiple rule types.
Initialization and AppsInitialization handle system and application startup security configurations.
Managing Rule Sensitivity
Your access issues likely stem from FilterPHP or PHPGen categories being overly restrictive about PHP information disclosure. The search results indicate that administrators often need to exclude specific rules that cause false positives.
You can identify problematic rules by examining the ModSecurity audit log at /etc/httpd/logs/modsec_audit.log and then exclude specific rule IDs through the Plesk interface
For WordPress sites, it’s common to need adjustments to PHP-related filters since WordPress legitimately outputs version information and other details that security rules might flag as information disclosure vulnerabilities. You can selectively disable problematic rules while maintaining overall protection by using the rule exclusion features in your Plesk ModSecurity configuration.
Conclusion
This comprehensive rule categorization system provides multi-layered protection against the full spectrum of web application threats, from basic protocol violations to sophisticated application-specific attacks.
While the system offers robust security, it may require fine-tuning for specific applications like WordPress to balance security with functionality.
The modular nature of these categories allows you to selectively adjust protection levels based on your specific hosting environment and application requirements.
I created this post because I couldn’t easily find a nice list.
Unfortunately the Plesk page about WAF – Web Application Firewall doesn’t tell me much.
There’s some Comodo PDF document about Plesk, but that is useless.
It seems a Github file is the most useful source Perplexity used, but that’s a lot of info to parse. Actually all of the files there seem to contain details about the filtering being done.
