Chapter 5: Configuring WordPress for Optimum Security

In This Chapter

Introducing web security

Understanding today’s web threats

Reducing the risk of attack

Using sources you can trust

Cleaning up to avoid a soup kitchen server

Hardening WordPress

In this chapter, you deal with web security and how it pertains to WordPress. There are a lot of scary threats on the Internet, but with this chapter — and WordPress, of course — you’ll have no problem keeping your website safe and secure.

Always have a reliable backup system in place so if something goes wrong with your website you can reset it back to the last version you know worked. Chapter 7 in this minibook shows you how to back up your website.

Understanding the Basics of Web Security

Information security is the act of protecting information and information systems from unwanted or unauthorized use, access, modification, and disruption. Information security is built on principles of protecting confidentiality, integrity, and availability of information. The ultimate goal is managing your risk.

There is no silver bullet that can ensure you are never compromised. Consider your desktop: The idea of running an operating system (whether it be Windows or Mac OS X) without antivirus software is highly impractical. The same principle applies to your website. You can never reduce the percentage of risk to zero, but you can implement controls to minimize impact and to take a proactive approach to threat preparedness.

---

---

You need to be familiar with six distinct types of risk (or threats):

Defacements: The motivation behind most defacements is to change the appearance of a website. Defacements are often very basic and make some kind of social stance, such as supporting a cause or bringing attention to your poor security posture. If you visit your website and it doesn’t look anything like you expect it to, contact your host to find out if it has been defaced and, if so, ask for assistance in restoring it.

SEO spam: This kind of attack sets out to ruin your search engine results — search engines can warn viewers away from your website. The most popular one is the Pharma hack. It injects code into your website and search engine links to redirect your traffic to pharmaceutical companies and their products. If you find that your website listing disappears from major search engines, such as Google, you should be concerned that your website has been a victim to SEO spam and contact your hosting provider for assistance.

Malicious redirects: Malicious redirect attacks direct your traffic somewhere else, most likely another website. For example, if your domain is http://domain.com, a malicious redirect might redirect it to a http://adifferentdomain.com. Malicious redirects are often integrated with a number of other attacks (SEO spam being one). If you visit your website and discover that your domain redirects to a different domain that you don't recognize, your website has been a victim of a malicious redirect attach, and you should contact your hosting provider for assistance.

iFrame injections: This kind of attack embeds a hidden iFrame in your website that loads another website onto your visitor’s browser (like a pop-up ad). These embedded websites or ads can lead to malicious websites that carry a multitude of infections.

Phishing scams: Phishing scams used to belong only to the world of e-mail: You get an e-mail from your bank asking you to confirm your login information, but if you follow the instructions, your information actually goes to the attacker’s servers rather than the legitimate site.

WordPress websites are now used for the distribution of these attacks. Attackers develop malicious files and code that look like plugins and themes and then exploit credentials to a server or WordPress site, or the attackers use a known vulnerability to infect the plugins and themes. They then use the bait-and-hook approach through ads or e-mails to redirect traffic to these fake pages stored on legitimate websites. Keep an eye out for abnormal behavior on your website, such as the display of ads that you didn’t insert yourself, or the redirect to other domains you’re not familiar with. If at any time you suspect your website, and underlying files, have been tampered with by anyone, contact your web hosting provider for assistance.

Backdoor shells: With a backdoor shell, an attacker uploads a piece of PHP code to your website, which allows him to take control of it and download your files and upload his own. This kind of attack is more difficult to discover because it doesn’t always change the appearance or your experience with your site. You typically will discover this kind of attack by noticing new files in your file system or notice a marked increase in your bandwidth usage.

The rest of this chapter shows you how you can prevent any of these nasty attacks happening to your WordPress website, so you can keep you and your visitors safe.

Part of being a website owner is keeping your website and subscribers safe from hackers.

Preventing Attacks

You can’t ever be 100 percent secure. But with a WordPress website, you’re in good hands because the WordPress developers understand the importance of security, and they built a highly effective system to address any vulnerabilities you’ll run across.

Updating WordPress

The first way to prevent hackers is to keep your WordPress website up-to-date. The quick-and-easy way to do so is through the automatic update feature. The next chapter in this minibook takes you through the process of updating WordPress step by step.

The beauty of applying updates is that they often introduce new streamlined features, improve overall usability, and work to patch and close identified or known vulnerabilities.

As technology and concepts evolve, so do attackers and their methods for finding new vulnerabilities. The further behind you get, the harder it will be to update later and the higher your risk increases, which in turn impacts how vulnerable you are to attacks.

Installing patches

All WordPress updates are not created equally; but there are a few that you should pay special attention to when it comes to the WordPress core software.

There are major releases, which contain feature additions, UI changes, and bug fixes and security updates. You can always tell what major release you’re on by the first two numbers in the version number (as in 3.4). See Book I, Chapter 3 for more information about the difference between major and minor releases.

Then you have point releases, which are minor releases that can be identified by the third number in the version number (as in 3.4.2). These releases contain bug fixes and security patches but do not introduce new features.

When you see a point release, apply it. Point releases rarely cause issues with your site, and they help close off vulnerabilities in a lot of cases.

Using a firewall

A firewall builds a wall between your website and the much larger Internet; a good firewall thwarts a lot of attacks.

Your web server should also have a good firewall protecting it. Every day there are countless visits, good and bad, to every website — some are from real visitors, but many from automated bots. A Web Application Firewall (WAF) helps protect your WordPress installation from those bad visitors.

Web application firewalls don’t offer 100 percent protection, but they are good deterrents for everyday attacks.

If you plan to manage and administer your own server, install and configure a tool such as ModSecurity (www.modsecurity.org) — an open source WAF-like solution that lives at the web server level as a module to Apache.

If you’re using a managed hosting solution, you’re probably in luck because most offer WAF-like solutions built into their services.

However, as a user, you can also install a plugin for WordPress called CloudFlare, which can be found in the official WordPress Plugin Directory at http://wordpress.org/extend/plugins/cloudflare. CloudFlare (see Figure 5-1) provides the best available WAF-like features for your WordPress website on a managed hosting solution. If you would like to use the CloudFlare plugin on your WordPress website, you do need to have a CloudFlare account at http://cloudflare.com. There is a free account option, but also upgrades to paid accounts that include more features. After you've installed the plugin on your website, follow the instructions on the CloudFlare configuration page to connect your WordPress blog to your CloudFlare account.

Figure 5-1: The CloudFlare plugin for WordPress.

Using Trusted Sources

One of the simplest things you can do to keep your website secure is to vet all the people who work on your website. This includes website administrators, website designers, developers, and web hosts, as well as trusted plugins, themes, and applications. If you’re running a self-hosted WordPress website, this could be quite a few people.

If you're using themes or plugins, use the WordPress.org theme and plugin repository (http://wordpress.org/extend/themes and http://wordpress.org/extend/plugins, respectively). Each plugin and theme you find there has gone through a documented review process, which reduces the risk of downloading dangerous code.

Engage the WordPress user community. The WordPress forums (http://wordpress.org/support) are a great place to start. Ask for community references and identify the support mechanisms in place to support the theme or plugin long-term.

Managing Users

The concept of Least Privilege has been in practice for ages: Give someone the required privileges for as long as they need it to perform their job or a task. If a task is completed then reduce the privileges at the completion of the task.

Apply these safeguards not just to your WordPress Dashboard, but also to your website host control panels and server transfer protocols. (See Chapter 2 in this minibook for information on file transfer protocol.)

Generating passwords

Password management is perhaps the simplest of tasks, yet it’s the Achilles heel of all applications, including both desktop and web-based apps. You can keep your files and data on your web server safe and secure through these simple password-management techniques:

Length: Create passwords that are more than 15 characters — this makes it more difficult for harmful users to guess your password.

Uniqueness: Don’t use the same passwords across all services. If someone does discover the password for one of your applications or services, he won’t be able to use it to log in to another application or service that you manage.

Complexity: A strong password contains a minimum of 8 characters and is made up of upper- and lowercase letters, numbers, and symbols, which makes any password hard to guess.

Use password managers and generators. Two of the more popular products right now are LastPass (https://lastpass.com) and 1Password (https://agilebits.com/onepassword).

Limiting built-in user roles

Not all users of your website need administrator privileges. WordPress gives you five user roles to choose from, and those roles provide sufficient flexibility for your websites.

You can find detailed information on each of the roles in Book III, Chapter 3. You can also discover more information on users and roles in the WordPress.org codex: http://codex.wordpress.org/Roles_and_Capabilities.

Create a separate account with a lower role (such as Author) and use that account for everyday posting. Reserve the Administrator account purely for administration of your website.

Establishing user accountability

The use of generic accounts should be the last thing you ever consider because the more generic accounts you have, the greater your risk of being compromised. If a compromise does happen, you want to have full accountability for all users and be able to quickly answer questions like these:

Who was logged in?

Who made what changes?

What did the users do while logged in?

Generic accounts preclude you from doing appropriate incident handling in the event of a compromise. In Book III, Chapter 3, you find all the information and step-by-step details on how to create new users in your WordPress Dashboard — keep the principles of Least Privilege and User Accountability in mind as you’re creating users.

Staying Clear of Soup Kitchen Servers

One of the regular issues plaguing website owners is soup kitchen servers. A soup kitchen server is one that has never been maintained properly and has a combination of websites, old software, archives, unneeded files, folders, e-mail, and so on, all living on the hard drive of the web server.

The real problem comes into play with the “out of sight, out of mind” phenomena. A server owner can forget about software installations on a server that may be outdated or insecure. Over time this forgetfulness introduces new vulnerabilities to the environment:

Disabled installs or websites that live on the server are as accessible and susceptible to external attacks as live sites.

When a forgotten install or website is infected, it leads to cross-site contamination — a worm-like effect where the infection can jump and replicate itself across the server.

In many instances, these forgotten installs or websites house the backdoor and engine of the infection. This means that as you try to rigorously clean your live website, you continuously get re-infected.

Figure 5-2 demonstrates what a soup kitchen server looks like. $wp_version indicates the version of WordPress that is currently installed in the directory listed. With a lot of listings for $wp_version = 2.9 — considering the most recent version of WordPress, at the time of this writing, is 3.5 — you can see how many out of date installations of WordPress this particular soup kitchen server has.

If you have more than one installation of WordPress on your current hosting account, try the following to help reduce your risk of running a soup kitchen server:

Isolate each installation with its own user — this action minimizes internal attacks that come from cross-site contamination.

Keep your installs up-to-date and remove them when you no longer need them — this action lessens the risk of attacks that result from outdated software on your server.

Figure 5-2: A fileserver listing from a typical soup kitchen server.

Hardening WordPress

When you harden (that is, take the steps taken to secure your system) your WordPress installation, you can the necessary steps to reduce your risk of being hacked by malicious attackers.

Hardening your website involves following these five steps:

1. Enabling multi-factor authentication.

2. Limiting login attempts.

3. Disabling Theme and Plugin Editors

4. Filtering by Internet Protocol.

5. Killing PHP execution.

I cover each of these steps in the following sections.

---

---

Hardening your website doesn’t guarantee your protection, but it definitely reduces your risk.

Multi-factor authentication

Authentication, in this case, refers to the act of confirming the identity of the person who is attempting to log in and obtain access to your WordPress installation — just like when you log in to your WordPress website by using a username and password. The idea for multi-factor authentication stems from the idea that one password alone is not enough to secure access to any environment. Multi-factor authentication is also called strong authentication and, when in use, it requires more than one user-authentication method. WordPress, by default, requires only one: a username with password. Multi-factor authentication adds layers of authentication measures for extra security for user logins.

To use multi-factor authentication, you can use a free plugin called Google Authenticator. It provides two-factor user authentication through the use of an application on your mobile or tablet device (iPhone, iPad, Droid, and so on). For this plugin to work, you need the following:

Google Authentication app: Find it at the Apple App Store for iOS devices or the Google Play Store for Android devices.

Google Authenticator plugin: You can find this in the Plugin Directory. See Book VII, Chapters 1 and 2 to find, install, and activate this plugin.

When you have both of those tasks accomplished, you can configure the plugin for use on your website. Follow these steps to configure the plugin for each individual user on your site:

1. Click the All Users link on the Users menu on your Dashboard.

The Users page opens.

2. Select the users profile you’d like edit by clicking the Edit link underneath their name in the Users list.

The Edit Users page opens.

3. Select the Active check box in the Google Authentication Settings section, as shown in Figure 5-3.

4. Type a description in the Description text box.

This is the description you can see in the Google Authenticator application on your mobile device. In Figure 5-3, I gave it the description of WPBlog.

If you’re using an iPhone or iPad as your authentication device, the description field must not have any spaces. At the time of this writing, a bug in the Apple application prevents it from working if there are any spaces in the description; this is why my example description of WPBlog is all one word, with no spaces.

5. Click the Show/Hide QR code button.

This displays the QR code on the page, as shown in Figure 5-3. A QR code is a scannable bar code which is readable by a mobile or tablet device using the camera.

6. Open the Google Authenticator application on your mobile or tablet device.

7. On the Dashboard of your WordPress site, click the Create New Secret button.

This refreshes the secret key and QR code needed to connect your mobile or tablet device.

Figure 5-3: The Google Authenticator Settings.

8. In the Google Authenticator application on your mobile or tablet device, click the Scan Barcode button.

The camera on your device starts.

9. Scan the bar code displayed on the Google Authenticator page on your WordPress Dashboard by taking a photo of it with your device.

Point your device camera at your computer screen and line up the QR code within the camera brackets of your mobile device. The application automatically reads the QR code as soon as it is aligned correctly and displays a 6-digit code identifying your blog. The 6-digit code will refresh on a time-based interval. After the QR code is scanned, the user receives a message on her mobile device that contains a unique, numeric code.

10. Click the Update Profile button at the bottom of the Edit Users screen in your Dashboard.

This refreshes the Edit Users page with a message at the top stating that the Google Authenticator settings have been successfully saved.

Now, with the Google Authenticator plugin in place, whenever anyone tries to log in to your WordPress Dashboard, she has to fill in her username and password, like usual; however, with multi-factor authentication in place, the user also needs to enter the authentication code that was sent to her mobile device in Step 9 in. Without this unique code, the user can’t log in to the WordPress Dashboard.

With the previous steps completed, you have enabled a form of multi-factor authentication, to your WordPress Dashboard.

The Google Authenticator application verification code is time based, which is why it is very important that your mobile phone and your WordPress blog are set to the same time zone. If you get the message that the Google Authentication verification code you’re using is either invalid or expired, you need to delete the plugin and then go into your WordPress Dashboard settings and make sure the time zone is set to the same time zone as your mobile or tablet device. See Book III, Chapter 1 for information on time settings for your WordPress site.

The following steps show you how the multi-factor authentication is now implemented on your blog:

1. Log out of your WordPress Dashboard.

This step logs you out completely and displays the login page, shown in Figure 5-4.

Figure 5-4: The WordPress login form with Google Authen-tication.

2. Type your username in the Username field.

3. Type your password in the Password field.

Do not click the Log In button yet. (If you’re like me, you probably have an urge to click that button a split second after typing your password. For these steps, you have to resist that urge.)

4. Open the Google Authenticator application on your mobile or tablet device and locate the 6-digit number code assigned to your blog.

This 6-digit number code refreshes every 60 seconds. If you have more than one blog using the application, find the code that corresponds to the description you assigned to the site from Step 4 in the previous list.

5. Type the 6-digit number verification code in the Google Authenticator code field.

6. Click the Log In button.

You are now successfully logged into your WordPress Dashboard using a two-factor authentication method.

The biggest shortcoming with this plugin is the inability to force all users to configure by default. This is why it’s important the principle of least privilege is employed on your site — give access only to the users who absolutely require it. In an ideal world, however, every single one of your user accounts will require a two-factor authentication in order to log in to their accounts on your site.

If you do not have access to a mobile device, WordPress does have a couple of plugins you can use, including these two:

Perfect Paper Passwords: http://wordpress.org/extend/plugins/perfect-paper-passwords

Yubikey Plugin: http://wordpress.org/extend/plugins/yubikey-plugin

Limiting login attempts

Limiting the number of times a user can attempt to log in to your WordPress site helps reduce the risk of brute force attack. A brute force attack happens when an attacker tries to gain access by guessing your username and password through the process of cycling through combinations.

To help protect against brute force attacks, you want to limit the number of times any user can try to log in to your website. You can accomplish this in WordPress easily enough through the use of the Limit Login Attempts plugin. You can find this plugin in the WordPress Plugin Directory. See Book VII, Chapters 1 and 2 to find, install, and activate it.

When you have the Limit Login Attempts plugin installed, follow these steps to configure the settings:

1. Click the Limit Login Attempts link in the Settings menu on your Dashboard.

The Limit Login Attempts Settings page opens in your Dashboard, as shown in Figure 5-5.

2. Select a configuration.

Under the Options heading, you see these four configurations:

• 4 allowed retries: This is the maximum number of times users are allowed to retry failed logins.

• 20 minutes lockout: This is the amount of time a user is prevented from retrying a login after he has reached the maximum allowed number.

• 4 lockouts increase lockout time to 24 hours: If a user is locked out 4 times after numerous failed login attempts, he then gets locked out for 24 hours.

• 12 hours until retries are reset: This is the amount of time before login retries are completely reset.

Figure 5-5: Limit Login Attempts Settings.

3. Select the Direct Connection option in the Site Connection section.

This option limits site connection to a single Internet Protocol. Alternatively, you can select this plugin to limit site connection from behind a proxy, if your users are using proxy IP’s to connect to the site.

4. Select Yes in the Handle Cookie Login section.

This option tells WordPress to set a cookie in the users browser for further identification. Alternatively, you can set this to No if you’re not worried about it — however, having Cookie Login Handling is a good extra security measure to have in place.

5. Select the Log IP option in the Notify on Lockout section.

This will notify the site administrator via email every time a user gets locked out. Alternatively, you can select the number of lockouts that will happen for a single user before it notifies the administrator via email.

6. Click the Change Options button at the bottom of the Limit Login Attempts Settings page.

This Limit Login Attempts Setting page refreshes with a message telling you that the plugin settings have been successfully saved.

If you are managing your own server, monitor your log in attempts to see if a malicious attacker is attempting repeated attempts to obtain passwords and usernames. Keep track of those IPs and if they repeatedly attempt to log in, add them to your server firewall to prevent them from burdening your server access points.

Disabling theme and plugin editors

By default, when you log in to the WordPress Dashboard, you have the ability to edit any theme and plugin file using the Theme Editor (found by clicking the Appearance link on the Editor menu) and the Plugin Editor (found by clicking the Plugins link on the Editor menu). The idea makes a lot of sense; it gives you the ability to do everything within your Admin panel without having to worry about logging into your server via FTP to edit files.

Unfortunately, having the theme and plugin editors available also provides any attacker that gains access to the Dashboard full rights to modify any theme or plugin file, which is very dangerous because even just one embedded within any file can grant an attacker remote access to your environment without ever having to touch your Dashboard.

You can completely avoid this by disabling the Theme Editor and Plugin Editor by adding a WordPress constant (or rule) to the WordPress configuration file (wp-config.php) found in the installation folder on your web server. Download the wp-config.php via FTP (see Book II, Chapter 2) and open the file in a text editor, such as Notepad (PC) or TextMate (Mac). Look for the following line of code:

define('DB_COLLATE', ''),

Add the following constant (rule) on the line directly beneath the previous line:

define('DISALLOW_FILE_EDIT',true);

Although the addition of this constant won't prevent an attack, it will help you when it comes to reducing the impact of a compromise. You can find more information on other constants you can add in the wp-config.php file on the WordPress.org website at http://codex.wordpress.org/Editing_wp-config.php.

You can also disable the automatic updates in WordPress (the system by which you are allowed to automatically update WordPress core and WordPress plugins), to include the administrator. This means you'd have to do everything, manually, via FTP. To do this you would use the following constant in your wp-config.php file:

define('DISALLOW_FILE_MODS',true);

Filtering by Internet Protocol (IP) address

Another option you have is to limit access to the Dashboard to specific Internet Protocols only. You also hear this method referred to as whitelisting (allowing) access, which compliments your blacklisting (disallowing) solutions you have put in place.

Everything that touches the Internet, such as your computer, a website, or a server network, has what is known as an Internet Protocol (IP) address. An IP on your computer is like your home address; it uniquely identifies you so the Internet knows where your computer is located, physically. An example of what an IP looks like is 12.345.67.89 — it’s a series of numbers that uniquely identifies the physical location of a computer or network.

You can edit the .htaccess file on your web server so that only IPs that you approve can access your Admin Dashboard, which blocks everyone else from having Dashboard access.

The lines of code that define the access rules get added to the .htaccess file located in on your web server where WordPress is installed, in a folder called /wp-admin. Download that file to your computer via FTP and open it using a text editor, such as Notepad (PC) or TextMate (Mac), and add the following lines to it:

order allow,deny

deny from all

allow from 12.345.67.89

In this example, the order defines what comes first. An IP that follows the allow rules is given access; any IP that doesn't follow the allow rules is denied access. In this example, only the IP 12.345.67.89 can access the Admin Dashboard; all other IPs are denied.

If the /wp-admin folder in your WordPress installation doesn't contain a file called .htaccess, you can easily create one using your FTP program by opening the /wp-admin folder and then right click with your mouse and select New File. Give that new file the name: .htaccess and make sure the new rules from the previous section are added.

Limiting access via IP does involve the following potential negatives:

This technique works only with static Internet Protocols. A dynamic Internet Protocol constantly changes. There are ways to make this work with dynamic IP’s but that would beyond this chapter.

The ability to use .htaccess is highly dependent on a web server that is running Apache. It won't do you any good if your web server is Windows based or IIS, or if you're using the latest NGINX web server.

Your Apache web server needs to be configured to allow directives to be defined by .htaccess files. Ask your web host about configuration.

Killing PHP execution

For most backdoor intrusion attempts to function, a PHP file has to be executed. The term backdoor describes ways of obtaining access to a web server through means that bypass regular authentication methods, such as file injections through programming languages such as PHP or JavaScript. Disabling PHP execution prevents an attack or compromise from taking place because PHP cannot be executed at all.

To disable PHP execution, you add 4 lines of code to the .htaccess file on your web server. Those lines look like this:

<Files *.php>

Order allow,deny

Deny from all

</Files>

By default, you have an .htaccess file in the WordPress directory on your web server. But you can also create an .htaccess file in other folders; — particularly the folders in which you would like to disable PHP execution.

To disable PHP execution for maximum security, create an .htaccess file with those four lines of code in the following folders in your WordPress installation:

/wp-includes

/wp-content/uploads

/wp-content

This WordPress installation directory is important because it is the only directory that has to be writeable for WordPress to work. This means if an image is uploaded with a modified header, or if a PHP file is uploaded and PHP execution is allowed, an attacker would be able exploit this weakness to create havoc in your environment. With PHP execution disabled, the attacker is unable to create any havoc.

To further your knowledge, and find additional information on web application security, consider checking out The Web Application Hacker’s Handbook: Finding and Exploiting Security Flaws, 2nd Edition, by Dafydd Stuttard and Marcus Pinto (Wiley).