Scan Interference

January 18, 2019, James Cox, Support Analyst, CoalfireOne Scanning Services, Coalfire

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.

James Cox

Author

James Cox — Support Analyst, CoalfireOne Scanning Services, Coalfire

Recent Posts

Post Topics

Archives

Tags

2.0 3.0 access Accounting Agency AICPA Assessment assessments ASV audit AWS AWS Certified Cloud Practitioner AWS Certs AWS Summit bitcoin Black Hat Black Hat 2017 blockchain Blueborne Breach BSides BSidesLV Burp BYOD California Consumer Privacy Act careers CCPA Chertoff cloud CoalfireOne Compliance credit cards C-Store Cyber cyber attacks Cyber Engineering cyber incident Cyber Risk cyber threats cyberchrime cyberinsurance cybersecurity danger Dangers Data DDoS DevOps DFARS DFARS 7012 diacap diarmf Digital Forensics DoD DRG DSS e-banking Ed Education encryption engineering ePHI Equifax Europe EU-US Privacy Shield federal FedRAMP financial services FISMA Foglight forensics Gartner Report GDPR Google Cloud NEXT '18 government GRC hack hacker hacking Halloween Health Healthcare heartbleed Higher Higher Education HIMSS HIPAA HITECH HITRUST HITRUST CSF Horror Incident Response interview IoT ISO IT JAB JSON keylogging Kubernetes Vulnerability labs LAN law firms leadership legal legislation merchant mobile NESA News NH-ISAC NIST NIST 800-171 NIST SP 800-171 NotPetya NRF NYCCR O365 OCR of P2PE PA DSS PA-DSS password passwords Payments PCI PCI DSS penetration Penetration Testing pentesting Petya/NotPetya PHI Phishing Phising policy POODLE PowerShell Presidential Executive Order Privacy program Ransomware Retail Risk RSA RSA 2019 Safe Harbor Scanning Scans scary security security. SOC SOC 2 social social engineering Spectre Splunk Spooky Spraying Attack SSAE State Stories Story test Testing theft Virtualization Visa vulnerability Vulnerability management web Wifi wireless women XSS