Why IP-based rules are bad, but we still use it
One of the first decisions when architecting a Web Application Firewall is whether or not to add blacklists based on IP addresses. Even though building rules based on IP addresses is bad, it’s still the right approach for most scenarios.
Why is it bad?
IP addresses can’t be used to confidently identify a client and, therefore, we risk blocking the wrong users.
ISPs and corporate networks commonly put their clients behind NATs, so that they can make better use of their small public IPv4 address pool. Blocking all the clients behind an address in this situation means blocking several innocent users sharing the same address. For websites with a wide audience, expecting several concurrent connections from users on the same geographic location, this is extremely annoying: the bad behavior of one client might degrade the experience of all users behind that IP address.
Another scenario where blocking IP addresses is bad is when the attacker is routing its connection via proxies, like through VPN providers or Tor exit nodes. The concern here is different, as it’s not only about blocking innocent users. We are more concerned that we are playing whack-a-mole with the attacker: whenever we block one IP, they would just establish a new connection and obtain a new address. We might end up with a very ineffective blacklist, with tons of address that were blocked because of a single bad behavior, making them highly irrelevant.
Finally, the biggest concern of all: solely blocking IP addresses won’t do much to stop a successful attack. A client performing a targeted attack might not get blocked at all, as the IP address probably won’t be present on any blacklists. For Qaclana, like other WAFs, we plan to cover this by adding more “processors”, analyzing further details about the incoming request and comparing it with similar attacks.
Why do we still use it anyway?
Despite all the drawbacks, IP-based white and blacklists are very cheap and effective.
As an IP address is just an integer, blocking a range is only a matter of specifying the first and the last integer to block, making it very cheap to check if an IP address belongs to a white or blacklist.
For most websites out there, blocking an IP address that is used by a corporate network or a foreign ISP isn’t a big deal, especially if this blocking is temporary and the confidence that an attack is coming from a client behind this address is high.
Making the assumption that an IP address represents a client allows us to also build a “stateful” attack profile, gathering request data based on multiple interactions, particularly useful for automated attacks. Once an attack pattern is recognized, we have high confidence that a client behind this IP address has bad intentions.
While some filters might be quite fast to process a request, there are cases where network operations might be involved, such as looking up the IP on the Project Honey Pot. In such cases, it’s ideal to attempt to complete the processing within a target window of time and, if the operation times out, continue processing it in the background. The outcome of this check could result in a new entry in the blacklist so that the next time this client performs a request for our protected target, we know beforehand that this IP is in a blacklist.
Summary
For bigger websites, it might cause too much damage to block all the clients behind an IP address, so, more complex heuristics would be required to single out specific clients behind an IP address, but for small to medium websites, it’s very attractive to make use of IP-based rules. Qaclana implements this approach, allowing potentially time-expensive processing of requests with the efficiency of IP-based blocking.
What’s your take on this? Let us know via GitLab or chat room.
