Why Should I Whitelist the Pentester’s IP Address?
Before we start any engagement, we like to go over a document that lists all of the Rules of Engagement (ROE) for the upcoming penetration test. We cover things like making sure you have approval from your cloud provider, when status updates will be sent to the client, and how time sensitive and critical issues we discover will be handled. Most of these, as you would expect, go over without many questions. However, one of the ROE items we discuss that usually gets a fair amount of conversation is a list of our IP addresses for whitelisting in your intrusion prevention system (IPS). After all, many clients want to know why they should whitelist the pentester’s IP address. Isn’t that cheating? And to be clear, I can see where this is coming from. After all you wouldn’t whitelist a hacker’s IP address, right? There are several reasons why you should whitelist the pentester’s IP address.
First, What Do We Mean By Whitelisting?
I don’t want to gloss over this in case someone reading this isn’t entirely sure what we’re talking about at this point. Whitelisting, in general, is to allow something by exception where everything is denied by default. Oftentimes, this is used in the context of a firewall, for example, where certain traffic is allowed to enter your network through a whitelist approach and all other traffic is blocked. The concept is similar for an IDS/IPS. If malicious network traffic is identified, it will block the sender’s IP address from communicating with the hosts it is protecting for some period of time. So we request that you whitelist our testing IP addresses in your IPS device, such that malicious activity it detects from us will be logged but our IP address will never be blocked. Let’s discuss the reasons why you should whitelist the pentester’s IP address, and then discuss some workarounds.
Reasons to Whitelist the Pentester’s IP Address
1. Time
The main reason why you should whitelist the pentester’s IP address comes down to time. An attacker, especially a smart and/or dedicated attacker, is going to take their time and only try a few things a day to avoid detection. After all, if they get caught, they are worried about going to jail. Penetration tests, by contrast, are sold primarily by the number of hours it will take to complete. Additionally, the pentester is trying to abide by a schedule that has been set and agreed to. Because of this, the pentester is usually not worried about being noisy, they are more worried about finding all the vulnerabilities on your network in a set amount of time. Naturally, the more noisy the attacks that are launched, the more likely your IPS will detect them and block our IP address.
2. Thoroughness
The second reason why you should whitelist the pentester’s IP address is because the pentester needs to be thorough. To better explain this, let me use an example from a recent penetration test I performed against a hospital. At the beginning of the penetration test, I was working on trying to achieve domain administrator and gain access to the sensitive information, in this case patient data. I did a few specific and targeted attacks against some older systems I noticed and was able to achieve those goals. Great! Screenshots and ready for the report! But not quite, because as a penetration tester, I do not have the same goals as an attacker necessarily. An attacker is only interested in finding one way in, and then exploiting and looting. A penetration tester is focused on giving your organization a better understanding of the risk. That includes finding all the ways in. So in this example, I had top-level permissions, but went back to the starting line and launched a vulnerability scan to try to find other systems on the network. The vulnerability scan is a very noisy tool, and naturally got caught by the IPS, which consequently blocked my system. It took several calls to explain to the client that I was already a domain administrator and I am just trying to give them the most comprehensive view of their network possible.
3. Evasion
The last reason we will cover is evasion. The way IPS works is similar to an antivirus solution in that, for the most part, it is based on signatures. It is looking for a specific signature, or indication of an attack, and then will block that traffic accordingly. So for example, it may be looking for a cross-site scripting attack that looks like this: <script>alert(1);</script>. If it sees something like that, it will block it to prevent the attack from working. However, just like antivirus, there are ways to evade this detection. This includes things like changing the characters to their respective html codes (A). There are many ways to evade an IPS or Web Application Firewall (WAF), many of which are explained here: OWASP Cheat Sheet for XSS. During a penetration test, if we notice we are getting blocked, we will of course try a number of combinations to try to evade being blocked. However, as this is a mostly manual process, there is a good chance we won’t be able to evade during the course of a time-limited engagement. This gives a much higher likelihood that some vulnerabilities may not be found and later, whether by luck or skill, an attacker may find a way to evade these controls and exploit the vulnerability anyway. That’s why during a penetration test, we are really trying to thoroughly test the security of the underlying application or network, but not necessarily the signatures on your IPS.
Alternative Options
Having discussed several reasons why it is important to whitelist the pentester’s IP address, let’s talk about several alternative approaches you can take if you do want to test the effectiveness of your IPS.
1. Detect but Not Block
First and foremost, in our rules of engagement request, we ask that you set your IPS to detect only mode for our IP addresses. This means you will be able to see whether your IPS recognized the attack, without actually stopping us from performing our test. This, in our opinion, is the best option because you are getting a thorough test, while still seeing if your IPS would have stopped us as a matter of defense-in-depth.
2. Turn on IPS at the End of the Test
Another option is to whitelist the pentester’s IP address and let them complete the engagement. Then, request that the engineer do a quick check at the end of the test with the IPS in full block mode. This will allow the test team to find all the vulnerabilities, while still allowing the client to see the blocking in action. This will have an effect on the time allotted for the test, so if you choose to go this route, bring it up as early in the process as possible so the test team can leave adequate time for this activity.
3. Red Team Engagement
As a final option, if you really want to leave the IPS turned on, we would recommend you switch the test to a red-team engagement rather than a traditional penetration test. During a red-team engagement, the penetration tester is focused on emulating an attacker and trying not to get caught. This means they will go slowly, try to evade all the protections you have in place, and use all available means that an attacker would (wireless, social engineering, physical penetration, etc.). This type of test is less focused on being holistic, and is more focused on breaking in without being detected. As such, this is primarily for clients who have had penetration testing performed previously and have a mature security program.
