What is IP whitelisting? Why do you want us to whitelist you against our WAF/IPS?
When we perform penetration tests and vulnerability assessments, we often ask clients to whitelist our source IP addresses. This allows us to be unfettered in our interactions and assessments of a client’s server. We request this to accomplish the following:
- a) To aid the client in recognizing and differentiating the network traffic we generate during a test
- b) To ensure our testing is not blocked by an intrusion prevention system (IPS) or web application firewall (WAF).
Some clients wonder why we take this approach, since it may seem to not replicate a “real attack.” The answer is found in comparing our approach to that of a real attacker. We are performing an assessment with time and resources that are all fairly limited when compared to the resources and time available to an average attacker. The paradigm of a penetration tester is fundamentally different, and therefore requires a more nuanced approach..
Most attackers are unlikely to run an off-the-shelf vulnerability scanner targeting one small set of IP addresses in a focused fashion. Instead, most attackers have a handful of useful exploits that work very well against systems with specific configurations, and are thereby forced to cast a broad net. They might use clever Google searches, Shodan scans, or use a network of compromised computers (“bots”) to scan the entire Internet for systems that exhibit a specific vulnerability. Additionally, our clients’ servers might receive only a handful of probes from an attacker over a spread out period of time on the basis that intruders hope to surveil targets while maintaining a low profile. In assessing a target, attackers work to carefully control their interactions with a target in hopes of reducing the likelihood that they trip an IPS/WAF and become blacklisted from communicating with their target. All-in-all, there are many attackers out there, looking for many different kinds of bugs over long periods of time. Finding the target that fits a given toolset and vulnerability profile is a task in and of itself.
Similarly, if the attacker gets lucky and finds a system that is vulnerable and the client’s IPS/WAF doesn’t have a signature to block that specific attack, then the attacker is likely to breach the application/network perimeter. Any heuristic-based filtering that an IPS performs would not be very effective in this scenario. Additionally, if a client’s servers have weaknesses in the areas of communications security, then an IPS/WAF won’t be effective. Furthermore, many examples of IPS bypass techniques exist, and many vulnerabilities are published without a fix available. For security vendors who develop these devices, this most closely illustrates the motto “You cannot fight what you cannot see”. Ultimately, these devices can certainly block a number of common attacks, but you can’t rely on them as your only form of perimeter security.
In addition to the potential shortcomings related to an IPS/WAF, we also want to understand what vulnerabilities might exist behind the IPS/WAF in case the signatures are ineffective or non-existent. In the context of the security assessment, we need to do this in a limited time window with limited resources. This is very different from an army of attackers randomly scanning for specific bugs across the entire Internet. This is why we always ask to be whitelisted in these active defense devices. Behavior-based blocking not only slows down our scans, but it also makes them less reliable. Once again, it is a standard practice in pentesting, particularly in network pentesting, to whitelist the scans and it provides our clients with much more value for the time invested.