Network Security in the New Millenium

James F. Carter <>, 2000-02-13

My family is installing DSL and wireless networking, which will expose us to substantially more security problems than in the past. Wireless networking is likely to appear soon at the UCLA Mathematics Department as well. My goal is, therefore, to assess what the threats are and how they might be mitigated. It is generally believed that a determined attacker with plenty of time and large but achievable resources is likely to successfully perpetrate any exploit he pleases, just as a determined burglar or embezzler is likely to be able to steal any of your resources. Nonetheless, most people who are careful about physical security do not get burgled, and I believe that the threat of hacking can be similarly reduced to an acceptable level.

First, some nomenclature. The ``hacker'' is the person perpetrating the attack, but since this essay is about computer threats, the ``hacker'' will often mean the computer operated by the meat person. The ``victim'' is the one being attacked. The ``exploit'' is whatever the hacker does. Frequently exploits are nested, e.g. the hacker first gains root access (a root exploit) and then uses that access to obtain encrypted material which he then cracks. It's a fact of life that most attacks involve a ``dupe'', a computer, and an account on that computer, which the hacker uses as a transfer point, so if the attack is caught in progress or if traces are found, the trail leads back to the dupe, and is frequently lost at that point. Nonetheless I will generally ignore the dupe and discuss as if the hacker and the victim were interacting directly.

Types of Threats

Threats can be targeted or random. As an example of a targeted threat, the hacker may decide that the victim specifically has money worth stealing, and may hack to discover what institution holds the money, and what are the authentication codes needed to disburse it to the hacker. In the academic setting occasional undergraduates concoct elaborate schemes to steal examinations or to tamper with grades. They may also retaliate against unfavorable outcomes by embarrassing the department or specific professors in it.

In random threats, on the other hand, the only relation between the hacker and the victim is that the victim is vulnerable. Nowadays we can expect blanket attacks in which an automated script attacks every address in a range, and does the exploit on all vulnerable machines. Dupes are generally selected at random. Random threats can become targeted, if the exploit is to scan for resources that the hacker considers valuable; the hacker would then return in a targeted attack to collect the resource.

Another dimension distinguishing threats is the purpose of the attack. Vandalism is common, in which the victim's disc is wiped. Targeted vandalism more often takes the form of putting embarrassing material in a public place such as the victim's web pages. A particularly insidious form of targeted vandalism is to introduce subtle corruption, for example by adding a nickel here and a dime there to financial records, that is likely not to be noticed until an audit (internal, the victim hopes). Recent months have seen targeted denial of service attacks, in which vast numbers of dupes are caused to bombard the victim with traffic which is legitimate as to form.

Another purpose variant is a virus attack, in which the purpose of the virus is to reproduce. Except possibly for the initial infection, viruses appear randomly. Generally the virus has some kind of payload, which is more or less subtle vandalism.

The next variant on this dimension is stealing or falsifying data. Sometimes the data itself is valuable, such as an examination before it is administered, or the data may simply give the hacker access to the real object of value.

Finally the hacker may be interested in impersonating the victim. For example a professor (impersonated by a student hacker) might notify the members of his class that an exam had been postponed. In this kind of attack the message is accepted as authoritative by the recipient, even though the sender did not actually authorize it. Another serious threat is for the hacker to impersonate the victim at a financial institution.

Stealing and impersonation pretty much have to be targeted attacks, unless there is a piece of software, such as a home banking interface, that is vulnerable and that is common enough that a blanket attack will turn up numerous instances before the hole is plugged.

In the family DSL scenario, targeted attacks are unlikely, and the major threat will be random and blanket attacks. On the other hand, at any one time there may be one or two students who are motivated and technically able to mount a targeted attack on the department, given a vulnerability; and (unsuccessful) random attacks are seen daily.

Types of Exploits

It's a fact of life that desktop computers, and particularly laptops, are stolen, or are sold when obsolete without proper precautions (wiping the disc). In a targeted attack the hacker may also gain physical access to the computer but decline to steal it. In these cases it is trivial to gain root access to the machine, for example by booting it off a repair disc. Sometimes non-root application programs can be exploited directly, but virtually all serious attacks will involve root access at some point.

However, most attacks are done over the network. Dialup (PPP) connections are intermittent and slow, limiting exposure, but DSL is always active. With a wireless network, a hacker can position himself unobtrusively within range, and from there can contact the internal network.

When computers are kept up to date with the latest security patches, most exploits fail, but new exploits appear a few times per year, and there is an interval before they are recognized and the hole is patched. It is generally believed that a determined targeted attacker can eventually gain access to any machine. I wish I had a good feel for the amount of effort required. Would the attacker have to research a whole new exploit? Or is the statement made because most machines aren't up to the minute on security patches? Or do kernels have non-publicized inherent flaws that cannot be plugged? Experience in the Math Department is that exploits do occur, but rarely. Perhaps there is a continual background of undetected exploits with invisible consequences, possibly using our machines as dupes. But hackers want credit for their work; not for long are they satisfied to hack into some machines and then leave silently. Thus, if we're dupes we should receive complaints, and if we're victims we should see damage. We don't, usually, and other departments do, occasionally, particularly when they aren't careful about security. Thus I conclude that the level of effort we're using at the Math Department is adequate.

There are only so many network services, and by now the ways to exploit them are well known, and (one hopes) most of the holes have been plugged. Thus successful attacks against network services are rare. Generally when the Math Department has been attacked successfully, the hacker was able to impersonate one of our users and then execute code on our machine, called a ``root kit'', that exploited some flaw in the kernel.

What to Defend Against, and How

When the hacker has physical possession of the computer to be hacked, there are a few defenses that are worth taking. Public terminals should be set up to not boot from removeable media (CDROM or floppy provided by the hacker), and there should be a password on the BIOS setup program so this setting cannot be changed. There is always a physical way to clear such a password, but typically it requires opening the computer and removing the backup battery, which would be suspicious activity in a public lab. UNIX machines should require a password to enter single-user mode (as root). Linux can bypass single-user configuration scripts for booting a damaged system; this feature should be sabotaged. These steps (except Linux) are in fact taken in the Math Department public labs. But of course in a non-public setting they only slow down the hacker for five minutes at most.

As set up in the Math Department, root on two master machines (Malibu and Julia) has a host-based privilege (/.rhosts) to execute on other machines, whereas root on other machines has no privilege elsewhere. Only certain staff members are allowed to login to the master machines. In this way, when a hacker impersonates a general user and uses a root kit, he cannot execute on the master machine either as root or as the user. He can, however, execute as the user on various non-master machines, and re-do the exploit there, so the restriction is not as onerous as it might seem. It would be a good idea at the Math Department to kick all users off the master machines except the programming staff, particularly on Malibu, where lab assistants and TA's are allowed.

It's important to keep our users' passwords out of the hands of hackers. We use shadow passwords, so a hacker on the master site can't just copy (and then laboriously crack) the password file, but we use NIS, which makes this information available to any machine on the local networks. Soon we will use NIS+, which is more secure. Linux on the home system uses shadow passwords and doesn't use NIS. Several times we've discovered that the entire password file from the Math Department has ended up on a hacker's site, and some of the passwords have been cracked. In that situation we make everyone change his or her password.

Frequently when the Math Department has been hacked, it's found that a user's account elsewhere was compromised, and the outside account had the privilege (granted by the user) to execute on our machine without authentication. We would very much like to limit our trust of outside authentication.

User-Level Threats

To the system administrator the main issue is that the hacker can get root access. But what does the hacker then do to individual users?

Clearly vandalism to the user's files can be very annoying. In the home situation we need to make backups much more aggressively: daily, and really do it, and we need a fractal scheme so we can go back to historical versions in case of selective or subtle corruption. For example, the backup discs are labelled 1, 2, 4, 8... and tape j is overwritten on (astronomical Julian) days divisble by j but not by 2j. The copy kept in the safe deposit box is in addition to this. During (or just before) the backup, the program's binary compare feature should be used, reporting altered files. We should humanly judge whether we were the ones who altered those files.

Being root, the hacker can read any file and ``su'' to become any user. The user's identification keys should be protected cryptographically by a good pass phrase. Both pgp and ssh do this. The privilege of logging onto another system without authentication should depend on the protected identification keys.

Unfortunately, it is difficult to use ssh effectively if you have to type a 35-byte pass phrase on every remote login. The whole point of .rhosts files is to obviate typing the password, so remote executions appear to be a seamless extension of the local session. Similarly, pgp runs on mail (or other) files individually and the pass phrase must be typed for each message to be signed, encrypted or decrypted. Unless the users are very serious about security, as at a bank or in military service, and sometimes not even then, they will avoid using the high security tools if the pass phrase has to be typed in more than a few times per day. Ssh includes a key agent which swallows the secret key of the user. The user's processes, such as ssh and slogin, can contact the agent and get a judgment that an encrypted challenge string actually decrypts to a provided value, implying that the user or host on the other end possesses the true authentication keys for the local user. Its socket is owned by the user and cannot be read by other ordinary users. Pgp has no such feature, but in theory it could be programmed to use the ssh key agent. [Update: pgp does now have a key agent, and it works.]

If the hacker does the root exploit while the user is logged in, he can open the key agent's socket and can do repeated challenges with carefully crafted data that (in theory) can reveal the secret key before the Sun turns into a cinder. In theory the key agent can use technological means to distinguish its session from the hacker's session. In theory the hacker can fake the session indicia, and in fact the hacker, as root, can root through memory, locate the key agent's data space, and (maybe) steal the key. With the present sophistication of hackers an attack on a key agent is unlikely, but as ssh becomes more common, we'll likely see exploit scripts which will locate any running key agents and perpetrate whatever exploit is feasible.

If we want users to routinely sign all mail, they should have three keys: a routine key, loaded in the key agent, which if stolen can be revoked and replaced with little loss; a secure signing key, for which the pass phrase must be typed each time it is used, and a secure encryption key, which can be surrendered in the (unlikely) event of a subpoena without compromising the signing key.

Action Items

  1. We should obtain various root kits, and determine if in fact our systems are vulnerable to them, and we should get a feel for whether there is ``always'' a root kit out there that we're vulnerable to, or whether security patches are plugging holes in a timely manner.
  2. We should require higher security login than the standard UNIX or Windows password mechanism. A passphrase controlling a RSA key comes to mind. The authentication keys should be distributed in the users' home directories (not centralized) and the relevant filenames should have an element of randomness and idiosyncrasy, to throw sand in the gears of a hacker's script designed to attack such a regime.
  3. Users should be capable of going through our full login procedure from a remote site. When we honor the authentication of a remote site we should require evidence that their authentication is at least as good as ours; for example, the user should have to set up the relation by coming to the bugs office and discussing (or demonstrating) what the security model is.
  4. Users should use a one-way web of trust. For example, their office machine has permission to execute on a Mathnet server which in turn has permission to execute on a foreign site, while the reverse relations are denied.
  5. The ssh key agent should be modified with a ``time to live'' for each identity, no more than eight hours, so a user who leaves an active session overnight will have to type the pass phrase again at the next work shift. ssh version 2 has this feature; version 1 doesn't.
  6. Pgp should be hacked to take a key from the ssh key agent. Instead, ssh version 2 can read keys from an "OpenPGP" keyring (but not pgp v2.6.2).
  7. The house server machine should be configured for ``dial on demand'', except rather than dialling, when a packet to the default route is handled, the DSL interface should be configured and its DHCP address obtained. After five minutes or so of non-use the interface should be taken down. This limits the fraction of time we are exposed to hackers. Since NTP packets will be continual, the "on demand" criterion will need to be hacked to at least ignore NTP, or more likely, to ignore all UDP and ICMP. DNS will have to be configured to use TCP instead. Major services that sit idle for a long time will have to be configured to use keepalives.
  8. The wireless network should have encryption if financially feasible (e.g. Aironet PC4810B or PC4820B rather than the non-encrypted PC4800B). 40-bit encryption is probably perfectly adequate for this purpose. The house DHCP server should be configured with the actual MAC addresses of each client. At the Mathematics Department the same rule should be followed, that rogue machines have to be registered by MAC address. At universities with many student machines changing each year, the registration is generally done with a script in which some simple secret, like the student's registration number, authenticates the student. It's understood that a hacker's wireless net card can be configured with an authorized MAC address. One hopes without conviction that the encryption can conceal the MAC address.