You know you need to install a firewall, but there are so many to choose from that it can be difficult to narrow down what’s best for you. We’re not going to recommend any specific models here. What we will do is give you a checklist of the things you need to consider when you start shopping around.

The first thing you need to decide (apart from how much money you have to spend) is what you’re going to be using this firewall for. What are you protecting? What type of attacker can you expect? We’re going to focus on enterprise-class firewalls but even so you need to define how your firewall will interact with the rest of your network.

A firewall that is solely to allow your users to browse the Internet and send and receive emails, for instance, isn’t going to have to be as complex as the one which protects your ecommerce web servers which support thousands of customer transactions a day. In that case, you’ll probably be building a DMZ for these externally-reachable servers, and you’ll add further protection for your internal device via a second firewall (see Building a security DMZ ).

Speeds and feeds
The first questions are how many interfaces do you need and what sort of speeds are we talking about? One port in, one port out and a 128kbps Internet connection isn’t going to need anything like the processing power of a four-interface, Gigabit-connected firewall.

When it comes to throughput, it’s not just the interface speed that counts. You’ll need an estimation (and this is the tricky bit) of actual throughput, packet sizes and number of concurrent sessions that will need to be supported. How easy is to upgrade? Can you add interfaces, processors and memory if you need to, or is the migration strategy to trade it in for a larger device? You may pay a premium for a chassis that you can upgrade; if that’s not important to you, you can save money.

Getting throughput figures from vendors is easy. Getting real-life, meaningful ones, less so. Make sure you know under what conditions you can get the sorts of numbers they’re quoting and try and push them for an indication of how these will change when you start turning on features.

You’ll need to decide if you want your firewall to just be a firewall, or perform other tasks as well. Many firewalls can support VPN termination, either for site-to-site VPNs or remote users. If you want your firewall to do this, it will make a big difference on throughput and CPU usage, and you’ll need to look at not just session support but tunnel setup rates.

Similarly, with intrusion detection, web caching and SSL termination - if you’d rather have separate devices, don’t go for the more expensive firewall that includes it all. Decide how important dynamic routing and VLAN support is to you. Maybe you can rule out any devices that don’t provide this.

On the firewalling side of things, any decent firewall should be able to handle NAT, packet and stateful filtering, URL and Java filtering. It’s th,/be more complex things you need to be sure of. How does the firewall handle multimedia applications? Voice over IP is the obvious one, though the question applies to other protocols too. If it’s a stateful firewall, how does it handle the random use of port numbers that these applications require? Similarly, for NAT’d traffic where the IP addresses are also embedded in the payload. Maybe you don’t see a need to cater for these situations right now, but it’s likely you will in the future. If a vendor tells you that their product can cater for this without having to open up swathes of port numbers, find out what performance impact this extra processing might have.

Management and High Availability
If you’re going to have multiple firewalls, you’ll want a centralised management system. Depending on the admin staff, you may need command-line and GUI interfaces. Is it important that you can browse in Telnet and, probably more importantly, SSH access should be available, and you’ll need to decide what SNMP support you need. The level of integration with your existing network management platform may be significant, particularly if you have a Manager of Managers, or an alert correlation system (see Security Correlation). What authentication mechanisms are supported for access to the firewall itself?

The management system should allow you to create security policies and push them down to the firewalls. The ‘granularity’ of policies may be a deciding factor, and the ease with which this can be done is more important if you have multiple firewalls in your remote offices, say.

Pay careful attention to the alerting and logging capabilities of the device too. It’s not enough that the firewall blocks what it should and allows what you want it to: you need to know what it’s doing. Find out what sort of reporting mechanisms are available - are they built in, at extra cost, or from a third party?

If you need 100 per cent uptime, you’ll need redundancy. Compare levels of redundancy both within the firewall itself (Can you provide dual power feeds? What about DC inputs?) and as a dual-system pair. Does it matter to you if they operate in active/standby mode or load balance. What extra hardware is needed for a load-balanced configuration. Find out the requirements and limitations of a redundant system. Some vendors charge much less for the second firewall if bought up front, as a redundant system.

Cost is obviously important, but there’s a lot more to it than the initial purchase price. Find out about ongoing support and maintenance and if those costs include software upgrades. Where would your support be based? Even telephone support, it can make a big difference if someone is relatively local.

If you’re using your firewall to terminate VPNs, you’ll need to be aware of licensing costs. Is there a per-user cost? You might be able to negotiate a per-site one cheaper.

The soft costs are more difficult to quantify but they shouldn’t be ignored. Integration with your existing network, training and management can play a big part in your decision. It can be worth going for a device that, on the face of it, doesn’t seem to have quite as many features, or marginally less performance, if it’s easier to install in your particular environment and doesn’t cause a massive learning curve within your support staff.