ModSecurity and Wordpress: Defense in Depth
Daniel Cuthbert writes an excellent paper for BlogSec on securing your blog with ModSecurity.
Here’s a snippet:
Wordpress is a state-of-the-art semantic personal publishing platform with a focus on aesthetics, web standards, and usability. Unfortunately it is also missing the vital security functions that protect the application from malicious attacks. A default install of Wordpress is not as secure as Web Application Security Professionals would like, hence the need for extra layers of defence to ensure that the application remains secure at all times.
This paper defines both general and specific rules to add that extra-layer of security to your blog! Thanks to Daniel for his great work.
This is version 1.0 of the paper. I’ve personally been testing these rules on WP 2.2.3 for the past couple weeks without any problems, however, circumstances vary.
The paper is available in PDF:
wordpress-modsecurity-paper.pdf
Spanish Version
Random Posts
If you enjoyed this post, please leave a comment or subscribe to the feed and get future articles delivered to your feed reader.
Comments
[...] habe ich mir diesen Beitrag durchgelesen und auf Grund dessen ein Config File erstellt. Bis auf die Beschränkung das man nur [...]
[...] especially with Wordpress. Go ahead, subscribe to our feed!Daniel Cuthbert has written a paper on ModSecurity and Wordpress. While I praise the work and the effort, I am not sure why they did not find it in themselves to [...]
[...] Blogsecurity.net gefunden: ModSecurity and Wordpress: Defense in Depth. Der Artikel verweist auf Daniel Cuthberts Artikel für BlogSec; es ist ein ziemlich [...]
@Xaitax
Agree, there are many ways to make wordpress secure, as as time permits, i will add to this to include other methods.
[...] Modsecurity and WordPress paper - I haven’t used ModSecurity myself but it seems like something good to know about. [...]
Contrary to what the authors of that paper and the readers of this blog may believe, none of that is actually needed. WordPress will prevent any attacks like that.
For example, one rule prevents you from using various SQL commands for values of querystring arguments. However, the authors did not research to make sure this was needed. The “tb_id” parameter (used with the wp-trackback.php file) is simply used to specify whether or not the trackback ID has been generated yet. It is never used in any queries.
The category ID is forced to be an integer by the get_term function (wp-includes/taxonomy.php).
Ask any WordPress developer and they’ll also tell you you don’t need this stuff. Even if it weren’t, why would you use something with major security holes?
those rules are for 1.9 I tried implementing mod security 2.0 according to this how-to: http://howtoforge.com/apache2_mod_security_debian_etch
after activating it I had some problems with uploading big files, but I could not find the rule that made problems, so I deactivated mod_security2 again.
I would be verys happy if someone could look through the default ruels that come with mod-security2 and eliminate those problematic for wp. This is just a suggestion and I am not lazy to do it myself, just not confident and comeptent enough to do it myself.
Mike, you are really looking at this in a two-dimensional way.
These rules will provide:
1. Potential to log and categorise attacks.
2. Protect against zero-day vulnerabilities through generic rules (i.e. PHP int function vulnerability)
3. Provide an additional security blanket, especially for older WP users who can’t upgrade for one reason or another.
As Daniel rightly titled this project, defense in depth.
ovidiu, yes, mod_security can be a little tricky sometimes if you haven’t used it before.
The rules have been tested on WP and should work fine, however, certain keywords and phrases in posts may trigger a rule. You’ll need to find your modsecurity . log file to locate the problem.
Mike,
This is a very weak argument from your perspective, let’s break it down.
“Contrary to what the authors of that paper and the readers of this blog may believe, none of that is actually needed. WordPress will prevent any attacks like that.”
Interesting, having gone over the wordpress code and seen how the developers do stuff, it makes me wonder how the application prevents attacks. Furthermore, visiting Secunia and checking to see how many public vulnerabilities have been discovered, tells me otherwise
http://secunia.com/search/?search=wordpress
“Ask any WordPress developer and they’ll also tell you you don’t need this stuff.”
To be honest, the WP developers don’t really get SDLC or secure coding, we have seen this with damn near every release from them, with security issues present in nearly every version.
I wrote this article as it is damn easy to hack into a wordpress install, and many people do not have the skills, or knowledge, of fixing the code themselves.
[...] BlogSecurity.net: ModSecurity and Wordpress: Defense in Depth - Paper about securing Wordpress [...]
Great paper. I will study each section of it. Lately some customer wordpress sites were hacked using a couple of methods. One to override the .htaccess file and one to override entries in the wp-options table.
Thanks.
[...] Tools Collection: ModSecurity and Wordpress Daniel Cuthbert has written a paper on ModSecurity and Wordpress. While I praise the work and the effort, I am not sure why they did not find it in themselves to [...]
[...] Mod Security Mod Security Mod Security Introduction To Mod Security Modsecurity and Wordpress Defense in Depth Proteja seu blog Compartilhe com a Blogosfera ! These icons link to social bookmarking sites [...]
my wp blog hosted on a webhosting provider, (i don’t have server), and as far i know, just admin right can accessing modsecurity file.
so, is there an alternative way so that i can use all modsecurity configurations on paper above/pdf (modsecurity configuration on General Configuration section, Additional Web Application Security Rules section, and ModSecurity Specific Rules for WordPress section)??
Thanks
boyank, unfortunatly, basic web hosting packages may not allow ModSecurity, check with your provider.
Well, all i can say is that serious webmasters use modsecurity v2.x and not the v1.9 as used for the whitepaper.
dieter, ModSec v1 is still considered the stable version. ModSec v2 requires special compiling under a number of Linux distros.
Regardless, these rules should still work in v2.
[...] of Samuel Aguilera we’re able to announce the instant availability of the Whitepaper and the ModSecurity Paper in Spanish. The translation is es_ES, but should be understandable as well for the other derivates [...]
Dieter,
What a load of rubbish, ModSecurity v2 only works with Apache v2, and I know many serious webmasters (sites that handle 10 million plus hits a day) that still run on Apache 1.3x
Come one..
[...] Ihr nun anfangen wollt, mit den regeln ein wenig zu spielen, schaut doch noch bei Blogsecurity vorbei. Hier gibt es z.B. einen feinen Regelsatz für Wordpress [...]
[...] BlogSecurity » Blog Archive » ModSecurity and Wordpress: Defense in Depth 0 Comments So Far Tagged with: Aesthetics • Apache • Blog Archive • Defense In Depth • Focus • Malicious Attacks • Modsecurity • Personal Publishing • Security Functions • Security Professionals • State Of The Art • Usability • Vital Security • Web Application Security • Web Standards • Web Usability [...]
You say you’ve been testing them with WP 2.2.3..
Unfortunately in WP 2.5, in order to use the Media Gallery functionality, you have to use the directive:
SecFilterScanPOST Off
Have you got an updated version of this for WP 2.5?
BCG
[...] an interesting project to keep an eye on nonetheless. An alternative approach would be to utilise ModSecurity which is much more powerful then mod_rewrite and which can be applied at the web server layer. [...]
I would prefere Suhosin-Patch/Extension instead of mod_security. It has lots more advantages.