mitigating wordpress xmlrpc attack using ossec

I’ve created some local rules for ossec to mitigate some of the effects of the wordpress xmlrpc attack presented here: WordPress Pingback Portscanner – Metasploit Module.

They seem to work for me, use at your own risk of getting flooded with tons of alerts. Obviously you need to set the alert level of the second rule to something that will trigger your active-response. Feel free to tweak the alert level, frequency and timeframe. Before you change frequency to something else please read the following thread though: setting ossec frequency level

   <rule id="100167" level="1">
    <description>WordPress xmlrpc attempt.</description>

  <rule id="100168" level="10" frequency="2" timeframe="600">
    <same_source_ip />
    <description>WordPress xmlrpc attack.</description>

btw, if you don’t want xmlrpc.php accessible at all, you can block it through a simple mod_rewrite rule:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/PATH/TO/xmlrpc.php [NC]
RewriteRule ^(.*)$ - [F,L]

or you can try any of the other numerous ways to accomplish the same thing as presented here.

You’ll lose pingback functionality though…oh well.

6 years! + grrbl news

It’s been exactly 6 years (!) since I started this blog:

Too bad I don’t have as much free time as I had in the past to post about interesting things. It’s a also a time for a redesign…I think I have the same theme for more than 5 years…

Anyway, GrRBL got redesigned yesterday by Christine and now there’s also a submission form for those who prefer it over forwarding emails. I also merged my other Greek spammers email addresses blacklist with lists by a couple of friends (postmasters) and now the list contains over 300 unique, verified, spammer addresses. This list is not yet public but if you are interested to use it and test it, give me a shout and I’ll give you access.

Convert greek characters from latin1 mysql database fields to pure utf8

The Problem
To sum it up, the case is this: many many many web applications were programmed so that they used latin1 collation for their fields inside mysql databases. But most users now use utf8 from within their browsers. What happens is that utf8 characters are getting stored inside latin1 fields, which in return produces chaos! A huge web application that used that kind of madness was WordPress. Luckily (or not) WordPress now uses utf8 everywhere. I’ve known many many many people that got so frustrated when they tried to move from their old WordPress installation to a newer one because all their greek posts couldn’t be exported “easily”, I won’t say “properly” because there are always solutions to problems like this, but all the solutions were not straightforward at all, that they finally dumped the idea of moving the posts and started a new blog.

This is a HUGE problem for many greek (and not only) users and I hope I now have an elegant(?) solution to it.

How much can misconfigured wordpress plugins stall your server’s performance

A couple of days ago I’ve met a guy who has a high traffic blog about tech stuff. The guy was telling me that he has hosting problems and that his blog is getting slower and slower by the day. I’ve offered to help him by providing hosting for him in one of the servers that I administer. After making the transition from his old hosting to my server, which was not an easy thing to do due to latin1 to utf8 conversions that had to be made – it deserves a post of it’s own, I started to notice increased load on my server. Sure his blog had heavy traffic…but could it be that bad ?