Endpoint vs Cloud Security: The Cloud WAF User Identity Problem
Imagine you’re a security guard at the entrance to a high security facility. You need to evaluate each person who wants to gain entry to ensure they are allowed access. You use information about each person to make your decisions. You might use information like what they say, whether they’re carrying a bag, if they’re carrying a gun and so on.
The most important item of information you’ll use in your decision-making is who they are and what access level they have. In other words, their identity. If you don’t have this identity information, you are going to have a very difficult time making a decision about whether someone should be granted access or not.
In this post, we show you how cloud WAFs like Cloudflare and Sucuri, also known as cloud firewalls, actually don’t know who you are. They don’t even know if you’re signed in or not. The result is that they tend to do a much worse job when it comes to deciding who should be allowed to access a website and who should be blocked.
This post is a continuation of a series of Endpoint vs Cloud blog posts, which we started on Tuesday. We have already described the Cloud WAF Bypass Problem, and how an endpoint firewall like Wordfence prevents bypass.
Endpoint Security: Wordfence Knows Who a Visitor Is and their Access Level
As we discussed earlier this week, ‘endpoint security’ is what all major security vendors are moving towards. The ‘endpoint’ is the target an attacker is trying to gain access to. It might be a workstation, mobile device or your web application like WordPress.
An endpoint security solution runs directly on the endpoint and protects it in a variety of ways. Wordfence is an endpoint security solution because it executes directly on WordPress, which is the endpoint for an attacker targeting your website.
Wordfence integrates deeply with WordPress. One of the items of data we have is who a visitor to your site actually is and what access level they have. In security industry terms, we refer to this as authentication and authorization. We know if they’ve proven they are who they claim to be and we know what they have authorization to access.
Identity information is a critical part of the decision-making that our firewall performs. It helps us create firewall rules that block the bad guys and make sure that administrators and other privileged users don’t accidentally get blocked.
User identity and access level is so important to our firewalls decision-making that we use the user’s access level in more than 80% of our firewall rules. It helps us prevent the dreaded “false positive” when a real user is blocked. It also helps us create rules that block against more complex attacks.
By having user identity and access level, we can be extremely aggressive in the kind of rules that we create. Along with user identity we use other information to make our decisions, like the path being accessed, the URL query string, the type of request being made, the body of the request and other headers that might be included in the request.
Cloud Firewalls Don’t Have Identity Information
A cloud firewall like Cloudflare or Sucuri’s WAF uses servers based out on the Internet, away from the endpoint they’re protecting. Visitors and attackers who come to your website first arrive at the cloud WAF. The cloud WAF runs the request through a series of rules and decides if it’s allowed or not.
Cloud WAF providers have a firewall that runs physically and logically separated from the endpoint. They don’t interact with the endpoint API to make their firewall rule decisions. They don’t have authentication and authorization data that can use to help with that decision making.
A cloud WAF might be able to see if a user has a login cookie, but that cookie can be easily faked because they can’t verify its authenticity, because they don’t have access to the endpoint API, data and execution environment.
As we have explained, it’s critically important that a firewall knows who a visitor is and what permission level they have to make effective decisions. A cloud WAF does not even know if a user is signed in or not.
Cloud WAFs use pattern matching. They examine the arriving web request and use patterns to try to determine if it’s an attack or not. This results in much less effective decision-making. They block a few attacks but miss many others.
Cloud WAFs may also suffer a higher rate of false positives because they can’t identify real users making perfectly legitimate requests that trigger their rules. The only way to fix the false positives is to loosen up the rule-set, which results in more attacks getting through. It’s a Catch-22 situation.
Endpoint Security for WordPress: Local Knowledge, Defense in Depth
Wordfence is an endpoint security solution that executes within the WordPress environment. That means we have full access the the WordPress API and we can use any data in this API to make our decisions about who is granted access. That’s one of the reasons the industry is moving towards endpoint solutions: they have local knowledge to help their decision-making.
To help the Wordfence Firewall make its decisions, the WordPress API provides us the following data:
- If the user is signed in or not.
- The user’s identity.
- The user’s authorization level e.g. ‘subscriber’, ‘editor’ or ‘admin’.
If we see a verified admin user trying to access something that looks like a common attack, we might allow it to pass if all other data indicates it’s safe. If we see the same request coming from a ‘subscriber’ level user or someone who is not signed in at all, we will block it.
Protecting Against Complex Attacks
Wordfence protects you against more complex attacks, like a “privilege escalation attack”, or privesc attack as we refer to it internally. If you look at the list of firewall rules we’ve deployed on your site, you’ll see at least three privesc attack rules that are currently active and protecting you.
A privesc attack is where an attacker uses an account with low level access, like a ‘subscriber’ level WordPress account. Then they use the lower level privileges that account has to exploit their way to administrator level access.
To protect against privesc attacks, you need to know if a user is signed in and what access level or level or ‘authorization’ they have. If you don’t have authorization information, you don’t know if a subscriber level user is trying to perform an admin function or if it’s a real admin taking the same action.
Wordfence in effect has local knowledge about the system it is protecting. To make better firewall decisions we have made sure we simply have better data.
Conclusion
Smart decision making requires the best data. By protecting against attacks at the endpoint, you can make smarter decisions about who should gain access and who should be denied. With better data, you can also benefit from a far more aggressive rule-set without risking false positives, because you know who is using your web application. That is why Wordfence protects against attacks at the endpoint.
Comments
9:42 am
As I've pointed out to a Cloud service, the intensity of the malicious activities increased dramatically after I run my website trough Cloud, receiving more bad activity from within the cloud service rather than limiting and enforcing the security and integrity of my website (endpoint wp)
10:22 am
Wouldn't it make sense to run both? I realize we are focusing on end point protection in this blog but doesn't both systems help in their own respective ways?
12:14 pm
Cloud WAF has it's strong point in DDoS protection, and CDN with many global servers. As said by Mark in the previous article, it does require you to be very carefull with your origin (or direct) IP. Cause if attackers find this IP they can directly launch a DDoS attack on it. And no htaccess or even iptables rules can help against a massive DDoS attack.
Because the Cloud WAF has multiple globally diverse servers spreading the load it can migitate a DDoS attack. That same strong point is the weakness why it isn't a good protection against sophisticated hackers using zero day vulnerabilities. it's not living on the server, it doesn't see the code that gets executed to catch something dangerous happening, it might have rules to catch something easy like XSS or SQL injections.
Wordfence on the other hand can't help at all against a DDoS attack, it might even go down faster because of the processing overhead that Wordfence creates.
Protecting against hacking attempts is what makes Wordfence an excellent Web Application Firewall. It runs before any php code is executed and analyzes everything that is happening. As Mark explains, it has access to user identity data and can use this data to make decisions. On top of that it also runs scans on all files on the server to check for known backdoors or attack vectors. It compares files from known plugins to the original version on wordpress.org to spot any modifications. Last but not least you get warnings about out-of-date plugins, about brute force login attempts and can even show you real time traffic to your site. Very neat stuff. Even the free version has all this.
6:58 pm
Stan, Thanks and I was specifically thinking about DDOS attacks. I've been hit before and they are no fun. I like having both options available and working for me. Website security is becoming a full time job! :)
12:26 pm
I would like to know how CleanTalk plugin compares to Wordfence. They seem to have an awesome Firewall Spam feature that stops hackers coming from spammy IP so they are blocked before they even get to our site. We use both for now i.e. CT & WF, and they seem to complement each other.
Please provide a comparison feedback on this.
thanks
3:13 pm
I'm sorry but I'm not familiar with that product. I googled it and it looks like it has a small user-base. Spam protection really benefits from the network effect. The more people who use it, the larger the attack surface, the more data they have to make their decisions. So I'd go with Akismet if you want spam protection. They have a massive install base.
Mark.
8:50 pm
One of the best security for WordPress, As of now 100s of attack blocked by WordFence and still protecting my Blog's from vulnerable crawlers and bots.
Thank you for Protectin The Web.
5:49 pm
I accept that product comparison is a fair way to market your product, but this article raises more questions than answers for me - albeit I have minimal technical knowledge:
1. There is no comparison between the free and paid versions of the products referred to.
2. My experience is that the free version of Wordfence does a good job in blocking malicious hits, but does not effectively block invasive bots that steal bandwidth.
3. The free version of Cloudfare offers caching and rules based filtering that effectively blocked the nuisance bots that free Wordfence didn't stop.
4. I found using both free Wordfence and free Cloudfare together provide good security while reducing server load and bandwidth abuse.
7:28 am
Two days ago we experienced constant emails from WordFence that someone was blocked. It happened every 30 seconds or so all day long creating about 1500 emails. I looked at the IP addresses of those attempting to login and they were from all over the planet. It kept going for the whole day. WordFence worked and blocked them all.
What was this??? It has now slowed to a trickle of attempted logins. I'm curious about what this is called. I have subsequently made all passwords to all our other sites VERY strong.
...