Scan Interference

What is scan interference?

Scan interference is best defined as when traffic from our scanners gets blocked, filtered, dropped, or modified in response to some sort of active protection system not recognizing our traffic. Once our scanners are flagged as an intruder, the client’s environment is no longer accessible, which causes the scan to fail. In order to ensure that reliable scans can be conducted, our scanners must be allowed to perform scanning without this interruption.

What can cause scan interference?

Active protection systems are most often the cause of scan interference. Examples of active systems that dynamically modify their behavior include, but are not limited to:

1. Intrusion prevention systems (IPS) that drop non-malicious packets based on previous behavior from the originating IP address (for example, blocking all traffic from the originating IP address for a period of time because it detected one or more systems being scanned from the same IP address)
2. Web application firewalls (WAF) that block all traffic from an IP address based on the number of events exceeding a defined threshold (for example, more than three requests to a login page per second)
3. Firewalls that shun/block an IP address upon detection of a port scan from that IP address
4. Next generation firewalls (NGF) that shun/block IP address ranges because an attack was perceived based on previous network traffic patterns
5. Quality of Service (QoS) devices that limit certain traffic based on traffic volume anomalies (for example, blocking DNS traffic because the DNS traffic exceeded a defined threshold)
6. Spam filters that blacklist a sending IP address based on certain previous SMTP commands originating from that address

What does scan interference look like on Coalfire’s end?

When investigating a failed scan, there are some key indicators that scan interference may be the reason for the failure. Some typical indicators of scan interference are: 

1. If the scan logs show extensive (100+) ports open on a single host 
2. If the scan logs show the scan successfully initiated, then lost connection and couldn’t successfully complete

If option 1 from above seems to be the reason for the failed scan, we will inform the client that the scan failed due to excessive ports being open on a host. This happens because the active protection system in place does not recognize our scanners, so it shows that all ports are open to confuse what it perceives as an attacker. Coalfire scanning IPs will need to be properly whitelisted before a successful scan can be run.

If option 2 seems to be the reason for the failed scan, we will inform the client that the scan started successfully but was unable to complete due to loss of connection. This usually means that our scanners were being disconnected on the client’s end somewhere. The client will need to run another scan and monitor the traffic on their end to see where our IPs are being disconnected.

What can I do?

The client should always make sure that the ASV’s scanners are whitelisted, so the scanners can have the access they need to scan the client’s environment. Whitelisting sounds less secure, but Coalfire (and most others in the ASV vendor community) find this as the most consistent way to get over this. If all IPs are properly whitelisted and there is still suspected scan interference, the client should then run the scan in question and monitor their traffic to see where the IPs of our scanners are being disconnected.