Web Filtering (part 3)

Web filtering restricts what web content a reader can access with a browser from their computer or mobile device.  However, there is no “one-size-fits-all” approach to web filtering, and a web filtering strategy for a large design and manufacturing company is not necessarily suitable for use at an elementary school or small medical office.

The “Who”

This is the “Source” parameter in the filtering policy and, as stated, can be defined by IP addresses, DNS names or user identities.  In some environments, all systems and users have the same access, security and restriction requirements and it is a simple matter to configure a single filtering profile for all outbound connections.  In other environments, there may be differential requirements based on what subnet, computer or user the traffic originates from.  In these cases, it is important to carefully define how these populations are identified.  Here are the most common strategies, along with pros and cons of each:

Apply filter policy based on source VLAN or subnet.

  • Pros
    1. Easy to define and implement.
  • Cons
    1. Lacks flexibility, changes are global.

In cases where all systems and users in a given subnet will have uniform access, security and filtering requirements, per-VLAN or per-subnet policies are likely to be the best fit and require the least effort to implement and maintain.

Apply filter policy based on machine identity (IP address/range or DNS name)

  • Pros
    1. More flexible than per-VLAN/subnet
  • Cons
    1. More effort required to define desired sources and implement the necessary objects and policies.
    2. Devices are likely to change over time, so there is an ongoing administrative burden associated with maintaining device definitions.
    3. Defining source devices by individual IP addresses or ranges requires that those devices have static IPs or DHCP reservations, which must also be maintained.
    4. Defining devices by DNS name requires accurate and healthy internal DNS, and Dynamic DNS registration for DHCP clients.  This can be problematic for devices that are dual-connected to both wired and wireless networks.

Apply filter policy based on the identity of the user logged on to a device using Single Sign-On technologies. (Note that not all firewall vendors have this option and that different vendors may have different capabilities)

  • Pros
    1. Does not depend on knowing source IPs in advance.
    2. Provides greater flexibility for shared computers.
    3. Can leverage user groups for simplified administration across users with the same requirements.
    4. Effectively handles dual-connected (LAN + WLAN) computers.
    5. There is no additional authentication requirement; once a user logs on to a computer, their identity is known to the firewall and policy is applied accordingly.
  • Cons
    1. Requires an Active Directory domain, RADIUS server or similar identity store that is supported by the firewall vendor
    2. In some cases, cannot be used for non-Windows devices or devices that are not part of an Active Directory domain.
    3. For Active Directory Single Sign-On, requires installation of a Single Sign-On Agent on all DCs to monitor user logon activity and correctly associate a user with an IP address.
    4. For Active Directory Single Sign-On, certain ports on participating computers must be accessible to the firewall for periodic polling to determine if the user is still logged on.  This is not strictly required, but long-standing logon sessions (for example users who do not logout every day) can eventually be timed out if not verified, resulting in a change in filtering behavior.  Group policy can be leveraged to configure Windows firewall for these exceptions, if needed.
    5. It should be noted that adding a user to multiple groups used for filtering purposes can lead to unpredictable behavior.

This method provides simpler implementation of differential filtering policies than per-subnet or per-device methods, assuming users with the same access needs are added to the same groups and the groups used stay relatively static over time.  Using user templates associated with different departments or functions simplifies administration for new users, as they will automatically be added to the appropriate group associated with their job function.

All of these methods can be used concurrently in a cascading fashion or across different source VLANs.  For example, on subnets dedicated to special purpose devices, such as security cameras, the per-device approach can be used for atypical devices, while per-subnet would apply to all other devices.  Multiple user identity policies can be applied to LAN and WLAN subnets for different job functions, with per-device and per-subnet policies to catch those devices that are not domain members or do not typically have logged-in users, but still require internet access (servers, cloud-controlled WAPs, etc.).

Deep Inspection and The SSL Conundrum

Web filtering (actually all traffic inspection and threat management features) can only effectively police traffic that can be interpreted.  For unencrypted protocols, such as HTTP and FTP, this is a given.  However, encrypted protocols, such as HTTPS and SSH, cannot be decrypted and examined without a valid decryption key.  Every HTTPS transaction has a unique decryption key negotiated between the client and server that is not known to the firewall, and this presents a conundrum for inspecting and policing encrypted traffic.

There is some unencrypted information in every encrypted packet, such as the destination IP address and port, which can be used to make rudimentary filtering decisions.  Some encrypted web traffic also includes unencrypted metadata about the destination server and SSL certificate, which can be used to increase filtering accuracy.  However, not all encrypted web traffic includes this supplemental metadata, and the actual data payload cannot be inspected for viruses or fully reliable content controls.

The solution to this is to proxy encrypted sessions so that the client-to-firewall and firewall-to-server traffic is properly encrypted, but packets passing through the firewall are actually unencrypted.  This is accomplished through the use of a specially crafted SSL certificate that must be installed as a “trusted” Certificate Authority on client devices on the inside.  For domain-joined computers, installation is as simple as creating a Group Policy to push the required certificate to all members.  For non-domain or non-Windows devices, this must be done manually.  It should be noted that it is only practical to implement deep inspection of encrypted traffic originating from devices under control of the organization.  Deep inspection is impractical to implement for unmanaged devices on guest networks.

What Should I Do About It?

When it comes to protecting your business, you need to be covered on all fronts. Our managed IT services are designed to help you develop and implement the best web filtering practices for your business.