Differences

This shows you the differences between two versions of the page.

--- faq:mod_security [2016-05-30 00:29] – Checking for 4 or more URLs in a single post daviding
+++ faq:mod_security [2023-09-13 08:50] (current) – [Error on certain page content] 37.24.179.178
@@ Line 3: / Line 3: @@
 :?: When certain code examples are entered on a page, the Server returns a "Error 403 -- Forbidden", "Error 406 -- Not Acceptable", "Error 403 -- Forbidden", "503 -- Service Temporarily Unavailable" or similar errors. What's the problem?
-:!: This is usually a problem caused by overly-restrictive security policies set in the webserver (usually [[http://www.modsecurity.org|mod_security]]) or an application level Firewall (Sophos Firewall Webapp Control is known to be problematic).
+:!: This is usually a problem caused by overly-restrictive security policies set in the webserver (usually [[http://www.modsecurity.org/|mod_security]]) or an application level Firewall (Sophos Firewall Webapp Control is known to be problematic).
-There is no way to fix this in DokuWiki, because it is not a problem caused by DokuWiki itself. You need to check your webserver or application firewall audit logs to identify the problematic rule and disable it.
+There is no way to fix this in DokuWiki, because it is not a problem caused by DokuWiki itself. You need to check your webserver or application firewall audit logs to identify the problematic rule and disable it (or notify your provider to do so).
 Commonly problematic words are parts of SQL statements, mail or UNIX commands like:
@@ Line 11: / Line 11: @@
   * select ... from
   * drop ...
+  * having ...
   * to: ...
   * wget ...
+  * /etc/ ...
 Sometimes the problem also occurs when certain parameters are passed in the URL, especially when they contain external URLs like when using external images that are loaded from DokuWiki's image cache system in ''lib/exe/fetch.php''.
-===== Possible Resolution =====
+===== Less-secure resolutions =====
-On apache, ''mod_security'' can be disabled at a user or hosted domain level.  The following two lines can be inserted in an ''.htaccess'' file that is saved in the ''[home_directory]/public_html'' directory:
-  SecFilterEngine Off
+On Apache, ''mod_security'' can be disabled at a user or hosted domain level.  The following two lines can be inserted in an ''.htaccess'' file that is saved in the ''[home_directory]/public_html'' directory:
-  SecFilterScanPOST Off
+  <IfModule mod_security.c>
+    SecFilterEngine Off
+    SecFilterScanPOST Off
+  </IfModule>
+  <IfModule security2_module>
+    SecRuleEngine Off
+  </IfModule>
 --[[chris@thefreyers.net|Chris Freyer]] 7/23/09
-This could be a trade off between security and usability.
+This could be a trade off between security and usability, although it is completely possible to have your DokuWiki work with mod_security, by spending time to update your security rules.
+On Apache2, you can disable mod_security for a specific path inside the VirtualHost block inside your site files (for instance, in /etc/apache2/sites-enabled/my_host.tld.conf), by specifying the directory that DokuWiki is in and disabling the mod_security engine on that path.
+  // /etc/apache2/sites-enabled/my_host.tld.conf
+  // Rather than using .htaccess for the entire domain.
+  <VirtualHost my_host.tld:443>
+   <Directory /var/www/my_host.tld/my_wiki_path>
+    <IfModule security2_module>
+     SecRuleEngine Off
+    </IfModule>
+   </Directory>
+  </VirtualHost>
+However, this means that for any undiscovered vulnerabilities in DokuWiki, mod_security will do nothing to prevent them from being exploited, which is not recommended security practice. For those who wish to maintain security of their installation, it is recommended to override the specific filters on for the **doku.php** file within mod_security's rules, so that it will allow for preview and editing of files, but remain enabled for the remainder of the site.
 ===== Other Solution =====
 In some cases it is not allowed to disable the ''mod_security'' option in the ''.htacces'' file. You have to contact your provider and ask for disabling some rules. In my case:
   * Rule 340009: \\ ModSecurity: Access denied with code 403 (phase 2). %%Pattern match "(?:/(?:etc|proc|var/tmp|usr|opt|s?bin|dev|tmp|kern|[br]oot|sys|windows|winnt)/|(?:\\/|\\\\)+inetpub|localstart\\.asp|boot\\.ini)" at ARGS:suffix. [file "/etc/apache2/modsec2/10_asl_rules.conf"] [line "215"] [id "340009"] [rev "26"] [msg "Atomicorp.com WAF Rules:Protected Path Access denied in URI/ARGS"] [data ""] [severity "CRITICAL"]%%
   * Rule 300001: \\ ModSecurity: Access denied with code 403 (phase 2). %%Matched phrase "home.arcor.de" at REQUEST_BODY. [file "/etc/apache2/modsec2/30_asl_antispam.conf"] [line "38"] [id "300001"] [rev "8"] [msg "Atomicorp.com WAF Rules: Blacklist Spam Domain"] [data ""] [severity "CRITICAL"]%%
 ===== A rule in mod_security =====
 Not having worked on my wiki site for some months, my attempts to edit and then save produced the problem described above.  Working with my site provider, I created a userid for the technician, who then diagnosed that the rule being triggered was "checking for 4 or more URLs in a single post".  This rule was safely disabled.
@@ Line 38: / Line 64: @@
 Changing the setting on that one rule was done.  A warning was given on removing mod_security:
 > While many sites (such as forums) would need this rule enabled to prevent spamming on their forums and usually limit the number of urls a post can have, sites that have posts with a large number of links in them (like wikis) can easily trigger this rule and may need it disabled.
-> Mod_security is made up of a few hundred thousand "rules" and while many developers would say "remove mod_security" this is not the recommended option.
+> Mod_security is m to the type of attack that the particular rule prevents, but disabling one rule is better then disabling all.
-> Instead, we can disable just the specific rules that are being triggered and is the recommended option in these type of cases where updates to the scripts would not be able to fix the issue.
-> This could potentially open you up to the type of attack that the particular rule prevents, but disabling one rule is better then disabling all.
 A little more problem determination gave a better solution.