How IDS and IPS Can Affect External Penetration Testing

One of the most common information security services TraceSecurity provides is an External Penetration Test, given its value of assessing security risks and its ability to simulate a real-world attack. During external penetration testing, an information security analyst (ISA) reviews and tests the ports and services available on the organization’s external network. These are the ports and services that would be visible to anyone on the public Internet. When scoping these assessments, the ISA will typically ask that the organization’s source IP addresses are whitelisted in any Intrusion Detection System (IDS) or Internal Prevention System (IPS) for the purpose of providing a complete and accurate review of their external ports and services.

Defining Intrusion Detection and Prevention Systems
When an organization implements technical controls to detect and block malicious traffic, these might be hosted services, appliances, or features within other core network systems like a router or firewall. An Intrusion Detection System (IDS) identifies malicious traffic and reports it to the organization for review, typically without taking any automatic actions on its own. Sometimes, systems with limited automatic responses might be called an “active” IDS.

Likewise, a firewall that has this kind of capability might sometimes be called an “active” firewall. In function, these systems would fall under the definition of an Intrusion Prevention System (IPS), which would be capable of detecting malicious traffic and be able to take automatic responses such as blocking the source of that traffic. In this article, the term IPS will be used to describe any system capable of detecting and blocking malicious traffic.

It would seem obvious that an IPS is a vital part of an organization’s security program, given how useful it can be for preventing malicious attacks, particularly during the initial scanning and probing phases. In order to understand how this conflicts with a penetration test, we must look at how a penetration test compares to and differs from a real-world attack.

The purpose of a penetration test is to use real-world attacks against the organization’s available ports, services and systems. In this way, penetration testing and real-world attacks are extremely similar. The primary differences come into play leading up to the attack. In a real-world attack, a malicious entity would need to discover the IP addresses or ranges to target. In a typical penetration test, these targets will be identified during the scoping of the assessment. This allows the organization to ensure all of their IP addresses are being tested, and it allows the ISA to ensure that the organization is claiming ownership of these targets and have legitimately authorized scanning, testing and attacking of them.

Avoiding Detection with Targeted Scanning

An attacker may have much more time and opportunity to avoid detection or evade countermeasures such as having their source IP address blocked. One of the simplest and most common ways to avoid being detected and blocked by an IPS is to perform more targeted port scans. This might involve limiting scans to individual or small ranges of hosts or ports.

Targeted scanning as a way to find open ports on a system with a decreased chance of being detected is often a more realistic scenario because an attacker may be only looking for this one particular service or port in the first place. An opportunistic attacker looking to exploit HTTPS services that might be vulnerable to the OpenSSL Heartbleed bug or the SSL “POODLE” vulnerability might only be looking for TCP 443 services. In scenarios like these, targeted scanning is far more likely than an attacker scanning for any and all ports that one particular organization might have open. However, rather than targeting an organization specifically, an attacker could also be searching a large range of IP addresses for particular ports or services. For example, they may be looking for SMTP services that allow open relaying of emails.

Likewise, another method is to perform much slower scans. An attacker then has the luxury of scanning their targets at their own leisure. Targeted scanning or slower scanning would add significantly more time to the assessment, therefore requiring a greater cost which is why these methods typically aren’t used by ISAs during a penetration test.

Evading Blocks by Hiding Sources

Another method an attacker might use to avoid detection or evade a block is to hide their source address by using a proxy to perform their attacks or attacking with botnet clients. By doing this, an attacker would avoid disclosing their actual source IP address. Any prudent attacker would be doing this in the first place – if not for the purpose of evading blocks, at least to hide their source IP and identity. If the proxy address or botnet client they are using is detected and blocked, they could simply switch to another proxy or botnet client and resume their malicious activity.

Again, the first problem with implementing this tactic during a penetration test would be increased time and cost. This would also require additional resources. While an ISA could use a proxy service such as Tor to perform scans, these proxy addresses are often already associated with illegal activity, and the speed of these proxies can vary significantly.

Conclusion

The tactics described in this article are only examples of some of the more simple methods that could be used to avoid detection and blocking by an IPS. As useful as these systems and methods may be in preventing real-world attacks, they can also prevent a penetration tester from performing a timely, cost-effective, complete, and accurate review of a client’s available ports, services and systems.

The goal of an external penetration test is to ensure that all of the client’s externally available ports, services and systems have been fully and accurately reviewed. Whitelisting the ISA’s source IP addresses in any intrusion detection and prevention systems provides a means to simulate real-world hacker techniques like the ones described in this article. Otherwise, the ISA could be prevented from seeing a port or service that might be detectable by an attacker. If the analyst performing the penetration test does not see a particular port or service, it will not be tested, and it may not be discovered or reported as vulnerable. If the client is not aware the port or service is vulnerable, they cannot take any action to prevent its exploitation.