Our region has been talking about Internet filtering/monitoring quite a bit recently. Some vendors have proposed hardware solutions that are “in line”, essentially forcing all traffic through the hardware appliance. There are a few pros and cons about this and, since I’ve been talking about it recently, I thought I’d add it to the blog.
Pros:
The best chance you have at capturing all Internet-related activity is with an in-line filter. Other proxy-based filters rely on browsers to direct traffic to them. Savvy users have found multiple ways to alter these browser settings to route directly to the Internet. A filter with a single NIC (essentially just another device on the LAN) would never see this traffic that may have been re-routed. Remember the OSI model. With a properly configured in-line filter (e.g. the physical layer), nothing would enter or leave the LAN without passing through the appliance.
It’s part of the same ‘pro’ really, but seeing this activity gives you insight into what’s going on in order to deal with it appropriately. Knowledge is power and I deal with many strong CIOs who will admit that they don’t entirely know what’s passing across their networks. A solution like this would give this type of visibility.
Cons:
In our Kentucky networks, certain traffic other than Internet traffic would need to pass through this filter. For example, antivirus updates reside on a local box that would be on the outside of the appliance. Proper exceptions would have to be made to allow this traffic to pass. In addition, districts would need to ensure that the hardware is sufficient to pass all of this traffic without causing problems or becoming a bottleneck.
An in-line solution would also introduce a single point of failure. Most vendors claim that traffic will continue to pass in the event of a hardware failure, so districts would want to verify that fact. Many support issues would have this appliance as an additional factor that would need to be considered.
In-line filters are an interesting concept and may serve some districts well. We have certain state product and configuration standards that must be followed, but I have no problem with districts who want to investigate these solutions while maintaining those standards. I will say, though, that I don’t think this solution fits every district. A device that sees (and potentially manipulates) all traffic is nice, but it definitely puts an additional burden on local districts that use them. These districts would now be more responsible than ever for having a keen understanding of the traffic passing across their networks.