Network Group

The UCL Institutional Firewall Project

Version:

1.0 (Draft)

Date:

7th May 2003

Author:

R.Lawrence

Document details:institutionalfirewall.doc

Last Updated:

6th May 2003

The UCL Institutional Firewall Project

At the Colleges CNUF meeting held on 30/04/03, I gave a short presentation on the UCL Institutional Firewall Project. The purpose of this briefing is to augment that material with further detail, describe the current status of the project, and make the information available to a wider audience.

0.Introduction

A firewall is a device used to help secure one or more local networks against unauthorised intrusion by outsiders. The device is typically located at the boundary where an organisation connects (eg. via an ISP), to the global Internet. Where the organisation is a commercial entity, the use of a firewall has become almost mandatory. Why is this so? The short answer is because the consequences of a security breach can be catastrophic, not just in terms of material loss, but also in loss of reputation.

What do we mean by unauthorised intrusion? A security breach can take many forms. These might range from a suspicious fingerprinting of a system (eg. as a preliminary to an attack), through a denial-of-service attack (where for example, a machine is subjected to a high level of traffic designed to deny access to legitimate users), through to a break-in (where a miscreant exploits a known weakness in a program to take control of the system that runs it). In all these and other cases a firewall can help limit the potential for misuse.

How does a firewall work? A firewall typically controls traffic entering and leaving an organisations network in accordance with policies defined by the organisation . A common policy (and very often the default one on a firewall) is to allow all outbound traffic and block all inbound. Traffic not permitted by policy is blocked. Traffic which is permitted is usually subject to stateful control. Stateful control, in very simple terms, implies that the firewall monitors the context and content of traffic passing through the firewall and ensures that, as far as possible, this traffic behaves in accordance with the relevant network and application protocols. Connections which are not well behaved in this sense, are terminated by the firewall.

Of course most organisations need a visible presence on the Internet or they are more likely than not to suffer competitive disadvantage. Most often this means that an organisation will need visible web and email services. How are these catered for? A common solution is to have a so-called DMZ (or De-Militarised Zone) connected at the firewall where public services are exposed in a controlled manner. The major benefit of this approach is that traffic for the organisations public services need never enter the organisations internal network.

1.The UCL requirement

Historically, the UK academic community has had a very permissive stance in regard to network security, and this fact doubtless reflects the closed nature of the JANET network in its earlier guises. With the connection of JANET to the Internet, and the subsequent evolution of the Internet as a global (as distinct from an educational and research based) phenomenon, this posture became very ill advised. Unfortunately UCL has been no exception to this norm and has suffered as a consequence. Formal recognition of this situation came with the establishment of the College CERT in late 1999.

As for current technology, some defence against unauthorised access has been built in the form of rudimentary packet filtering at the routers that connect College to the London MAN. These filters provide broad-brush screening of certain types of traffic that are known either to be suspect, or inappropriate in a WAN context. In some cases, packet filters have also been configured at the point where a department connects to the College backbone to match known traffic patterns specific to the department. Better practise is observed in those departments that have chosen to install departmentally managed firewalls at the departmental boundary.

So the picture is sketchy and inconsistent. Some departments have reasonably good protection against potential abuse, others have virtually none.

In order to help address these weaknesses, a UCL Institutional Firewall Project has recently been set up.

2.The Institutional Firewall Project

The UCL Institutional Firewall Project has as its goal the identification, piloting, and deployment of firewall technology for the College so as to provide a consistent level of network protection across the whole of the Colleges campus network. This network comprises both academic and administrative departments, the medical school, and merged or merging institutions. The firewall will not, at least in the first instance, impact upon those other organisations that connect to the London MAN, JANET and the Internet via UCL. These organisations include other HEIs connecting under UKERNA contract, and sponsored connections.

In discussing the project, there are two distinct issues to be highlighted. The first concerns the nature of the technology. The second concerns the firewall policy for traffic crossing the campus network boundary.

2.1Technology

The project has identified the Cisco Catalyst 6500 Firewall Services Module as a strong candidate for institutional firewall.

There are three major reasons for this. Firstly, the cited performance and functionality of the FWSM places it in the enterprise equipment category. Secondly, the UCL IS Network Group has extensive experience of the Cisco PIX firewall technology upon which the FWSM is based. Thirdly, the module is in the form of a blade or line card for the Cisco Catalyst 6500 switch. With Catalyst 6500 switches deployed throughout the UCL backbone, the bearer hardware for the blade is already in place, making the technology a very cost effective option for our needs.

The FWSM is currently being piloted inside the Network Group LAN. This pilot is essentially designed to test the functionality of the blade rather than its throughput/performance, though this latter will be assessed at a later stage of the project. Details of the pilot will be written up and made available elsewhere.

Deployment of the firewall will follow if pilot activities are deemed successful. The decision on where the firewall will be sited within the network has not yet been made, but there are essentially two broad possibilities. Blades can be deployed either within the campus core switches or in the MAN switches, and the choice is currently seen as a technological rather than a topological or political one.

It is anticipated that there will be two blades housed in distinct chassis, one in the Kathleen Lonsdale Building, one in Foster Court. This will enable a resilient, realtime failover configuration in which the Foster Court blade will track the state of the active blade in KLB, with automatic assumption of control should the KLB blade fail.

A paper on the anticipated service deployment of the technology is in preparation.

2.2Policy

A provisional firewall policy has been endorsed by the UCL ISISG Computer Security Working Group. While a decision has been taken in principle, there is ongoing consultation and discussion between the UCL Computer Security Team, and interested parties, eg. HoDs and computer representatives, together with presentations at faculty level to inform users.

There are essentially two distinct choices to be made in regard to policy, one in respect of outgoing traffic, one in respect of incoming traffic. The former is traffic originating within the campus network and connecting to systems off-site. The latter corresponds to traffic originating off-site and connecting to systems inside the campus network.

The policy agreed by the Security Working Group is as follows,

1.A default permit stance on all outbound traffic.

2.A default deny stance on all inbound traffic.

Exceptions to policy rule (1) will be made in line with current practise. These exceptions are blocks placed on certain ports known to be associated with malicious activity, and blocks on certain services which are only appropriate in the LAN context, eg. BOOTP/DHCP services.

Exceptions to policy rule (2) will be allowed to permit inbound traffic to a limited number of services. A possible model is already in place in respect of inbound SMTP traffic. This is permitted to a number of registered servers for those departments which run their own mail hubs and are prepared to accept direct connections from the Internet. Traffic to other internal addresses is denied. In the case of SMTP, a registered server must be configured to prevent the third party relay of email between sender and recipient(s), so as to help limit the proliferation of unsolicited bulk email (or SPAM) by UCL systems. This condition is tested on a regular basis by IS staff, and any listed machine which subsequently violates this condition is removed from the registered list.

A similar scheme may be introduced for other services with specific criteria for acceptance to be defined for each service concerned. An automated registration scheme (eg. based on a web form(s)) will be required to expedite this process, with a guaranteed turnaround for the inclusion of new services and servers.

The policy outlined above may not be effective from the date of firewall deployment, but may be transitioned to in a phased manner, thereby easing the introduction of this service from the user perspective.

3.Limitations

A firewall is not a universal panacea for site security, and is never a substitute for sound systems security management. It is merely one component of an in-depth security architecture. Two particular functional limitations stand out and need to be emphasised.

A firewall works essentially at the connection management level, in that connections are either permitted or not. The firewall is not usually sensitive to the nature of the data carried over a connection, and hence is typically unable to block dubious content, eg. viruses, worms, or other malicious executables. Virus control, for example, is therefore a separate issue for which other solutions are appropriate, eg. the use of anti-virus software on the desktop.

Firewalls are also, self-evidently, only able to control traffic that they forward between inside and outside networks. Systems on the inside may therefore be vulnerable to attacks from other inside systems, since the traffic between any two such machines does not transit the firewall. This fact points up the need for separate security strategies at the departmental (as well as the institutional) level.

4.Conclusions

In common with a small number of other HEIs which have adopted similar technology, UCL intends introducing an institutional firewall to service, with deployment scheduled to take place in time for the 2003/2004 academic session.

The default policy for inbound traffic will be to deny traffic other than for registered systems. An automated registration process will be required to assist this registration process. In practise, there is likely to be a phased approach to realising this policy target.

The leading technology candidate for the firewall role is the Cisco Catalyst 6500 Firewall Services Module. A pilot evaluation of the technology is underway in the UCL IS Network Group.

Bob Lawrence

7th May 2003

The Computing and Networks Users' Forum.

Of course the firewall must permit return traffic corresponding to outbound connections (or nothing works!).

Though no major break-in to a UCL business critical system has yet been acknowledged, there have been many recorded instances of intrusion into departmental desktop and server systems. The costs associated with material loss and recovery from these intrusions can only be guessed at. They are likely to amount to a considerable number of FTEs.

Computer Emergency Response Team. UCL CERT has since become the UCL Computer Security Team (CST).

Though in some cases the firewalls concerned have been very poorly configured and sometimes by a contracted third party.

Specifically, Birkbeck College, the Institute of Education, the London School of Hygiene and Tropical Medicine, and the School of Oriental and African Studies.

See HYPERLINK "http://www.cisco.com/warp/public/cc/pd/si/casi/ca6000/ps4452/index.shtml" http://www.cisco.com/warp/public/cc/pd/si/casi/ca6000/ps4452/index.shtml and related links for a detailed discussion of the FWSM.

For which reason the FWSM is commonly referred to as the PIX blade.

There is a core switch and a MAN switch in each of the Kathleen Lonsdale Building and Foster Court communications rooms. Both KLB and Foster Court core switches are active and load sharing with respect to the rest of the 6500 switch network. The Foster Court MAN switch is essentially a backup for its KLB counterpart.

In firewall parlance, this would also be known variously as the inside, protected, trusted, or secured network. The corollary is that the firewall regards the rest of the world as comprising the outside, unprotected, untrusted, or unsecured network.

An example is a block on port 1434/udp which is associated with the MS SQL Server Slammer worm.

Example include Oxford and Southampton Universities. The former uses Cisco PIX 535 standalone appliance technology.

PAGE 6