When it comes to WordPress security, it's important to have a solid foundation for looking at your site with a critical eye toward making it more secure.
Here at WP Engine, we recently hosted a webinar with two fellow security experts who provided a number of insights on this topic, including the most common types of attacks, why hackers attack, and tips to make your website more secure.
Read on to learn more about some of these security insights to help you get a better understanding of WordPress security and how to harden your site to keep the bad guys at bay.
The WordPress Threat ModelGetting hacked isn't as easy as you might think — that's as long as you don't practice laxity in best security practices. There are a few things that can open up the portal to security vulnerabilities on WordPress, including:
Outdated componentsThe main way to attack a WordPress site is through outdated components, like themes, plugins, WordPress core or the hosting infrastructure itself. The No.1 thing to make sure you do is to upgrade all of the things.
Even though you get it for free, pirating should always be avoided due to security concerns. This is a bad idea because the scripts contained in the pirated versions are likely nulled (cracked), thus meaning these bootlegged items aren't up to date with the latest security patches.
Reusing unaudited codeNever reuse unaudited code. You can look at the change log to detect this to see whether or not a theme or plugin is safe to use. By looking at the log, it'll include details regarding what code has been changed, what has been modified based on security updates, and so on.
Giving out the wrong accessNot everyone needs to be an "Admin" within your WordPress install. Make sure you are cautious about who you give privledges to. In addition, you should always enforce strong passwords for users on your site.
Security at 50,000 feet
Getting a big picture of security from above can help you get a high-level view of whether or not your systems are secure. Make sure to evaluate if you've chosen the most secure option, that way you'll feel more confident about it in the future. Here's how it's done.
A good way to start including security with how you make decisions is by doing a pre and post mortem. Pre-mortem is where you make up a security incident and evaluate how you'd respond to it hypothetically. Post-mortem is how you actually responded to the incident.
Evaluate your assets and form a planThink about the internal (corporate systems), partners (business relationships), and public (site visitors) assets that could be affected by your security.
The ways in which you can provide defense and security for these assets are to reduce the impact of issues (mitigation/prevention), make sure a breach in one area won't spread to another (segmentation), and your ability to know that something has gone wrong and respond to it (detection/response).
Here are some examples putting this to practice:
Say you're making the decision on whether to have a WooCommerce site and a blog on the same WordPress install (perhaps using Multisite) or to keep those two on separate WordPress installations.
The big win here (security-wise) would be to have a separate install for each. Since the people who manage each site are separate people, and the visitors will likely be different, it's a good idea to segment these. The plugins, themes, and software you'd be updating are different, thus require different installations.
The downside is that with two sites, you now have two entities to manage and two security logs to look at — the detection/response cycle suffers as a result.
This isn't the only input into the decision either. There might be licensing fees or cost reasons why you cannot separate the two.
Another example that's more of a post-mortem scenario is through the host header. It turns out, a WP Engine blog defends against host header injections very well because the signature of these attacks is something we can look for in our logs centrally across all the sites. We as a partner have a very fast detection response cycle for detecting these.
Further, because at WP Engine you're specifying a concrete whitelist of domains, the actual technical measure that was being used in this vulnerability was directly prevented by how WP Engine intrinsically operates. We further have a hardened execution environment that if somehow that first control were not in place, there was another backup control to keep the issue from affecting you.
Attacker MotivesYou might be wondering why would someone want to attack your website. There are many motives for malicious behavior, some including money, spam operations, ad fraud, fame, malware distribution, and just straight up evil people who enjoy causing havoc for others.
Types of Threats
Various types of threats
One of the main attacks you'll hear about are brute-force attacks. This is where a bad guy uses a dictionary to try and constantly guess a password through thousands of login attempts. Once (and if) they log in, they'll do something like put ads or something on your site so they can make money off your hacked site.
SSH and FTP injections are a common malware that plagues WordPress. This is where an attacker brute-forces a service and once they get in, they will find all PHP files and embed PHP code in there to mess your site up.
Exploitation of old tools refers to when web developers will leave a tool on a blog they were using to do some sort of operation. There are several tools out there that have been exploited to inject ads and things like that because they expose access to the database.
Unauthenticated file upload is exactly what it sounds like — a bad guy can upload anything…for instance, malicious PHP scripts that try to take over the web server.
XSS (cross site scripting) is where unsanitized input can be exploited to embed malicious JavaScript into any page.
Information disclosure is where a bad guy can get information about your web server, for instance, if you left logs exposed, which can give file path information.
FAQsWhat should I look for in a secure WordPress theme?When it comes to choosing a WordPress theme, you'll obviously want to make sure your theme is frequently updated and compatible with the latest version of WordPress. In addition, you'll want to make sure there's a good change log to let you know what changes are going in and why they're being made.
WordPress 4.7.5 was recently released. What were the major changes?There were several security vulnerabilities fixed in this release, including several cross-site scripting (XSS) vulnerabilities and it also fixed some authentication issues.
There was a vulnerability discovered in the filesystem credentials dialog – the reason there's a filesystem credentials dialog in the first place is because of the diversity of environments WordPress is meant to run on. People are continually finding issues with these things to keep this compatibility possible.
How often should I upgrade "all the things"? Is there a recommended schedule?As often (and as soon) as possible. But it also depends on the software you're using and the developer's release cadence. Sometimes you can predict an upcoming release and factor that into patching.
If you log in to your WordPress site every day, there's a clear reminder in the admin dashboard as to what needs to be updated. As long as you take action when you see that update notification, you should be in pretty good shape.
What does WP Engine do by default for security?WP Engine does a lot of things by default — one of our most powerful tools is that we do nightly backups. It's not obvious at first glance that this is a huge security measure, but doing this will allow you to instantly recover from a bad state, should your site become exploited. Cleaning up your site after it's been hacked can be very difficult, which is one reason why we have backups in place should this ever happen.
Another thing we do by default is we have mitigations that prevent "drive-by" attacks, like brute-force attacks (which commonly occur on the WordPress login page). We prevent these types of login attempts on our platform. We avoid using the "admin" username, which makes it easier to hackers to guess your login info.
We also have some controls in place that prevent drive-by visitors from being able to upload particular kinds of scripts and files to your site. This means that every time there's an unauthenticated file upload vulnerability, for example, it's much more difficult to weaponize that on the WP Engine platform.
Do I need a security plugin if I'm on WP Engine?That is more up to you as a customer. It's not a bad idea because security plugins do help with a lot of things. Most security vendors do a lot of great research and provide some extra value.
As an agency with lots of clients, do you have a recommendation on how to store client passwords?There are several different password managers out there, like Encryptr by SpiderOak. They run on a zero knowledge platform, so even if their services are ever compromised, it'd be impossible for a hacker to get access to passwords.
In addition, if you can use a social login plugin that makes it so that you don't have a distinct password, but it's tied to your Facebook, Twitter or Google+ account, that can sidestep the issue quite nicely.
Another thing you can do is use multi-factor authentication, like a 2FA plugin, so that even if those passwords are compromised, a bad actor would still have to have access to the device (like a smartphone) where you're sent the access code to get in.
I have Wordfence installed. What other steps should I take to harden my site?Check out this guide: 15 Ways To Harden Security of WordPress Site
Also, make sure the roles on your site are up to date and admin privileges are given to the right people. If someone leaves your company, you should switch their user role from "admin" to "subscriber" or a similar role.
What common attack scenarios does WP Engine guard against?There are lots of different attacks that we guard against. There are many plugins and components that have been common targets in the past. Our built-in technology actively guards against a lot of these types of vulnerabilities, including older versions of certain components.
We also limit login attempts. Particular customers on our platform have had millions of login attempts re-limited by our system in a day.
Can Cloudflare be used with WP Engine smoothly?Most definitely. We have a lot of customers using Cloudflare currently.
I've recently been scanning my site using OWASP's W3AF against WP Engine. What's your recommendation around doing security scans on WP Engine installs? Since W3AF is not targeted at WordPress specifically, you might consider another service, like WPScan. You'll find that with this service, your scans will not take as long.
Does WP Engine implement fail2ban as a way to strengthen a firewall? If so, is there a way to configure it? We don't have fail2band implemented for the wp.login. But, we are monitoring login attempts to the management subsystems, SFTP in particular.
WP doesn't allow the plugin Wordfence on its platform. Are there any other recommended plugins? In the absence of Wordfence, you might check out iThemes Security or the Sucuri Security plugin.
In regards to WordPress core updates, can we assume they are safe and secure? There was some controversy earlier in the year where a talented developer made a minor fuss that WordPress updates don't have code signing as part of them. Matt Mullenweg put out a response detailing why code signing isn't a top priority.
While it would be nice to have signed updates, here at WP Engine we do not download a copy of WordPress individually for each install that we're upgrading. We have a central repository that we update, done from an extra trusted network space. We are taking extra measures to make sure that WordPress updates aren't modified in-flight.
How big is the risk of downtime for a shared vs. dedicated server? This depends, as it will largely depend on how downtime affects your business. For a small business that has a blog, downtime won't be as impactful because Google will actually cache most of that information in the search results page. On the other hand, if you have a transactional business on your website, this is a different equation.
A shared infrastructure means noisy neighborhoods could eventually become a problem. WP Engine has specific things in place to mitigate this sort of issue. If it's a significant source of revenue to have your website online, it's worth considering a dedicated infrastructure.
How much time should I spend reading terms & conditions and privacy policies (and what should I pay attention to) in regards to themes and plugins? The good thing about themes and plugins is that they're open source, so they use the same licensing. But if you're going to go premium, it may be worth reading a bit more into things, especially depending on the nature of the plugin.
Have a question we didn't answer here? Feel free to ask in the comment section below.
Source: The Right Security Mindset For WordPress
No comments:
Post a Comment