Best Practices For Fortigate In School Setting

[clayrogers]

I am going to be installing a Fortigate in a small secondary school. Can you guys give me a rundown of tips and best practices for content filtering in this environment?

I would love to get a list of recommended config options along with instructions on how to set it up.

Setting up filtering for a school seems like a bigger challenge as opposed to setting them up for a business which is where most of my experience with Fortigate is.

Thanks!

[eti_andrei · Accepted solution]

Our company deals exclusively with the education market. While we remain vendor agnostic, I'm a big fan of the FortiGate - and several of Fortinet's products - in an educational setting and I recommend them whenever I think they're appropriate.

Here's an abbreviated version (focusing on content filtering) of our internal guide:

First and foremost, we always speak to administration about their needs and expectations. We also explain the practical limitations of the device and try to temper expectations. Suffice it to say, there have been many times when administrators have come to us in a panic: "How were students able to get onto this inappropriate site? We just spent $xx,xxx on this device, isn't it supposed to block everything?" Conversely, we deal with many schools who don't mind certain sites being accessible by students that others would want blocked. We use administration's guidance to build our content filtering policies.

Second, we always establish a logical organizational map of user groups and who should have access to what. We will use this for our group mapping.

Third, and this is optional, we recommend to our client that they have some sort of client management/MDM solution in place. While this doesn't directly affect perimeter security and content filtering, it's especially useful for distributing certificates when enabling deep SSL inspections. If you're a homogenous Windows environment, you can get by pretty well with GPOs. Likewise, you can do basic certificate pushes with Apple's Profile Manager for your Macs.

Fourth, we find out how users are accessing the network and determine how we will identify them. By now, we have created our groups in the FortiGate and mapped them accordingly to our LDAP environment. 

For Windows clients bound to AD, you can have the FortiGate poll your domain controllers or retrieve logon info from the aggregate collector on a Windows machine that can be configured to either poll your DCs or install an agent. You may not like the idea of an agent on your domain controllers, so polling should suffice in many cases. We also found that polling is a must if you have Mac clients.

For clients connecting wirelessly and authenticating via RADIUS, enable the RSSO collector agent on the FortiGate (and configure the groups accordingly) and have your RADIUS server forward accounting packets to it. This works just fine with Microsoft's NPS.

If you're connecting non-AD-bound wireless devices and aren't using RADIUS authentication but want to apply content filtering policies, you'll either need to register individual devices into groups (which becomes inefficient and unwieldy for all but the smallest environments) or create a VLAN for wireless devices and use the FortiGate as the VLAN's gateway with captive portal enabled. The idea is to have a user login mapped for every device that accesses the network whenever possible. Using FortiAPs for your wireless network can make this process somewhat easier, but this is not always realistic.

Lastly, and depending upon your needs, have a look at the FortiAuthenticator. Think of it as the "professional" version of the FortiGate's SSO/authentication features. For example, it allows for users to register their BYOD devices via a self-service portal.

Best of luck!

[clayrogers]

Anyone? I tried working with support on it but they seem to be more used to just answering a specific question, not necessarily communicating best practices etc.

[jmcnutt]

Hi Clay.  I am using a Fortigate 1500D in a two district elementary school and high school setting.

My list of lessons learned is so long, I have probably forgot most of them.  Is there anything specific you are struggling with?  I've found SSL filtering creates a ton of issues, but turning it off allows student and staff to bypass the web filter somewhat easily.  Google Apps for Education, Chromebooks, iPads, and Android devices present a new set of issues (in my environment at any rate).  Not sure if I am follow best practices, but I've found a work around for most of the stuff I've run into.

After some core differences with Fortigate Customer service and support, I'm exploring the option of replacing mine at the end of the school sure.  In my experience - Fortinet is a very large company with some very large companies and if you are a small school district in Arizona, they don't have the time to help.

James

[hklb]

Hi,

Each installation is different.. But the webfiltering is very important and the reporting (in switzerland, the school need to have a trace of each site visited for 6 months).

For the google search, pay attention to safesearch. You have to configure your web profile in proxy mode to activate the safesearch. If you don't use SSL interception, look at on this : https://support.google.com/websearch/answer/186669?hl=en (Personnaly, I use the dns cname nosslsearch.google.com).

Configure if possible the authentification (I configured the RSSO, it's works fine)

I hope it help

Lucas 

[emnoc]

BCPs? no such thing.

What is you security policy and AUP? What do you want to allow or disallow. E.g

In K-12 we dis-allowed   LGBT sites, guns, religious /politics/controversal/etc...( outs side of the sites we whitelisted ) 

Each school district is going to be different, a elem/mid/junior/senior school could have a unique & different policy.

[shartnett]

We are in the initial stages of setting this up. What we are currently doing is multiple profiles.

One for IT, Staff, Students, and Guests are the main four. Still we be tuning for a while since we are just getting off the ground here.

Some issues we are having are devices like Chrombooks and IOS devices do not authenticate against AD, so they get the guest profile, not a great situation. MACs sometimes forget how to authenticate against AD.

A school is much more challenging for putting filters in place over a business.

[MikePruett]

Depending on how deep the Fortinet hardware goes (the APs, switches, etc) you can use mac filtering based on devices to help alleviate that problem (if specific users have specific devices).

You can force people to authenticate against the WIFI using their own PSK's or RADIUS and that will provide the identification you need as well. I know on 5.6 each user can have their own individual PSK in general.

[neonbit]

Depending on the wireless controller the school is using I'd recommend looking at implementing RSSO (RADIUS single sign on). If the wireless controller supports RADIUS attributes you can get it to send the login information to the FortiGate (or ideally a FortiAuthenticator). That way the FortiGate can determine the users/groups on the Chromebook and IOS devices and apply the profiles correctly.

Definitely recommend enabling SSL deep inspection as it will allow the school to have greater visibility on what the students are doing (and if they're trying to use proxies to bypass the FGT). This will also allow the school to get visibility on what students are searching for (seeing suicide or bullying searches can help schools target students in need of help).

I'd have a conversation with the school around Google translate as many schools allow this. Thing is you can use google translate to translate pornography pages to other languages (bypassing the web filtering). I usually demo this to the IT managers and they decide to block google translate altogether.

Blocking YoutubeHD can be beneficial as it will force students to use standard def when they all take their lunch breaks (saving bandwidth).

[eti_andrei · Accepted solution]

Our company deals exclusively with the education market. While we remain vendor agnostic, I'm a big fan of the FortiGate - and several of Fortinet's products - in an educational setting and I recommend them whenever I think they're appropriate.

Here's an abbreviated version (focusing on content filtering) of our internal guide:

First and foremost, we always speak to administration about their needs and expectations. We also explain the practical limitations of the device and try to temper expectations. Suffice it to say, there have been many times when administrators have come to us in a panic: "How were students able to get onto this inappropriate site? We just spent $xx,xxx on this device, isn't it supposed to block everything?" Conversely, we deal with many schools who don't mind certain sites being accessible by students that others would want blocked. We use administration's guidance to build our content filtering policies.

Second, we always establish a logical organizational map of user groups and who should have access to what. We will use this for our group mapping.

Third, and this is optional, we recommend to our client that they have some sort of client management/MDM solution in place. While this doesn't directly affect perimeter security and content filtering, it's especially useful for distributing certificates when enabling deep SSL inspections. If you're a homogenous Windows environment, you can get by pretty well with GPOs. Likewise, you can do basic certificate pushes with Apple's Profile Manager for your Macs.

Fourth, we find out how users are accessing the network and determine how we will identify them. By now, we have created our groups in the FortiGate and mapped them accordingly to our LDAP environment. 

For Windows clients bound to AD, you can have the FortiGate poll your domain controllers or retrieve logon info from the aggregate collector on a Windows machine that can be configured to either poll your DCs or install an agent. You may not like the idea of an agent on your domain controllers, so polling should suffice in many cases. We also found that polling is a must if you have Mac clients.

For clients connecting wirelessly and authenticating via RADIUS, enable the RSSO collector agent on the FortiGate (and configure the groups accordingly) and have your RADIUS server forward accounting packets to it. This works just fine with Microsoft's NPS.

If you're connecting non-AD-bound wireless devices and aren't using RADIUS authentication but want to apply content filtering policies, you'll either need to register individual devices into groups (which becomes inefficient and unwieldy for all but the smallest environments) or create a VLAN for wireless devices and use the FortiGate as the VLAN's gateway with captive portal enabled. The idea is to have a user login mapped for every device that accesses the network whenever possible. Using FortiAPs for your wireless network can make this process somewhat easier, but this is not always realistic.

Lastly, and depending upon your needs, have a look at the FortiAuthenticator. Think of it as the "professional" version of the FortiGate's SSO/authentication features. For example, it allows for users to register their BYOD devices via a self-service portal.

Best of luck!

[MikePruett]

eti_andrei wrote:

Our company deals exclusively with the education market. While we remain vendor agnostic, I'm a big fan of the FortiGate - and several of Fortinet's products - in an educational setting and I recommend them whenever I think they're appropriate.

Here's an abbreviated version (focusing on content filtering) of our internal guide:

First and foremost, we always speak to administration about their needs and expectations. We also explain the practical limitations of the device and try to temper expectations. Suffice it to say, there have been many times when administrators have come to us in a panic: "How were students able to get onto this inappropriate site? We just spent $xx,xxx on this device, isn't it supposed to block everything?" Conversely, we deal with many schools who don't mind certain sites being accessible by students that others would want blocked. We use administration's guidance to build our content filtering policies.

Second, we always establish a logical organizational map of user groups and who should have access to what. We will use this for our group mapping.

Third, and this is optional, we recommend to our client that they have some sort of client management/MDM solution in place. While this doesn't directly affect perimeter security and content filtering, it's especially useful for distributing certificates when enabling deep SSL inspections. If you're a homogenous Windows environment, you can get by pretty well with GPOs. Likewise, you can do basic certificate pushes with Apple's Profile Manager for your Macs.

Fourth, we find out how users are accessing the network and determine how we will identify them. By now, we have created our groups in the FortiGate and mapped them accordingly to our LDAP environment. 

For Windows clients bound to AD, you can have the FortiGate poll your domain controllers or retrieve logon info from the aggregate collector on a Windows machine that can be configured to either poll your DCs or install an agent. You may not like the idea of an agent on your domain controllers, so polling should suffice in many cases. We also found that polling is a must if you have Mac clients.

For clients connecting wirelessly and authenticating via RADIUS, enable the RSSO collector agent on the FortiGate (and configure the groups accordingly) and have your RADIUS server forward accounting packets to it. This works just fine with Microsoft's NPS.

If you're connecting non-AD-bound wireless devices and aren't using RADIUS authentication but want to apply content filtering policies, you'll either need to register individual devices into groups (which becomes inefficient and unwieldy for all but the smallest environments) or create a VLAN for wireless devices and use the FortiGate as the VLAN's gateway with captive portal enabled. The idea is to have a user login mapped for every device that accesses the network whenever possible. Using FortiAPs for your wireless network can make this process somewhat easier, but this is not always realistic.

Lastly, and depending upon your needs, have a look at the FortiAuthenticator. Think of it as the "professional" version of the FortiGate's SSO/authentication features. For example, it allows for users to register their BYOD devices via a self-service portal.

Best of luck!

That abbreviated write up is better than 99% of what I see in the field.