WordPress.org

Codex

Attention Interested in functions, hooks, classes, or methods? Check out the new WordPress Code Reference!

Hardening WordPress

Languages: Deutsch • English • 日本語 • Italiano • 한국어 • Português do Brasil • (Add your language)

Security in WordPress is taken very seriously, but as with any other system there are potential security issues that may arise if some basic security precautions aren't taken. This article will introduce you to basic security concepts and serve as an introductory guide to making your WordPress website more secure.

This article is not the ultimate quick fix to your security concerns.

What is Security?

Security is not an absolute, it's a continuous process and should be managed as such. Security is about risk reduction, not risk elimination, and risk will never be zero. It's about employing the appropriate security controls that best help address the risks and threats as they pertain to your website.

Security also transcends the WordPress application. It's as much about securing and hardening your local environment, online behaviors and internal processes, as it is physically tuning and configuring your installation. Security is comprised of three domains: People, Process, and Technology. Each work in a synchronous harmony with each other, without the people, and their processes, the technology itself would be useless. Keep this in mind as you work through this guide, the threat landscape is constantly evolving and as such so should your security posture.


Website Hosts

If you have downloaded WordPress from WordPress.org you will need to self-host, and you will have a wide range of options. You will need to choose from shared-hosts, managed-hosts and a number of other variations. Each host will handle security differently, but each will be consistent in that the ultimate responsibility for your installations security will fall on the website owner (not the host).

We will not dive into the hardening of your host, as it is beyond the intent of this guide - which will focus on your WordPress installation. For more information though, we encourage you to jump over to the Hosting WordPress codex page.

How you decide to host your website is important, and should be done with care; the decision you make will dictate the specific security controls you will want to leverage. This means that you, the website owner, will be responsible for hardening your installation and why this guide is so important.

Security Concepts

There are basic concepts Information Security (InfoSec) concepts that you should be aware of as you embark on your journey of securing WordPress. These concepts are critical to helping you understand and implement the recommendations presented in this guide.

Least Privilege Principle

When configuring web applications and WordPress, each application or user should only be able to access the resources that are necessary for it's legitimate purpose and nothing more. In other words, don't give applications or users access beyond what they need. You can learn more about this principle on Wikipedia.

The least privilege principle builds on this idea, it is about giving people the access they require, for as long as they require to do their job, no more and no less. When they are done with their work, reset their access to the most appropriate level. This is most applicable when thinking about users and their appropriate roles. WordPress provides a number of different roles out-of-the-box, each designed with different permissions.

CIA Triad Principle

The CIA triad is a model used in InfoSec to help organizations assess risk, build policies and deploy security controls.

It is divided into three core domains:

  • Confidentiality: Preventing unauthorized access to data. Data in this case includes files and the database contents. Only authorized users and processes should be allowed to access your data.
  • Integrity: Preventing unauthorized modification or corruption of data. You need to have security controls in place to ensure that your files and the contents of your database retain their integrity.
  • Availability: Ensuring that services continue to be available and aren't taken offline by a someone malicious. A denial of service attack is an example of something that affects availability. A hacker may remove an important configuration or WordPress core file which can take your site offline. Your system should be secure against attacks that affect availability.

When thinking about securing your WordPress website, it helps to consider each of the above as part of a checklist.

Security Controls

Security professionals think about three different kinds of 'controls' that they can use to ensure confidentiality, integrity and availability are maintained. These controls are categories of things that you can do to secure your website.

  • Administrative :These are procedures and processes that you can put in place to help secure your website. If you are an individual you might have a checklist you go through each week to help secure your site. If you are a company, administrative controls will include policies and procedures that describe what to do in day to day operations to keep your website secure.
  • Logical :When we think about security, these are the controls that we are most focused on. Logical controls include software and data that help secure your website. Passwords, firewalls, virus scanners and encryption are all logical controls that help secure your website.
  • Physical :These are controls that protect your physical environment. You usually aren't responsible for physically securing your web server or database hardware. That is your hosting provider's responsibility. But you are responsible for the physical security of your working environment and any portable devices. You need to ensure that if you leave your laptop on a plane, someone malicious can't use it to gain access to your website and modify it. The same applies to securing any mobile devices you own.
Defense in Depth

The idea of Defense of Depth subscribes to the concept that there is no single solution capable of addressing all your security concerns. Instead, it promotes the use of a layered approach to complementary security solutions each designed to address each others shortfalls. With multiple layers of security, if one fails you may still stop the attack, or at the very least be able to detect it early and recover quickly.

Employing a defense in depth approach might look like this: employing a firewall to help mitigate external attacks, employing a security scanner in the event something is successful, leveraging multiple authentication controls, or even integration of a key manager. Each are security controls designed to directly address a threat.

Combining security Concepts into actionable items

Moving beyond the theoretical, we take the concepts presented above and provide a list of actions you can take as a website administer to harden and improve your security posture:

  • Limit access: Reduce the number of people who have administrative access to your WordPress site to a minimum. You should also reduce the number of possible entry points to a minimum. You can do this by only installing web applications that you need and use. Remove any unused plugins and themes. These follows the principle of least privilege and provides administrative and logical controls to help preserve confidentiality, availability and integrity.
  • Functional Isolation: Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised. Where possible, avoid having a large number of diverse web applications on a single hosting account. Logical separation of applications into separate accounts with their own access will confine a compromise to that one account and reduce damage.
  • Backups: Maintain reliable backups. You should occasionally verify the integrity of backups to make sure that you can restore your website if it is damaged. Have a plan to recover your website if it is compromised and document this plan. A good guide can be found WordPress Backups
  • Stay Up-to-Date: Do your best to stay up-to-date with your WordPress installation, including plugins and themes. You should put an administrative control in place that requires a check, with some frequency, that status of your site and it's extensible components.
  • Trusted Sources: Do not get plugins/themes from sources that are not trusted. Googling for a free version of a premium plugin is a recipe for disaster. Malicious people and organizations distribute what is known as 'nulled' plugins and themes which contain malicious code that will extend the premium plugin, but bundle it with malware.
  • Security Updates and News: Security vulnerabilities is something that affects all software, WordPress is no different. To stay current, we recommend subscribing to the vulnerability database maintained by WPVulnDB.com. You can also stay ahead of the latest trends following WordPress's own Security tag, Sucuri blog and Wordfence blog.

Securing your Working Environment

Make sure the computers you use are free of spyware, malware, and virus infections. No amount of security in WordPress or on your web server will make the slightest difference if there is a keylogger on your computer that sends your WordPress admin username and password to a hacker.

Always keep your operating system and the software on it, especially your web browser, up to date to protect you from security vulnerabilities. If you are browsing untrusted sites, we also recommend using tools like no-script (or disabling javascript/flash/java) in your browser.

You should also secure your mobile devices. Install any updates as soon as they are available.

When you are mobile, never use an untrusted WiFi connection without using a Virtual Private Network (VPN) app that encrypts all your traffic. If your WordPress website does not use HTTPS (SSL) and you sign in over an untrusted WiFi hot-spot, an attacker can capture your admin username and password and take control of your site.

You should also ensure that your home router is kept up to date. You can often access your router with the following URL: https://192.168.1.1/ Sign into your router and make sure that your firmware is up-to-date. Review any firewall rules and options that are available and choose a configuration that works for you.

Vulnerabilities in WordPress

Like many modern software packages, WordPress is updated regularly to address new security issues that may arise. Improving software security is always an ongoing concern, and to that end you should always keep up to date with the latest version of WordPress. Older versions of WordPress are not maintained with security updates.

Updating WordPress

Main article: Updating WordPress.

The latest version of WordPress is always available from the main WordPress website at https://wordpress.org. Official releases are not available from other sites -- never download or install WordPress from any website other than https://wordpress.org.

Since version 3.7, WordPress has featured automatic updates. Use this functionality to ease the process of keeping up to date. You can also use the WordPress Dashboard to keep informed about updates. Read the entry in the Dashboard or the WordPress Developer Blog to determine what steps you must take to update and remain secure.

If a vulnerability is discovered in WordPress and a new version is released to address the issue, the information required to exploit the vulnerability is almost certainly in the public domain. This makes old versions more open to attack, and is one of the primary reasons you should always keep WordPress up to date.

You can find the official WordPress.org blog on this page where security updates are announced.

If you are an administrator in charge of more than one WordPress installation, consider using Subversion to make management easier.

Reporting Security Issues

If you think you have found a security flaw in WordPress, you can help by reporting the issue. See the Security FAQ for information on how to report security issues.

If you think you have found a bug, report it. See Submitting Bugs for how to do this. You might have uncovered a vulnerability, or a bug that could lead to one.

Web Server Vulnerabilities and Security Problems

The web server running WordPress, and the software on it, can have vulnerabilities. If you are managing your own server, make sure that you install security updates for your operating system, web server, PHP and any applications. If you are using managed hosting, your hosting provider will usually take care of these security updates for you.

If you're on a shared server (one that hosts other websites besides your own) and a website on the same server is compromised, your website can be compromised too, even if you follow everything in this guide. This rarely happens, but it can happen if your hosting provider has not properly implemented permissions in your hosting environment. If you are doing everything you can to stay secure, but are repeatedly compromised, this may be the cause.

If you are on shared hosting and one or more sites on that shared host have been hacked, you may find that your website IP address is black-listed by spam lists like Spamhaus. If you find you are having email deliverability problems, find out what your website IP address is and look it up using a blacklist lookup tool like mxtoolbox.com.

You can find your website IP address by using a hostname IP lookup tool or by using the command prompt on your operating system and typing 'ping example.com' which will display your website IP address.

Passwords

Many potential vulnerabilities can be avoided with good security habits. A strong password is an important aspect of this.

The goal with your password is to make it hard for other people to guess and hard for a brute force attack to succeed. Many automatic password generators are available that can be used to create secure passwords.

WordPress also features a password strength meter which is shown when changing your password in WordPress. Use this when changing your password to ensure its strength is adequate.

Things to avoid when choosing a password:

  • Any permutation of your own real name, username, company name, or name of your website.
  • A word from a dictionary, in any language.
  • A short password.
  • Any numeric-only or alphabetic-only password (a mixture of both is best).

A strong password is necessary not just to protect your blog content. A hacker who gains access to your administrator account is able to install malicious scripts that can potentially compromise your entire server.

Suggestions for improving your password strength are:

  • Use at least 12 characters.
  • Use a mix of upper-case and lower-case letters, numbers and symbols.
  • Use random characters without any words.

Services like 1Password and LastPass can help you manage complex passwords. However it is worth noting that some of these services have been compromised in the past.

To gain an in depth understanding of what makes a strong password and how passwords are cracked, you can read the Wikipedia's article on password strength.

In addition to using a strong password, it's a good idea to enable two-step authentication as an additional security measure.

FTP

When connecting to your server you should use an SFTP connection if your web host provides it. If you are unsure if your web host provides SFTP or not, just ask them.

Using SFTP is the same as FTP, except your password and other data is encrypted as it is transmitted between your computer and your website. This means your password is never sent in the clear and cannot be intercepted by an attacker.

SFTP is actually FTP via the SSH protocol. It stands for SSH File Transfer Protocol. There is another kind of secure FTP protocol called FTPS which provides a similar level of security but is internally different to SFTP. You can read more about the differences between SFTP and FTPS here.

File Permissions

Some neat features of WordPress come from allowing various files to be writable by the web server. However, allowing write access to your files is potentially dangerous, particularly in a shared hosting environment.

It is best to lock down your file permissions as much as possible and to loosen those restrictions on the occasions that you need to allow write access, or to create specific folders with less restrictions for the purpose of doing things like uploading files.

Here is one possible permission scheme.

All files should be owned by your user account, and should be writable by you. Any file that needs write access from WordPress should be writable by the web server, if your hosting set up requires it, that may mean those files need to be group-owned by the user account used by the web server process.

/ 
The root WordPress directory: all files should be writable only by your user account, except .htaccess if you want WordPress to automatically generate rewrite rules for you.
/wp-admin/ 
The WordPress administration area: all files should be writable only by your user account.
/wp-includes/ 
The bulk of WordPress application logic: all files should be writable only by your user account.
/wp-content/ 
User-supplied content: intended to be writable by your user account and the web server process.

Within /wp-content/ you will find:

/wp-content/themes/ 
Theme files. If you want to use the built-in theme editor, all files need to be writable by the web server process. If you do not want to use the built-in theme editor, all files can be writable only by your user account.
/wp-content/plugins/ 
Plugin files: all files should be writable only by your user account.

Other directories that may be present with /wp-content/ should be documented by whichever plugin or theme requires them. Permissions may vary.

When you switch to making certain files read-only by your web server, you lose the ability to upgrade WordPress core from within the WordPress administrative interface. You also lose the ability to have WordPress automatically upgrade itself. Any upgrades to non-writable files will need to be done manually by you using FTP or another method to manually copy files.

This is a trade-off that you need to be aware of. You can lock down your filesystem permissions, but you also lose flexibility. You should make the choice that best fits your security needs and your workflow.

Changing file permissions

If you have shell access to your server, you can change file permissions recursively with the following command:

For Directories: 

find /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \;

For Files: 

find /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \;

Regarding Automatic Updates

When you tell WordPress to perform an automatic update, all file operations are performed as the user that owns the files, not as the web server's user. All files are set to 0644 and all directories are set to 0755, and writable by only the user and readable by everyone else, including the web server.

You can read more about WordPress updates and file ownership on the Updating WordPress codex page.

Database Security

If you run multiple blogs on the same server, it is wise to consider keeping them in separate databases each managed by a different user. This is best accomplished when performing the initial WordPress installation. This is a containment strategy: if an intruder successfully cracks one WordPress installation, this makes it that much harder to alter your other blogs.

If you administer MySQL yourself, ensure that you understand your MySQL configuration and that unneeded features (such as accepting remote TCP connections) are disabled. See Secure MySQL Database Design for a nice introduction.

Restricting Database User Privileges

For normal WordPress operations, such as posting blog posts, uploading media files, posting comments, creating new WordPress users and installing WordPress plugins, the MySQL database user only needs data read and data write privileges to the MySQL database; SELECT, INSERT, UPDATE and DELETE.

Therefore any other database structure and administration privileges, such as DROP, ALTER and GRANT can be revoked. By revoking such privileges you are also improving the containment policies.

Note: Some plugins, themes and major WordPress updates might require to make database structural changes, such as add new tables or change the schema. In such case, before installing the plugin or updating a software, you will need to temporarily allow the database user the required privileges.
WARNING: Attempting updates without having these privileges can cause problems when database schema changes occur. Thus, it is NOT recommended to revoke these privileges. If you do feel the need to do this for security reasons, then please make sure that you have a solid backup plan in place first, with regular whole database backups which you have tested are valid and that can be easily restored. A failed database upgrade can usually be solved by restoring the database back to an old version, granting the proper permissions, and then letting WordPress try the database update again. Restoring the database will return it back to that old version and the WordPress administration screens will then detect the old version and allow you to run the necessary SQL commands on it. Most WordPress upgrades do not change the schema, but some do. Only major point upgrades (3.7 to 3.8, for example) will alter the schema. Minor upgrades (3.8 to 3.8.1) will generally not. Nevertheless, keep a regular backup.

Structural changes to WordPress that may help

Below we discuss several structural changes you can make to WordPress that may provide some additional security. Each option comes with some disadvantages and problems which you need to be aware of. They make break certain functionality on your WordPress site and introduce incompatibilities or additional security problems.

Securing wp-admin

Adding server-side password protection (such as BasicAuth) to /wp-admin/ adds a second layer of protection around your blog's admin area, the login screen, and your files. However, this practice prevents normal site visitors from accessing /wp-admin/admin-ajax.php.

The admin-ajax.php script provides dynamic AJAX features for normal site visitors and sign-in users. If you are using AJAX, implementing this layer of security will prevent your AJAX functions from working.

If you do enable basic authentication on the /wp-admin/ directory, it prevents some automated attacks that target content below the /wp-admin/ URL.

See the Resources section for more documentation on how to password protect your wp-admin/ directory properly.

Securing wp-includes

A second layer of protection can be added where scripts are generally not intended to be accessed by any user. One way to do that is to block those scripts using mod_rewrite in the .htaccess file. Note: to ensure the code below is not overwritten by WordPress, place it outside the # BEGIN WordPress and # END WordPress tags in the .htaccess file. WordPress can overwrite anything between these tags. 

# Block the include-only files.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>


# BEGIN WordPress

Note that this won't work well on Multisite, as RewriteRule ^wp-includes/[^/]+\.php$ - [F,L] would prevent the ms-files.php file from generating images. Omitting that line will allow the code to work, but offers less security.

Securing wp-config.php

You can move the wp-config.php file to the directory above your WordPress install. This means for a site installed in the root of your webspace, you can store wp-config.php outside the web-root folder.

Note: Some people assert that moving wp-config.php has minimal security benefits and, if not done carefully, may actually introduce serious vulnerabilities. Others disagree.

Note that wp-config.php can be stored ONE directory level above the WordPress (where wp-includes resides) installation. Also, make sure that only you (and the web server) can read this file (it generally means a 400 or 440 permission).

If you use a server with .htaccess, you can put this in that file (at the very top) to deny access to anyone surfing for it: 

<files wp-config.php>
order allow,deny
deny from all
</files>

Disable File Editing

The WordPress Dashboard by default allows administrators to edit PHP files, such as plugin and theme files. This is often the first tool an attacker will use if able to login, since it allows code execution. WordPress has a constant to disable editing from Dashboard. Placing this line in wp-config.php is equivalent to removing the 'edit_themes', 'edit_plugins' and 'edit_files' capabilities of all users: 

define('DISALLOW_FILE_EDIT', true);

This will not prevent an attacker from uploading malicious files to your site, but might stop some attacks.

Plugins

Most WordPress vulnerabilities are not in WordPress core, or WordPress themes, but in WordPress plugins. They are introduced into WordPress sites when a plugin developer accidentally introduces new code in a plugin that can be exploited by an attacker.

Plugin developers try hard to avoid writing vulnerabilities, but in software development vulnerabilities are inevitable. What usually happens when a vulnerability is discovered is that a security researcher will let the developer know about it privately. The plugin developer will fix the vulnerability and will release that fix. Then the researcher will make the vulnerability public.

This process occurs constantly with WordPress plugins and with all software and hardware that is connected to the Internet. That is why it is important to keep your WordPress plugins up-to-date. If you want to maintain a secure WordPress website, you must install plugin updates as they are released.

The space of time between when a plugin security update is released and when you install that update is the time during which a hacker can compromise your website. Your goal should be to minimize that time window.

Security Plugins

There are many security plugins available for WordPress that provide a range of miscellaneous features that can help provide additional security. These features often include brute force protection, two factor authentication and ways to hide information about your site that may be useful to a hacker.

Using a Firewall

For WordPress, there are two basic kinds of firewall. There are WordPress security plugins that do include a rule based firewall and there are also web application firewalls that intercept web traffic before it reaches your website or WordPress.

Using a firewall should not be considered a substitute for good security practices, but it can be a valuable security enhancement, as part of a defense in depth security strategy.

Below are described both firewall type and provided a few options for each.

Security Plugins with a Rule Based Firewall

A rule based firewall is a firewall that analyzes each request to your WordPress website to determine if it is malicious or not. It uses a set of rules to decide if a request is malicious. Those rules are usually continually updated with a remote server.

A rule based firewall will not only analyze requests that are handled by the WordPress application, but all requests to any script in your WordPress subdirectories. The way they do this is by using a auto_prepend_file directive in your .htaccess to ensure that the firewall code is executed before any PHP code in any directory below your WordPress installation or in the root of the install.

This technique ensures that the firewall code loads before any PHP code and allows the firewall to analyze and block all attacks on PHP applications in your WordPress directory.

Examples of a rule based WordPress firewall plugin are Wordfence and Ninja Firewall.

Web Application Firewall (WAF)

A Web Application Firewall (WAF) acts as in intermediate layer between a web application and internet traffic to filter, monitor, and block malicious traffic. Using a WAF can prevent and/or mitigate a variety of common attacks, such as SQL injection, Cross-Site Scripting (XSS) and security misconfigurations.

Web application firewalls are generic in that they contain rule-sets that are designed to stop attacks on a wide range of application types, platforms and programming languages. These can often be tweaked to be provide more specific protection to accommodate a specific website's needs.

Cloud Web Application Firewall (WAF)

A cloud web application firewall is a WAF that uses servers on the public Internet to filter HTTP traffic. To configure a cloud WAF you will point your website DNS entry to the cloud WAF provider's servers. They will then route traffic to your website once it has been filtered. Most cloud firewalls are paid services because it costs the provider to install the infrastructure and bandwidth required to provide the service.

Technically a cloud WAF functions as a reverse proxy. It accepts the initial request to your website, filters it and forwards it to your web server, stripping it of malicious requests. A cloud firewall accomplishes this by modifying your DNS records, via a CNAME record or full DNS swap, allowing all traffic to pass through the new network first. This causes all traffic to be filtered by the firewall before reaching your site.

If you are using a cloud firewall, your site may still be reachable by directly accessing your website IP address. However, you can configure your website to deny all direct requests and only accept connections from your cloud firewall provider. If you are using a cloud WAF, it is important that you take this additional step to prevent an attacker bypassing the firewall.

Examples of cloud firewall providers are Sucuri Cloudproxy WAF,Cloudflare WAF, Incapsula WAF.

Local Web Application Firewall

A local web application firewall is installed directly on the website's local server, and does not rely on any external server or service. It can usually be installed in one of two methods, embedded or as a reverse-proxy. ModSecurity is an example of an excellent free open source local WAF that can be installed on Apache, IIS and NGINX servers. Some web hosting providers already have ModSecurity pre-installed, even on shared hosting. If you have a VPS or dedicated server, there are a number of additional customization options and rule sets available. See the OWASP ModSecurity Core Rule Set (CRS) for examples.

Using a Malware Scanner

There are two basic kinds of malware scan available for WordPress websites: A remote malware scan and a server based scan. Below we describe each type and provide some examples.

Server Based Malware Scan

A server based malware scan runs locally on our web server. It may run at the operating system level or as a WordPress plugin. A local scan is able to view all directories on your server filesystem and can 'see' your entire website structure. A server based scan can also read the contents of all files, including files that would normally be executed by your web server when accessed remotely.

Local or server based scans usually execute by recursively walking your directory tree and scanning files. That means that they examine your directory structure and use an algorithm to scan the file contents of every directory on your website. Server based scans can examine thousands or tens of thousands of files relatively quickly and are able to scan the entire content of your site including your source code.

An examples of a server based malware scan are ClamAV, Wordfence, Sucuri, and VaultPress.

Remote Malware Scanning

A remote malware scanner accesses your website remotely and examines your web pages to determine if you have been infected with malware. A remote scanner does not have access to your website directory structure, so it 'crawls' your website like a search engine using the link structure of your site to find web pages.

Remote scanners examine the content of web pages that have been served up by your server. This is often produced by code that executes on your web server as HTML which is served to the browser. Remote scanners don't have the ability to examine your website source code. Instead, they look for signatures in your website HTML, Javascript and other content that indicate that your site has been compromised.

Remote scans do not examine your website source code and usually scan fewer items than a server scanner due to resource and load constraints. An example of a remote scanner is Sucuri sitecheck.

Be aware of what plugins access

When you install a WordPress plugin, it has access to your WordPress files, directories and database. The level of access that the plugin has is the same access level as WordPress core. There is no separation of permissions between WordPress plugins. There is also no way to limit the amount of access a plugin has.

Therefore it is important for you to understand what a plugin does and what it will be accessing. You should read the plugin documentation, check it's reputation by reading reviews and check the plugin support forums for any known problems before granting a plugin access to your system by installing it.

If you would like to verify in depth what a WordPress plugin does, you can read the code yourself, or you can ask a developer to do a code review on the plugin before you install it. You can also ask for help on the Support Forums and IRC Channel.

Code execution plugins

WordPress security has improved significantly over the years. However you may occasionally run across an open source or commercial plugin that includes a way to arbitrarily execute new code.

An example of this is where a plugin may select code stored in the database and execute that code. A plugin may also download new code directly from a developer website and execute that. This may become a security problem if the plugin changes ownership or the plugin website is hacked. It may also be an issue if an attacker is able to modify the database contents.

In general you can determine if a plugin is doing anything shady or has a vulnerability by doing a Google search for the name of the plugin and adding keywords like 'vulnerability' and 'reviews' to your search. Plugins with a bad reputation or with vulnerabilities quickly become known within the WordPress community.

Security through obscurity

Security through obscurity is generally an unsound primary strategy. However, there are areas in WordPress where obscuring information might help with security:

  1. Rename the administrative account: When creating an administrative account, avoid easily guessed terms such as admin or webmaster as usernames because they are typically subject to attacks first. On an existing WordPress install you may rename the existing account in the MySQL command-line client with a command like UPDATE wp_users SET user_login = 'newuser' WHERE user_login = 'admin';, or by using a MySQL frontend like phpMyAdmin.
  2. Change the table_prefix: Many published WordPress-specific SQL-injection attacks make the assumption that the table_prefix is wp_, the default. Changing this can block at least some SQL injection attacks.

Data Backups

Back up your data regularly, including your MySQL databases. See the main article: WordPress_Backups.

Data integrity is critical for trusted backups. Encrypting the backup, keeping an independent record of MD5 hashes for each backup file, and/or placing backups on read-only media increases your confidence that your data has not been tampered with.

A sound backup strategy could include keeping a set of regularly-timed snapshots of your entire WordPress installation (including WordPress core files and your database) in a trusted location. Imagine a site that makes weekly snapshots. Such a strategy means that if a site is compromised on May 1st but the compromise is not detected until May 12th, the site owner will have pre-compromise backups that can help in rebuilding the site and possibly even post-compromise backups which will aid in determining how the site was compromised.

Logging

Your hosting provider will usually provide web server logging. You may need to enable this feature or request that they enable logging for you. Your web server logs will log each request to your website. They will also log errors that occur.

Information included in your web server logs is:

  • IP address that accessed your site
  • Time of access
  • Type of request e.g. GET or POST
  • The URL of the request, usually a path that starts with a forward slash.
  • The size of the response
  • The response code e.g. 200 for a successful response or 404 for page not found.

Your logs may include some additional info. The reason logs are important for security is that they provide an audit trail of requests that occurred on your website. If your website is hacked, it allows you or a forensic analyst to determine how your website was compromised. This is important because if you know how your site was compromised, you can close the security hole once you repair your site. This prevents you being hacked through the same method in future.

Unfortunately the logs will not tell you which username logged into your website But they will allow you to identify the IP and time and more importantly, the actions the attacker might have taken. You will be able to see any of the following kinds of attacks in your log files:

  • Cross Site Scripting (XSS)
  • Remote File Inclusion (RFI)
  • Local File Inclusion (LFI)
  • Directory Traversal attempts

You will also be able to see brute force attempts. There are various examples and tutorials available to help guide you through the process of parsing and analyzing your raw logs.

If you get more comfortable with your logs you'll be able to see things like, when the theme and plugin editors are being used, when someone updates your widgets and when posts and pages are added. All key elements when doing forensic work on your web server.

The are a few WordPress Security plugins that assist you with this as well, like the Sucuri Auditing tool or the Audit Trail plugin.

There are a wide range of additional tools that can detect and block intrusions at the server level. They do this through log file analysis and network traffic analysis. You can find a guide to open source intrusion detection tools on this page.

Monitoring

Monitoring and alerting is an important part of maintaining a secure website. Once you have logging enabled, you can use your logs to perform monitoring. You can also install applications that will perform monitoring for you without having to enable logging on your server.

Monitoring Availability

Services like UptimeRobot and Pingdom monitor website availability. They send you an alert via email, SMS or mobile application if your website goes down. You can monitor your site from multiple locations.

One of the features of some of these services offer is the ability to monitor web page changes. Websitepulse in particular can tell you if a page has changed by a certain percentage. Using availability monitoring along with monitoring of page changes can give you an early warning if your website has been hacked. Often a hacker will change or deface your website and catching changes early can alert you within minutes of a hack.

Monitoring Traffic

Once you enable logging you can download your website traffic in the form of access logs. This gives you the ability to manually monitor traffic and errors on your website. If you are on a shared hosting provider, you can usually download your access and error log via FTP.

If you have SSH access to your web server, you can access a command line shell on your server and view your logs as they update in real-time with the following command: tail -f /location/to/log/file. This gives you the ability to monitor your raw traffic in real-time at no additional cost.

If you would like to learn how to perform log file analysis to identify attacks, you can start by reading the Log Analysis for Web Attacks: A Beginner’s Guide.

You can also monitor your website traffic in real-time using the real-time view from Google Analytics or Piwik. Unfortunately this does not show you crawlers and malicious bots that visit your site because those usually do not execute Google Analytics' javascript code.

If you want to view visits by crawlers and malicious bots to your website, you can use a plugin like Wordfence or a web application firewall like CloudFlare, Sucuri Cloudproxy, or Incapsula. These services interdict potentially malicious traffic, and offer a number of capabilities, including DDoS mitigation, traffic monitoring, and custom traffic filtering.

Monitoring Filesystem Changes

Monitoring filesystem changes can give you early warning of an intrusion. Plugins like File Changes Monitor, Wordfence, Sucuri, and VaultPress can alert you if a file has been added, deleted or changed on your system.

The tool you choose for filesystem monitoring will depend on whether you are using a managed hosting account, or whether you are administrator of your own server. If you use managed hosting, you will likely use a WordPress plugin to monitor files. If you have 'root' access to your own server, you will use system utilities, revision control and OS or kernel level monitoring.

A few specific tools for system administrators are listed below:

  • diff - build clean test copy of your site and compare against production
  • Git - source code management
  • inotify and incron - OS kernel level file monitoring service that can run commands on filesystem events
  • Watcher - Python inotify library
  • OSSEC - Open Source Host-based Intrusion Detection System that performs log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and active response.

Monitoring Malicious Activity

Most WordPress security plugins and security products provide a wide array of monitoring and alerting options. These include alerts on:

  • Brute force login attacks and login attempts
  • Login attempts and successful login
  • IP blocking

When configuring alerting it is important to have a high signal-to-noise ratio. In other words, you should only get alerts that are important to you and that you will do something about. If you receive too many alerts, you tend to become desensitized over time and won't be paying attention when something important happens.

General Monitoring Considerations

Below we have listed a few things you should consider when configuring your monitoring strategy:

  • If you are a system administrator, run your monitoring service as root if you can. This will make it more difficult for attackers to disable or modify your monitoring solution.
  • Disable monitoring during scheduled maintenance and upgrades. This will prevent unnecessary notifications when you are performing maintenance.
  • When monitoring files, you might consider only monitoring executable files, like .php files on a website. This will reduce the number of alerts you receive and may improve your signal to noise ratio.
  • Use strict file system permissions on files. Avoid enabling execute and write permissions where possible. This will reduce the amount of access an attacker has to files and will reduce alerts and help secure your system.
  • If an attacker defaces your site or adds malware, you can also detect these changes by using a web-based integrity monitor solution. This comes in many forms. Use your favorite search engine and look for 'website malware scanner' and you'll likely get a long list of service providers.

Resources

WordPress Security Plugins

Cloud-Based Web Application Firewalls (WAF)

Local Web Application Firewalls (WAF)

Malware Scanners

Further Reading on Hardening WordPress

See Also

Retrieved from "http://codex.wordpress.org/index.php?title=Hardening_WordPress&oldid=159364"

Codex Resources