System Security and its Impact on a Merged Informatics Computing Environment

George Ross

Version 1.21 of April 29, 1999

0 Summary

1. For the avoidance of doubt and to clarify the position for everyone, a security policy framework should be agreed at a Division-wide management level.

2. It’s not obvious that a single unified computing environment is sensible, though it is attractive at first sight, and in any case the existing mechanisms would not scale. There could be advantages to adopting an “islands of trust” model instead. Authentication mechanisms need thoroughly investigated before any decision can be made, and difficulties with, for example, NFS could prove to be show-stoppers.

3. The network can not be assumed to be secure. Mechanisms must assume that machines can be impersonated, and that the network can be snooped and packets spoofed.

4. Software distribution needs careful planning if trojan horse possibilties are to be minimised. At least one existing mechanism is known to be very insecure, and effort should be invested in its replacement.

5. External connectivity needs review; also inter-island connectivity if that model is adopted. Existing firewall mechanisms at KB should be further developed and extended to the other sites of the Division.

6. PGP should be documented and deployed. We should definitely consider investing in a local keyserver. This does not really need to wait on a merged environment, though it is sensitive to the mechanisms used for software installation.

7….

1 Introduction

Following the establishment of the Division of Informatics it has been suggested that the various disparate computing environments which previously existed should be “merged.” This document attempts to consider just those implications of any merger relating to system security, though it is naturally hard to treat this in isolation. Most of what is written here is independent of the actual platforms in use; exceptions are indicated as required.

For the purposes of the discussion here three models are considered:

1. The status quo. The existing arrangements would remain in place. This is assumed to be undesirable, and is expected to evolve into or be replaced by one or other of the following two.

2. A completely uniform service, with all machines having identical access rights to all services. This is probably what comes to mind first when the idea of a merger is first mooted. It’s not at all obvious, though, that it’s the most sensible model, or even that it’s practicable.

Security in a Merged Environment  Page 2 of 14

3. Disjoint “islands” of various sizes ranging from the single laptop to, say, the Division’s entire undergraduate teaching machine complement. Machines might be able to move between islands, or be members of more than one at a time. Islands could be administratively imposed, and don’t necessarily imply disjoint kit. It could be argued on the one hand that this is a “second-best” approach and that we should be striving for uniform accessibility for resources; but on the other hand pragmatically recognising that this may be an unachievable goal and designing around that fact could result in more relevant boundaries being drawn.

The current practices of the former Departments of the Division are summarised in section 6 starting on page 12. Security involves a three-way tradeoff between: degree of protection; convenience to the users; and cost, in both money and personnel terms.

In any discussion of security the threat model should be considered early on. In the case of the Division there are basically three threat sources:

• Members of the Division itself, who on the one hand might be expected to have a vested interest in maintaining security; but who on the other hand possess particular knowledge of the Division’s systems and any weaknesses in them, and might have reasons for wanting to exploit those weaknesses^{1};

• Other members of the University, over whom there are reasonable sanctions available if they are detected; and

• Users of the Internet at large, who are for all intents and purposes completely anonymous and over whom we have no control whatsoever.

Nevertheless, there is generally no attempt to distinguish between these in the remainder of this document.

2 Network Security

Once upon a time it was reasonable to trust the network. Machines were large, rather heavy and pretty expensive, and making a physical connection involved drilling cables or connecting to scarce interface ports. It was reasonable to assume that only those machines which should be connected were connected.

This is no longer the case. Structured wiring is used everywhere, and laptops are small, light and cheap and can easily be sneaked in and out as required. Network addresses can be set so that any unsupervised machine can easily be impersonated almost completely invisibly.^{2} Traffic can be injected with arbitrary addressing, and anything on a shared medium can be snooped for “interesting” information. It is therefore not sensible to rely on a machine’s network identity for any security-related purpose. A machine-specific cryptographic key gives some improvement; but ideally the machine’s identity should be irrelevant, with the user’s identity being all that matters.

Ether switches (multi-port bridges) can go some way towards hiding traffic from snoopers, as they learn the hardware addresses on their ports and forward packets only as necessary, but they are fairly easy to get around with a little effort. Encryption would render all traffic unreadable except to the intended recipient, and should be seen as the most complete answer; but if this is not possible then segmenting the network into trusted subnets could be helpful in some situations.

Switches have their own security problems too, of course. They are often remotely configurable using telnet, SNMP or http, with passwords being transmitted in clear for all to see, and it has been by no means uncommon for manufacturers to put back-door passwords into the firmware to aid their support teams. An attacker who controls a network switch could easily divert packets for his or her own ends.

1In one ex-DCS security breach (which was spotted; there may have been others which weren’t) the pattern was such as to suggest that exam papers in preparation were the intended target.

2In principle it’s possible to fingerprint machines by looking at subtle timing characteristics of their protocol stacks, rather in the way that a morse key “fist” can be identified and used for traffic analysis. In practice there are easier ways to deal with the problem.

Users connecting in from remote sites have, of course, no option but to send their packets over untrusted networks. As well snooping, attackers who control the packets’ routing can easily inject arbitrary commands, or indeed anything they like into the data stream, with the user being completely unaware that anything untoward is happening. One-time passwords can reduce the exposure due to snooping, but only strong end-to-end cryptography can offer a truely secure connection.

Any machine which ever makes a connection to another one can be attacked and perhaps compromised using chosen sequences of packets sent over that connection. In addition to plain simple bugs and the kinds of connection hi-jacking mentioned above, there are a couple of generic attacks against network code which are widespread:

Sequence-number prediction is the development of address-spoofing attacks against UDPbased protocols to encompass TCP. The simple UDP case involves a service, such as NFSv2, which relies on the authenticity of a packet’s “source” address to correctly identify a machine and thus authorise some action — for example, to delete some file. The attack here is simply to send packets claiming to be from some other authorised machine (additional required information is often easily obtained or guessed), with the fact that any responses go elsewhere being irrelevant. For TCP, with its three-way handshake when a connection is established, the loss of those responses might be expected to render this kind of attack unworkable, but in practice it is often possible to predict what the responses would have been and to perform a successful attack based on those predictions and without ever seeing any responses. rlogin and rsh are vulnerable to this attack. Careful filtering by firewalls together with RFC1948style sequence numbers can reduce exposure, but trust based on source addresses should never be extended beyond the boundary of a network’s administrative domain.

Buffer overflows are a rather pervasive form of security hole, where a running program or daemon, or a library used by one, does not adequately check the size of input passed to it in its environment, its command-line or through a pipe or socket. Attacks take the form of overrunning an internal buffer, either in the program itself or in a library that it uses, with carefully-crafted data such that the stack-frame is overwritten. A function-return may then result in arbitrary code being executed. Local users may be able to trick setuid programs into giving them enhanced privileges, while remote attackers may be able to coerce a daemon into giving them a shell on a server machine. Although this sounds a rather unlikely sequence of events, buffer overflows are actually rather common, and many manufacturers’ patches are issued to address issues like this which may have entered the code-base before the problem was properly recognised.

Should we proactively scan centrally-managed and self-managed machines? After all, there are numerous scanning-kits freely available and apparently plenty of people who run them against anything that catches their attention. Scanning the former might show up problems with our configurations. Scanning the latter wouldn’t really help much with security, as we wouldn’t want self-managed machines in trusted positions anyway, but it could be helpful to the owners of the machines. On balance it’s probably a useful service to offer, but we shouldn’t rely on it.

How can external (and inter-island) connectivity be controlled? The two main mechanisms are to strengthen machines’ own defences and to interpose a “firewall” of some kind.

Strengthening: This operates at several levels:

• Keep up-to-date with the patches. This can’t be emphasised too much.

• The machine’s configuration should be reviewed and modified so that only those services which need to be running actually are running. Anything which isn’t necessary for the machine or its user to be able to work should be disabled. A service which isn’t running can’t be attacked and used to break into the machine.

• Those services which are necessary, which are started from the inet daemon, and which can be controlled using the “TCP wrappers” (section 5.1) should be so handled.

• Many services can not be wrapped. If a machine is exposed and must run one of these services then IP-level filtering software (section 5.2) should be installed.

• Inherently-secure services, such as ssh (section 5.6) should be used in preference to inherently-insecure ones, such as rsh.

While strengthening is generally desirable, particularly for portables which may have to operate on arbitrary potentially-hostile networks, it is unlikely that all the right tools would be available for all types of system which might want to be connected to the Division’s network. Therefore mechanisms, such as firewalls, must be built-in to the network infrastructure to control traffic.

(It goes without saying that all the Division’s systems should in principle be hardened against crack attempts as much as possible. In practice this is likely to be unachievable, particularly when self-managed machines and part-time administrators are considered.)

Firewalls: There are two basic types of firewalls: (stateful) packet filters and application-level relays. Packet filtering firewalls operate by passing or blocking packets based on source and destination addresses and ports and on various protocol-level flags. If state is kept it can allow the firewall to associate packets together into a connection or stream, which can then be subject to higher-level rules; but state can be hard to maintain in the presence of asymmetric routing. In effect, the kind of strengthening described above can be regarded as a distributed firewall, and similar tools used for both.

Application relays might be generic in form, such as the socket-level “socks” (section 5.9), or one of a number of protocol-specific tools which are available.

What kind of inbound connectivity is desirable? UDP can be hard to deal with without maintaining state in the firewall, because of its connectionless nature, and so may have to be completely blocked apart from specific services (for example DNS, NTP). Inbound TCP to “privileged ports” should certainly be controlled, but the advent of remote-control packages such as Netbus and BackOrifice make any kind of unrestricted inbound connectivity unsafe.

And which machines should be allowed to connect out? All of them, or only a few centrallymanaged ones? Can proxies and application-level relays provide sufficient functionality for most cases? Is it actually necessary for all machines to have direct Internet access?

Allowing unrestricted outbound connectivity but restricting inbound connections to only a few controlled machines might be an appropriate compromise. In any case, a clear statement of policy requirements would be highly desirable, though likely to be hard to obtain. In the absence of a clear, approved policy any restrictions are likely to be perceived as arbitrary, even though there may be very good reasons for them. In defining policy the options and likely consequences thereof need to be clearly spelled out to the policy-making body so that a properly-informed assessment of the Division’s best interests can be made.

3 Authentication

“Authentication” is the process of deciding whether a would-be user is actually who he or she claims to be.

Where a machine is only used by one or a small number of users and makes no use of external services then authentication could be done locally using well-known methods. However, where there are clients and servers involved then somehow the user has to be authenticated to the server’s satisfaction to establish their identity.

There are three basic authentication mechanisms which could be used:

3.1 Be trusting…

Each machine in the unified Informatics domain could locally authenticate its users in whatever way it felt like. Servers would then trust the client machines not to lie when they requested services on behalf of those users.

This could be almost reasonable where all the client machines are centrally managed and secure and the supervision of network ports is such that personal laptops can not be substituted for “official” machines. It does mean that a vulnerability in any one machine can easily be exploited to break security generally; and in the presence of self-managed and personal machines it essentially equates to there being no security at all.

HOWEVER… the assumptions being made here are completely implausible in general, though they might work within small islands of trust; and this is definitely not a sensible model to adopt Division-wide. Nevertheless, this is how the existing NFS services are operated, for want of a better mechanism, and as a result filesystem security is essentially illusory.

3.2 Public key encryption

Public key cryptography relies on mathematical operations which are easy to perform in one direction with some partial information but hard to invert without complete information. The partial information is the “public key,” while the complete information gives the “private key.” Generally the possession of the public key allows either for the encryption of messages which can only be decrypted by the private key or for the decryption of messages encrypted with the private key. Guessing the private key is made very unlikely by choosing it at random from a very large keyspace, while exhaustively testing each possible private key should take longer than the lifetime of the Universe. Servers can rely on the user being correctly authenticated because no-one else is assumed to know the passphrase that unlocks the private key.

This kind of mechanism is well-suited to laptops and personal machines, where the public key can be distributed around as necessary while the private key never leaves the user’s machine. It doesn’t fit quite so well when there’s a shared pool of workstations, as the passphrase is then the only protection for the private key. And for multi-user machines there’s always the possibility that the user’s cleartext private key could be extracted from a kernel or daemon buffer somewhere.

SKIP (section 5.3), ssh (section 5.6) and SSL (section 5.8) all work like this. Sun’s “secure NFS” does too, but implementation limitations make it not a lot stronger than “trust the client.”

3.3 Trusted third party

In this approach the user proves his or her identity by convincing a trusted third party (“TTP”) that they know a password or passphrase. Servers then rely on the TTP for authentication. Examples of this are Kerberos and its Heimdal non-US reimplementation.

There are a few disadvantages to this approach:

• The TTPs (“Key Distribution Centres” or KDCs in Kerberos-speak) are in an extremely privileged position, and are therefore particularly tempting targets for attack. It is essential that they, and any backups made of their filesystems, are properly secured and kept in locked rooms to which only a very few people have access.

• The KDCs and the networks between them and the Division’s other machines have to be completely reliable if they’re not to be failure points. Ideally the KDCs would be replicated and distributed (and locked away in several rooms!). Unfortunately, the added complexity also makes the entire system more vulnerable through procedural slip-ups.

• Laptops, in particular, are likely to want to operate from remote sites. Having to access a KDC or work around it being inaccessible wouldn’t be very convenient.

• This has similar problems on multi-user machines as does public key cryptography. The user’s ticket has to be stored on-line somewhere, and if exposed can be used to impersonate the user. Furthermore, the kernel may rely on the user’s local identity to determine which ticket to send from those of all the users it has available, as for example with “Kerberised NFS”, and so simply having the ticket exist on the machine may be enough to allow impersonation. Machines still therefore need to be made crack-resistant.

• Programs have to be “Kerberised” in order to be able to participate, requiring source code access. While a number of common utilities have already been dealt with, on some platforms at least, many have not. In particular, Kerberos-authenticated NFS has been “imminent” for ages now, but unfortunately nothing really usable has yet emerged; and it’s not at all clear when (or indeed if) anything will as encryption technology becomes another political football. If we want to follow this route we should expect significant implementation effort to be required, and even then full integration may never be possible.

Against that, with some work this method has the potential to provide completely uniform authenticated access to those services and from those machines which know how to use it. There are some sites^{3} with very large Kerberos installations; and Microsoft’s NTv5 can apparently use Kerberos for authentication, though with proprietary extensions, which might give a push to the more widespread Kerberisation of client programs. And the possibility of using multiple realms whose KDCs mutually trust each other could ease transition problems at the cost of some loss of transparency.

3.4 Passwords

Passwords are often weak, and we should pro-actively try to crack them so as to weed out unacceptable ones. If we don’t then someone else will sooner or later. We might want any passwordchanging commands to refuse to accept weak passwords in the first place. The standard UNIX password encryption algorithm was designed several years ago, and while the compromises made were appropriate then it’s now a realistic proposition to crack it by simple brute-force; and it therefore makes sense to enable alternative stronger algorithms where possible. We should also offer one-time passwords for external access to those who want to use them, and encourage their use where ssh isn’t an option for some reason.

4 Software Distribution

Problem: how to allow people to install things without opening up to trojan horses.

Example: ex-DCS’s Solaris mechanism. Nearly 100 people can install packages. Any one of them could introduce a trojan horse, either deliberately or accidentally or through their accounts being cracked. Combined with NFS’s security weaknesses, anyone with physical access to the network has, in effect, full write access to the local-binary filesystems.

Example: ex-DCS’s Linux mechanism. Anyone can create an SRPM, but only a few trusted people are able to install binary RPMs. The idea is for those people to take users’ SRPMs, look them over for a few obvious problems, and if OK to then install them. Ultimately RPMs would be PGP-signed, to guarantee that even if rogue ones were somehow to get into the repository they still wouldn’t be installed on machines. There could also be less-well-vetted “user contributed” areas, or project or Institute areas, again with PGP control.

Perhaps the default PATH should be less all-embracing, with more things made available through an opt-in mechanism?

3MIT of course, UMich, and Penn State, though the last at least is apparently exercising only some of Kerberos’s capabilities.

5 Particular Services

In this section we consider the problems and advantages peculiar to particular services.

5.1 TCP wrappers

For convenience of programming and configuration, and to minimise machine resources used, many services are not run directly at boot time, but instead are started as required by the inet daemon. Many of these can have their use controlled by “wrapping” them: interposing a small control program between the inet daemon and the specific program that handles the service. Access can then be restricted to various classes of remote machine, with connections being logged, and arbitrary commands can be run if required.

There are restrictions on what can be wrapped in this way. The most restrictive of these is that each invocation of the specific program must handle only one connection from one remote host, and must terminate when this connection is closed. Multiple connections, even from the same host, are handled by running one new invocation for each connection. Most TCP-based protocols work in this way, and so can be wrapped, but UDP-based ones generally don’t and so can’t be. And of course only programs started by the inet daemon can be handled in this way (unless they deliberately call the wrapper library themselves, as ssh can be configured to do).

Unfortunately many important and vulnerable services are not able to be wrapped. The NFS and lock daemons, the mount daemon and the RPC portmapper are just a few.

5.2 IP filtering

IP filtering, for individual machines and for firewalls, operates at the lowest level of the protocol stack. Packets are inspected before forwarding or passing upwards, and perhaps blocked based on criteria which can include: source and destination addresses and ports; interface through which the packet arrived or is to be sent; various flags at the IP and TCP levels; the contents of any byte or bytes of the packet; and state-tables based on traffic which has gone before.

A fairly sophisticated package (IPfilter) exists for Solaris, *BSD, IRIX, and some non-glibc versions of Linux; and a rather less general capability (ipchains) is built-in to later Linux kernels.

5.3 SKIP

SKIP (“Simple Key-management for Internet Protocols”, http://www.skip.org/) offers secure networking at the IP level. It’s based on X.509 public key certificates. It’s available from Sun for Solaris and Windows, and in alpha form from ethz.ch for Solaris and Linux. SKIP authenticates the hosts at the end of an IP conversation rather than the users of those hosts, which is an improvement but still insufficient for our purposes.

It’s not clear that there’s much development going on at the moment.

5.4 IPv6

IPv6 is the future standard version of IP, prompted by the feeling that the existing IP(v4) address space is too small and its lack of structure makes routing hard. The main point of interest here, though, is that it features built-in encryption mechanisms. Like SKIP, IPv6 promises to offer security at the IP level, but it’ll be quite a while before it’s ubiquitous enough to solve (some of) our problems. And again this authenticates the machines on the ends of a connection and not their users.

5.5 X

X does not have a particularly strong security model. There have been attempts in recent versions to improve this, but they’re not really widely deployed. In general, only the initial connection from a would-be X client to an X server is checked in any way, and if that test is passed then the client can do any valid X operation to all of the windows opened on the server. There is no concept of windows being “owned” by a connection or by the client which first created them.

There are two common X connection authentication mechanisms in use. One is host-based, and in addition to all the usual spoofing problems that that brings it does not distinguish between different users on the connecting host. This is not a sensible mechanism to use in general, and particularly not when multi-user machines are involved.

The other common method is “MIT magic cookie” authentication. Each time a new X session is started a large random number is generated, either by the session scripts or by the xdm display manager daemon. This cookie is passed to the X server and is also stored securely in the user’s filespace, and it can therefore act as a shared secret with which to “guarantee” the identity of a connecting user. There are a couple of problems with this, however:

• the X protocol is not encrypted in any way, and the cookie is passed in the clear when a connection is established; and

• the cookie is valid for the entire life of the X session, so it may be valuable for a long time after it has leaked.

ssh’s “one-time cookies” (section 5.6 below) eliminate the first problem and much reduce the window of vunerability for the second, but nevertheless X security still leaves a lot to be desired.

5.6 ssh

ssh provides encrypted end-to-end connections for remote login and copying operations. It first uses the public and private keys of the target machine to establish an ephemeral symmetric session key which is then used to encrypt all subsequent traffic over the link.^{4} As well as giving privacy, encrypting the link makes the connection much harder to hi-jack (section 2) as knowledge of the session key and of the cryptographic state are both required in order to inject anything meaningful into the data stream. ssh works over both high-speed and low-speed networks, and contains datacompression options which are particularly effective in the latter case.

Depending on how it is configured, three forms of authentication are possible:

RhostsRSAAuthentication: similar to rlogin using a .rhosts or .shosts file, but with the additional requirement that the public keys of the participating machines must previously have been made known to the other ends (by some out-of-band mechanism). This isn’t really much more secure than ordinary rlogin, other than being reasonably immune to the usual spoofing attacks.

RSAAuthentication: where each user has their own public and private keys. The private key is kept on the user’s own machine, protected by a passphrase. The public key is installed on all the user’s target machines, either by the user himself or herself or by a system manager.^{5} Then the user is allowed to connect if the calling program is able to encrypt and decrypt using the private key, the assumption being that only the user would have known the passphrase to make that information available. The user doesn’t need to know a password on the target machine for this mechanism to work, or even have one set at all, which could be attractive for special purpose machines such as mail servers.

For the user’s convenience, ssh provides an agent daemon which can have the user’s private key loaded into it so that the passphrase need only be given once rather than for each separate connection. This is most useful in the case of single-user desktop machines or laptops.

4The system manager can choose as default and the user optionally prefer one of: IDEA, blowfish, DES, 3DES, “arcfour” (an RC4 re-implementation).

5By definition it doesn’t matter who knows the public key.

(If the user has a ssh identity (a personal public/private key pair) then the ex-DCS standard login environment will automatically wrap the agent around the X session for console logins. X-terminal logins are deemed to be less secure, and the agent is not automatically started in these cases.)

Password: if all else fails the target machine performs the usual login authentication, based on username and password.

As well as providing simple remote logins, ssh also knows how to forward X and other TCP connections securely. The latter can be used to tunnel such things as POP and IMAP, rsync, amanda, CVS and rdist.^{6} The X forwarding also generates an ephemeral “magic cookie” which becomes invalid when the connection is closed, thereby much reducing that window of vulnerability. Port- and X-forwarding can be disabled by the user as command options.

5.7 telnet, rlogin

Traditional telnet is, of course, vulerable to sniffing and spoofing (section 2), as well as being less capable than ssh in other ways. It is often, however, the only option available, and so one-time passwords should certainly be available on any telnet servers.

rlogin and rsh are usually set up such that a list of machines is configured by the system manager and user which allow login with no further authentication. In general, however, the names and addresses of remote hosts are easy to spoof and can not be trusted, and so these applications must be deprecated except under particular limited circumstances or when operating in a fully-Kerberised environment.

5.8 SSL

“Secure sockets layer” — https, maybe IMAP.

5.9 SOCKS

Provides a mechanism by which connections can be relayed between machines even though there isn’t a direct connection between those machines. Useful in a firewalled environment.

5.10 Mail transmission and storage

Email, particularly to and from outside sites, can traverse many networks of unknown cleanliness and sit around in the spool areas of various mail relay machines before it gets to its final destination. Realistically, the only way to guarantee that only the intended recipients can read it is to encrypt it. PGP and, perhaps, PEM are the obvious candidates.

5.10.1 PGP

PGP is a de facto standard for secure email. Many mail agents support it, either directly or through plug-ins, on UNIX, Macs and Windows machines.

PGP is based around public key cryptography. Each user has a public key which is widely published and a corresponding private key which is kept secret and encrypted with a passphrase. These are used both to sign messages and to encrypt them.^{7} Messages are signed by encrypting a digest of the message with the sender’s private key. Since that key is by definition private this is something that only the sender could have done. Anyone can verify the signature by decrypting the digest using the sender’s public key and checking that it matches the message.

6… and presumably also NFSv3/TCP, though I’ve not actually tried it yet …

7In fact, because public key operations are slow, symmetric key encryption using generated per-message keys is used for the bulk of the work, with the public key methods being used solely to protect the message key.

Secrecy is done by encrypting the (possibly signed) message with the recipients’ public keys. It is then unreadable by anyone else, including the original sender.

PGP doesn’t have a hierarchical key structure, unlike X.509. Instead it relies on a “web of trust”: users sign others’ public keys to indicate that they believe those keys really belong to those corresponding other users (note that this doesn’t mean they necessarily trust the people whose keys they sign). To make this process easier, each key generates a corresponding “fingerprint” which sender and recipient can compare to ensure that they really are talking about the same key.

Trust is not automatically transitive, but instead each user can individually select the reliability as an “introducer” of any other key owner. Some may be regarded as good enough to confirm the identity of a new key; or several partially-reliable introducers all indicating the same thing might be regarded as sufficient. In any case, PGP will indicate the current level of faith in a signature when it verifies a document signed by it. And of course, a user should certainly ensure the validity of another’s key before sending anything confidential encrypted with it.

PGP public keys can be propagated in many ways. Sometimes they are simply mailed around. They can be published on users’ web sites^{8} or by FTP or even finger. There is also a world-wide network of “keyservers” which act as well-known publishers of public keys: users submit their keys by mail and can make queries by mail or through a web-based interface. PGPv5 knows how to interact with the keyserver network.

Ex-DCS ran a keyserver for a while as an experiment to try to get a feel for the amount of resources required — relatively modest CPU power would suffice to handle the query and update load (roughly one every three or four seconds, on average), but the keyring databases are already rather large and growing, and several Gb of reasonably fast disc would be necessary.

There aren’t really any implications either way on the use of PGP from the particular “merge model” eventually adopted, though keeping the public and private keyrings on a non-shared filesystem would obviously give some added security. All that’s needed, apart from some documentation, is to set up a key certification and exchange mechanism and possibly a local keyserver, and to arrange for a reasonably well-connected web of trust to be set up. In fact, PGP could just as well be adopted under the existing status quo, assuming that the existing problems of secure software distribution could be solved.

5.10.2 PEM

PEM is an “official IAB standards-track protocol” for Privacy-Enhanced Mail — see RFC1421, RFC1422, RFC1423 and X.509. In spite of that it seems to be rare and probably not worth expending effort on for now. PGP is much more widely used.

5.10.3 Key escrow

If a PGP passphrase is forgotten then any keys stored using it are lost irrevocably, as is all mail encrypted with those keys. The question therefore arises: should important keys be escrowed? Should their passphrases be written down, sealed in an envelope, and then locked in a safe along with copies of the keyrings they’re on? Or should we have some on-line mechanism where the keys are encrypted and which requires m-of-n users to cooperate before they can be recovered? This needs some thought and development effort.

In any case, it makes sense to have, say, a “HoD key” rather than use personal keys. As well as clearly demarcating the user’s personal and public functions, this has the advantage that the personal key can continue to be used after its owner demits office. Other “office” keys will no doubt be identified over time. Office keys should probably be routinely regenerated, and in any case certainly when office-bearers change.

8For example http://www.dcs.ed.ac.uk/home/gdmr/PGP-key.asc and http://www.dcs.ed.ac.uk/home/gdmr/PGP-print.asc

5.10.4 Mail collection

What are the implications for mail delivery of the authentication mechanisms which might be used in a merged environment? In a completely uniform setup, using something like Kerberos, the traditional approach of delivering into files in a spool directory or the users’ home directories could still work, though in the latter case the mail machine(s) would require some kind of privileged NFS access to get around the fact that they wouldn’t have the right tickets.

Things are not quite so straightforward in the “islands” model. Perhaps the central mail machine(s) should belong to all islands, or could relay to per-island delivery machines. Laptops don’t fit into that scenario very well, though, and it would probably make more sense for the client machines to suck mail from the centre rather than having it pushed out from there. Mail could be collected using IMAP/POP, perhaps SSL-wrapped, or could be fetched through ssh tunnels. Or it could be PGP-(super)encyphered before writing to the spool area, on the basis that it then wouldn’t matter who could see the messages because only the rightful recipient(s) could read them. All these are simple in principle but would need some development effort.

5.11 NFS

There are three basic forms of NFS security in anything like widespread use:

• “AUTH UNIX” — trust the client to have authenticated the user, which is of course in practice pretty much the same as having no security at all. (When machines were big, heavy, expensive, under central control and user communities were small it was arguably^{9} reasonable, but not any more.) While it could still be useful in restricted circumstances within islands of trust, it would be a Bad Idea to implement this Division-wide. Nevertheless, this is the way existing NFS services are operated.

• Kerberised NFS has been “imminent” for ages now. Unfortunately it’s caught up in US armaments export policy, mathematics being clearly a munition, and it’s unclear when, if ever, it’ll be available sufficiently widely to be useful. If it were then it would go a long way towards making the completely-unified-filesystem scenario realistic.

• “Secure NFS” is based around public key cryptography. Each user has a key-pair, both parts of which are published through NIS or NIS+ or some equivalent service (the secret part being encrypted with the user’s password). The NFS server uses a challenge-response protocol to ensure that the user really is or has recently been at the client machine. Unfortunately this was designed when machines were less powerful than they are now, and the key length is not long enough to be regarded as secure.

5.12 SMB

This is the remote filesystem protocol used by NT. The authentication mechanism is reported to be weak (though not as bad as AUTH UNIX NFS) and fairly easily cracked. It’s perhaps to be Kerberised in NTv5 (or whatever that’s called these days). We need to support this in at least the small to medium scale.

5.13 Web

While there are certainly lots of security implications concerned with running a web service, it is assumed that the Division’s web working group is already dealing with these and they are not considered further here for now. (I might expand this section at a later date. Pointers to documents welcome...)

9And we did argue over it in ex-DCS in the mid-’80s, where it was clear from the spec that it was worse than our existing protocols, even before we had any NFS-capable machines!

6 Current Practice

This section summarises the current security practices of the former component Departments of the Division.

6.1 ex-DCS at KB/AT

• Ex-DCS runs mostly Solaris and Linux machines. These are kept up-to-date through ad hoc package upgrades and a fairly regular cycle of patch applications.

• There are quite a few self-supported machines. These are generally not trusted, but they are inside the IPfilter perimeter.

• IPfilter is used to control inbound connectivity. By default everything to “privileged ports” is blocked, with specific services being opened up to their respective servers, telnet being allowed from anywhere in .ed.ac.uk, and ssh being allowed from anywhere at all. Inbound connections to “non-privileged ports” are not currently blocked, other than to an anonymous range used by system daemons, though this isn’t really a good idea in principle and should be reviewed.

Outbound TCP connections are not restricted, but outbound UDP is blocked other than from a range of “non-privileged ports” due to the difficulties in associating replies with their corresponding connection in the presence of asymmetric routing.

Logs are regularly inspected — these generally show several probes to specific major service machines (for example DNS, web and FTP servers) per day and roughly one scan of the complete address space per week on average. Smurfs and fraggles are counted but not logged separately. Blatant or novel incidents are reported to JANET-CERT, but minor ones are usually ignored unless they are repeated or appear to fall into some kind of pattern.

• RFC1948-style “unpredictable” TCP sequence numbers are enabled on Solaris machines.

• Services started by inetd are controlled by the TCP wrappers where possible. The default policy is to disallow all access by default, with telnet and ssh allowed from .dcs.ed.ac.uk except for particular designated servers. SMTP is allowed only from the local host itself, apart from the main and backup relays of course, as this makes tracking down forgeries slightly easier and more reliable.

• ssh is the preferred remote access protocol, both internally and externally, though telnet is also accepted. rlogin is not supported for external access at all, though it is still accepted internally for backward compatibility. There are no one-time password facilities at present.

• Proactive scans of machines are done only on an ad hoc basis.

• Proactive password cracking is carried out and accounts with weak passwords are disabled if a warning has no effect.

• Most NFS filesystems are shared using AUTH UNIX to all the centrally-managed ex-DCS machines, but not to the self-managed ones. This is done because it was set up when it was still a reasonable thing to do, and has come to be expected in spite of it being a major security hole.

• Solaris software distribution is the other major security hole, with around 100 users plus anyone with physical network access potentially able to put a trojan horse into everyone’s PATH. Linux software distribution is much more secure, and will become even more so once RPMs are routinely PGP-signed. If the use of Solaris were not ramping down it would make sense to extend the Linux technology to encompass it too.

• There is some nascent use of PGP, but the infrastructure and documentation are not yet in place for it to become widespread.

• …

6.2 ex-DAI at FH/SB

• Most ex-DAI machines run Solaris. These are kept reasonably up to date with patches ...?

• Self-supported machines?

• Services started by inetd are (mostly?) wrapped. The default policy is to block access from outwith .ed.ac.uk except for a few specific machines.

• External traffic is not otherwise filtered ...?

• ssh is available and is used for important inter-host traffic.

• Passwords are cracked proactively. The password-changing program rejects weak passwords.

• One-time passwords are available for external connections.

• NFS using AUTH UNIX ...?

• …

6.3 ex-CogSci at BP

• Ex-CogSci runs mostly a mixture of Solaris and Macs with some Windows machines. The former are kept patched with a reasonably up-to-date patch set. There are also one or two machines running fairly ancient and rather insecure versions of SunOS.

• Self-supported machines?

• Services started by inetd are (mostly?) wrapped. The default access policy is ...?

• External traffic is not otherwise filtered.

• Remote access is provided by ...?

• NFS using AUTH UNIX ...?

• …

7 Resources

Here’s a list of some useful resources. It’s by no means complete… • Books: Cheswick & Bellovin, Garfinkel & Spafford, …

• A local reasonably-up-to-date collection of RFCs can be found at

  http://www.dcs.ed.ac.uk/home/RFC/.
• The bugtraq mailing list: send “subscribe bugtraq” to listserv@netspace.org. This

is a moderated full-disclosure list which can be quite high-volume at times, but it’s very useful.

• There’s also a separate ntbugtraq list, dealing with NT issues. (I haven’t been reading this one for a while.)

• Most manufacturers have security bulletin mailing lists.

• There are quite a few pages on aspects of cryptography dotted around the web. Start at:

  http://www.counterpane.com/, http://home.cern.ch/~frode/crypto/,
  http://jya.com/crypto.htm, http://www.cs.hut.fi/crypto/.
• The IPfilter home page is at http://cheops.anu.edu.au/~avalon/ip-filter.html; the
  ipchains page is at http://www.rustcorp.com/linux/ipchains/.
• http://www.Europe.DataFellows.com/, http://www.ssh.fi/ and
  http://www.cs.hut.fi/ssh/ all deal with ssh.

• Kerberos is described at

  http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html; the Heimdal home
  page is http://www.pdc.kth.se/heimdal/.

• Several mailing lists and newsgroups cover PGP, and there are at least three books. See

  also http://www.uk.pgp.net/pgp.
• See http://www.socks.nec.com/introduction.html for an introduction to SOCKS.

• The JANET-CERT page is at http://www.ja.net/CERT/cert.html, where you’ll find contact information and lots of useful pointers to documentation and tools.

• http://www.digicrime.com/dc.html is an excellent place to find out what your web browser can do that it perhaps shouldn’t!

• …