How to choose a firewall 2005
Like buying a new car, it's always tempting to purchase more than you need.
By Louise McKeag, Techworld | Techworld | Published: 10:00, 12 April 2005
Firewalls are critical to your network security, and everybody is supposed to have one. But with so many on the market and being touted around at show such as Infosecurity Europe like so much hardware confetti what should you look for in a good firewall? Is it speed, cost, or are they now so commoditised that it is just a matter of counting flashing lights? Here we'll guide you through what you should be considering in the latest products before you reach for the company credit card.
Before you start ploughing through data sheets, stop and consider your security policy. If you dont have one, then buying a firewall will be like putting a bouncer on the door of your nightclub and then forgetting to tell him whom to keep out and whom to let in. He'll do his own thing and it'll be chaos. You'll be keeping out some of the bulging wallet brigade that you want to encourage, and letting in all sorts of riff-raff that you really didn't want. And worse, it'll change every night.
Similarly for firewalls. If you don't have a proper and that means properly documented policy for what is allowed and not allowed on your network, then you dont know what your firewall is going to have to do, and when it arrives, bits and pieces of configurations will be done by different people in different ways. It won't work efficiently, and it'll be a nightmare to manage. So be warned. Sort out the high-level cans and cannots first.
Okay, you know what you're trying to keep out, and what you're going to let in. So how does this relate to picking the best firewall?
At its most basic level, your firewall will have to be stateful, in other words aware of conversations, not just individual packets. This lets you, for example, allow ping requests out of your network and permit the replies back in, but not allow in ICMP traffic that's generated from outside. It also allows for applications that use dynamically allocated (and random) ports, for instance in an FTP session, where we know the TCP port at the server end, but the one used at the client might be more or less anything. Without this feature, you have to open up a raft of port numbers, just in case, which isn't secure.
This shouldn't be an issue for most firewall manufacturers today, but you need to find out how far they take this capability, depending on the sort of traffic your network's likely to carry. It will call for application-level, as well as network layer, awareness, if, say, you expect to be able to run VoIP. Your firewall will have to be able to look inside the signalling packets to work out which ports are going to be used for a call, then dynamically allow them through, just for this one call (which itself will be a different IP stream than the signalling one), then close everything up again at the end. VoIP also has a tricky little feature (although it's not the only application that behaves in these ways, just one of the more topical ones) where it embeds IP addresses in the data payload, so any traditional NAT you're trying to do (again a pretty standard firewall feature these days) wont work, and you'll need extra functionality that understands applications, how they work and what their packets look like. And you need to ask your vendors what effect the extra processing requirements will have on performance.
How about extra features like time-of-day controls? Or filtering out potentially dodgy Java applets? URL filtering, perhaps (often this last one needs a separate device in addition to the firewall). And of course there's management and monitoring to consider. What sort of logs are provided, how useful are they and what would you do with them? Do you configure the firewall via a web front end or command line, and do you care?
Intrusion detection and prevention systems are all the rage, but they dont have to be dedicated devices. Your firewall might be able to provide what you need. Do you want the full prevention option, or just detection and notification? Perhaps a one-box solution would be suitable for your remote sites, where you have more limited traffic types to worry about, or the load isnt so great. Some firewalls have features known as something like application intelligence, or deep packet inspection, which look at packets for anomalous behaviour, and can react to block them in a variety of ways again make sure you know what sort of performance hit turning this on will cause though.
Decide if you want your firewall to also handle your VPN terminations, or offload SSL traffic. The more you run on one device, the more powerful it will have to be and the more you'll lose if it fails. If you'd rather have this sort of functionality on a separate device though, don't get conned into paying over the odds for 'extra features' you won't use.
Speeds and feeds
It may seem odd to get to this part last, but if your firewall can't handle the applications you need, it doesn't matter how fast it goes. But it's still an important consideration. How much traffic do you need to push through this box? What are the upgrade options, in terms of extra processing or more interfaces a chassis with slot-in modules may be more expensive initially but save you a fork-lift swap later. Perhaps there's a model that will let you load-balance units, for resilience and to let you add throughput without a major overhaul. And, talking of resilience, what are the options but remember to match that to what you actually need. Don't pay over the odds for 24x7 uptime if the business can live without its email and web access for a few hours.
It used to be, a firewall was a firewall, at least in name. Nowadays it's not that simple. The firewalls we've been talking about here are what are now known as perimeter firewalls, to distinguish them from a new breed, the email firewall.
Email has its own challenges, and there are enough stories on this site about the problems of phishing, spam, Directory Harvest Attacks and the like to make you never want to log in to your email system ever again. We'll cover email firewalls in more detail in a separate article, since they tend to be separate devices, with their own rules.
The good news is that most firewalls are now pretty similar when it comes to the basics a far cry from a couple of years ago. The bad news is that as applications have become more complex, and the bad guys more sophisticated, the basics aren't good enough any more for most organisations. Firewalls are cleverer these days. You'll have to be too.
In summary, heres the bottom line:
- Before you look at hardware, consider the security policies it will enforce.
- Double-check the firewalls stateful design
- Is configuration web-based or command line?
- How extensive is its filtering?
- Do you need intrusion prevention or is detection/notification enough?
- When assessing performance requirements, consider long-term benefits of chassis-based design
- Dont pay over the odds for high levels of uptime if you can tolerate occasional downtime. This adds heavily to cost.
- Do you need a conventional firewall at all? Might an email-protection system be a better investment?