skip to content

IT Help and Support

University Information Services


Please note that this service is being discontinued and will end on the 31 October 2019


This document is a revision of the proposal of June/July 2005; it reflects the move from proposal to implementation, but otherwise contains very little new material. Constructive comments are solicited, by email to .

A summary of the technical details is available.

1. Introduction

1.1 The resources of CSIRT and PC support teams are stretched by dealing with hacking incidents caused mainly by host computers in the University becoming infected with a variety of malware programs and by that infection spreading within the University. To ease this, a facility for blocking incoming network traffic destined for high-numbered ports is to be available to institutions on an opt-in basis, and it is hoped that institutions will recognise the value to themselves of opting-in.

1.2 The blocking is implemented between the CUDN and institutional networks so that blocking between JANET and the CUDN, except for certain special cases, is unnecessary. The blocking will prevent TCP connections being opened on high-numbered ports and prevent much communication using UDP; however, there is no plan at this time to block multicast traffic. As at present for the existing port blocks, means will be provided for certain protocols, e.g. ftp, or hosts to circumvent the blocking, but to keep the effort of administering exceptions within reasonable bounds and to ensure that the performance of network equipment in the CUDN is not degraded, some compromise will be needed. It is hoped that most requirements can be accommodated by generic exceptions.

1.3 It is likely that the blocking will have no effect on most of the use of the CUDN and JANET that is related to the principal activities of the University and the Colleges. There are some areas, particularly e-Science research, where the blocking is likely to affect their current practice; subject to resource limitations, UIS will work with such institutions to determine whether or not they will able to gain the security benefits without compromising their work.

1.4 It is likely that the blocking will affect activities such as P2P communications. Where such activity is of clear academic benefit, UIS will endeavour to find a means whereby it can continue; this might, in itself, cause a substantial load on Computing Service resources. Otherwise, if the application cannot be configured to use ports that are not blocked, it will cease to be usable.

1.5 UIS regrets that original timescale targets have not been met. However, the blocking has been implemented on UIS's internal staff network for much of the Michaelmas Term and trials involving other institutions are about to start. If successful, this should lead to a more widespread offering of the facility later in the Lent Term 2006.

1.6 Although the object of a network is to facilitate communication, and port-blocking does exactly the opposite, it is necessary to be pragmatic rather than dogmatic about this: port-blocking can probably help in reducing the scale of infection within the University and is therefore worth trying. However, UIS realises that this issue is contentious (in terms both of restricting service to host computers and whether it will have the desired effect), with people having strong views on both sides - this is as true within UIS as it is in the rest of the University.

1.7 It should be emphasised that the issue of not one of network insecurity, but of host insecurity. All port-blocking can do is a degree of papering over the cracks, but one must not forget that the cracks exist and must be dealt with. The intention of the port-blocking is to reduce the immediate workload and to buy some time.

1.8 Whatever is done, but especially as port-blocking is being implemented, members of the user community are reminded that they are individually responsible for keeping their systems up to date with patches, etc. This point cannot be emphasised strongly enough. For its part, UIS will also look into offering further training opportunities for IT staff in institutions to make them better able to prevent infection within their institution and to deal with it if it occurs.

2. Previous network traffic security policies

2.1 The following policies have been in place for some time and will continue:

  • TCP/IP only
    Only the TCP/IP family of protocols are allowed across the CUDN/JANET interface and the CUDN as a whole, although any protocol is allowed on an institutional VLAN than crosses the CUDN, and IPX is used across PWF VLANs.
  • Broadcast blocking
    Broadcasts (i.e. packets with a destination address of are blocked in both directions at the interface to JANET and between institutional networks and the CUDN. Directed broadcasts (i.e. packets having a subnet broadcast address, e.g. x.x.x.255, as destination address) are also blocked at the interfaces to institutional networks.
  • Anti-spoofing
    Packets are blocked if their source IP addresses are not consistent with the network from which they are received. No exceptions to this policy are permitted.
  • Blocking access to certain services
    Where it makes little or no sense to employ a particular service between networks and the services are believed to be particularly vulnerable to attacks, the port for that service will be blocked at the network boundary (either CUDN-JANET or CUDN-institution, as appropriate). See Port blocks on the CUDN for specific details of blocked ports.
  • Data Protection Act compliance
    Incoming connection attempts from JANET to 'finger' services are blocked.
  • Authentication
    Use of smtp/pop/imap (e-mail) is blocked other than to/from authorised servers; vulnerabilities of various mail implementations are also of concern.
  • Network reliability/consistency
    DNS connections are blocked other than to authorised nameservers.

Except where indicated, exceptions to the policy are permitted on presentation of a suitable case.

Details of the opt-in high-numbered incoming port-blocking scheme

3.1 TCP
For an institution that has opted-in to the scheme, the blocing will apply to IPv4 TCP connection attempts from the CUDN to institutional (departmental or College) networks using destination port numbers between 1024 and 64000 (64000 being, essentially, an arbitrary number) as described below.

3.2 UDP
UDP packets with both source and destination ports between 1024 and 64000 will be blocked. (The earlier suggestion of reflexive filtering has turned out to be impractical.)

3.3 IPv6
The port blocks will not be applied to IPv6 traffic for the time being although, if the situation warrants it, the blocks may be extended to IPv6 at short notice.

3.4 Multicast
The port blocks will not be applied to multicast traffic for the time being as, currently, use of multicast has not been seen to any extent in malicious activity (other than Denial of Service attacks).

3.5 Ports >= 64000
Ports numbered 64000 (an arbitrary number which might be varied as a result of experience) or above will not be blocked because, as far as UIS is aware, these have not so far been used for malicious activities to any extent. These ports can therefore be used for activities that would otherwise be blocked; it may be necessary to configure the application software to make use of these ports, rather than those with lower numbers. It has been suggested that the blocking should be applied to all ports (other than those excepted or involving excepted addresses); this has already been done successfully by at least one institution within the University. This might be considered if circumstances warrant it, but is not envisaged at the present time.

3.6 Exceptions
It is recognised that exceptions to this policy must be allowed. To avoid affecting the performance of the CUDN, the number and complexity of the exceptions must be kept within bounds. UIS anticipates that most exceptions will be able to be accommodated using rules of the form: either

  • allow any port for a specific address (or address range), or
  • allow a specific port for all addresses.

There may be a need for a number of exceptions of the form "allow specific port for specific address" (for example, port 53 for authorised nameservers). It is hoped that the number of these will be comparatively small.

4. Additional measures

4.1 In addition to this port-blocking proposal, the following additional measures are being taken to increase the basic level of host security within the University:

  1. UIS's (Windows) Security CD is being reviewed so that it has wider applicability (currently mainly College COs).
  2. A Windows Updates Server is being commissioned: this will provide updates automatically to hosts in the University that are appropriately configured.
  3. Extending the applicability of the "friendly probing suite" to Microsoft Windows hosts is being investigated.

5. Anticipated consequences of deny-all-incoming port-blocking

5.1 Although this port-blocking will not affect normal use of common protocols such as http (web), smtp/pop/imap (e-mail), it is likely to affect peer-to-peer protocols (file-sharing, messaging).

  1. Reduction in the consequences of malware infection (through whatever means) both to the originally infected host and to other vulnerable hosts in the University. Consequential reduction in the amount of staff time spent by CSIRT and others on such things.
  2. A flow of requests for exceptions resulting in a drain on staff time in processing and implementing these. A dynamic compromise will be needed to minimise the overall amount of staff time (CSIRT, networks, admin). The other points below indicate areas that are likely to generate exception requests.
  3. Discontent across at least the student community at the adverse effect on P2P (peer-to-peer, often filesharing) network applications is anticipated. Typically, such traffic uses high-numbered ports, but this is not necessarily the case; some P2P applications have been re-engineered to use port 80 (http/web). Also, certain popular semi-recreational applications, such as many of the instant messaging applications, are known to be port-agile and may well not be affected by the blocks. Although some consider P2P to be a Bad Thing, UIS has not taken a position on this, though it does not condone copyright breaches which may associated with such activity. UIS has noted that the most active area of research in grids at the moment involves the convergence of P2P technology with Grid technology to form peer-to-peer grids.
  4. Exceptions will need to be provided for Globus-related (grid) traffic. At Cambridge, there are already at least four Grid projects involving significant traffic in and out of Cambridge; there could be others and it is quite likely that UIS would not know about them.
  5. Exceptions may be needed for e-Science Condor pools, which include the use of UDP.
  6. Exceptions may be needed for Computer Science and Engineering networking research requiring use of arbitrary ports.
  7. Exceptions will be needed for videoconferencing; whilst bypassing the blocks on the basis of IP addresses would probably suffice for fixed videoconferencing facilities, this would not be feasible for desktop videoconferencing. One solution might be to employ a proxy through which Raven-authenticated videoconferences would be allowed. Further study is still needed.
  8. A specific exception will be needed for the protocol using port 6000; however, it is strongly recommended that SSH be used as it will provide secure communication.
  9. The 'friendly probing' carried out by UIS on visible hosts across the University would, prima facie, be affected by the extension of the port-blocking. However, it is straightforward to provide a bypass for the blocks for the communications from the subnet from which the friendly probing is run.
  10. The port-blocking may result in the relative proportions of network traffic generated by different sectors of the Cambridge community changing, and this would cause consequential changes in the distributed JANET network charge for those sectors.

6. Avoiding the port-blocks

6.1 The port-blocks can be avoided by any of the following means:

  1. An institution may choose, as a whole, not to opt in to the port-blocking. Institutions that make this choice will be expected to have adequate IT expertise to be able to deal with any infections without requiring significant assistance from UIS. As is anyway the case, the institution might have to be disconnected from the CUDN until any infection had been dealt with.
  2. Subject to its being practical to implement, an institution may opt not to have the blocks applied to certain address ranges at its interface to the CUDN. Again, institutions that avail themselves of this will be expected to have adequate IT expertise to be able to deal with any infections without requiring significant assistance from UIS. As is anyway the case, the institution might have to be disconnected from the CUDN until any infection had been dealt with.
  3. Individuals may request that the blocks are not applied for a host that they are responsible for via their institutional Computer Officer. Individuals or their institutions that avail themselves of this will be expected to have adequate IT expertise to be able to deal with any infections without requiring significant assistance from UIS. As is anyway the case, the institution might have to be disconnected from the CUDN until any infection had been dealt with.
  4. Certain protocols are already treated specially by the CUDN at the JANET interface; for example, incoming ftp transactions are allowed to ftp servers that have been registered with UIS. This facility might be extended to other protocols.
  5. It is possible to evade the port-blocking by using a proxy. As with tax, avoidance is acceptable, but evasion is not. Except where specific approval has been obtained from UIS, the setting up or use of an unauthorised proxy to evade the port-blocking could be considered as contravening Rule 3 of the Information Services Committee Rules, specifically "by deliberate [or] wilful ... act, jeopardize the integrity of data networks, computing equipment, ... ", and disciplinary action might be taken against the offender. The e-Science community has developed NAT/firewall traversal techniques such as GCB (Generic Connection Brokering) and it is possible that this technique is also used by others; the position of GCB regarding this point is for further study.

6.2 There are no plans to set up a vetting committee of either UIS or the Information Strategy and Services Syndicate. Instead, UIS would normally act on the requests of appropriate institutional Computer Officers, although it might discuss certain cases with the CO.

7. Introduction of the port-blocking service

  1. UIS has been piloting the port-blocking on its own staff network.
  2. A small number of volunteer institutions will be chosen to pilot the port blocking. The pilot will start with University departments as more severe problems with College traffic are anticipated.
  3. Colleges will be invited to volunteer to join the pilot.
  4. Subject to the piloting being satisfactory, a full service will be offered.