In my last blog, I introduced some of the basics of network security and why enforcing traffic on the standard source port isn't enough to determine what’s in a payload. I've talked mostly about port 80 and HTTP, but the ports associated with DNS (UDP 53) are also often abused.
In the context of firewalls, Deep Packet Inspection (DPI) is often the first line of defence against port tunnelling or applications that obfuscate their intent. Different security vendors call it different things, but the differences amount to marketing and implementation. Firewall DPI looks beyond the simple source/destination/port three tuples and attempts to understand what is actually going on. There are two ways this is commonly achieved, protocol anomaly detection (PAD) and signatures checks.
Protocol Anomaly Detection
Commonly used protocols usually have an IETF RFC associated (the ones that don’t tend to be closed implementations of client/server apps). Each RFC defines the rules that two hosts must follow if they are to successfully communicate. As an example the specification for HTTP 1.1 is defined in RFC 2616*. It lays out the standard actions for GET, POST, DELETE etc. PAD inspects the traffic flowing through the firewall (or IDS device, for that matter) and compares it with a literal definition of the RFCs (plus any common customizations). If TCP packet contains a payload of HTTP but is using the ports typically associated with DNS; then clearly something is amiss. With PAD enabled, some applications that attempt to tunnel using any open port (Skype and VPN clients are common culprits) may be stopped by the firewall. Additionally, it prevents some vendor-implementation attacks. For example, if bounds checking isn't properly implemented a malformed string may cause a process to crash; or arbitrary code execution. A nice, tight, PAD engine should pick this up and protect a vulnerable server. Code Red was the classic example and to this day, very occasionally, I see a match signature match in my firewall logs as some lonely, un-patched IIS server trawls the net looking for someone to infect..
PAD has it limitations though;
- Some protocols change often and are not that well documented; valid traffic can sometimes be blocked by an out-of-date or too restrictive implementation of PAD
- It’s not that hard to write an application that appears to confirm to the RFC but still allows the exchange of data
As result, PAD is often combined with another common defence; protocol signatures.
Protocol signatures are analogous to desktop AntiVirus signatures. Every time something “bad” is detected (lets take Heartbleed as a recent example), security vendors scramble to create a pattern that matches so it can be identified and blocked. I've written about this elsewhere before, but signatures are also an imperfect measure of intention. There are often shades of grey (and no, there are not 50 of them, you filthy people) between what is definitely good traffic and definitely bad. But, it’s not all bad. As a side-effect, signatures can also be used to be provide fine control over the users web activities. This is not an accurate science, and vendor implementations vary greatly in what they can offer. For example, identifying Facebook over HTTP is straightforward enough, but blocking it outright is unlikely to win many friends, especially at the executive level. Apparently, a lot of business is conducted on Facebook so draconian policies are effectively impossible. As result, one has to disappear down the rabbit-hole of Facebook applications. Some vendors boast of being able to identify thousands of individual applications, but trying to establish a meaningful corporate security policy on each one would be futile. The best firewall implementations break it down into categories, and enable the creation of a policy along these lines:
- Permit Chat applications, but warn the user they are logged (and not just by the NSA)
- Block Games outright, except after 6pm
- Otherwise Allow Facebook
This is not perfect, and indeed determined users will always find a way past, but it might deter that idiot in Sales from abusing his ex-girlfriend in Accounts on company time and equipment.
In most cases, both PAD and signatures are enabled on the firewall. Signatures are good for identifying stuff that is known to be bad, whilst PAD can mop up *some* of the unknown stuff and prevent some protocol tunnelling attacks.
For my next post, I’m going to move onto the “Making things go faster” aspects of DPI. Edit: Sorry, after the popular vote I've covered the security limitations of DPI. Plenty more to come!
* During the research for this post I discovered that RFC 2616 is essentially deprecated have been rewritten as a series of more precise RFCs, 7230-7235. I stumbled across this blog by one of the revision authors, so I thought it would be nice to share.