Personal machines
From time to time people enquire about the possibility of connecting their own laptop or even desktop to TCM's network and running it themselves. Although I am never wildly ecstatic about such proposals, due, in part, to some interesting experiences in the past, it is generally possible. In general the use of the wireless service is easier for everyone, although sometimes a wired connection id indeed more appropriate.
The following sets out our current position on such `private' connections, and tries to strike a balance between providing a useful service, and preventing people causing a nuisance on the network. It is a tediously long list of `don'ts', and I would much prefer it simply to say `please, go ahead, and use a little common sense,' but experience has shown that this does not work.
The executive summary is that we do not object (in general) to people attaching computers as long as they are being run fairly competently, which usually means disabling as many unnecessary features as possible. However, you MUST ask first before connecting something to the network, and must NEVER disconnect something else to make room for your computer.
You will need an IP address of a suitable shape for TCM (College ones simply will not work, due to the routing in Cambridge).
Other regulations
TCM is bound by CUDN rules, JANet rules and UK law. A useful summary of these is provided by the CS, although in all cases contact with the CS's IP Register should be done via TCM's COs.Ownership, insurance, electrical safety, commercial use
This document is written by TCM's CO. His remit covers none of these interesting issues, so nothing is said about them here, beyond that they are issues which may need considering.
Who is responsible for the system?
Either the system is fully integrated into TCM's system and run by TCM's COs, or (much more likely) it is not. There is no half-way house. It is not possible for TCM's COs to be responsible for some aspects of a system which has been installed or configured by someone else.
What operating systems are supported?
If run by TCM, the version of our choice of an O/S we currently support. Requests to support things we do not currently run are unlikely to be well received unless there is a strong academic case.
If run by you, anything you like.
What can TCM provide?
Currently a direct connection its network, which is in turn connected to the CUDN. Some ports are blocked at the boundary of TCM's network, and also at the boundary of the CUDN.
However, due to both a shortage of IP addresses in the University, and security concerns, we prefer to offer addresses in the "private" (aka RFC1918) range of addresses. From these it is possible to connect to, and be connected to by, any machine in Cambridge, and, by the magic of NATing, one can connect to any machine with a public address outside Cambridge. It is just incoming connections from outside Cambridge which are impossible. (Most home routers act in precisely this fashion too.) I tend to take the view that either people understand the limitations of these addresses and can work around them, in which case they do not need public addresses, or they don't understand them, in which case they are not safe with public addresses. However, exceptions have been made...
We do offer DHCP for the "private" address range, which, assuming your College also offers DHCP, allows you to plug your machine in to our network or your College's without any reconfiguration (assuming that you have registered your machine with the relevant COs first).
In addition, all our printers are accessible via our print servers and the CUPS protocol.
What will TCM not provide?
We will not recognise any form of client-side authentication.
How should any machine connected be configured?
Securely. It is important that people outside TCM (or Cambridge) cannot use your machine to inject traffic onto our network (or syphon it off), and sophisticated OSes (such as Windows NT/2K/XP, MacOS X and Linux) provide all the tools a hacker needs to do this.
For those who insist on running systems which offer significant external services (typically UNIX), the list of the good, bad and ugly is:
We like: ping. Actually, ITS rules require that one responds to ICMP echo requests (i.e. pings) from 131.111.12.0/24 to aid their investigations, and we'd add 131.111.62.128/25 to that list to aid ours.
We can ignore: sshd, lpd.
We absolutely cannot tolerate: mail servers (pop, imap or sendmail), news servers (nntp), netstat, bind, IRC, NFS servers, anon ftp or other forms of anonymous file sharing, passwordless accounts, 3rd party accounts of people not otherwise entitled to an account in the University.
We don't like: daemons running as root whose functioning you cannot explain and justify.
We might permit, after negotiation: httpd and 3rd party accounts.
To put it another way, we do not mind (much) what services are available from the console, we mind a lot what services are offered to the world.
The only other way of causing major upsets is by excessive use of broadcasts or by emitting malformed packets. It is trivial to stop the whole of TCM's network like this...
Ongoing work
The UCS has recommendations (to be found on their security page). Many can be summarised as keeping the thing patched.
Note that many operating systems cannot be patched because the companies responsible for them no longer support them. Currently (December 2012) this list would include OpenSuSE 11.4 and MacOS 10.5.
People running Windows will want to ensure that they have decent anti-virus software on their computers (it is free within the University).
The ultimate sanction
Any machine which is persistently found in an insecure state will, after a reasonable number of warnings, be disconnected, possibly permanently. This group is far too attached to its computers to permit anything to remain that is a risk to them. We also owe this service to the rest of the University. One person's recklessness can easily cost another part of the University substantial sums, as has been shown recently.
Have fun
And try to find that elusive balance between running a computer and actually doing some research.