How to secure your WordPress site

Contents

1. A note about securing your WordPress site
2. Change the default WordPress username
3. Change the default WordPress table prefix
4. Disable file editing
5. Configure the site to use SSL encryption

• SSL Providers

6. Updating your server

How to secure your WordPress site

Security is an important aspect of any WordPress site. DebOps already puts a lot of focus on securing your server. You don't have to worry about that.

That said, there are still extra steps that you can take to secure your WordPress site even further. This guide will go over those extra steps.

This guide assumes that you're familiar with how to customize your server. If you don't know how or aren't sure, take a moment to go over this guide first.

A note about securing your WordPress site

There are a lot of security recommendations out there. The recommendations in this guide only focus on the configuration of your WordPress site. It won't discuss server configuration, plugins, backups or other security recommendations.

It's also important to note when you can use these recommendations. Except for SSL encryption, DebOps cannot apply any of them to an existing server. They will only take effect when DebOps configures the server for the first time. That said, you can apply all them to an existing server by following the instructions in the codex.

Change the default WordPress username

Common usernames such as admin can create an unnecessary weakness in your site's security. That's because an attacker only needs a username and a password to access your site. By using a common username, you're removing one of the two obstacles. They only have to figure out your password now.

The good news is that you can let DebOps create your password for you. If you do, it'll create a strong password that's hard to break. That said, you should still change your admin username.

# inventory/host_vars/wordpress.example.com/vars.yml

wordpress__admin_username: 'not-admin-or-webmaster'

wordpress__admin_username is the option that controls the username of the initial WordPress user. By default, that user is admin which is the default for most WordPress site. You should change it to be something other than admin or webmaster (which is also quite common).

Change the default WordPress table prefix

The default table prefix is another default that attackers leverage all the time. Most SQL injection attacks assume the site has `wp_” as the default prefix. The majority of attackers won’t bother to check what the actual prefix is. That's why you should change it.

# inventory/host_vars/wordpress.example.com/vars.yml

wordpress__table_prefix: 'example_wp_'

wordpress__table_prefix is the option that controls the WordPress table prefix. The default option value is wp_ which is the WordPress default.

Disable file editing

File editing is the most powerful capability available to administrators. It allows any attacker to execute malicious code at will. All they need is an administrator account.

Even with solid account security, you’re still taking an unnecessary risk. You shouldn’t edit files in a production environment. Disabling file editing makes sure that an attacker can’t either.

# inventory/host_vars/wordpress.example.com/vars.yml

wordpress__disable_file_edit: True

wordpress__disable_file_edit is the option that controls whether users can edit files or not. The default option value is False to match the WordPress default. You should set it to True to disable file editing.

Configure the site to use SSL encryption

While using SSL encryption isn’t mandatory yet, it’s getting closer every day. Using SSL encryption prevents an attacker from intercepting any of your site's traffic. This keeps you and the visitors of your site safer.

# inventory/host_vars/wordpress.example.com/vars.yml

wordpress__ssl: True

wordpress__ssl is the flag that determines whether DebOps will configure your site to use SSL encryption or not. By default, it's set to false. Changing it to true is the only thing that you need to do to enable SSL encryption on your WordPress site. This will create a free certificate using the Let's encrypt certificate authority. This is the default SSL certificate provider.

SSL Providers

You can control the SSL certificate provider using the wordpress__ssl_provider option. You can set the option value to one of these three values: letsencrypt (default), manual or selfsigned. These represent the three currently supported SSL certificate providers.

Let's encrypt

# inventory/host_vars/wordpress.example.com/vars.yml

wordpress__ssl: True
wordpress__ssl_provider: 'letsencrypt' # Default, not necessary.

As mentioned earlier, letsencrypt is the default SSL certificate provider. By default, it'll create a certificate for the wordpress__domain. If wordpress__domain points to a root domain (e.g. example.com), DebOps will also create a certificate for the www subdomain (e.g. www.example.com).

Manual

# inventory/host_vars/wordpress.example.com/vars.yml

wordpress__ssl: True
wordpress__ssl_provider: 'manual'
wordpress__ssl_crt: '/absolute/path/to/certificate.crt'
wordpress__ssl_key: '/absolute/path/to/certificate.key'

manual is the SSL certificate provider that you want to use when you by an SSL certificate from a certificate authority (e.g. RapidSSL). With the manual provider, DebOps also needs to copy over your purchased certificates to your server. That's why you also need to set both the wordpress__ssl_crt and wordpress__ssl_key options.

These should point to the crt and key files that you received from the certificate authority. You should also use absolute paths to point to the certificate files on your computer. Relative paths will not work.

Self-signed

# inventory/host_vars/wordpress.example.com/vars.yml

wordpress__ssl: True
wordpress__ssl_provider: 'selfsigned'

The selfsigned certificate provider generates a fake SSL certificate. You should only use this provider for local development environments. That's because most browsers do not recognize these types of certificates. They will show you a warning (or worse an error) when you try to load a site that uses a self-signed certificate.

Updating your server

If you already have an existing server, you'll need to run the WordPress DebOps playbook again. DebOps will then update the configuration of your server so that it uses SSL encryption.

$ debops wordpress