Maybe also an environment variable should be set? SecDefaultAction "phase:2,deny,setenv:modsec=denied,log" With this the user could display a different msg with a #if expr= in the error page.
Michael 2012/6/6 Ryan Barnett <rbarn...@trustwave.com>: > Updated the following section for the SecDefaultAction directive that > controls the mode of operation – either self-contained or collaborative > detection. > > # > # -- [[ Modes of Operation: Self-Contained vs. Collaborative Detection ]] > ----------------- > # > # Each detection rule uses the "block" action which will inherit the > SecDefaultAction > # specified below. Your settings here will determine which mode of > operation you use. > # > # -- [[ Self-Contained Mode ]] -- > # Rules inherit the "deny" disruptive action. The first rule that matches > will block. > # > # -- [[ Collaborative Detection Mode ]] -- > # This is a "delayed blocking" mode of operation where each matching rule > will inherit > # the "pass" action and will only contribute to anomaly scores. > Transactional blocking > # can be applied > # > # -- [[ Alert Logging Control ]] -- > # You have three options - > # > # - To log to both the Apache error_log and ModSecurity audit_log file use: > "log" > # - To log *only* to the ModSecurity audit_log file use: "nolog,auditlog" > # - To log *only* to the Apache error_log file use: "log,noauditlog" > # > # Ref: > http://blog.spiderlabs.com/2010/11/advanced-topic-of-the-week-traditional-vs-anomaly-scoring-detection-modes.html > # Ref: > https://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual#SecDefaultAction > # > SecDefaultAction "phase:2,deny,log" > > For discussion purposes, regarding "disruptive actions", I believe that we > should consider responding differently to malicious transactions. Issuing > HTTP 4xx level response codes are of no help to non-malicious end users who > have innocently triggered an alert and they also "tip the hand" a bit to > malicious users that there is some type of separate security layer in place. > I am a proponent of trying to make a WAF deployment transparent to the user > – meaning that they can decipher when ModSecurity has triggered an alert vs. > if the application itself issues some type of violation. > > For example – oftentimes when an invalid request is received, applications > will issue 302 Redirects back to the previous page or a login page. I would > like to prose the idea of using the redirect action here within the > SecDefaultAction setting and letting the ModSec Admin choose where to > redirect users too when an alert is triggered. Example: > > SecDefaultAction "phase:2,redirect:http://www.example.com/login.php,log"; > > Comments? > > -- > Ryan Barnett > Trustwave SpiderLabs > ModSecurity Project Leader > OWASP ModSecurity CRS Project Leader > > ________________________________ > This transmission may contain information that is privileged, confidential, > and/or exempt from disclosure under applicable law. If you are not the > intended recipient, you are hereby notified that any disclosure, copying, > distribution, or use of the information contained herein (including any > reliance thereon) is STRICTLY PROHIBITED. If you received this transmission > in error, please immediately contact the sender and destroy the material in > its entirety, whether in electronic or hard copy format. > > _______________________________________________ > Owasp-modsecurity-core-rule-set mailing list > Owasp-modsecurity-core-rule-set@lists.owasp.org > https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set > _______________________________________________ Owasp-modsecurity-core-rule-set mailing list Owasp-modsecurity-core-rule-set@lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
