Scanning Problems through a Firewall

Vulnerability assessment scanning through a network or host-based firewall can create an unknown level of complexity, uncertainty into the quality of scan results, and a change control process that essentially decreases the security posture of the network and / or host in order to perform a vulnerability assessment scan.

Prior to Windows XP SP2, network-based vulnerability assessment worked on a default system build using credentials. This Service Pack included a Windows Firewall that was turned on by default and blocked credentialed based scans by blocking Windows File and Print Sharing by default. With the advent of Windows Vista and Windows 7, key services required for a credentialed-based network scan were also turned off by default. These included Network Access enumeration to either the Classic Model or Guest account and the deactivation of the Remote Registry Access Service. Both introduce additional challenges and settings that needed to be modified on top of scanning through the host firewall. When all of these settings are set correctly, you effectively need to decrease the security posture of the asset and increase its exposure in terms of risk in order to perform a network based vulnerability assessment scan.

Many organizations require these changes for other tools and other operational functions and it does not present a challenge. Other organizations have taken a stronger stance on security when deploying desktops and will not make these changes since they violate best practices for a hardened host. Even on critical servers that may be forward- facing or in the DMZ, these changes are not acceptable. So, scanning through a firewall is just not possible and even null session scans will yield false negatives.

One possible action is to use a local vulnerability assessment agent to gather the information as a service and upload the results on a periodic basis to a management console. eEye's Blink solution will do this, as will the Retina Protection (without local antivirus or host-based firewall). While this is not ideal for everyone, it provides a simple and effective solution for mobile Windows devices, hardened desktops, and critical servers that cannot have the exposure of remote credentialed access or remote registry connectivity.

A more common approach is to use strict change control to allow scan windows into the target and then to harden the host again during normal operations. This requires using a solution that can apply these setting on the fly (versus just a GPO) or building a custom package that makes these changes from the command line and registry and deploys it using a standard software delivery solution. This of course increases exposure during the scan window, but does not require agents or decrease the security posture during normal operations. This technique is most commonly used for audits performed by the government and for regulatory compliance.

The second part of the problem is scanning through a network-based firewall. Let us first consider a NAT or PIX solution. Cisco PIX devices are limited to approximately 64,000 simultaneous connections by default. If you scan one target through a PIX Firewall, using All Ports and full TCP handshakes on each port, you will crash the Firewall since it will run out of connections. Juniper devices allow approximately 260,000 simultaneous connections and fail after 4 targets. Since a standard vulnerability assessment solution can scan much more than 4 targets at a time, assessments through a PIX Firewall or even a NAT device will typically abend the device, cause an outage, or multiple false negatives. This type of scanning is therefore never recommend.

The other scenario for a network firewall connects two routed networks. This presents a challenge when any rule blocks a scan. To make sure this type of inline device works correctly, and performs well, a new rule should be added and placed at the highest priority (i.e. #1 in the list). This rule should allow the vulnerability assessments scanner’s source IP to communicate with the foreign network for every port and protocol in the target range. This is essentially a One to Any Rule with no restrictions. This assures that the traffic from the scanner is processed only by one rule (versus evaluating the entire list and consuming firewall resources) and the performance is optimized for time- sensitive audits. As long as the firewall has no IPS or packet shaping features, the scan will work correctly.

Continue learning about systems hardening best practices.