Do you require deep packet inspection on a server-only firewall?

Question

I have a server behind a firewall. It runs a web application (Java servlets under Apache Tomcat) and responds only to port 443 (HTTPS). There is no scripting code in the pages served - the forms use HTTP POST to receive the form, process the data (with appropriate input filtering) and then output an HTTP result page.

I am currently using an appliance firewall, but it is 'hardware-flakey'. I have been looking at upgrading to a more 'industrial strength' solution, but the vendor is quite insistant that I purchase a subscription to their "deep packet inspection" software. He claims that even web servers need this kind of protection.

I am not convinced, but do not have the security background to be certain. The firewall would sit between the "world" and my server, and use "port forwarding" to allow only ports 443 and 22 (for maintenance) to reach the server.

So - do I really need this deep packet inspection, or not?

Answer 1

Given that the only protocols that you're interested in (ssh and https) are "negotiate encryption on connect" there's little that a standard firewall will be able to inspect after that point. Once the SSL/SSH session is established the firewall will only see encrypted packets. Ask your vendor what their product examines in this context.

Alternatively, it is possible that the device acts more like a proxy -- that it acts as the server-side end-point for the connection before relaying on to your real server -- in which case it is possible that the product does something deeper, although this isn't the case if the firewall really is "port forwarding" as you say. Again, your vendor should be able to explain how their device operates.

Also you may want to ask what vulnerabilities/risks the inspection system is intended to protect against. For example: Does it look out for SQL injection? Is it targetted to a particular platform? (If your web server runs on a SPARC CPU, for example, then there's little point inspecting URLs for x86 shellcode).

Answer 2

As a network security professional, this sounds like overkill to me.

Martin Carpenter's answer is 100% on target. Anytime you're considering security, you need to understand

• What you're securing,
• What you're securing it against,
• The likelihood of an attack, and
• Your risk if an attack succeeds.

For your application, which allows only encrypted, authenticated communication on only 2 ports, I can see only a few vulnerabilities:

• Denial-of-service (DOS) is always a threat unless your firewall blocks those attacks.
• You might have other applications listening on other ports, but you can detect them with any simple port scanning program.
• You may want to restrict outbound communication to prevent a user or rogue application from initiating communication to an unauthorized server.

I also agree that it's a good idea to ask the vendor what "deep packet inspection" means to him and why your particular situation requires it. Unless you get a specific, knowledgeable answer, in layman's terms, that makes sense to you, I'd go elsewhere. There's nothing about network security that can't be explained simply, without buzzwords.

Answer 3

Update on several fronts...

First - I now have reason to believe that part of the flakiness of the OTS hardware product is a combination of low-powered CPU and insufficient buffer memory. In weeks of logging and a few crashes, there are no entries in the logs before the crash, yet I'm logging everything according to the log control. Talking with another firewall vendor, it was indicated that may suggest the buffer is filling faster than it can empty during heavy use. This corresponds with findings - the most used IP is the one crashing the most often.

So I checked, and the firewall did have some deep packet inspection stuff turned on. I've turned it off to see if things improve.

The firewall's main purpose in my network scenario is "gate keeper". That is, I want the firewall to prevent all traffic EXCEPT http, https and some ssh from ever getting beyond the WAN port. Since there are no users inside the firewall, any traffic generated from the inside comes from my application and can be allowed out.

Further talks with the one vendor indicated that they no longer thing deep packet inspection is necessary - the other fellow was just trying to "upsell" me on the unit in question. I also found out their hardware won't really do all that I want without spending a ton of money.

I'm now seriously exploring the use of OpenBSD and a PF firewall to do what I reauire in a cost-effective manner.

Cheers,

-Richard