A Well Architected Use Case : Securing WordPress by aligning best practises to the Security Pillar
Security is often described as job zero for AWS. It is paramount to the success of any workload running on AWS, and this ethos is replicated at CirrusHQ. For example, as part of our Well Architected reviews, the security pillar is a key focus on our remediation efforts. As we continue to highlight the importance of security, we have focused here on a typical concern: Securing WordPress on AWS.
WordPress is one of the most popular blogging, ecommerce, and marketing content management platforms. With over 60% market share, it has become a common target for hackers and spammers trying to maliciously affect a site hosted on it. Given the known threats on WordPress, some basic security precautions are required so that the chance of an installation being compromised is reduced. We pride ourselves on the rigour we have introduced for our customers to set up and secure their WordPress based websites. As a result of these preventative activities, we significantly reduce the risk of malicious intent.
This blog focuses on how to secure WordPress by aligning it to the security pillar of the well architected framework. Broadly the security pillar can be split into the following:
- Identity and access management
- Detection and Incident Response
- Infrastructure and Data Protection
Identity and access management
Implement 2FA for user logins
2FA, or two factor authentication, requires an user to authenticate via 2 different and unique ways. This is also one of the industry standard best practises to prevent login exploits. Typically a generated one time token is used in addition to the password associated with the user account to gain access. This can be achieved by installing a suitable plugin from the wordpress plugin directory or a custom plugin.
Remove/rename admin user
Every WordPress install asks you to create an admin user when being first created. It’s advisable to set up the admin user with a different name rather than the default ‘admin’. Also this user usually has a user id of 1. These are not exactly secret as it is the default for most WordPress sites, which hence plays right into the hands of the hackers’ information gathering procedure. Therefore it is advisable to use a different name other than admin and change the user id to something different than 1.
Grant Least privilege by Leveraging different levels of permissions Users
WordPress has inbuilt functionality to specify access levels. These include roles like Administrator, Editor, Author, Subscriber. For a default use case as a blogging platform, these can be used natively. Alternatively this functionality can be extended and custom roles can be created either via a custom plugin or one of the numerous plugins available in the WordPress plugin repository
Infrastructure and Data Protection
Make use of database prefixes and change default salt values
An important consideration while setting up a WordPress database is to set up the database tables with a non-common prefix. Since it is common knowledge that WordPress installs have the default prefix as wp_, sql injection attacks, and other exploits, can in theory run like brute force attacks without having to know much about the site’s setup. In fact many published WordPress-specific SQL-injection attacks make the assumption that the table_prefix is wp_, the default. Changing this can block these opportunist attacks.
In addition, another consideration for the database is to change the salt values you would find in wp-config.php to custom values.
Disable PHP and file execution inside uploads directory and give proper permissions
WordPress has a folder called uploads into which users can upload content. It is important to disable any php executions inside this directory as well as execution of any other type of files as well. The rationale is to mitigate an executable file being uploaded to the folder, which allows the intruder/hacker the ability to compromise the site. Disabling of executions of specific files can be achieved with the help of .htaccess rules. Lastly, never give the uploads directory a 777 permission. Utmost if properly configured, it requires a 755 permission.
Permissions for wp-config
There is no reason to have write permissions on wp-config after the WordPress site has been configured and is running without any issues in production. To prevent any vulnerability or a hack from manipulating these files, it is advisable to remove write and execution permissions and leave it only with read permissions. (i.e) 444. This can be done after all the required plugin installations.
Remove files like Readme.html / Readme.txt
These files contain information regarding the WordPress install and are easily available over the URL. Hackers first try to find this file to know more about the version of WordPress being run and using this they can identify any and all vulnerabilities with that specific version and try to exploit them. it is advisable to deny access to these files.
Keep WordPress and Plugins up to date
The WordPress team is currently excellent at identifying and patching security issues with the WordPress core. It’s important to keep track of updates released by them and apply as required.
The same applies to the plugins chosen to maintain patching and security vulnerability. Given the volume of available plugins being used it is important to ensure these are sourced reliable developers/3rd parties. Unfortunately, plugins can be built with malicious intent.
Detection and Response
Leverage WAF to block common attack scenarios
AWS WAF (Web Application Firewall) can be implemented at the CDN level, or at a load balancing level when the site is built for scale. There can also be use cases where WordPress is used as a micro site and lives on a single instance. During these scenarios, a custom software WAF can also be installed along with the web server to inspect and protect the site against attacks. A common strategy is to protect against the top 10 exploits from OWASP https://owasp.org/www-project-top-ten/. In addition, there are a variety of managed rules sets, including a WordPress specific AWS managed rules set, that can be applied to AWS WAF that ensure optimal protection is available for the website. It is highly recommended, along with the above mentioned PHP application rule set, and IP reputation rule groups should also be enabled. All these help automatically detect and respond to vulnerability scanning, SQL infection, and cross site scripting attacks
Make use of Security Plugins
There are quite a few plugins that are available for securing WordPress sites. We recommend the iThemes Security plugin for securing WordPress sites. It provides a simple and centralised way to configure a lot of the above mentioned security reinforcements. It also scans the WordPress site and suggests any reinforcements that can be applied. It also detects and blocks bruteforce and scanning attacks.
Leverage AWS Services like GuardDuty and Shield
AWS provides managed security services like Guard Duty which automatically and continuously monitor the VPC flow logs and DNS logs to provide actionable alerts regarding any malicious activity. Shield and Shield premium provides protection against DDoS which is a very high threat for WordPress sites that are popular.
At CirrusHQ we can analyse and help secure your WordPress installations. Our focus is to help migrate them to a secure, highly scalable and highly available AWS architecture to improve performance and also help reduce your recovery time if anything impacted your website. Hope these steps help you secure your WordPress websites.
If you would like to find out more from CirrusHQ regarding your WordPress sites on AWS, feel free to contact us via our contact page.
