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.
The post Endpoint vs Cloud Security: The Cloud WAF User Identity Problem appeared first on Wordfence.
