The issue in the probably due to ModSecurity™ web application firewall enabled on your domain.
What does ModSecurity™ do, the following is a list of the most important usage scenarios:
- Real-time application security monitoring and access control
- At its core, ModSecurity gives you access to the HTTP traffic stream, in real-time, along with the ability to inspect it. This is enough for real-time security monitoring. There's an added dimension of what's possible through ModSecurity's persistent storage mechanism, which enables you to track system elements over time and perform event correlation. You are able to reliably block, if you so wish, because ModSecurity uses full request and response buffering.
- Full HTTP traffic logging
- Web servers traditionally do very little when it comes to logging for security purposes. They log very little by default, and even with a lot of tweaking you are not able to get everything that you need. I have yet to encounter a web server that is able to log full transaction data. ModSecurity gives you that ability to log anything you need, including raw transaction data, which is essential for forensics. In addition, you get to choose which transactions are logged, which parts of a transaction are logged, and which parts are sanitized.
- Continuous passive security assessment
- A security assessment is largely seen as an active scheduled event, in which an independent team is sourced to try to perform a simulated attack. The continuous passive security assessment is a variation of real-time monitoring, where, instead of focusing on the behaviour of the external parties, you focus on the behaviour of the system itself. It's an early warning system of sorts that can detect traces of many abnormalities and security weaknesses before they are exploited.
- Web application hardening
- One of my favourites uses for ModSecurity is attack surface reduction, in which you selectively narrow down the HTTP features you are willing to accept (e.g., request methods, request headers, content types, etc.). ModSecurity can assist you in enforcing many similar restrictions, either directly, or through collaboration with other Apache modules. They all fall under web application hardening. For example, it is possible to fix many session management issues, as well as cross-site request forgery vulnerabilities.
More information is available at
https://www.modsecurity.org/
Why has ModSecurity™ blocked me in the screenshot? On the server we are using the OWASP ModSecurity Core Rule Set (CRS) ruleset to protect your website against malicious attacks such as SQL Injection (SQLi), Cross Site Scripting (XSS), Local File Inclusion (LFI), Remote File Inclusion (RFI), Remote Code Execution (RCE), PHP Code Injection, HTTP Protocol Violations, HTTPoxy, Shellshock, Session Fixation, Scanner Detection, Metadata/Error Leakages, Project Honey Pot Blacklist. More information is given at
https://modsecurity.org/crs/ . Specifically, your access to the URL was blocked by rules number 930130 and 949110.
What do rules 930130 and 949110 do? Rule 930130 restricts direct file access attempts. It detects attempts to retrieve application source code, metadata, credentials and version control history possibly reachable in a web root. This means that when you try to access
https://residenceduhamel.com/wp-admin.php whereas WordPress mandates the access should have been
https://residenceduhamel.com/wp-admin// which then is redirected to
https://residenceduhamel.com/wp-admin.php ModSecurity OWASP ruleset's rule number 930130 classifies that as an incorrect method and probable malicious access and blocks your IP address.
Rule 949110 is an Inbound Anomaly Score Exceeded (Total Score: 5) rule. The rule calculates the score for each web access and blocks the access if the total score exceeds the specified value.
Don't need it, turn it Off? ModSecurity™, in general, is an effective, established web application firewall but maybe is generating too many issues compared to the security value it provides or maybe the ruleset is generating false positives or you just need a lower level of security on the server for this website and can manage your security on the application level. In such cases, we have provided an option to turn off ModSecurity™ on the domain through cPanel domain management interface. Here are the steps to disable ModSecurity™ on a domain
Please navigate to cPanel > Security > ModSecurity™. On that page, you will see the following options
I have marked with a red arrow in the picture above the button which will disable ModSecurity on your chosen domain while leaving other websites protected. Please click on "disable" option to completely disable ModSecurity on the domain.
If the above has not resolved your issue, please raise a ticket with technical support to look into the issue in more detail.
