In this series of blogs I’m going to explore some of the use-cases for deep packet inspection on the network and types of devices that use it. I’ll also cover some of the common caveats for each specific definition and possible resolutions.
There are (at least in my estimation) three common(ish) use-cases for Deep Packet Inspection (DPI):
- Keeping bad guys out - using DPI to identify “bad” traffic on a Firewall or Intrusion Detection / Prevention system
- Making things go faster - using DPI to identify traffic flows that should given priority access to bandwidth, or are candidates for protocol optimisation/compression
- Trying to fix something - DPI is very useful when trying to understand when an application, or indeed an entire network is running slowly
There are of course overlaps, some network devices can use DPI to achieve all the above. If I’ve forgotten or missed any use-cases, I’m sure you’ll let know me know in the comments
As is my want, I’ll start with my own primary use case for DPI; keeping the bad guys out, but first it’s worth visiting some security fundamentals.
Trust in your network
A network of any size will usually have at least two zones of trust; Trusted (i.e. the internal network) and Untrusted (i.e. the dirty internet). Things start getting murky when you consider zones of partial or incomplete trust, such as guest Wi-Fi, links to 3rd parties, or Internet facing services. In most cases traffic between these zones of trust is policed by a common-garden firewall. Traffic that wants to be somewhere else is routed to the firewall network interface; a security policy is checked before the firewall forwards the traffic to it’s next hop. The policy is matched against the simplest parameters in standard IP headers; where it is coming from (source address), where it wants to go (destination address), and the apparent protocol (destination port). There are of course exceptions; some people use conventional servers as a security enforcement points and/or try and enforce security on layer-2 broadcast domains; but those people are mostly crazy. The non-crazy exception is when you need security between virtualized hosts, but that's a can of worms which I’ll come back to.
The Evolution of HTTP
Most security policies are straightforward enough; Allow this server access to the internet. Prevent the internet from telneting on to my core router; that kind of thing. Where it gets a bit trickier is when you need to start making policy decisions based upon something ambiguous such as HTTP. Allowing any group of users unfettered access to this protocol is right up there with dousing yourself in petrol and taking up chainsaw juggling. In a fireworks factory. In North Korea. With Courtney Love. This is because HTTP has evolved beyond it’s intended purpose into a transport that used for (from the top of my head): voice chat, video chat, text chat, email, large files transfer, Remote Desktops/Terminal Services, every flavour of Social media, and very occasionally, displaying a web page. The point is, allowing port 80 through the firewall in any direction (either from a group of your trusted users to the Internet or from the Internet to a server you have anything less that total ambivalence towards) is a sure-fire way of bad things happening. Whilst you can infer things like probable country of origin from the IP address or application in use from the headers, you are far from being able to establish intent, and whether the HTTP payload is actually something you’d want transiting your network.
In the next post, I’ll dig deeper into how DPI on firewalls can help you avoid the whole Petrol/Chainsaw/North Korea/Love paradigm.