Timothy Parker Consulting Incorporated


 

Still more on Firewalls

Last time we started to look at firewalls. That column prompted questions from VARs about how to choose a good firewall. It’s a fair question, one with different answers depending on whom you ask. You already know what a firewall does (check the last column!) so now the issue becomes how much protection the customer needs, and what features they want in the firewall software. Obviously, the more the firewall does, the more it costs. Knowing how to balance these factors makes you look good, and prevents the customer from spending too much.

A few basic rules for choosing a firewall apply to all sites. First, the firewall must be capable of blocking all traffic in and out of the internal network if the need arises. That means completely shutting down access, either in one direction (usually incoming from the Internet) or both in case of network problems or security matters. This basic rule should be extended to say that the firewall should block all services and access except those the network administrator specifically allows. For example, one customer may want to allow only out-going Web and FTP requests, and only permit incoming FTP. All other services should be blocked completely. Most firewalls allow this type of blocking, usually from a simple window list that shows all the services with check boxes next to them to allow the service to pass through the firewall. However, a few firewalls only handle specific Internet services, and these should be avoided.

Ideally a firewall will allow even more filtering than just service access. Some firewalls allow administrators to decide to pass some services only to specific servers inside the network. For example, a company may have a Web server or two inside the corporate network, accessible through the firewall. Other Web servers on the network used internally only should be blocked by the firewall. This is an advanced feature and not many firewalls offer selectivity like this. The ability to target internal servers makes the network much more secure and flexible.

Proxies should be supported by the firewall for all services, not just Web or e-mail. If the customer decides they want to allow inbound and outbound FTP then the firewall should have an FTP proxy. The use of proxies makes the internal network and its users more secure.

Firewalls should support all current authentication schemes. Proprietary or little-used techniques are used by some firewall packages, and these require extra effort on the part of users and administrators. This is a bad choice. Instead, the firewall should allow any authentication scheme the customer is currently using, or that might be encountered during normal business. Again, most firewalls are very good at this, allowing all the current authentication methods to be used, and many allow software updates to be loaded when new schemes are developed. Check this item carefully, though, as a bad choice may annoy your customer for years to come.

Little things make firewalls even more useful to some networks, such as SNMP support. SNMP (Simple Network Management Protocol) allows an administrator to obtain status reports across a network. Many networks use SNMP because it has a small overhead and provides quick notice to administrators of bottlenecks or failures. Not all firewalls support SNMP, although they all should. If the firewall requires an operating system such as UNIX or NT, make sure the customer knows the versions required so they do not have an entirely new entity on their hands.

Whichever firewall you are looking at should be flexible in its configuration. This allows the firewall to adapt to the customer’s network, instead of forcing the customer’s network to adapt to the firewall. While the latter may be more secure in the long run, the effort and administration involved, not to mention the bad will generated in the process, are not worthwhile. This extends to things like security policies. The firewall should fit into the customer’s existing security policy (assuming they have one) without forcing the customer to completely rewrite the policy to cater to the firewall’s requirements.

Finally, make sure the company selling the firewall has been around for a while, has a good record in both customer support and security issues, and offers frequent updates for their product. TCP/IP services change considerably every few years and being stuck with an expensive obsolete box only two years after purchasing it is going to sour any customer.

Does all of this mean that only expensive firewall products on even more expensive hardware platforms are the best? Definitely not. While there are many superb software-based firewall packages available for NT and UNIX in the $5,000 and up category, many of these have features smaller networks will never use (and hence shouldn’t bother paying for). The same applies for hardware. Why pay many thousands of dollars for dedicated hardware when you can use existing machinery that is even tending towards obsolete? For smaller companies and organizations (up to 150 employees, say) that do not need megabytes-per-second throughput, the cost of the firewall hardware can be minimal. I’ve installed several firewall systems on older 66MHz Pentium workstations that were due to be replaced and junked. These systems required only 16-32MB RAM and a couple of gigabytes of hard drive. The operating system for most of these slower-platform firewalls was Linux, which is almost free. You can even create a firewall out of Linux itself with no additional software, if you know TCP/IP well enough. Just think: a basically free firewall!

Of course, this solution won’t work for many, because most companies want a commercial product with a name to call in case of problems. Still, instead of looking at tens of thousands of dollars, a company can put a secure firewall in place for only a few thousand. Great insurance and peace of mind.

 

Send mail to tparker@tpci.com with questions or comments about this web site.
Copyright © 1995-2007 Timothy Parker Consulting Incorporated
Last modified: January 23, 2007