Problem with denying FQDN

[micycle]

I am using an evaulation vm of Fortigate 6.4.1

I have enabled all traffic in one rule, and one to block an FQDN (for the sake of this example it would be facebook.com).

And yet when I try to reach facebook.com through my browser it is not blocked.

If i'll try to use a web filter, Facebook will be blocked.

Is this because the evaluation trial of Fortigate doesn't support FQDN, or am I not configuring something properly?

Thanks in advance.

[lobstercreed · Accepted solution]

To effectively block web traffic you always need to use a web filter because that's the only way you can actually look at the URL (or at least domain, because of HTTPS) that the browser is requesting. 

FQDN is just a more dynamic way of specifying an IP address.  If mywebsite.com resolves to 1.2.3.4, and I want to block all traffic destined for 1.2.3.4, I can either use a subnet address object of 1.2.3.4/32 or I can use the FQDN of mywebsite.com.  If mywebsite.com starts to resolve to 5.6.7.8, then the FQDN object will stop blocking 1.2.3.4 and start blocking 5.6.7.8.  This may or may not be desirable behavior.  Usually this is more useful for allowing traffic; think an IoT platform that is programmed to connect to a specific domain.

The biggest problem is neither of the IP-based solutions (FQDN or subnet) scale particularly well.  Especially when it comes to the BIG websites like Facebook.  Your user may be resolving Facebook to a completely different IP address than the 3 that the firewall discovered.  For example I resolve to a completely different address where I am right now. 

Plus, the browser is likely loading various parts of the site from multiple subdomains of facebook.com, like www.facebook.com and more.  You would need FQDNs for each of these as well to even stand a chance of blocking the site.  Again, this is not what a layer-3 ACL is intended for.  You want an application-layer tool like the web filter.

[micycle]

lobstercreed wrote:

FQDN is just a more dynamic way of specifying an IP address.  If mywebsite.com resolves to 1.2.3.4, and I want to block all traffic destined for 1.2.3.4, I can either use a subnet address object of 1.2.3.4/32 or I can use the FQDN of mywebsite.com.  If mywebsite.com starts to resolve to 5.6.7.8, then the FQDN object will stop blocking 1.2.3.4 and start blocking 5.6.7.8.  This may or may not be desirable behavior.  Usually this is more useful for allowing traffic; think an IoT platform that is programmed to connect to a specific domain.

I've tried to check if an FQDN rule works when I am using it to allow a domain instead of blocking one. And when I set it that way I can't access the website.

So I still don't quite understand why and when should I use it, or whether I am even using it correctly.

[lobstercreed]

It has limited usefulness, honestly, but I can tell you it is not going to be useful for almost any website, ever.  Again, websites pull data from a plethora of locations at various domains and subdomains.  Just run developer tools in your browser (F12) and you can see that.

Maybe to get you away from thinking of it wrong...you would generally only ever use it where you would otherwise use a single, static IP address in your policy.  The only advantage is if that single, static IP address changes but retains the same hostname. 

One of the main places I use it is when I have a particular user's PC (named BLD123EC01 in Active Directory) that needs a particular rule applied to them.  They may get a different IP next week (depending on DHCP and all) but their hostname remains the same and is resolvable against AD DNS.