Firewalls are usually seen as a requirement if you are going to attach your network to other networks, especially the Internet. Unfortunately, some network administrators and managers do not understand the strengths a firewall can offer, resulting in poor product choice, deployment, configuration and management. Like any security technology, firewalls are only effective if the implementation is done properly and there is proper maintenance and response to security events.
Additionally, with the proper deployment of firewalls other security strategies are often much easier to integrate, such as VPNs and IDS systems. So what makes firewalls good, and what can you do to ensure they are used properly?
One of firewalls' weaknesses is also one of their strengths. Firewalls are typically deployed as a perimeter defense, usually intersecting network links that connect your network to others. If the firewall is properly deployed on all paths into your network, you can control what enters and leaves your network.
Of course, as with any form of perimeter defense, if an attack is launched from inside, firewalls are not too effective. However, this deployment on your network perimeter allows you to prevent certain kinds of data from entering your network, such as scans and probes, or even malicious attacks against services you run.
Conversely, it allows you to restrict outbound information. It would be nearly impossible to configure every workstation to disallow IRC, but blocking ports 6667-7000 (the most common IRC ports) is relatively easy on your perimeter firewalls.
While you can employ access control lists on servers internally, this still allows attackers to scan them, and possibly talk to the network portion of the OS on the server making a number of attacks possible. This perimeter also allows you to deploy IDS systems much more easily, since "chokepoints" will have already been created, and you can monitor all data coming in or leaving.
VPN deployment also becomes easy. Instead of loading up VPN software on every desktop that might need it, you can simply employ VPN servers at those network access points, either as separate servers or directly on your firewall, which is becoming increasingly popular (more on this later).
Controlling one, or even multiple firewalls is a much easier job than maintaining access control lists on numerous separate internal servers that are probably not all running the same operating system or services. With firewalls you can simply block all inbound mail access except for the official mail server. If someone forgets to disable email server software on a newly installed server, you do not need to worry about an external attacker connecting to it and exploiting any flaws.
Most modern firewall products are administered from a central console. You get an overall view of your network and can block or allow services as needed very quickly and efficiently.
With VPN-capable firewalls you can easily specify that access to certain networks must be done via encrypted tunnels, or otherwise blocked. With VPN software on each client, you would have more to worry about with misconfiguration or user interference. This results in sensitive data being accidentally sent out unencrypted. If your firewall is set up to block all but a few specific outbound services, then no matter what a user does even to bring in their own laptop they will probably not be able to access the blocked services. Enforcing this without firewalls and instead on each client machine is nearly impossible.
Enforcement of Security Policies
You may have a set of corporate guidelines for network usage that include such items as:
Chat clients such as IRC, AIM, and Yahoo IM are strictly forbidd
Accessing external mail servers is forbidden (antivirus policy); only use the internal server to send or receive.
Network games, such as Doom or Quake, are forbidden, except between 8 a.m. and 6 p.m. all weekdays for members of management.
Websites such as playboy.com are forbidden for legal reasons.
Enforcing the first policy without a firewall would be possible, but difficult. In theory, if you managed to secure every single desktop machine and prevent users from installing software, it would be possible. Then you would need to prevent people from attaching "rogue" laptops and so forth to the internal LAN with software preinstalled. While possible, this is a Herculean task compared to configuring a dozen rules (or even a hundred rules) on your firewalls to prevent access to the ports and servers that IRC, AIM and the rest use.
The second policy would be very difficult to enforce without a firewall. You would need to do the above steps to prevent people from installing their own email software or using rogue machines such as laptops with it preinstalled. Moreover, any email software you do use (such as Outlook or Eudora) would need to be configured so that users could not modify any preferences, add new accounts and so on. This is not possible in almost all email clients.
The third policy is virtually impossible to enforce without a firewall. You would need to take the above steps to prevent any user except for management installing the software. One possibility would be to place the software on a network share and only make it available from 6 p.m. to 8 a.m., and on weekends to users of the management group. However, many network games would not function properly, and you would have to prevent the software from being copied off, etc.
Even with all this, the software may still continue to function after 8 a.m. if it is running on the client machine (or it might crash horribly). In any event, this is much easier to enforce with a firewall such as FW-1: enable user authentication, then define a policy that allows users of the management group access to the ports used by these games at the appropriate times.
Enforcing policy number four is basically impossible as well without a firewall. While some Web clients do allow you to list sites that are off limits, keeping the browsers on multiple workstations up to date would be a virtually impossible task. Compare that with configuring the firewall to force WWW access through an application-level Web proxy where *.playboy.com can usually be blocked with one additional line.
A Secure Network Is a Healthy Network
Generally speaking, any security implementation done in a network will help with its overall health. Cataloguing systems and software versions to decide what needs upgrading first, implementing automated software upgrade procedures, and so on all helps with the overall health of your network and its systems.
A network configuration that creates chokepoints for firewall deployment also means you can easily implement a DMZ, a zone with servers to handle inbound and outbound information with the public. These servers can typically run a hardened and stripped down OS and application software. A proxy email server, for example, only needs to be able to accept and send email. There is no need for user accounts, POP or IMAP services, or GroupWare software integration.
Usually the simpler a system is, the easier it is to secure, and hence the harder it is for an attacker to break into. Securing a messy network is almost impossible. You must find out what you have, which versions, where the servers are deployed, what network links exist, and so on.
Firewalls, properly deployed, configured, and main
One advantage of firewalls, however, is a relatively high return on investment. One or two firewalls are usually just as effective for controlling external access to network services as implementing access control on every single server on your network. And using one or two firewalls will probably be much cheaper, both for initial cost and long-term maintenance.
Firewalls can also be used to give you an idea of how much hostile intention your network is earning and what kinds of attacks are being attempted and hence what you need to concentrate on. If you don't have a firewall, you should make sure you have good backups of all your data, and then contact a firewall vendor.
Kurt Seifried (firstname.lastname@example.org) is a security analyst and the author of the Linux Administrators Security Guide.