Reason for me to write this blog entry is two fold, firstly typical Gartner statistics cited that by the year of 2009, 80% of enterprises will fall victim of application layer attacks (another handy marketing phrase for typical InfoSec consultants) secondly to discuss practicality and effective deployment to avoid possible false positive.
Why these application layer attacks are becoming prominent and successful? Simple answer is: application layer attacks are fundamentally designed to circumvent or bypass network centric controls that we have implemented over the past decade, such as port blocking using ACLs. Classic example to describe how attackers getting smarter than earlier; unlike those days attackers use “malicious propagating” rather than “botting” and planning a DDoS (yet most destructive attacks method). Most of emerging worms propagate by using security vulnerabilities in the HTTP protocol suit. Most leading Application layer FWs (such as Checkpoint Power with SmartDefence) allows detecting and blocking worms based pre-defined patterns.
Consider typical web application attacks, conventional firewalls protecting a web server by placing it in the DMZ and blocking all sort of ports but allowing tcp port 80 and 443. So what’s wrong with it? Sadly, traditional firewall can not distinguish desirable port 80 traffic from undesirable – malicious port 80 traffic. Imagine a SQL injection or long URL/Large header to overrun the buffer of a web server (many buffer-overflow attacks require a very large header to be sent to the web server). Arguably it’s a good security practice to limit the sizes of in HTTP request and response, this helps to reduce the chance for buffer overruns and limits the size of `code` that can be inserted into the header.
Application firewalls has the ability to perform upper-layer inspection of web traffic before it reaches the Web server. The devices are able to deep inspect request packets and analyze the nature and type of commands are complies with relevant RFC standard. For example, The HTTP RFC allows a restricted set of HTTP methods. However, even some of the standard methods are unsafe, because they can be used to exploit vulnerabilities on a web server. HTTP methods can be break into three sets: Standard safe (GET, HEAD and POST), standard unsafe and WebDAV. In Checkpoint NGx FWs with Smart defense technology by default, all methods are blocked other than the standard safe methods.
Sounds very complex and slow to deploy but application FWs have great potential. Even in the test environment I had to adopt a cautious approach, conducting careful analysis and extensive testing. It is amazing how easily would end up blocking legitimate traffic. It’s still painful and need careful consent with our web application developers and also to convince them that the technology will help the company more than it will hinder their day to day lives.
Finally and important strategy that can be adopted in deploying application layer FWs is to start with passive mode. Begin with monitoring without actually blocking any traffic. This will help you to get a better view. Before FW is actually put into active mode, lots of monitoring is a must. I’m sure you don’t want you e-comm server sending TCP reset packets to customers. We still have problems with new CISCO ASA FWs with AIP-SSM IPS module, which needs extensive testing in a fully loaded lab. These FWs acting as the border FWs and sit on top of CheckPoints. More importantly once the FW is deployed in the active mode, it should be watched very carefully with greater patient. Logs needs to be carefully scrutinized because that will tell you an interesting story. Record all blocked attacks and you could use them to justify ROI of company’s security investment. There will be always false-positive, and they need to be further analyzed perhaps with web developers to balance the security and the usability.
Compared to packet filters/statefull FWs, application FWs are not a panacea. You may have to use web/application vulnerability tools test your web/application servers exposures. Effective yet continuous web vulnerability management strategy and finely tuned application FW would definitely complement each other.
