Mod Security and WordPress

I was in the middle of setting up my developers blog again, and getting everything configured when I lost all connection to it.  I contacted my hosting provider and they came back and said: “It looks like you managed to trigger a mod_security rule and get yourself blocked from the server. I’ve disabled that mod_sec rule for your site, and unblocked you.”.  It seems that I validated the 211540  ‘COMODO WAF: Blind SQL Injection Attack’  rule.  This kinda of got me scratching my head a little, I’ve already setup a couple of WordPress sites over the past couple of months with no issues.  So after I got everything setup the way I wanted to started to Google around to see how I triggered this rule.

From 9,000 + results it seems that this rule causes a lot of false positives.  So what is the Blind SQL Injection Attack rule actually trying to prevent?

Blind SQL Injection is a form of SQL Injection that overcomes the lack of error messages. Without the error messages that facilitate SQL Injection, the attacker constructs input strings that probe the target through simple Boolean SQL expressions. When an attacker executes SQL Injection attacks the server sometimes responds with error messages from the database server indicating that the SQL Query’s syntax is incorrect. Blind SQL injection is nearly identical to normal SQL Injection, the only difference being the way the data is retrieved from the database. When the database does not output data to the web page, an attacker is forced to steal data by asking the database a series of true or false questions. 

Even though I have a better understanding about what the rule is trying to do, I have no idea what I did to create a false positive.  So with these changes I made sure to do the following to tighten down the security on my installations.

  1. Run secure, stable versions of my plugins and installation
  2. Have a server-level firewall.
  3. Never, ever access your server from an insecure network.
  4. Never FTP, use SFTP
  5. Always create a unique database for each blog installation, and make sure your database table DOES NOT begin with wp_.
  6. Backup your database and other files as often as possible, especially right before you make a change
  7. And, of course, make sure your passwords are both complex and not used elsewhere.

The next step will be to beef up the default .htaccess configuration that WordPress sets up during the installation.

Leave a Reply