A note on the Deep Packet Inspection requirements:
As far as the firewalls are concerned and their ability to do deep packet inspection, I want to be sure there is a clearly defined requirement here on exactly what that is and what capabilities it needs to have. There are plenty of vendors promising the world but few are actually specific on what their inspection consists of. I think it’s easiest to explain some of my frustration with an example of inspection outside of a firewall (note that I am not suggesting we should or should not use this method, it is simply a case for demonstration):
I have a web service of some sort, let’s call it a forum, hosted at https://forum.podunk.com which is a node.js webserver of some sort. It sits behind a firewall that does not do anything but stateful inspection and protocol analysis, and I wish to add deeper inspection to it. I add an NGINX reverse-proxy, load the certificate for forum.podunk.com on the proxy, and have it connect to the node.js server using an internal-only certificate pair that is unique to the proxy and web server. I add ClamAV and hooks with the NGINX configuration for it to scan and forward anything sent via POST. I add rules to NGINX such as:
# deny access to base64 encoded urls
location ~* "(base64_encode)(.*)(\()" {
deny all;
}
in order to catch obvious attempts at exploiting common vulnerabilities. I additionally configure Fail2Ban to watch NGINX logs and ban the ip addresses of offenders. These logs could also be collected and sent to a SIEM of some sort. A quick summary of work:
- Replaced a potentially less secure webserver (node.js) with a server that I have more trust in handling edge traffic (NGINX)
- Inspected the actual HTTP requests, and parsed out attempts at exploits
- Inspected incoming content against viruses and malware
- Responded to malicious intent with firewall rules (Fail2Ban)
- Logged the events for analysis
Each of these is also clearly defined. Any rules I add to NGINX to intercept are there to see. What gets passed to AV and what it looks for is also defined and available to me. If there is a threat out there that I want to know if I am protected against, I can look at my configuration and be able to tell you if it is protected or not. It is definitely doing something to protect a system, and it is definitely doing something that should be considered ‘deep packet inspection’, but does this fulfill the requirement? Now for a firewall example
We can tell from the requirements to set up a similar setup that at least some level of work is being done, based on this example for Fortinet:
…but what exactly is being done here? Is it simply a more secure web server? Is it actually looking for exploits in the request, and if so, which? Is the onboard virus scanning facility utilized, and under what conditions? Given this firewall’s capabilities it seems unfathomable that if it detected SOMEthing it would not at least have the ability to block, or not log the event, but under what circumstances?
It isn’t my desire to put down any commercial NGFW product here. The self-built protection example is obviously fairly complex, and it would be very nice to not have to setup something like that for every service offered. The questions I am asking do, in fact, have answers, whether we know them or not. Where the problem lies is with the requirements, and when I am trying to scope out whether or not a product is suitable I need to know exactly what form(s) of protection are desired for each service that is being hosted. The example cited was for HTTPS services, which is almost guaranteed to be available in any product, but what about something like SSH or IMAP or FTP? Is it enough to say that if the firewall has some mechanism for that protocol to ‘protect’ it, that is enough for our purposes, whether that protection is clearly defined or not? And if that is NOT the case, what specific protections must the firewall have?
Additionally, I would ask what the purpose of outbound DPI would be in this case. There should not be anything considered a ‘user’ going ‘out’ on the inside of the firewall, there will be traffic headed out to various repos for software updates, and certainly traffic headed via secure link to other sites, but how much other traffic is there actually? Can what traffic there is be defined well enough to restrict via stateful inspection, without compromising PKI? There may even be some services (a container that is frequently re-downloaded) where adding certificates to the root store may be extremely difficult to do.