Evaluation License - Coming from Palo Alto - Issues with URL Filtering / Application Detection

[belnea1]

Hi Everyone,

I'm having 10 years of experience with Palo Alto's. We make heavy use of their URL filtering and Application Detection.

In our environment it's not possible to decrypt any traffic, yet the Palo could block all URL's (based on SNI, certificate names etc) but here with the Fortigate Eval License it even refuses to block any webpage using the URL filtering - I've tried "youtube.com", whatsapp.com, facebook.com and none of these work and I'm refusing to believe that this isn't possible with a Forti without decryption. 

What I've done:

1. Security Profiles -> Web Filter -> Create New -> Checked URL Filter (Static URL Filter) and I've choosen Wildcard, Block, Enable for *facebook.com* / *whatsapp.com* and "*youtube.com*"
2. I've made sure the Filter is set in "Flow Mode" and hit OK.
3. Created a "Firewall Policy" under "Policy & Objects" that includes this Filter:
Accept, All, All, All, Flow-Based, Web-Filter checked and choosen, SSL-Inspection left on "no-inspection" and asked it to log all sessions.
4. Taking a test-client, and trying to access the pages in question: All of them are accessible. (Sometimes facebook is blocked, even though in the traffic log its shown as "facebook.de" - which shouldnt be blocked in this example).
5. I've checked the traffic is hitting the correct policy (in eval mode you can only have 3 policies, so its not that hard)

6. I've checked the forward logs and I've seen IP's that resolved to whatsapp and others but were allowed ("UTM Allow" or "Accept"). 

I absolutely need this to work reliable on any webpage - without decryption. Am I missing something obvious?
On the Palo we use this a lot - for instance to create a pop up captive portal, but thats another topic I have yet to figure out here with the Fortigate. 
I've done the same testing with using application filters and then using the applications and they too still worked. I did a cross-check against a palo with same configuration and it blocked it. 

Thanks for helping out!  

[dfish85]

Hello,

On the firewall policy you will want to select "certificate-inspection" for the ssl inspection section.

[belnea1]

This is decrypting traffic in the background, which requires a certificate to be installed on the client device which is what I cant do. 

[dingjerry_FTNT]

Hi @belnea1 ,

"no-inspection" means no inspection, so it will not detect any SNI/CN of the certification for inspection.

"Certificate Inspection" will not decrypt/encrypt the traffic. 

However, for blocked URLs, we will show the Block Page Replacement Message in HTTPS protocol to the clients and FGT will have to re-sign the response using the self-signed certificate.  

This might be an issue for you.

[belnea1]

Hi dingjerry,

Understood! So Certificate inspection is not actually doing decryption, I must have falsely made that assumption due to the certificate error I was getting - this makes perfect sense now.

This means that all I  have to do is to configure the Forti with a publicly trusted certificate (for the block page) instead of the default one and all clients should be good!? I assume that's possible? 

Thank you for this insight. 

[dingjerry_FTNT]

Hi @belnea1 ,

We need a "CA:True" type certificate for the MIMT traffic.   But I don't think there is any public CA authority that will sell the "CA:True" type certificate.

However, you may use, i.e. Microsoft CA server to generate a "CA:True" type certificate and push it to your clients using GPO if you are using Windows.

[belnea1]

Thank you for your help here but unfortunately what you suggest is not possible for our environment as we are dealing with an airport like situation here - we have thousands of end user devices we do not control.

What other options do we have with the Fortigate?
Maybe we can we simply disable the response page in order to avoid that certificate error as long as the blocking works? 

One example use case where I would need that block page though would be the aforementioned captive portal popup. I'm not there yet on the Forti but on the Palo we are using response pages to redirect unauthenticated users (depending on what kind of subnet they come from) to a locally hosted captive portal page of our choice. Since the block page is configurable, I hope would this will be possible on the Fortigate as well? The captive check traffic from the devices is always HTTP, so interception (& redirect) here should not need any certificate inspection / MIMT.

[belnea1]

Happy new year everyone!

Is there no other way of archiving my goal without the need of a private certificate to be installed on all devices? 

[dingjerry_FTNT · Accepted solution]

You are right.