Search code examples
phpsymfonyinstallationcpanelmod-security

Keep ModSecurity Enabled With Symfony installation W/Cpanel & WHM

This question is an extension of another here (Symfony framework install 406 Not Acceptable Error w/CPanel & WHM), please read my answer there to see how I solved the issue.

I was able to solve the issue I had with the 406 errors but at a cost.., I had to disable mod security in WHM which is a huge security vulnerability I'm sure. My question is how can I keep mod security enabled and still have it work with the default Symfony installation so that I do not receive 406 errors anymore?

EDIT

ModSecurity Logs

Request: GET / Action Description: Access denied with code 406 (phase 4). Justification: Pattern match "^5\d{2}$" at RESPONSE_STATUS

Solution

  • Background

    ModSecurity is a Web Application Firewall (or WAF). You can define rules to attempt to identify and block illegitimate requests. WAFs are not perfect though, and often generic rules are used that work in "most sites", but do sometimes block legitimate requests (known as false positives).

    The first thing to understand is that no one will know what ModSecurity rules you have installed except you. ModSecurity does not come with any rules at all, though there are rules available to download, from free ones (like the OWASP CRS) to paid for ones from the likes of Atomic) or you can write your own. So the first thing to explain to you is that no one will be able to tell you how to solve this problem as it's likely to be specific to you depending on your installation. Saying that we can guide you on the way to finding your own solution.

    Running a WAF does give extra protection but does require a lot of maintenance. While I personally like it and can see the merit, most sites live without it to be honest and it's rare (though not unheard of) that hackers make it in anyway if you keep your software up to date and don't install software that is high target (WordPress for example). It's up to you whether to keep it depending on how critical and security minded your website needs to be but, if do want to use it, then you will need to understand how it works to deal with issues like this.

    Your problem.

    I am not familiar with Symfony but from what I can understand when ModSecurity is turned on, your application fails and at least one ModSecurity rule fires. When ModSecurity is switched off it all works fine.

    So first of all you need to find out ALL the rules that are stopping your applications from working. You have given one rule but I suspect that is not the only one blocking.

    That rule is, as I discussed in the comments to your original question, a fairly standard rule in most rulesets to try to prevent information leakage. All web servers respond with a 3 digit status code for each request. The most well known is 404 or "page not found". The ones in the 500 range mean server error. So this rule says that if the server responds (RESPONSE_STATUS) with a pattern matching "^5\d{2}$" (i.e. 5XX were X is a digit so 0-9) then something has gone wrong, and ModSecurity steps in to prevent any error messages going back to the user and instead sends it's own 406 error message instead.

    ModSecurity has 5 phases:

    1. Rules that scan Request headers (REQUEST_HEADERS)
    2. Rules that scan Request body (REQUEST_BODY)
    3. Rules that scan Response headers (RESPONSE_HEADERS)
    4. Rules that scan Response body (RESPONSE_BODY)
    5. Rules that affect Logging (LOGGING)

    This rule fires in phase 4 - which is when the request is being sent back to the client. So at this stage something has already gone wrong for your application to have returned a 5XX status.

    I suspect that another ModSecurity rule fired earlier (a phase 1 or phase 2 rule) which caused the error and you have only shown the last rule that fired.

    Before I could help you further with your problem I would need to know:

    • ALL ModSecurity error messages from the Apache Error logs.
    • Additionally it would be helpful to know what version of ModSecurity you are running (this should be in the Apache error logs at start up).
    • It would also be helpful to know what ruleset you are running. Are they some of the standard ones discussed above, or ones that have been written especially for your site? Most rules have a rule id (in fact this is mandatory from ModSecurity 2.7 onwards) so surprised this is not listed in the error log snippet you gave earlier.

    With that I, or someone else, might be able to help point you in the right direction.

    How you can self-diagnose this problem (and future problems!)

    If I were you I would take the following steps to identify the problem:

    1. Read all your Apache config filesand find out where the ModSecurity config and rules are defined. ModSecurity rules are just text config using the ModSecurity language added to standard Apache config - often by including external files were the rules are defined. Get to understand what those rules do and mean.
    2. Find the "SecRuleEngine On" line on your config and change this to "SecRuleEngine DetectionOnly" then restart Apache. This will flag rules in the log files but NOT block attempts. Then do what you want to do and take not of the rules that fire.
    3. Also turn on the additional Audit engine to capture full details of requests which block ("SecAuditEngine RelevantOnly").
    4. Decide if you need those rules tat are causing you problems, and then either comment them out of your config, or there are ways to tune them to stop blocking legitimate requests.
    5. Once all the rules are tuned, then turn ModSecurity on again.

    The ModSecurity Reference Manual is a very useful resource to understand ModSecurity.

    I can also recommend the ModSecurity handbook for further reading. It was written by the original author of ModSecurity and while it hasn't been updated since version 2.7 it's still a great intro.

    Hope that helps, Barry