How to Protect Your Wordpress

[alika]

My main site was attacked for a week. Traffic was soooo high that it overloaded the server.

My web host said that the attack was aimed to gain bruteforce access to our Wordpress. Thankfully, they were not successful. I totally blocked off the entire country where the attack was coming from, and that seemed to stop the attacks.

What are you doing to secure your Wordpress?

[matrix_jan]

alika,

I assume they were trying to gain access to the admin area (wp-admin). Allowing access to wp-admin through .htaccess from certain IP addresses can secure your website enough. You might try that instead of blocking a whole country, try providing access to sensitive areas to only few IPs.

[DeeCee]

Locking wp-admin with a white-list and using good passwords is an important good idea, and works for a few attack types. Pure login and brute force password attacks.

However, the most frequent attacks I see and catch are attacks on vulnerable themes and plugins. The hackers check the code of such themes and plugins and easily see some of the vulnerabilities. Often the same vulnerability in all of them, because they all included the same insecure piece of code with the theme/plugin. Borrowed or expanded from some other GPL'ed piece of code.
Most often the security issues are not in Wordpress itself, but the many free amateur themes and plugins people use. Being a good visual theme designer often is not combined with being a good security programmer.

I had one barrage of attacks that went on for weeks, seemingly trying every theme name and plugin name under the sun multiple times from many, many IPs (botnet or cloud services). I use none of the hacked site themes fortunately, plus I check the code I use.

Usually attacks targeted at any plugin or theme that supports file uploads. Such as having an image gallery or others that somehow allow a user-upload mechanism. Even if you did not actually enable it.

No wp-admin lock-down protect from those. They do not need admin log-in or /wp-admin access. All they need is an upload mechanism and and a purposefully insecure upload directory to stash the code in. Only fixed upload code, good secure file/directory permissions on the server preventing bad files, (or a plugin/htaccess that blocks these URL patterns).

Some attack patterns initially simply look for the bad themes or plugins by trying to load a known file. Such as "wp-content/themes/theme-name/styles.css", which would always be there if the theme is installed. If they cannot load the style file, on to the next theme check. Thousands and thousands of them. Similar for the gallery type attacks. All they need is one good (read: "bad") upload of a code file to your server, and the infection is in place. Now they can call it from the outside as a standard URL, make your http server call on it as valid code that suddenly makes many funny site modifications, and they own you. Pretty simple mechanism, really.

Alika,
The best way stop attacks from overloading a server is at the firewall level (assuming one has access to that), since that stops the server overload. Next best through an http server config or a good mod_security setup, third by htaccess pattern blocking on the individual site level. That 3rd option is unfortunately what many or most site owners are limited to. The further "out" towards the network you shut them down, the better it is for your server.

Fourth option is using a security/spam plugin that might be able to block some of the known scammers and patterns. But by that time you are in at least the initial load routines in Wordpress when the plugin call and check happens, so some server load has started.

[Go60Guy]

I'm no expert, but here's what I've done lately on multiple existing WP sites. Bear in mind, I always use very strong passwords unique to each site.

1. Updated all my WP sites to 3.3.1.
2. Updated all plugins.
3. Installed, activated and made settings that make sense with the Better WP Security plugin (it's free to download).
4. Using that plugin, among other things, I've:

_{a. Set up brute force protection, setting only 5 login attempts and blocking for 600 minutes
b. Replaced the "admin" username
c. Secured the .htaccess file
d. Blocked long urls
e. Various other tweaks available with the plugin}

Also, you might want to check for malware coming in through timthumb.php using the timthumb vulnerability scanner plugin (also a free download).

I think blocking individual IPs through your firewall is a losing battle (I have a VPS). I'm not saying don't do it. Just that there are so many attempts going on since the first of the year that it's difficult to keep up.

On new installs, you can, apparently, safely change the wp prefix which can be problematic on existing sites.

I'm open to all other suggestions.

Addendum:

What triggered my beefing up of security was hacking of one of my sites. I took the matter up with my host (I have VPS) and received this in the exchange:

There's no indication that this occurred through cPanel or FTP or any other protocol other that HTTP. I've only seen this variety of hack with WP....

The hack took the form of injection of malicious code in all the index.php files on the site.

[lorax]

There are literally many things you can do to help.

Read this list at WordPress [codex.wordpress.org...]

Basic security includes:

strong passwords,

tightening up file permissions,

using strong Salts,

don't use the default table prefix,

keep your sites & plugins updated,

minimize the use of plugins that aren't well supported

[suhanaanjum]

We can protect Word Press from so many methods as mentioned above like
Using a constant and relevant strong passwords,updating the sites always use supportive plug ins only.

[xword_5601]

Using the excellent WordPress Firewall plugin. This excellent piece of kit automatically detects attacks and blocks them, sending you an e-mail each time. If the guy quoted above had been using the plugin he never would have been hacked!
In once case, I’ve received over 1,000 of these e-mails on the same day! It was only after I blocked the IP address of the attacker (included in the e-mail) that the attacks ceased.