Log in

Site menu:



Site search

November 2021




It must have been the striking dearth of jargon that led the security industry to introduce a new term for an existing technology: High-Definition (or Next-Generation) firewalls want you to ask yourself the question: “Is the traffic on your network a wolf in sheep’s clothing?” In other words, let’s say you’ve configured your firewall to allow inbound HTTP (TCP port 80) to your web-server, but how do you know it’s really an HTTP client that’s connecting to it? Without deep-packet inspection, or application-level validation (App Firewall or App Proxy), you can’t.The typical threat that springs to mind is “bad-guy connecting to a web-server on port 80 (sheep’s clothing) and using that allowed connection to transport covert badness (wolf)”. It’s the traditional perspective of “we must build a strong perimeter to keep the bad guys out” that makes it simple to disparage the alleged disconnect between DPI and firewalls with the claim that “[deep packet inspection] has been limited to a small set of applications being run through an intrusion prevention system.” But what is the risk in this case? If it’s a real web-server listening on port 80, then it’s only going to be able to do web-server things (handle HTTP methods like GET, POST, HEAD, etc.). If the client tries sending something over the port 80 connection that is outside of the capabilities of the web-server (say an FTP put, or some sort of Remote Procedure Call), the attempt will fail because it will not be interpretable by the server. The exception would be if it were specially crafted payload designed to exploit a vulnerability, but if it were a “˜detectable’ attack (i.e. through signature, behavior, format/structure/content validation, etc.), it would be preventable by any competent intrusion prevention system (IPS) or deep-packet inspection (DPI) engine; if it were undetectable, it would be, well… undetectable.

So consider this simplified flow of events:

Five decision points, two points of potential risk. Risk susceptivity: 40%

Bottom line in this case is “Does the detection engine work?” (i.e. “can it accurately detect intrusions without a material occurrence of false positives or negatives?”) If the answer is “yes”, then DPI works wherever it is. If the answer is “no”, then it doesn’t work regardless of where it is. For some, a question might linger: “Why do we even need port-based access rules to govern access to the server – why not just use a next-gen firewall to configure an “˜allow only valid HTTP’ rule?” While this would mean “drop any traffic that is not HTTP, or that can be classified as invalid”, it would also mean “allow enough traffic through to enable the classification of HTTP, and then to determine the absence of invalidity”. Since the question itself implies a transcendence beyond dependency on port-based classification of traffic, the following simplified sequence might then have to occur:


Eight decision points, four points of potential risk. Risk susceptivity: 50%

While this is a dramatization, the point is not simply that there is greater risk for failure, it’s that the model is more complex (and thus more computationally costly) than it needs to be. But clearly, the web-server example isn’t the only use case. More interesting than the outside-in perimeter defense model is the inside-out or inside-inside models.

Inside-out would typically refer to hosts on a LAN accessing resources on the internet. In draconian firewall configurations, access might be limited to a couple of necessary ports like TCP 80, 443. Using port-based access controls without DPI, it would be simple to evade these controls through anonymizing proxies, tunneling, port-redirection, etc. Port-based access controls with DPI would allow for a rule that says “if you see traffic that is not HTTP/HTTPS on ports 80/443, then block it”, and this would catch traffic such as IM, P2P or unyielding Skype-like protocols running covertly over port 80/443 – but this still needs a port for classification. Without the port as a classifier, it would not be possible to determine whether traffic is masquerading, because there would be nothing defining what it shouldn’t be.

Inside-inside is a relatively new concept, not for the IPS, but for DPI based validation of traffic. IDS/IPS have been employed within networks for quite some time, seeking out malicious agents in the realm of the trusted, such as a PC infected with some sort of contagious malware. Historically, there hasn’t been much of a need to validate the traffic beyond “it isn’t an intrusion, it isn’t a virus, etc.” while on the trusted network. As NAC emerged as a new trusted network security model, so emerged the limitations of its early incarnations. The pre-admission control model evaluated hosts to determine their security posture before allowing them access to the network. Once access was granted, however, they could do as they wished – so if they managed to contract some badness once on the network (e.g. through the internet, removable media, etc.) then it was up to the IPS to handle things since the NAC platform had already done its job. Not a problem if the IPS solution was properly deployed and up to the task.

The problem, however, became evident through NACs exception model: since NAC largely depends on software agents for posture assessment, network devices unable to run said agents (e.g. incompatible OSs, printers, VoIP devices, switches/routers/firewalls, etc.) were excluded (by MAC/IP address, VLAN, etc.) from NAC’s enforcement. While this was fine in cases of legitimate device-after all, the current risk of a printer doing bad things is virtually non-existent-it was the illegitimate devices that were the problem. In a simple example:

1. A printer was granted an exclusion by its IP address and MAC address
2. Miscreant determined IP/MAC of the printer
3. Miscreant assumed IP/MAC of printer on laptop
4. Disconnected printer from network
5. Connected infected laptop to network
6. Miscreant played WoW while resident malware attempted 3,000,000 TCP 135 connections to random IP addresses, and sent 1 billion pieces of spam.

Of all the use-cases, the inside-inside scenario stands out as the one seemingly most in need of DPI for the purposes of validation. The kind of validation, though, is not “this application must only run on this port” but rather “this device should only be communicating using these ports and/or applications.” If anything, this suggests that DPI needs to be more tightly coupled to NAC. Since direct integration is precluded both by the multi-gigabit speed requirements of LANs, as well as by the understandable desire to maintain solution/component flexibility, perhaps the best model is a correlation API that can enable cooperative event and network intelligence sharing between devices on the without a compulsory dependency on an additional external platform like a SEIM.

Just about any IPS today can detect and classify port-hopping, productivity-robbing applications such as IM, P2P, and streaming media. The good ones can even catch notoriously tricky applications such as Skype and Winny. UTM platforms integrate these classification capabilities into the policy capabilities for which the traditional firewall is best known. When a UTM solution is well-architected, the result is a security platform that can:

  • Detect malicious traffic such as application-based instructions, viruses, and spyware
  • Accurately classify even obscured traffic application-by-application
  • Finely control traffic and applications with basic log/allow/deny rules, bandwidth management, or identity-based access methods.
  • Be managed centrally, and provide meaningful and actionable reporting on utilization

All while meeting the demanding performance and reliability requirements of today’s networks.

Share: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Twitter
  • Reddit
  • Slashdot
  • LinkedIn
  • Facebook
  • email
  • Print


Comment from adaswani
Time: 2008-01-07, 14:47

HD ? What next – Blue Ray ? Its rather amusing (or call it marketing ingenuity), to read that HD firewalls are out there indeed. Interesting post.

You must be logged in to post a comment.