Online Services

Category: Security

Do You Need a WordPress Security Plugin?

At Wordfence we are a big team these days with millions of customers, and we think about security all day long. Sometimes we can get deep down the proverbial rabbit hole and forget about the basics.

I recently overheard someone asking “Do I really need a WordPress security plugin?” and I realized this is a perfectly valid question. If you are not in the security industry, you might ask it.

I know that many of you are well versed in security already – and WordPress security in particular. Perhaps that is why you are reading this post or subscribe to our mailing list. What I would like to provide you with in this post is a way to answer the question of “Do I need a WordPress security plugin?” to friends, family and colleagues that is both enlightening and easy to understand.

If you are new to WordPress, I hope this post helps increase your understanding of WordPress security.

Physical Security compared to WordPress Security

Many people think about WordPress security in the same way that they think about physical security in the real world. In the physical world, we might build a facility like a bank that needs to be secured. We build barriers to entry and access controls as part of the construction project.

Once the project is complete, we have a secure facility with walls, gates, secure entry and exit, cameras, access controls and human personnel to implement security procedures as people enter and exit. The physical construction does not change much over time, once the project is completed.

You are unlikely to discover that the concrete you used to build a wall for your bank is now vulnerable and needs to be replaced. A wall is still difficult to penetrate and a locked gate with a guard is going to still be quite effective a few months from now.

It is easy to make the mistake of thinking about WordPress security in the same way. If you install software that is secure to power your WordPress website and you implement good security policy and controls, one might think a website would behave in the same way. In other words, one might think a secure website today should be secure a few months from now if it doesn’t change.

That is not the case and I’m going to explain why. If you build a website using the newest software that has been verified to be secure and you implement good security policy, your website does not change, but the environment it is operating in changes. Attackers continually research the software that powers your website and vulnerabilities are eventually discovered in most popular online software.

Therefore the problem is that, while your website software starts off secure, it almost always ends up being insecure without anything changing on your website. It’s not your fault or the fault of the person who created your website. It is just the way of the online world. This differs from our building metaphor above in that a secure building doesn’t usually end up insecure a couple of months after being built without anything in the building changing. But a website does.

In fact, this is an ongoing cycle. Vulnerabilities are discovered, attackers start using them and ultimately if you are a responsible WordPress site owner, you upgrade your site regularly to fix those vulnerabilities. Then new vulnerabilities are discovered in new versions and the cycle repeats.

The Time Gap Between Vulnerability Knowledge and Installation of a Security Fix

You might build a new website with the latest secure versions of WordPress and all of the relevant plugins and a theme. As time passes, vulnerabilities are discovered in your plugins, theme and the version of WordPress core you are using. Those vulnerabilities (or security holes) become public knowledge at some point.

There is usually a delay between when the vulnerability becomes public knowledge and when you get around to installing a fix. Even when a fix is automatically released by the WordPress security team, the vulnerability may have been public knowledge for some time. This was the case with the recent PHPMailer vulnerability, which took several weeks for a patch to appear in WordPress core and be automatically deployed.

A WordPress security plugin provides many valuable functions, but at its most basic, a WordPress security plugin protects your website from attacks during the time it is vulnerable.

We do this in two ways. Wordfence provides a firewall that has rules that are constantly updated. At Wordfence, when we learn about a new security hole in software that you might use, we release a firewall rule to your site that allows Wordfence to block hackers from exploiting that security hole.

The second way we protect you is by providing a malware scan. Wordfence detects thousands of malware variants. If the worst happens and somehow a hacker does manage to penetrate your website, Wordfence alerts you to the presence of malware on your website and even helps you find it and remove it. Our malware signatures are also continually updated.

As many of you know, our Threat Defense Feed is what distributes new firewall rules and malware signatures to your Wordfence security plugin. Our Premium customers receive these in real-time. Free customers are delayed by 30 days.

Protecting You When You’re Vulnerable is What We Do

Wordfence provides many other security functions including two factor authentication, country blocking, brute force protection, rate limiting and more. But the most important function we provide is this: Wordfence protects your WordPress website once vulnerabilities are discovered in your previously secure website and before you have installed a fix.

Most websites are hacked as a result of an attacker gaining entry by exploiting a vulnerability in the website software. By using an effective WordPress firewall like Wordfence with a real-time Threat Defense Feed, you are protected, even if your website suffers from a vulnerability.

I hope this has helped provide a fundamental understanding of the most important reason you or someone you know needs a WordPress security plugin like Wordfence. As always I welcome your feedback in the comments below.

Stay safe!

Mark Maunder – Wordfence Founder/CEO.

Thanks to Dan Moen for editing this post.

The post Do You Need a WordPress Security Plugin? appeared first on Wordfence.

February 10, 2017
Announcing Wordfence 6.3.0 – Exciting Improvements
This morning I’m very excited to announce the release of Wordfence 6.3.0. This is one of our bigger releases and it includes a few exciting changes to the user interface and the way Wordfence helps you secure your site.

Since 2012, Wordfence has been securing WordPress. We started with a handful of important security features. As Wordfence became successful, as the team grew and as we improved the product, the list of menus in Wordfence kept increasing.

Another side-effect of improvements in Wordfence is that the number of things you need to pay attention to also increased.

In user interface design, as with just about everything else, attention is in short supply. We are all busy with plenty of other important things to do in our day to day lives. Securing our WordPress websites is just one of our many priorities.

With the release of Wordfence 6.3.0, the team started by thinking carefully about what is most important when it comes to security. We also looked at the range of functions that Wordfence provides and how they are related to each other.

Finally, the team considered how best to communicate with our users when they have a security problem or something else important they need to know about.

Introducing the Wordfence Dashboard

The first change we’ve introduced is the new Wordfence Dashboard.

The Wordfence Dashboard appears at the top of the new menu structure on the left in your WordPress admin console. The Dashboard is a way for you to view your security posture at a glance. Some of the data the new Dashboard includes is:
- When your last scan completed.
- If any security problems were detected.
- Important security notifications.
- What security features are enabled and disabled.
- The number of Threat Defense Feed rules you have enabled and protecting your site. These are malware signatures and firewall rules.
- Attacks that have been blocked by Wordfence during the past day, week and month.
- The top IP addresses we have blocked in the past day, week and month.
- Attacks blocked over time (a chart) across the Wordfence network of sites we protect.
- The top countries that attacks on your website are originating from.
- Successful and failed login attempts on your WordPress site.
The Dashboard is completely new, available at the top of your WordPress menu and gives you an instant view of your WordPress site security status.

Menu Redesign

The next thing you will notice in the newest version of Wordfence is the redesign of the menu on the left side of your site.

As you can see the Dashboard is at the top of the new menu and is your “jump off” point because it provides an overview of your website security.

Scan Page Improvements

The next item is the “Scan” menu which combines Scan and Scheduling. We have also introduced a new scan “options” tab which gives you instant access to all the Wordfence options that affect your scan. You no longer need to go to the separate “options” menu to change your scan settings – it’s right where scan is.

Meet Your New Firewall Page

The new ‘Firewall’ option on the menu is one of the most exciting changes in Wordfence 6.3.0 because it consolidates all firewall related security options onto a single page which looks like this:

As you can see above, the new tabs on this page give you tabbed access to:
- Your Web Application Firewall configuration or WAF. This is the most important firewall option available because our WAF provides the best protection available against attacks.
- Country Blocking which allows you to selectively block countries.
- You can view and manage Blocked IPs.
- Advanced Blocking gives you the ability to build blocking patterns based on address ranges, browser, referring site and more.
- Brute Force Protection which lets you prevent login and password guessing attacks.
- Rate Limiting which gives you the ability to limit the rate at which automated crawlers access your site.
Live Traffic is Unchanged and Awesome

The Live Traffic menu option still takes you to the same live traffic page that includes advanced filtering and a real-time view of your website activity. As always, live traffic shows you attacks being blocked in real-time.

Introducing the new ‘Tools’ menu option

The Tools menu option in Wordfence is new. It combines our powerful security tools into a set of tabs that lets you easily find and access them:

As you can see we have combined the following:
- Password Audit is now the default tab visible when you hit the ‘Tools’ page.
- The Whois Lookup lets you get detailed information on an attacking IP address or hostname.
- Cellphone Sign-in gives you the ability to enable and manage two-factor authentication on a per-user basis.
- The Diagnostics page is our page for diagnosing issues with your system. It provides tools and information related to diagnostics.
The Options Page Remains Unchanged

The Wordfence ‘Options’ page at the bottom of our menu gives you the ability to manage all of your Wordfence options in one place. It is also where you install your Wordfence Premium API key if you have purchased one, in order to upgrade to Wordfence Premium.

Always Improving

Improving Wordfence is a collaborative process. I’d like to thank our user community for all the valuable feedback they’ve given us over the past months and years. Whether you have contributed in the comments on this blog, in our public forums or via a Premium support ticket, we appreciate your input.

Wordfence will continue to evolve and improve this year. We have a few exciting new features we will be announcing later this year that will help make your website even safer.

Please leave your feedback in the comments. Because this is a release announcement, I should add that we don’t recommend you post support requests in the comments below. Our support team does not check these comments. They are waiting to help you in our public support forum and in our Premium ticketing system.

Finally, a huge congratulations to all the team members involved in this release. This was a big one with many moving parts and a lot of testing. Congratulations team!

The post Announcing Wordfence 6.3.0 – Exciting Improvements appeared first on Wordfence.
February 10, 2017
XMLRPC or WP-Login: Which do Brute Force Attackers Prefer

At Wordfence we constantly analyze attack patterns to improve the protection our firewall and malware scan provides. We recently took a closer look at brute force attack targets, specifically XMLRPC and wp-login, to gain a deeper understanding of how attackers behave.

In WordPress, there are several ways to authenticate, or sign in to, your website. The two most common ways to authenticate are using the standard login page located at wp-login.php, and by using XMLRPC.

The XMLRPC method is usually used by applications like mobile apps to authenticate before you are able to perform privileged actions on the site.

We analyzed attack data over a 2 week period from January 16th until Janary 29th to determine which target attackers prefer to attack. Here are the results of our analysis.

Which Target Receives More Attacks?

During a two week period we saw almost exactly the same number of attacks on XMLRPC as wp-login. We saw a total of 106 million attacks on wp-login compared to 108 million attacks on XMLRPC.

This result surprised me because I assumed that attackers targeting XMLRPC would be more sophisticated or perhaps creative. But on reflection it takes about the same amount of effort to write an attack script or bot that brute force attacks either target. So this makes sense.

How Many Attackers Hit Both XMLRPC and WP-Login?

The above graph shows the number of unique IP addresses per attack target. Note that this is not the number of attacks, but number of attackers counted as unique IP addresses we saw attacking.

While XMLRPC saw slightly more attacks, wp-login saw slightly more unique attackers, as you can see from the above column chart.

We saw 11,453 attackers only targeting XMLRPC. We saw 38,771 attackers only targeting wp-login. And we saw a whopping 224,461 unique IP addresses targeting both XMLRPC and wp-login.

Clearly most brute force attacks target both XMLRPC and wp-login.

Do Attackers in Different Countries Prefer XMLRPC or WP-Login?

We analyzed attacks from the top attacking countries and saw an interesting trend. As you can see above, most of the attacks come from Russia and the USA is the second most prolific attacker.

What is interesting here is that the attacks originating in Russia have a strong preference for wp-login as a target. And attacks originating in the USA have the opposite preference. They seem to mostly target XMLRPC instead.

Digging Deeper into Brute Force Attacks originating in the USA

As you can see the majority of the total number of attacks originating in the USA come from Amazon.com which provides cloud computing services to developers. We saw a total of over 144 million attacks over two weeks originate from Amazon.

Most of these attacks were targeted at XMLRPC. What is surprising though is that they came from only 36 unique IP addresses hosted at Amazon. All but 3 of these IP addresses appear to be EC2 instances based on their reverse hostnames.

So what is happening here? I’m going to suggest two theories:

One possibility is that 36 servers at Amazon EC2 have been compromised and they have been used to launch a very rapid and wide-spread brute force attack during the past 2 weeks. That attack generated over 144 million failed login attempts across the sites we monitor.

An alternative theory is that a developer may be using EC2 to host an application that is trying to sign into WordPress websites using XMLRPC. The application may not handle bad user credentials correctly and may just keep retrying.

It may be a combination of both bad applications hosted at EC2 and compromised servers engaging in a large scale brute force attack.

Conclusion

The data in this post brings up the old debate about whether or not it’s a good idea to hide your login page. Unless you hide every login method on your site, attackers will still be able to brute force your website.

If you disable or move XMLRPC, you risk breaking various applications, including mobile applications, that rely on XMLRPC to do their job.

If you hide or move your login page, you are going to inconvenience or confuse your users, and XMLRPC is still an attack vector.

Other authentication methods will soon become available in WordPress via, for example, the WP REST API. These will also be exploited by attackers.

So the action we recommend is that you use a security product like Wordfence to intelligently block brute force attacks, no matter what they target. Wordfence counts brute force attacks across all authentication methods and blocks attackers if they violate security policy.

Wordfence can also help you enforce strong passwords and audit your passwords for strength.

We also track attacks across all the sites we protect and take earlier blocking action against known bad IP addresses that have attacked other websites.

As always I welcome your comments below and I’ll be around to join the discussion.

Mark Maunder – Wordfence Founder/CEO

Special thanks to Dan Moen who produced much of the data used in this post and to assistance from our team in analyzing the data.

The post XMLRPC or WP-Login: Which do Brute Force Attackers Prefer appeared first on Wordfence.

February 10, 2017
Reminder to Update to WordPress 4.7.2 and Check Your Site

During the past few weeks we have seen two WordPress core security updates. WordPress 4.7.1 was released on January 11th which was a security update. Then WordPress 4.7.2 was released a few days ago on January 26th.

Both of these releases contain important security updates that fix known vulnerabilities in previous WordPress versions.

These are ‘minor’ updates. That means that if you have a default install of WordPress, your site has probably been updated automatically, unless you have restrictive file permissions or some other restriction in place that prevents automatic updates.

The Wordfence firewall currently protects against all vulnerabilities that are fixed in these two releases. This includes the privilege escalation vulnerability in 4.7.2 that was disclosed yesterday.

If you do have automatic update enabled and your site has been updated to 4.7.2, we encourage you to visit your site and make sure that everything is functioning as expected. WordPress core releases are well tested, but it’s always better to be safe and to verify site functionality after a series of automatic updates like this.

If you would like to learn how to change the automatic update behavior of WordPress, you can read about the WP_AUTO_UPDATE_CORE constant in wp-config.php. The default behavior of WordPress is to automatically upgrade your site to minor releases. And the default behavior is to not automatically update to major releases or development releases. Security releases like the ones mentioned above are ‘minor’ releases, so the updates are applied automatically.

The post Reminder to Update to WordPress 4.7.2 and Check Your Site appeared first on Wordfence.

February 10, 2017

Your cart (items: 0)

Products in cart
Product	Details	Total
	Available on backorder Previous price: Discounted price:	Save