UC Berkeley Campus Firewall Issues

George C. Kaplan

ISSUES

Decentralized management

The network on campus is managed centrally: CNS operates all of the network equipment from the border router all the way to each user's wall jack, or to some other demarcation point for departments with private nets. Because the network is maintained for all campus users, CNS does not enforce policies for individual departments, only for the campus as a whole. For example:

• Restrictions on network use are based on maintaining network operations for all users (bandwidth, for example), not on service or content.
• Security actions, such as blocking a host's network access, are taken only to mitigate threats to network operations, not to protect individual systems.

A key part of network management is monitoring the equipment. CNS operates a management station that monitors the condition of the hubs and switches around the campus. (Well, the modern ones, at least; older equipment doesn't support such monitoring, but is slowly being replaced). The ability to monitor and, in some cases, reconfigure network equipment from a central location greatly simplifies troubleshooting when problems arise. This is essential for CNS to maintain a growing network with the limited resources available to us.

In contrast to the centrally-managed network, individual servers and other computers are managed by the departments that own them. There are general campus and systemwide policies on computer use, but specific policies on which services a given system offers and who is allowed to use them are up to individual departments. It is the departments that are responsible for the configuration and the security of each of their systems.

Some departments want to set up firewalls to protect some or all of their computers from intruders. Two important points need to be considered:

• A firewall is not a guarantee. If it allows any traffic through at all, the systems behind it are still vulnerable. Departmental administrators must still be diligent about maintaining the security of their individual computers.
• Even though a departmental firewall is a "network" device (because it's directing the delivery of packets on the net), it's implementing security policies of a single department. Therefore, a firewall is really a tool for system management, not network management, and must be managed by the department, not CNS.

This last point illustrates a problem of departmental firewalls, or rather, of supporting the network behind them. CNS supports the network up to a "demarc"; everything past the demarc is up to the department. The firewall, operated by the department, establishes a demarc, which makes it difficult for CNS to support the network behind it, as discussed in the next section.

Problems of departmental firewalls

Some ways to support nets behind firewalls have been proposed. One is to require deparments to use bridging firewalls, and implement a temporary bypass, or "shunt" that can temporarily take the firewall out of service to allow CNS to perform troubleshooting. But this prevents us from routinely monitoring the network equipment in the department.

Another approach is to set up a special out-of-band ("OOB") channel around the firewall for CNS monitoring use. There are various ways to use VLANS to set up an OOB channel for CNS while all normal traffic goes through the firewall. But they all complicate the design of the network, and raise the cost to the department because of the extra switch equipment needed.

However, both the shunt and OOB approach turn out to be unacceptable from a liability standpoint. They both allow CNS to subvert the department's firewall policies. Even though this subversion is limited, it effectively involves CNS in the management of the department's firewall, which we don't want to do. What's more, if an intruder gets past the firewall, CNS could be held responsible for the security breach.

How about if the department is responsible for the firewall, but maintains a secure channel through it for CNS network monitoring? The problem with this approach (aside from some liability issues that are still present) is that it puts CNS network support at the mercy of the competence and responsiveness of the administrator responsible for the firewall. The overall record of campus departments in other areas of shared administration is not encouraging.

Delegated DNS zones offer a good illustration of the problem. CNS is responsible for DNS on campus. In a few cases, we've delegated DNS zones to departments that run their own nameservers. These departments must agree to certain conditions, such as maintaining up-to-date nameserver software and responding quickly to requests. Results are mixed: a few departments do a good job, others are mediocre, still others do a poor job.

Non-responsive departments can be a real drain on CNS resources. For example, a syntax error in a zone file can cause a department's nameserver to fail. This is a simple error, easy to fix. It won't cause an immediate problem, since the CNS nameservers provide secondary DNS for delegated zones. But the error must be corrected quickly (within a few days) or the department will disappear from DNS. When departments fail to fix such errors quickly, the result is a cycle of repeated (and escalated) requests that tax CNS resources far out of proportion to the effort necessary to actually fix the error. A similar level of responsiveness by departments running firewalls would severely impact the quality of our network support.

The only option for departmental firewalls supported under current policy is the "private net". CNS establishes a demarc; the firewall and the network behind it are then the responsibility of the department. The problem with this approach (for the department, at least) is cost: the department must devote resources to running the network, as well as the firewall.

PROPOSED SOLUTIONS

Here are a few suggestions for offering better support to departments who want firewalls. Note that while all of them have been discussed to some degree within CNS, we have not, as a group, come to any conclusions about which of these we'd be prepared to support.

"Every system should have one"

Firewall software to protect individual systems is available for every major operating system used on campus. For example, ipfw, ipfilter and other packages run on various flavors of Unix. There are even "point-and-drool" firewall packages available for Windows and MacOS. Widespread use of such individual firewalls could greatly reduce the need for firewall hardware to protect sections of the network.

SNS can play a major role in supporting and encouraging departments to use of firewall software on individual systems. SNS may not have the resources to become experts in a wide variety of firewall packages. But they could easily be a focal point for collecting "best current practice" recommendations, and maybe even some sample configuration files for some of the common firewall packages.

The advantage of this approach is that it requires no change in existing policy. CNS still supports the network all the way to the user's wall jack; no private nets are needed. And disseminating information on how to run the firewall software fits very nicely with SNS's "Education and Communication" goals.

"Secure Pen"

A TBD group in IST would set up a private net behind a firewall in Evans Hall or some other central location. Departments that need to protect critical servers would locate their servers on this private net. The IST group would (for a fee) manage the firewall for the departments that had critical servers on the protected net.

The advantage to this scheme is that the private net support model is preserved, yet it could reduce the proliferation of new private nets around campus. However, it isn't clear which group would take on the responsibility, and the recharge model would have to be developed.

IST Firewall Operations Group

Is there any way for departments to have their own firewalls and retain CNS management of their networks? One possible approach would be for an IST group to manage (again, for a fee) the departmental firewalls, and collaborate with CNS to make sure CNS is able to monitor the network equipment behind the firewalls. SNS seems like a good place to put such a group, but it could be elsewhere in IST. It is not at all clear that this idea would work, but it's at least possible to consider it for a couple of reasons:

• Within CNS, the NS and OIR groups already share administration of routers and switches, and this works reasonably well.
• CNS would only have to collaborate with one firewall administration group, rather than a bunch of different departments of varying degrees of responsiveness.