Sunteți pe pagina 1din 6

Network Group

The UCL Institutional Firewall Project

Version:
Date:
Author:
Document details:
Last Updated:

1.0 (Draft)
7th May 2003
R.Lawrence
institutionalfirewall.doc
6th May 2003

The UCL Institutional Firewall Project

At the Colleges CNUF1 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 inbound2. 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.

The Computing and Networks Users' Forum.


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

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 consequence3. Formal
recognition of this situation came with the establishment of the College CERT4 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 boundary5.
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 HEIs6 connecting
under UKERNA contract, and sponsored connections.

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.
4
Computer Emergency Response Team. UCL CERT has since become the UCL Computer Security
Team (CST).
5
Though in some cases the firewalls concerned have been very poorly configured and sometimes by
a contracted third party.
6
Specifically, Birkbeck College, the Institute of Education, the London School of Hygiene and Tropical
Medicine, and the School of Oriental and African Studies.

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.1

Technology

The project has identified the Cisco Catalyst 6500 Firewall Services Module7 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 based8. 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 switches9, 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.2

Policy

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

See http://www.cisco.com/warp/public/cc/pd/si/casi/ca6000/ps4452/index.shtml and related links for


a detailed discussion of the FWSM.
8
For which reason the FWSM is commonly referred to as the PIX blade.
9
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.

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 network10 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.
2.

A default permit stance on all outbound traffic.


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
activity11, 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

10

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.
11
An example is a block on port 1434/udp which is associated with the MS SQL Server Slammer
worm.

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 antivirus 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 HEIs12 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

12

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

S-ar putea să vă placă și