Print-friendly version

Information Security Guideline

Introduction

1. WordPress is a popular content management system and is frequently targeted for attacks; this hardening guide is meant to further enhance the level of security for WordPress by reducing the exposed attack surface and by providing configuration guidance.
2. This guideline has been issued by the Chief Information Officer to supplement the Vulnerability Management standard. Compliance with this guideline is recommended, but not mandatory. Questions about this guideline may be referred to information.security@ubc.ca.

Hardening WordPress

1. The official WordPress hardening guide provides security best practices to reduce the attack surface of WordPress deployments. The security hardening recommendations in the table below supplement the official hardening guide in the UBC context. The table also shows the value and estimated cost associated with each recommendation.

   Recommendation	Category	Value	Effort	Cost
   HTTPS for all communication	Prevention	High	Medium	None
   Restrict access to wp-admin and wp-login	Prevention	High	Medium	None
   Restrict file system permissions	Prevention	Medium	Low	None
   WordPress Config hardening	Prevention	Low	Low	None
   Add WordFence Security plugin	Detection	High	Low	None/119 USD/year
   Add WP Activity Log plugin	Auditing	High	Medium	99 USD/year
   Add Two Factor Authentication Plugin	Prevention	High	Medium	None
   Add Akismet Anti-Spam Plugin	Prevention	Medium	Low	None
   Monitor site home page	Detection	Medium	Low	130-240 USD/year
   Use CWL authentication for users and administrators	Prevention	High	High	None
   Block WordPress XML-RPC	Prevention	Low	Medium	None
   Create staging environment	Prevention	High	High	None
   Review and cull plugins	Prevention	High	High	None
   Remove non-critical WordPress files	Prevention	Low	Low	None
   Perform regular external security scans	Prevention	Medium	Low	None
   OS Hardening	Prevention	High	High	None
   Keep WordPress and plugins up-to-date	Prevention	High	High	Unknown

   Table 2.1 Security Hardening Recommendations
   1. Restrict access to wp-admin and wp-login
      1. Using a .htaccess file, block all non-UBC IP addresses from accessing the wp-admin folder and prevent access to wp-login.php and wp-admin areas for non-SSL encrypted connections.
      2. Removes risk of off-site access to login and administrative pages.
      3. Eliminates possibility of off-site login attacks.
      4. Third party developer access would each require a guest CWL account for VPN access, or an exception to the IP range restrictions on the server.
      5. Adds additional step for UBC staff who need to login to the site off-campus.
   2. Restrict file system permissions
      1. Where possible, restrict permissions on WordPress files such that they cannot be modified by the WordPress install. The details can be found in the official WordPress hardening guide. In order to retain the ability to use the web functionality to update the site, WordPress can be configured to perform updates locally over secure FTP connections.
   3. WordPress Config (wp-config.php) hardening
      1. Restrict plugin installs to prevent users from modifying plugins or themes.

         define( 'DISALLOW_FILE_EDIT', true );

      2. Enforce SSL to potect against the possibility of a server-side SSL misconfiguration.

         define('FORCE_SSL_ADMIN', true);

   4. Add WordFence Security plugin (free, but the paid premium version is recommended). Enable the following security controls (some controls require the paid premium version):
      1. Web application firewall uses a threat defense feed to block attackers from your site.
      2. Brute force attack blocking watches for malicious login patterns.
      3. Malware scanner scans core files for malware, code injections, and backdoors.
      4. Password auditing to ensure that passwords meet a minimum level of complexity.
      5. Email notification on security events such as administrator logins on new devices or from new locations.
      6. Prevent discovery of usernames.
      7. Prevent execution of code files in the WordPress uploads directory.
      8. Notification of out-of-date plugins and core files.
   5. Add WP Activity Log plugin
      1. Purchase and install the WP Activity Log plugin. This plugin adds comprehensive event audit logging and log search capabilities to WordPress, making any post-incident investigation easier. Beyond security events, this plugin also tracks changes to accounts and site content, and allows for email alerts when specific events occur.
   6. Add Two Factor Authentication Plugin
      1. If you are using CWL authentication, CWL multi-factor authentication for your site can be requested. Regardless, you should still enable a two factor authentication plugin for all local-only WordPress accounts.
      2. Require local admin users to enter a randomly generated, time specific code when they login. Besides preventing unwanted account access, this also helps prevent the sharing of accounts.
      3. There are several plugins available for this.
   7. Add Akismet Anti-Spam Plugin
      1. If using blogging on the site, consider enabling Akismet Anti-Spam plugin to aid in preventing comment SPAM.
   8. Block WordPress XML-RPC
      1. If your site does not need to use the xml-rpc functionality of WordPress, block it either by using a .htaccess file, or by installing the Disable XML-RPC plugin.

         # disable access to xmlrpc
         <Files "xmlrpc.php">
         Order Allow,Deny
         deny from all
         </Files>
         

   9. Remove non-critical WordPress files
      1. To prevent attackers from gaining information about the version of the WordPress Core, or other WordPress plugins, remove non-critical WordPress files (e.g. /readme.html).
   10. Review and cull plugins
       1. Out of date plugins represent additional security risks to the site. Review the list of existing WordPress plugins on the site to see if they are being used and are necessary for site functionality. Remove any that are not necessary. Be mindful of utilizing free third party plugins that could contain vulnerabilities.
   11. Block brute force attacks
       1. Brute Force Login Attacks predominantly have three types of requests:
          /wp-signup.php
          /wp-login.php
          wp-login.php?action=register
       2. To block Brute Force Login and comment requests from a remote HTTP_REFERER, add the following .htaccess rule (replacing the HTTP_REFERER with your site domains), which performs a redirect to a non-existent site:

          <IfModule mod_rewrite.c>
          RewriteEngine On
          RewriteCond %{REQUEST_METHOD} POST
          RewriteCond %{REQUEST_URI} .(wp-comments-post|wp-login)\.php*
          RewriteCond %{HTTP_REFERER} !.*(yourdomain.ubc.ca|yourdomain2.ubc.ca).* [OR]
          RewriteCond %{HTTP_USER_AGENT} ^$
          RewriteRule (.*) http://0.0.0.0/$ [R=301,L]
          </ifModule>
          

   12. OS Hardening
       1. To reduce the attack surface of the operating system, it is important to use an appropriate CIS benchmark to harden the operating system hosting the WordPress deployment.
   13. Keep WordPress and all plugins up-to-date
       1. Only the latest version of WordPress is actively maintained. It is important to keep WordPress and all plugins up-to-date in order to patch known vulnerabilities and improve the security posture of the WordPress deployment.

Process Recommendations

1. Accounts - Where it's not possible to rely on CWL integration for the site:
   1. Create a single new administrator account with a random username and password.
      1. This new account should be held by a UBC staff member and used in “break glass” scenarios only.
      2. This new account should never be provided to a third party.
   2. Delete all existing generic accounts, creating individually assigned user accounts where necessary.
   3. Do not create additional generic accounts.
   4. Promptly de-activate accounts as staff or third party developers change.
   5. Perform regular review of site accounts to cull those that are no longer required.
   6. Grant permissions according to the Principle of Least Privilege. Only give users access to the minimum level of permissions that they need to do their functions.
2. System maintenance
   1. Subscribe to the WordPress security mailing list.
   2. Perform regular reviews of WordPress and plugin versions.
   3. Keep WordPress and all plugins up-to-date.
   4. Identify high-risk flaws and patch as soon as possible.
   5. Develop a change plan to regularly test and roll out updates, ensuring that the impact on the live site is kept to a minimum through testing and timing. Having a staging environment makes this process much smoother.
   6. If the site contains Medium, High, or Very High Risk Information, develop a data lifecycle plan to regularly review and purge WordPress content data in compliance with UBC records retention schedules.
      1. Reduces the impact in the event of a site breach or compromise.
      2. Reduces the size of the database should a post-incident investigation be required.
3. Staging and rolling updates
   1. Keeping a separate staging environment is highly recommended.
   2. Content updates should be content only. This should never be a system database dump that overwrites accounts and credentials unless that is the clear intent.
   3. Any updates, whether security, code, or major content, should be staged in the staging environment first.
   4. Thorough functional testing must be performed to make sure things function properly in the staging environment.
   5. Thorough security testing must be performed to make sure that things are secure in the staging environment.
   6. The staging environment must be replicated to the production environment only after the security and functional testing has been completed.
      1. This process must include a rapid back-out plan in the event of unexpected failure.
4. Monitoring and notifications
   1. Determine who should be responsible for responding to automated notifications sent by the site.
      1. It is recommended that a mailing or distribution list be used for this purpose.
      2. At least two UBC staff should be members of this list to ensure coverage during leave.
      3. It is recommended that third party developers be on the list if they maintain any ongoing responsibility for the site.

Recommended Sites

1. The following sites provide additional information on securing WordPress

   Topic Area	Site
   Hardening WordPress	https://wordpress.org/support/article/hardening-wordpress/
   Combating Spam	https://codex.wordpress.org/Combating_Comment_Spam
   Brute Force Attacks	https://wordpress.org/support/article/brute-force-attacks/ https://blog.sucuri.net/2014/07/new-brute-force-attacks-exploiting-xmlrpc-in-wordpress.html
   Hardening the Operating System	https://www.cisecurity.org/cis-benchmarks/
   Article on CryptoPHP	https://foxitsecurity.files.wordpress.com/2014/11/cryptophp-whitepaper-foxsrt-v4.pdf

Related Documents and Resources

1. Policy SC14, Acceptable Use and Security of UBC Electronic Information and Systems
2. Vulnerability Management standard
3. UBC Systems and Application Hardening Guides

Guideline Last Revised: 2023-09