Do you need deep packet inspection on a server-only firewall?
I have a server behind a firewall. It launches a web application (Java servlets under Apache Tomcat) and only responds to port 443 (HTTPS). Served pages have no scripting code. Forms use HTTP POST to receive a form, process the data (with appropriate input filtering), and then display an HTTP results page.
I am currently using a device firewall, but it is "hardware-flexive". I was looking at upgrading to more "industrial capacity", but the seller is pretty insistent that I buy a subscription to their "deep packet inspection" software. He argues that even web servers need such protection.
I'm not sure, but I have no confidence in security. The firewall will sit between the "world" and my server and use "port forwarding" to only allow access to ports 443 and 22 (for service).
So - do I really need this deep batch control or not?
source to share
Given that the only protocols you are interested in (ssh and https) "negotiate encryption on connect", not only will the standard firewall be able to check after this point. After the SSL / SSH session is established, the firewall will only see encrypted packets. Ask your supplier what their product considers in this context.
Alternatively, it is possible that the device acts more like a proxy - that it acts as a server side endpoint to connect before being sent to your real server - in which case it is possible that the product is doing something deeper, although this is not if the firewall really is "port forwarding" as you say. Again, your supplier should be able to explain how their device works.
Also, you might ask what vulnerabilities / risks the inspection system is designed to protect. For example: does SQL injection look? Is it targeting a specific platform? (For example, if your web server is running on a SPARC processor, then there is a little dot checking urls for x86 shell code).
source to share
As a network security professional, this sounds like overkill to me.
Martin Carpenter's answer to the target is 100%. Anytime you consider security, you need to understand
- What do you provide,
- What are you protecting from him,
- Attack probability and
- Your risk if the attack succeeds.
For your application that only allows encrypted authenticated communication on only 2 ports, I only see a few vulnerabilities:
- Denial of Service (DOS) is always a threat if your firewall does not block these attacks.
- You may have other applications listening on other ports, but you can detect them with any simple port scan program.
- You might want to restrict outbound communication so that a rogue user or application does not initiate communication with an unauthorized server.
I also agree that it is a good idea to ask the salesperson what "deep packet inspection" means to them, and why your particular situation requires it. If you don't get a specific, knowledgeable answer, in layman terms that makes sense to you, I would go elsewhere. There is nothing about network security that cannot be explained simply without prompting.
source to share
Updating on multiple fronts ...
Firstly - I now have reason to believe that some of the coolness of the OTS hardware product is a combination of a low-power processor and insufficient buffer memory. For several weeks of logging and several crashes, there are no logs before the crash, but I am logging everything according to the log control. Speaking with another firewall vendor, it was pointed out that it might suggest that the buffer fills up faster than it might empty during heavy use. This is consistent with the findings - the most commonly used IP is the most common mistake.
So I checked and some deep packet control was enabled in the firewall. I turned it off to make sure everything got better.
The main purpose of the firewall in my network scenario is the gatekeeper. That is, I want the firewall to deny all EXCEPT http, https and some ssh traffic from leaving the WAN port. Since there are no users in the firewall, any traffic generated from inside comes from my application and can be allowed.
Further negotiations with one seller showed that they no longer needed a thorough inspection of the packages - the other guy was just trying to "lift" me on the device in question. I also found that their equipment wouldn't do everything I want without spending a ton of money.
I am now seriously looking into using OpenBSD and the PF firewall to do what I reauire in a cost effective way.
source to share