Gone are the days when a firewall was a firewall and a virus checker scanned files for viruses. With the increasing commoditisation of networking software and equipment, manufacturers are looking for ways to differentiate their products from the competition. The obvious way to go about this, of course, is to add more features.
The trouble is, when you run out of ‘obvious’ features for a product, you have to think laterally. So when you can’t think of any more ways to mangle IP packets in your firewall, it’s not a vast leap of logic to say: “Hey, why don’t we do virus checking, or URL blocking, or …”.
Hence today’s plethora of network devices that perform multiple functions. But is it a good thing to have everything running in one device?
The main advantage of having everything in one place is that you can write (or OEM and customise) a coherent set of applications to deal with the various types of traffic. So if your firewall does port blocking AND statistical analysis of port scans AND virus checking AND URL blocking, it becomes more possible to heuristically spot patterns of behaviour whose constituent parts wouldn’t necessarily be flagged as an attack but which, when combined, add up to one.
A good idea?
There are a number of downsides with this approach, of course. We’ll leave the usual equipment resilience to one side for a moment, since there are ways around failed firewalls (auto-failover, for instance, or even keeping a spare in the cupboard). The main issue, at least with security systems that run on a PC or Unix workstation, is that the more you load up the processor, the slower your firewall goes. This isn’t a problem for the average company’s internet firewall (you generally have less than 2Mbit/sec going through it, which shouldn’t tax a decent PC) but when you start getting into intra-department firewalls with 100Mbit/sec Ethernet connections, performance is an issue.
The obvious answer, then, is to off-load the actual work but still collate the answers at the firewall. This is a common approach with modern equipment – the firewall may hand off all outgoing port 80 TCP traffic to a URL blocking package on a separate machine, for instance, or all incoming port 25 (SMTP) traffic could be sent to a virus scanning machine before being passed on to its destination. This approach actually works well in the average case, because equipment is cheap and dividing the security problem into manageable units aids troubleshooting and configuration – not to mention relieving the load on the main firewall.
What happens, though, when you want to get really complicated and start (for example) handling VLAN admission, access control and packet forwarding in your network switches based on the authentication information you got from a VPN client. If you’re getting this complicated, the problem is that you have to start doing things internally in the switching devices themselves – in hardware or firmware – because they have to be fast. The downside is that when security functions are built into network switches, this generally means they have to be developed by the switch vendor. So you lose the ability to run an external best-of-breed alternative, and instead trust your vendor’s programmers to do it right.
In the average case, then, it’s probably cheaper – and certainly more manageable – to keep doing things separately. The performance penalty introduced by separating the functions is usually negligible compared to the relatively slow speed of the Internet link itself, and so little would be gained from integrating the functions. And you even get the bonus of being able to use your favourite best-of-breed packages instead of trusting (say) a firewall manufacturer to develop an embedded virus checker into its hardware.
In short: on balance, unless you need the screaming performance offered by an integrated security package, stick with a bunch of separates. The manufacturers of the various offerings work together all the time anyway, to ensure that firewall ‘A’ can integrate with virus checker ‘B’, and so even though they’re not in the same box or written by the same people, they’ll communicate just fine.
Find your next job with techworld jobs