At the end of October we had the opportunity to attend WordCamp Las Vegas. WordCamp’s are great events organized in various cities/countries by the WordPress community to discuss, learn, and teach all things WordPress. If you’ve never attended one, I highly recommend you do! More than likely, there is already an event near you.
John Hawkins, one of the WordCamp Las Vegas organizers, asked if I’d be interested in standing in on a Q&A session after lunch, he said he had some questions for me. Of course I obliged, and we headed off to lunch.
Lunch was great. We then gathered in the main conference hall to field questions. As moderator, when John had an opportunity, he fired off the following question at me:
“What best practices do you recommend be used to secure a WordPress install?”
I had fun fielding various questions from the crowd during the Q&A session in Vegas. John’s question was great and stemmed into a pretty cool session. After hearing such varying questions, it really put into perspective that there are a ton of other areas that come to play when trying to maximize your security posture, in fact, there’s a cubic ton to cover. To make things a bit easier, we’ve decided to put together a comprehensive, multi-post series about WordPress security to help centralize various best practices and recommendations.
Yes, there’s already a ton of WordPress security posts (WordPress Codex) out on the interwebs, including one we wrote a while back. We just figured it never hurts to continue hitting on this point as it is crucially important, and often over looked.
Note: We’ve attempted to be as comprehensive as possible but may have missed some things. We’re targeting WordPress users working in LAMP environments and not Windows based installations
It starts with you.
Am I a secure? Is my site secure? Well, my question to you is define secure? There is no easy answer. Are you doing everything possible to minimize risk?
If you’re asking these questions, you’re heading in the right direction. At least you have security in mind, and you already know there are security risks involved with managing a site.
Too vague? Here are a couple other questions you should be asking yourself:
- Am I doing the right things to protect myself, my assets, and my users from potential security risks?
- Am I managing risk mitigation correctly, accurately, and in a timely fashion?
Doing the right thing will enable you to stand with a stronger security posture. Remember, the percentage of risk can never be zero. There are too many variables to consider. However, if you’re doing all the right things, and you stay proactive as much as possible, you minimize the inherit risks of doing business online.
Information security is everyone’s responsibility, which means It starts with you. If you’re doing everything in your power to mitigate risk from your end, you’re less likely to end up with a website serving Viagra ads on Google.
- Stay away from security through obscurity (applies to plugin and theme authors also!)
- Start using defense in depth to protect yourself and your users, and don’t solely rely on technology. If you’re not practicing good security processes, the latest and greatest technology won’t do anything to protect you.
Here are a few tips to get you situated in everyday life on the web, even before you install WordPress:
With thousands of new malware strings found daily, you’re putting yourself at higher risk of infecting your websites if your local environment is already exploited.
- Keep your computer up to date – Ensure you’re patching or installing updates ASAP. Automatic updates rock!
- Install an anti-virus solution and ensure you’re keeping definitions current – Again, automatic updates rock!
- Yes, personal firewalls still apply!
Just because you’re connected to your server remotely doesn’t mean it was done securely. One of the most used protocols to transfer files back and forth to your server is file transfer protocol (FTP) which should be avoided, and even turned off on your server if possible. When using FTP, the login credentials for your session are transmitted in clear text, and are susceptible to sniffing attacks.
- Avoid using FTP (disable on server if possible), use a secure alternative like SSH or sFTP. Most FTP clients support secure protocols.
- If FTP cannot be avoided:
- Do not allow anonymous login
- Limit the number of FTP connections allowed
- Practice least privilege: Ensure only the people that need access get access, and ensure they only get access to what they need to get their job done!
- Disable SSH access for root user.
- Use alternate port for SSH if possible.
- Configure SSH to allow or deny certain IP addresses
- Do not store any passwords in your FTP/SSH client
Passwords are like toothbrushes, you should keep them to yourself. And discard them, and get a new one, if they have been used by others.
- Change passwords often
- Don’t share your passwords
- Avoid writing passwords down
- Use a password manager
Of course you don’t want to be the one serving malware, but what about sites already exploited?
- If a site has been blacklisted, you should probably avoid using it. If your not sure, scan the site, there are various site scanning solutions out there you can use to check if a site is blacklisted. Google is also very good about giving a warning that they’ve blacklisted a site.
- Disable pop-ups
Where do you live? Choose wisely!
In a perfect world, we’d all have dedicated servers with packet ninjas inspecting every ounce of traffic in and out of our networks. We’d have the best technology, people, and processes guarding against every attack known to man. This my friend, is unrealistic. Remember, the moment you spend a penny more on security than the cost of your assets, you’ve spent too much!
What is realistic however, is to expect a minimum level of security from your provider. At the end of the day, hosting providers market the world, you in turn, should have opportunity to know how they’re going to protect you.
Here are few things to consider before choosing a host:
- Cheap doesn’t always mean best, or safe! Although cost should be a consideration, it doesn’t come to play at the cost of your brand or business!
- How many sites on their network are blacklisted for malware reasons?
- What are the remediation responsibilities and service level agreement times for submitted trouble tickets.
- Are any passwords used in their hosting environment stored in clear text
- What version of Apache, PHP, etc. are being used in production?
- How far outdated is the provider?
- When will they upgrade and how often do they upgrade?
- How are users authenticated to the hosting control panel, and how are credentials stored?
- Are the hosting control panel credentials separate from the server credentials?
- If not, do you ever have to disclose these credentials to customer service or support?
- Are you able to run ModSecurity? If so, Are you running it? 😀
These considerations are mostly focused towards shared hosting environments, although they still apply. When you have control of your environment using a VPS or dedicated server, the rules are a bit different. I am writing this post with the assumption that if you’re running a VPS or dedicated server, you’re properly securing it, or have someone taking care of your hardening.
Upgrade Upgrade Upgrade
We often hear that WordPress has been hacked, or WordPress is unsecure, this isn’t the case really. Any software overtime has a higher risk of being infected. In fact, WordPress is actually very well managed and coded with security in mind. It has a tremendous community, and historically when vulnerabilities have been found, they are quickly patched.
We have found that over 78% of the malware cases we deal with are attributed to outdated core applications, plugins, modules, or some other server side software.
The reason we share this before we get into specific WordPress hardening tips is because of its importance. You can take all of the precautions in the world, but if your software is out of date, and a vulnerability has been identified, you’re at a very high risk of being owned!
The WordPress development team has made it ridiculously simple to automatically update WordPress core, plugins, and themes. If auto-update isn’t an option, a manual upgrade is easy as pie.
The argument often heard is “If I upgrade, all my modifications will break”. If you find yourself saying this, there are ways to get you towards better leveraging the flexibility of WordPress.
Here are a couple things you can do to avoid this:
- Don’t edit WordPress core – use your theme functions file or plugins to adapt WordPress to your needs.
- Research your add-ons – If you’re using third party plugins & themes, try to choose smartly.
- Use plugins found in the WordPress plugin repository.
- Is the plugin or theme in active development?
- Are the authors upgrading with the WordPress development cycle?
- Use child themes – Instead of editing your theme directly, create a child theme. This is will minimize the risk of your theme breaking when an upgrade is released for the theme.
- Read reviews – If you’re not sure, take the time to Google for reviews. If you find two reviews and both look shady, it’s probably best you stay away from the theme or plugin in question. #JustSayin!
- Don’t test hot – Set up a sub-domain on your server mimicking your production environment and test upgrades there first. This way you don’t take down your production site while upgrading core, or one of your cool widgets.
So there you have it, the first in our series “Yet Another WordPress Security Post”. We’re going to follow up with another post soon to start getting down to the nitty gritty.
The idea with part one was to set the foundation. You should include security practices throughout the entire web management experience to maximize your defenses, and minimize your risk.
Part two in the series will include a bit more in depth look at specific WordPress files that should be secured, various methods to harden your install, and some simple practices you should consider.
Please let us know if you have any questions, or if there are any areas we can help you with. Remember this is foundational but we’re definitely interested in hearing from you, make sure to leave a comment!