Differences

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

--- faq:mod_security [2013-07-16 09:09] – andi
+++ faq:mod_security [2017-06-21 10:55] – Forgot the IfModule block! 2.98.36.101
@@ Line 15: / Line 15: @@
 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
@@ Line 21: / Line 22: @@
 --[[chris@thefreyers.net|Chris Freyer]] 7/23/09
+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 =====
@@ Line 27: / Line 46: @@
   * 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.
+We had suspected that the rule being triggered was:
+> Atomicorp.com WAF AntiSpam Rules: Possible Spam: Multiple embedded urls in argument (Disable if you wish to allow 4 or more URLs in a post) .
+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 m 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.