A really tricky issue with DPI is how to avoid port checks inside the code while making sure the code doesn’t produce false positives. For example, it’s not possible to reliably detect data transfer connections in FTP. If one doesn’t add port 20 to the equation, it’s not possible to detect those transfers properly. That’s just one of a couple of cases where one is inclined to use the port-based approach to make the detection more reliable. But here comes the kicker: It makes hiding traffic easy while also providing the administrator with a false sense of security.
An interesting finding was presented in the Modern Malware Review by Palo Alto. They realised that networks tend to have port 443 opened unconditionally, because SSL/TLS is not eligible for higher layer policy enforcement while it is also integral for the organisation’s workflow. If we translate this to what a DPI engine could assume, then it would mean: consider all traffic through port 443 to be HTTPS traffic. That’s most likely not a brilliant approach. Let me explain why.
Someone else might think the following: ‘Great, we have HTTPS detection. I better write a rule that does not allow HTTPS for ports 1-442 as well as 444-65535 to make our network more secure.’ The fallacy is imminent: the DPI engine can only detect HTTPS on port 443. The same holds true for most other common protocols, e.g. DNS, SMTP, FTP, etc. The use case would be to catch undesired behaviour on non-standard ports, but one cannot catch it because it cannot be described as a rule, because the DPI makes rule decisions of its own already. The rule itself cannot produce hits, because the joined conditions are impossible.
I usually deal with this issue in one of three ways:
- Keep the DPI as sharp as possible on the data stream so that IP addresses, port numbers or other statistical properties of the flow do not override the capabilities of the rules engine.
- Exclude well-known ports of other application in offending protocols instead of including well-known ports in the target protocol.
- And if all else fails, don’t provide a DPI detection.
Number two is a big compromise. Eventually, it is better to go with either of the two other ways. Find a clever way to make the detection work or reliably say “I don’t know”, while still providing the administrator with the means to transparently deal with this problem in a port-based fashion.