We needed to configure the Internet-facing firewall for a customer to block encrypted files such as protected PDF, ZIP, or Microsoft Office documents. We tested it with two next-generation firewalls, namely Fortinet FortiGate and Palo Alto Networks. The experiences were quite different…
Note that the Internet connection must be either unencrypted itself, i.e., HTTP or FTP, or some TLS inspection/MITM techniques must be used to look into those encrypted streams such as HTTPS. Otherwise no firewall can ever recognize what kind of files are transferred over those connections. For our test purposes we used some test files at http://testfiles.webernetz.net/. Since that webpage runs via HTTPS and plain HTTP we could run our tests without further security burdens. We tested a Palo Alto Networks PA-200 with PAN-OS 8.1.2 with threat version “8030-4788 (06/12/18)” and a Fortinet FortiGate FG-90D with firmware v5.6.4.
For each firewall we did two runs, one with plain documents and another with encrypted documents. We downloaded four different document types in this order: docx, pdf, xlsx, zip. For every download we initiated a new HTTP session in order to have them distinguishable (different source ports). Before those tests we configured a “File Blocking” (Palo) and a “Data Leak Prevention” (Forti) profile in order to block encrypted file types:
The Palo Alto Networks firewall correctly identifies the four plain documents as seen in the “Data Filtering” log section. Depending on the file type a couple of different log entries are generated, though I downloaded only one document at a time. (I really do not know why the last run, source port 4025, in which I ONLY clicked the zip file also shows a download of the docx and pdf file. Maybe this is kind of a pre-download from the used Firefox 60.0 browser?)
Coming to the encrypted files, Palo Alto Networks does not recognize them correctly anymore. Bad. The two Microsoft Office files (docx, xlsx) are only detected as “Microsoft MSOFFICE” but not as “encrypted-docx” or “enrcypted-xlsx”. Note that I configured a “File Blocking” profile to block exactly those file types. Not working! At least the encrypted PDF and zip file is correctly identified:
We opened a ticket at the support portal from PAN. After some troubleshooting they admitted that it’s not working. Hence, it is not a configuration error on our side, but a security malfunction. Bad design or whatever.
No problem with the plain documents as well. All four types are correctly identified by the FortiGate:
And the same is true for the encrypted file types: All four encrypted documents are correctly identified as Filter Type “encrypted” by the FortiGate, and denied as per policy configuration. Good!
This one clearly goes to Fortinet. Palo Alto Networks fails at least for two out of our four test documents. To my mind it’s not excusable for a firewall that has “encrypted-docx” or “encrypted-xlsx” file types is not able to detect them at all. What’s up guys?
By the way: This was not the first time I struggled with the file blocking by PAN. Have a look at this blogpost from 2013: Palo Alto File Blocking: Benefits and Limitations.
In the meantime Palo Alto has updated its threat database detection to recognize encrypted office documents again. Nice. Beginning with version 8042 it detects an “Encrypted Microsoft Office 2007 File” when an encrypted docx or xlsx flies by. Following is the same test run as already posted above, tested with threat version 8047. You still have two log entries for each downloaded file:
Note that you MUST use the “encrypted-office2007” file type within you file blocking profile to get those files detected. You MUST NOT use the “encrypted-xlsx” or the like file types since they still don’t work. You can not differentiate between “encrypted-docx” and “encrypted-xlsx” – the Palo simply detects an encrypted Office 2007 document. Still not exactly what the file types imply but at least it brings back the possibility to block those encrypted office docs at all, such as shown in my screenshot. Thanks for that!