Understanding the Growing Need for Application Layer Filtering

Nearly all organizations with a presence on the Internet have put some type of packet-filtering firewall technology into place to protect the internal network resources from attack. These types of packet-filter firewall technologies were useful in blocking specific types of network traffic, such as vulnerabilities that utilize the RPC protocol, by simply blocking TCP and UDP ports that the RPC protocol would use. Other ports, on the other hand, were often left wide open to support certain functionality, such as the TCP 80 or 443 ports, utilized for HTTP and HTTPS web browsing and for access to SharePoint. As previously mentioned, a packet-filter firewall is only able to inspect the header of a packet, simply understanding which port the data is meant to utilize, but unable to actually read the content. A good analogy to this would be if a border guard were instructed to only allow citizens with specific passports to enter the country, but had no way of inspecting their luggage for contraband or illegal substances.

The problems that are becoming more evident, however, is that the viruses, exploits, and attacks have adjusted to conform to this new landscape, and have started to realize that they can conceal the true malicious nature of their payload within the identity of an allowed port. For example, they can “piggy-back” their destructive payload over a known “good” port that is open on a packet-filter firewall. Many modern exploits, viruses, and “scumware,” such as illegal file-sharing applications, piggy-back off of the TCP 80 or 443 ports, for example. Using the border guard analogy to illustrate, the smugglers realized that if they put their contraband in the luggage of a citizen from a country on the border guard’s allowed list, they could smuggle it into the country without worrying that the guard will inspect the package. These types of exploits and attacks are not uncommon, and the list of known application-level attacks continues to grow.

In the past, when an organization realized that they had been compromised through their traditional packet-filter firewall, the knee-jerk reaction common was to lock down access from the Internet in response to threats. For example, an exploit that would arrive over HTTP ports 80 or 443 might prompt an organization to completely close access to that port for a temporary or semi-permanent basis. This approach can greatly impact productivity as SharePoint access would be affected. This is especially true in a modern connected infrastructure that relies heavily on communications and collaboration with outside vendors and customers. Traditional security techniques would involve a trade-off between security and productivity. The tighter a firewall was locked down, for example, the less functional and productive an end user could be.

In direct response to the need to maintain and increase levels of productivity without compromising security, application layer “stateful inspection” capabilities were built in to the Forefront Edge line that could intelligently determine whether particular web traffic is legitimate. To illustrate, the Forefront Edge line inspects a packet using TCP Port 80 to determine if it is a properly formatted HTTP request. Looking back to the analogy we have been using, the Forefront Edge line is like a border guard who not only checks the passports, but is also given an x-ray machine to check the luggage of each person crossing the border.

The more sophisticated application layer attacks become, the greater the need becomes for a security solution that can allow for a greater degree of productivity while reducing the type of risks which can exist in an environment that relies on simple packet-based filtering techniques.