1

Hello!

I’ve been trying to tackle a somewhat annoying issue of users being able to access blocked websites via https. We can’t block https flat out since most of our work environment is Google Apps.

Essentially we are just looking for a way to block https to specific URLs. I think at most we want to block 5 websites that can be bypassed via https, so this doesn’t really warrant us to turn on the SSL inspection policy that would literally block all incoming/outgoing https connections.

Questions:

  • Can this be done on a specific URL level on the fortigate?
  • Can this be done on the computers? If it can, what are the steps?
  • Can this be done in AD? If so, what are the steps?

Firewall territory is somewhat new to me. Thanks for any help in advance. If this question is on the wrong area, please feel free to close it or move it.

2 Spice ups
2

If you have a paid subscription with Fortigate I want to say that you can visit their website to input a trouble ticket and they will give you the steps. In some instances they will even screen share with you.

3

You could create a policy that would block port 443 to those domain names.

4

I’ve only seen guides on how to block port 443 for https flat out, nothing that shows how to block for specific domains.

The only thing I’ve seen is to where you literally black list everything https and then whitelist certain https links, but that won’t work for us.

Would you mind laying out some steps on how to do so?

5

Just to get some clarity here…
For these 5ish URLs, are you trying to block them entirely or just block the HTTPS version?

What FW branch are you running on your 500D?
5.2 or 5.4?

Are you running the Fortigate as an explicit proxy?

You can definitely block HTTPS by URLS as the URL request destination itself is not encrypted, it can’t be.
You should be able to block the URLs completely using your website filter profile.
What you can’t do with HTTPS, without SSL inspection, is block based on content since the content is encrypted.
But it depends on what type of filtering you’re doing and how your Fortigate is setup.

6

if you have a paid subscription for the webfilter part you can block sites based on categories etc.

if not, you can still block sites on the url name (blacklist them)

the cli is quite difficult to enable this. but going through the gui, this should be a no-brainer : create a policy that blocks https to addresses. addresses are created using FQDN.

But using the webfilter of fortigate is better.

7

You can do one of two things

  1. you can block it at the URL level using address object for an FQDN and then creating a LAN to WAN policy to deny those connections. Doing this will give users a time out screen/page cannot be displayed rather then the fortigate website block page.

  2. If you are attempting to do this via web filtering, that will not work. You will at the very least need SSL inspection enabled so that the firewall can inspect the header information of the packets going out 443. If the fortigate is unable to decrypt the header information at the very least, it will not know the URL and will let the 443 packet passthrough.

1 Spice up
8

We are wanting to block them entirely, which we have a couple of “Block for all” profiles in which we enter in the URL for the site, however we have people bypassing that filter by using " https://website.com" ; to get to the site still.

Version for 500D:
v5.2.8,build727

I’m not sure if we are using it as a proxy or not, to give you a better idea of how we are using it, it is just basic filtering as we haven’t done anything major to it other than have our vendor that sold it to us set it up with what they “think” are the best settings.

The sites that we are trying to block are already categorized in the web filter, however. Employees and ourselves have been able to bypass certain sites. For instance, 4chan.org being a website we want to for sure block. Is blocked by our filter, but when entering in https://4chan.org , we get to it unblocked.

9

Can you take a screenshot of the Web filter profile?

It sounds to me like maybe the filter is setup to specifically block the HTTP version and not the HTTPS.

URL blocking is not affected by https as the URL itself isn’t encrypted, only the content.

10

Sure thing.

Hopefully I’ve attached the image correctly. For example, I’d like to place in a policy for a high school and I’ve already got everything configured for what to block and unblock for them. As well as our custom policies where essentially we have an “allow for all” and “block for all” category.

webprofile.png
webprofile.png846×604 77.2 KB
11

Well I’m a bit confused. In that screenshot you’re not blocking any URLs.

If you wanted to block 4chan.org you would add it right under the Gmail entries, and choose block.

You also need to make sure that you have that Web filter profile is selected in the firewall policy that handles the users internet bound traffic

12

We actually have that blocked under the profile that is actually being used. The profile shown is one that we are working on to see if we can put out and see if it works.

What you are saying is that under the URL block, it should also block the https link?

13

It depends on how it’s setup, but yes it should block both https and https.

14

Here is what we have at the moment.
We have 3 web filter policies.

  1. Staff Policy (which is currently above everything else)
  2. Default Policy (Which is very strict and is the base line filtering outside of staff)
  3. High School Policy (Which is currently being tested)
    Default and High school apparently do not filter out https.
    I applied High School with the URL blocks in place and I can still jump right around the URL block with https://imgur.com instead of just imgur.com
    The only difference between the 3 is that Staff Policy is actually set on a “Proxy” setting instead of flow based. Staff uses the Server Agent to read AD login. Default users that are not authenticated in our AD groups should not be getting a group and should be receiving the default policy.
    What is odd, if you are under the staff policy, you can’t get around using HTTPS. To make this even more confusing, we do not have a URL filter placed on Staff. Everything essentially that we want blocked. Is blocked.
    Pictures below:
    HS Policy that I’m trying to apply and prevent HTTPS connections. With URL blocks now, still doesn’t work.
    webfilter-hs-policy.png
    webfilter-hs-policy.png800×624 120 KB

    Staff Policy which is Proxy based and not flow based. (you cannot access problem sites via https while under this filter as long as you are authenticated in an AD group since we use an agent on our AD Server)
    Webfilter-staff-policy.png
    Webfilter-staff-policy.png800×400 59.7 KB

Message I get when I try https://imgur.com

webfilter-imgur-staff.png
webfilter-imgur-staff.png800×380 74.4 KB

Message from the computer lab via normal http://imgur.com
nonhttps-site.png
nonhttps-site.png761×263 11.5 KB

Results from computer lab via https://imgur.com
https-site.png
https-site.png800×433 249 KB

Staff policies are always at the top of our IPv4 Policy & Objects fields. Default is usually below that since, if students are not being authenticated. They should get the same results no?
15

For filters using flow mode, you do have to use SSL inspection to block HTTPS.

It’s not ideal, but you could distribute the builtin Fortigate cert as trusted to all of the devices that are managed using GPO or some other deployment method.

The other option, if we are talking about a handful of sites, is to poison your internal dns by creating entries for the domains you wish to block. You can forward the traffic to nothing or to a page that shows the Web usage policy or whatever you want.

Technically someone could get around this by using the IP of the website or putting something in their hosts file, but DNS poisoning would cover about 99% of a normal user base.

16

The DNS Poisoning we could try. So the ideal scenario would be Proxy Mode?

If we block the IP address of the sites and do the DNS redirects, technically it should work. I think this might be our best bet.

17

If you are not wanting to use SSL inspection, which I don’t recommend as a lot of threats are coming through SSL now and need to be inspected rather then passed though, I have had success with using FQDN objects and deny policies to deny the FQDN you are attempting to block. The downside of this is that you will get a web page timeout rather then the fortigate web filter block page.

18

Proxy mode ended up working the way we wanted. The company that came out and installed the Fortigate for us since we are a small department, didn’t really explain to us which modes did what.

We tested proxy mode all last week and finally introduced it into our environment and it is working great. No one has been able to bypass anything.