The below error was generating when add Post on webpage the code developed by PHP.
[error] [client 1192.168.0.1] ModSecurity: Access denied With code 406(phase 2). Pattern match "(?:\\b(?:\\.(?:ht(?:access|passwd|group)|www_?acl)|global\\\.asa|httpd\\\.conf|boot\\\\.ini)\\\\b|\\\\/etc\\\\/|\\\\/root\\\\/|\\\\/public_html\\\\/)" at ARGS:content. [file "/usr/local/apache/conf/2.user.conf"] [line "134"] [id "1234123401"] [msg "Remote File Access Attempt"] [data "/etc/"] [severity "CRITICAL"] [tag "WEB_ATTACK/FILE_INJECTION"] [hostname "mydomain.com"] [uri "/admin/preview.php"] [unique_id "U36x7XyZeYcAAFVUXLsAAADC"]
I found the code from below file :
vim /usr/local/apache/conf/modsec2.user.conf
"phase:2,capture,t:none,t:htmlEntityDecode,t:lowercase,ctl:auditLogParts=+E,deny,log,auditlog,msg:'Remote File Access Attempt',id:'1234123401',tag:'WEB_ATTACK/FILE_INJECTION',logdata:'%{TX.0}',severity:'2'"
Is it secure may mod_security will be disabled?
As I see it the problem is that in one of the request parameters of the request to "/admin/preview.php" the string "/etc/" was used, which looks like an attack and therefore the rule with the id 1234123401 blocked the request.
If this was an attack than ModSecurity worked nicely.
If this was a legitimate request which needs to go through ModSecurity one could
1) Change the request so that it does not contain the string "/etc/" as a parameter value - maybe the PHP script has to be adapted for this
2) Modify the rule's regular expression and remove the /etc/ part
3) Change the rule action from deny to pass
I would not go with options 2 & 3 as you would lower the security level. Instead I would try to go with option one.
Best, Ronald