How do we filter internet content: the concept of “deny all”

At a meeting later this week, a subcommittee of the district’s technology committee will begin exploring our internet filtering and social media policies.  While content filtering is a very complex issue, with implications stretching from the mundane (the process for requesting that a website be unblocked, for instance) to the extraordinarily challenging (such as issues of censorship and cyberbullying), the simple reality remains that the Children’s Internet Protection Act (CIPA) requires all schools that receive federal funding, ADM included, to filter certain internet content.

As such, I wanted to share – briefly – how we filter internet traffic at ADM.  At a fundamental level, a request for information looks like this:

request_for_internet_resources

1. A computer requests internet content, such as a website.
2. The request is routed to the district firewall
3. The firewall determines whether the web resource is allowed
4a. If yes, then the request for the resource is denied.
4b. If no, then the request is processed and the internet content is delivered to the user.

Step 3, though, speaks to a very crucial decision that must be made when it comes to content filtering, should you use an “allow all” approach or a “deny all” approach?

In our case, we’ve chosen to implement a “deny all” approach.  Basically, this means that unless the content is explicitly allowed by a firewall rule, the firewall will deny access to the resource.  The rules that drive this process can be thought of as you’d think of any other rule; here is an analogy using a parent’s thought process in answering a question from their child:

Child: “Can I watch TV?”

In order to answer this question, the parent needs to consider the relevant rules:

Rule #1: You can watch TV if you’re required to for homework (like watching a State of the Union address)
Rule #2: You can watch TV if you’ve finished your homework
Rule #3: You can watch TV on Saturdays

After considering the rules, the parent can ask the following questions:

Question #1: Are you watching something required for class?
Question #2: Have you finished your homework?
Question #3: Is it Saturday? (we’ll ignore that this would be a concerning question for a parent to need to ask …)

If the answer to any of these questions is yes, then the child is allowed to watch TV.  If the answer to none of these questions is yes, then the child is not allowed to watch TV.

Our firewall works exactly the same way.  We currently have 42 access rules, ranging from general things like “allow general internet apps” to more specific rules such as “allow external to internal access to our technology support ticket system”.  The rules look like this:

firewall_access_rules

Each rule must specify direction (is this only allowing internal to external traffic, or external to internal traffic, or both), and what content – which we call apps – are allowed.  We group allowed apps – like general web browsing protocols, specific apps like Evernote or iTunes, etc. – into categories such as “Social Networking” or “Network Management”.  Apps that are not allowed to any of these lists, like Snapchat, don’t match any rule and will be blocked.  If we find that a site or service is blocked that shouldn’t be, we just need to add that app to the appropriate group and it will then be allowed by the firewall rule for that group of apps.

We also have some control to filter within these rules.  While general internet browsing is allowed, for instance, sites that include pornography are not, and are filtered within this level.  If we need more granular control, we can whitelist (allow) and blacklist (deny) specific websites, though the vast majority of our internet content filtering relies upon definition updates that our firewall receives daily from our firewall vendor, Palo Alto.

At the end of our list of rules is a crucial one called “Deny All”.  Just like our TV watching example, if the answer to none of the questions is yes, the request is denied.

deny_all

This approach works because firewall rules are handled in order.  Every time a request is sent through the firewall, it first checks it against rule #1, then rule #2, and so forth until – if the request doesn’t match any of the other rules allowing traffic – it hits the “Deny All” rule and gets blocked.

The huge advantage to the “deny all” approach is that if a new threat emerges that hasn’t yet been categorized by our firewall, the default behavior is to block it.  This is a paradigm shift in firewall management, in that the “allow all” approach used to be more common.  In an “allow all” framework, the firewall rules are set up to deny certain types of traffic (whereas ours are set to allow), with a final rule called “allow all” that allows any traffic not explicitly denied by a previous rule.  The following example illustrates the problem with this approach:

Step 1: I set up a firewall that blocks all traffic classified by my firewall provider as a virus
Step 2: A malicious hacker writes a new virus that doesn’t match any existing definitions, and attempts to steal information from my network
Step 3: Since the virus doesn’t match any of my “deny” rules, it hits the “allow all” rule and is allowed
Step 4: Security breach

In this scenario, a “deny all” rule would’ve denied the virus-related traffic right away, since it wasn’t explicitly allowed.  The drawback of this approach is that legitimate traffic that is not yet addressed with an “allow” rule will be denied until we’ve explicitly allowed it.  In my opinion, this is a small price to pay for the level of security offered by a “deny all” approach.

On a practical note, any ADM Schools staff members who need to request that a site or service be blocked or unblocked should submit their request via the ADM Support system.

Advertisements
This entry was posted in Non-Tech Information, Tech Department News, Technology Information and tagged , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s