If you are running external vulnerability scans against hosts that are protected by a perimeter firewall that includes next-generation features, typically referred to as NGFW, chances are you're doing it wrong. Here's why.
Typically when using an NGFW product, some form of Intrusion Prevention capability is available. Even some firewalls that aren't considered "next-gen' have basic capabilities that will automatically add external host IP addresses to a "block list" if suspicious activity is detected coming from this host. NGFW capabilities can be as simple as the detection of port scans or as complex as advanced exploit monitoring and blocking. These are great features that, in most cases, should be enabled. But when these features are applied to traffic coming from your vulnerability scanning tool the result is completely invalid vulnerability scanning results.
How can that be? Well, first think about the purpose of vulnerability testing. Actually, there are a few purposes. Of course you want to understand what vulnerabilities an attacker might be able to detect and take advantage of. But, more importantly, you want to understand all of the vulnerabilities that actually exist on the target hosts that might be exposed via the ports that are made available on the target host. Running scans against a host with NGFW capabilities enabled does not accomplish the latter.
Typically when using an NGFW product, some form of Intrusion Prevention capability is available. Even some firewalls that aren't considered "next-gen' have basic capabilities that will automatically add external host IP addresses to a "block list" if suspicious activity is detected coming from this host. NGFW capabilities can be as simple as the detection of port scans or as complex as advanced exploit monitoring and blocking. These are great features that, in most cases, should be enabled. But when these features are applied to traffic coming from your vulnerability scanning tool the result is completely invalid vulnerability scanning results.
How can that be? Well, first think about the purpose of vulnerability testing. Actually, there are a few purposes. Of course you want to understand what vulnerabilities an attacker might be able to detect and take advantage of. But, more importantly, you want to understand all of the vulnerabilities that actually exist on the target hosts that might be exposed via the ports that are made available on the target host. Running scans against a host with NGFW capabilities enabled does not accomplish the latter.
Typically, as soon as an NGFW product detects suspicious traffic from an external host, some sort of evasive action is automatically carried out by the firewall. So, when an external host seems to be running a port scan against my web server, the source address is added to a block list for a period of time. Until that time expires, any new traffic from that host will automatically be denied. Some of the NGFW products will detect specific streams of traffic that match a signature for exploit traffic and block only that traffic. In both of these cases, if these automated actions are carried by the firewall on traffic that is coming from your vulnerability scanning system then your scanning system is not able to execute all of it's tests agains the destination. And most vulnerability scanning products will just continue to try and run their tests, but will stop receiving responses from the destination host. And these scan tools aren't smart enough to inform you that the scan didn't actually complete. The scan results look pretty clean. But they are also incomplete and invalid.
Sure, scanning this way confirms that the IPS features of your firewall are functioning. But that's not the most important reason to run vulnerability scans. Again, the primary reason for doing scans is to understand all of the vulnerabilities that actually exist on the target hosts that might be exposed via the ports that are made available on the target host. If you want to continue to run a set of scans to validate the effectiveness of your IPS features, that's fine. But you must run a set of scans with these IPS features disabled for traffic from your scanning solution for a vulnerability scan to actually complete and be considered valid. The only thing your firewalls should be doing for this vulnerability scan traffic is stateful firewall services. As a matter of fact, if you run PCI scans using an ASV, PCI DSS requires that IPS capabilities be disabled during PCI scans.
The best way to accomplish this is to "white list" the source addresses for your vulnerability scanning solution on the firewall so that the IPS capabilities, or any other blocking capabilities other than standard stateful firewall blocking, are not applied to this vulnerability scanning traffic. While you're at it you may as well also limit the logging of this traffic. Vulnerability scanning generates lots of firewall logs that are useless.
Sure, scanning this way confirms that the IPS features of your firewall are functioning. But that's not the most important reason to run vulnerability scans. Again, the primary reason for doing scans is to understand all of the vulnerabilities that actually exist on the target hosts that might be exposed via the ports that are made available on the target host. If you want to continue to run a set of scans to validate the effectiveness of your IPS features, that's fine. But you must run a set of scans with these IPS features disabled for traffic from your scanning solution for a vulnerability scan to actually complete and be considered valid. The only thing your firewalls should be doing for this vulnerability scan traffic is stateful firewall services. As a matter of fact, if you run PCI scans using an ASV, PCI DSS requires that IPS capabilities be disabled during PCI scans.
The best way to accomplish this is to "white list" the source addresses for your vulnerability scanning solution on the firewall so that the IPS capabilities, or any other blocking capabilities other than standard stateful firewall blocking, are not applied to this vulnerability scanning traffic. While you're at it you may as well also limit the logging of this traffic. Vulnerability scanning generates lots of firewall logs that are useless.
