Practical Security

This talk by Peter Billam of P J B Computing was presented to the 1997 Summer Seminar of AUUG Tasmania on 19th Feb 1997.

Abstract

This talk discusses some serious weaknesses in traditional computer security, and some new tools based on strong encryption, such as ssh and pgp, which address these weaknesses. It then describes the different way you have to set up your computer in order to realise this improved security, and a migration path which allows you to work in this way within an established, less secure, site, whether you are a user or just the System Administrator.

The Bad News

Usernames and Passwords

Back when Unix was invented, in the days of Minicomputers and Terminals, each user had a private length of serial wire leading to a multi-user computer; the interior of the computer was a relatively public place. Thus the password is kept on the computer in encrypted form, and transmitted down the wire in plaintext.

Nowadays, the wire is a public resource, and yet people still transmit passwords down it in cleartext. This is completely inappropriate behaviour.

Usernames and Passwords provide only weak authentication; adequate to encourage normal operating procedures within a co-operative environment, but not to enforce security.

Loops of Trust

Definition
If computer A trusts computer B, then it means that the answer to the question "is computer A secure ?" must be "well it depends whether computer B is secure".

Now imagine that as a result of your actions as a System Administrator, a loop of trust exists, such that computer A trusts computer B, computer B trusts computer C, and computer C trusts computer A.

Is computer A secure ? well, it depends on B; is B secure ? well, it depends on C; is C secure ? well, it depends on A. So is computer A secure then ? Well, you don't know; they might all be secure, in which case they're all secure, or they might all be insecure, in which case they're all insecure. What you have constructed, as a result of your actions as a System Administrator, is a bi-stable, which could be in one of two states, but you have no way of knowing which state it might actually be in.

Loops of Trust are a Bad Thing, which you must eliminate if you wish to know your security status.

Inherently Insecure Protocols

Inherently vulnerable to uid-spoofing: NFS, rsh, rlogin, rcp.
Inherently vulnerable to password-snooping: telnet, SNMP, ftp.
Inherently vulnerable to IP-address spoofing: NFS, DNS, NIS.
Inherently vulnerable to password cracking: NIS.
Inherently vulnerable to session hi-jacking: telnet, ftp, rlogin.
Inherently vulnerable to e-mail bombs written in WordBasic: Microsoft Word6.

It's a Tough World Out There . . .

A few years ago, on the other side of the router was a fairly civilised environment, like a University corridor.

These days it's Street-Level at best; at worst it's a War Zone.

The Good News

Public-Key Encryption

The user generates a pair of keys, one public and one private. Crucially, the mathematics are such that although the two keys are uniquely related, there is no way of deducing the private key from the public key. The relationship between the keys is such that a message encrypted with the recipient's public key, which everyone knows because the recipient has published it, can only be decrypted with the corresponding private key, which only the recipient knows. This encryption functions as a (highly opaque) envelope.

The same process will also run backwards; if the sender encrypts a message with his own private key, which only he knows, everyone else can decrypt it with the senders public key, and thus verify that the message must have come from the sender. This encryption functions as a (unforgeable) signature.

See PGP, Simson Garfinkel, O'Reilly books.

PGP

Courtesy of Phil Zimmerman. Provides Public-Key (and also secret-key) encryption, but not the means of transmission; so first you encrypt, and then you send the encrypted data by some pre-existing channel, typically e-mail. Various front-end menus and interfaces to existing mail clients are available. PGP provides a means of certifying (signing) the keys of people you know, thus building up a web of keys known to correspond to real personal identities.

Some commands you'll need to know (on Unix or DOS) are:

pgp -h
Prints help message
pgp -caw filename
Encrypts the file (with conventional, secret-key encryption), encodes the result to ascii, and wipes the original plaintext file.
pgp -kg
Generates a new public-key/private-key pair
pgp -kv
View the keys on a keyring
pgp -kxa userID keyfile
Key Extract to Ascii - Copies userID's key out of the keyring into a separate ascii keyfile.
pgp -sat filename
Sign the file.
pgp -seat filename userID
Sign the file, and encrypt it to be sent to userID.
pgp filename
Check the signature of, and/or decrypt, the file.

The magic files are (by default) $HOME/.pgp/secring.pgp, where your secret key is kept, and $HOME/.pgp/pubring.pgp, which is where all the public keys of everyone you correspond with are kept.

See PGP, Simson Garfinkel, O'Reilly books, and also comp.security.pgp.announce. Available from ftp://ftp.cc.adfa.oz.au/pub/security/

SSH

Courtesty of Tatu Ylonen, ssh provides drop-in replacements for rsh, rcp and rlogin, which use strong encryption and authentication in a very transparent way. Both the host and the user have key-pairs and are strongly authenticated. Nifty features include automatic setting of $DISPLAY, automatic Xauthority, general port forwarding, compression of all network traffic.

The server runs a daemon sshd which listens on port 22.

Some client commands you'll want to know are:

ssh -f host xterm
The recommended way to start X11 programs at a remote host
slogin -l username host
Log into the remote host as username
scp filename host:/dir/filename
Remote file copy
ssh -t host vi remotefile
Forces pseudo-tty allocation, so that interactive remote programs can be run.

The magic files are $HOME/.ssh/identity, which is your secret key, $HOME/.ssh/identity.pub, which is your public key, $HOME/.ssh/authorized_keys, which is where you keep the public keys of all the users on all the hosts that you wish to allow to log in as you, and $HOME/.ssh/known_hosts, which is where the public keys of all the hosts you log in to are kept.

The corresponding files for the host are /etc/ssh_host_key, which is the host's secret key, /etc/ssh_host_key.pub, which is the host's public key, /etc/known_hosts, which is where the public keys of all the publicly known hosts are kept.

See also comp.security.ssh, and the FAQ at http://www.uni-karlsruhe.de/~ig25/ssh-faq/.

A Windows port of the client is available from Data Fellows; other versions are available free from ftp://ftp.ssh.com.

Strong Authentication

Someone is coming in over the network. Who is it ? Criteria for Computers to authenticate Humans can be sorted into three classes. A good authentication procedure uses criteria from more than one of these classes.

Something you Are
Fingerprint, Iris, or Voice-print scanners. Expensive and exotic.
Something you Know
For example a Password, or PIN number. Since the "Something you Are" method is exotic, in practice you'll need a password, plus something from the third class . . .
Something you Have
  1. A trustworthy computer, with some Secret Keys on it.
  2. A Secure_ID card (cost $100). But you're still vulnerable to snooping and session-hijacking.
  3. A little credit-card-sized piece of paper with some S-Key (or OPIE) keys printed on it. This costs just 5c - you need a trustworthy computer to print it out, after which it's very light and portable; but you're still vulnerable to snooping and session-hijacking.
  4. Your floppy disc with some Secret Keys on it. This costs only $5 - but you need a trustworthy computer to put it in, otherwise, who knows who is reading your secret keys ? So why not buy the computer and save the $5 ?

So to do the "Something you Have" method, it looks like you're probably going to need a trustworthy computer anyway.

The Trustworthy Host

A trustworthy host in a site allows loops of trust to be broken.

Computer A is trustworthy if it trusts no other host, so that the answer to the question "is computer A secure ?" is "Yes, regardless of whether any other computer, such as B, might be secure".

There must be at least one trustworthy host at each site, so the System Administrator has a base from which to distribute configuration information, or check the integrity of other hosts. Other hosts can then avoid falling into a Loop of Trust by trusting only the Trustwothy Host.

However, a site can have more than one Trustworthy host; in practice each System Administrator should run one, and indeed every user can have one.

The Practicalities of Trustworthiness

Physical Access - your Competitive Advantage

If the intruder has physical access to your computer, you (the defence) are lost anyway. The real guru knows that the quickest way to erase a disc is with a hammer ! Within the Site Perimiter, you can concentrate on defining normal operating procedures; don't waste time trying to enforce security against physical access.

Don't worry about physical access to your computers as a threat; look on it as the crucial advantage that you have over malevolent intruders by virtue of the fact that you own the computer and they don't. You can switch the machine off and on, you can insert a CD into the drive and boot from it, you can press ESCAPE during reboot, or Stop-A or Ctrl-Alt-Del while running; no outside hacker, however expert, can do these things.

Security comes from the leverage you can generate from your ownership, your physical access. For example, you can then put some Secret Keys on your computer.

Hygiene

A host which has recently been rebuilt from CD, and has since then run only in single-user mode and/or offered no services to the network, is trustworthy. It can be maintained in a trustworthy state by not executing any program coming from outside.

If any outsider is able to program the computer, (in sh, perl, machine code, DOS Batch, WordBasic, or whatever) then the computer loses its trustworthy status. A few year's work experience in a Kosher kitchen would be an advantage; there are rules to be kept, and if ever one is broken, the machine must be re-built.

These are some of the rules which ensure that no outsider gets access to any programming language . . .

Local $HOME
The user's home directory must reside locally on the user's Trustworthy Host ( because of ~/.chsrc, elmrc, .xinitrc etc ) and must not be file-served elsewhere ( not even read-only, because it may contain secret keys such as ~/.ssh/identity or ~/.pgp/secring.pgp )
Local $PATH
Everything in $PATH and LD_LIBRARY_PATH must reside locally on the Trustworthy Host. So /usr/local must be physically local, for example. You must never execute an imported program.
No NIS/YP
No NIS must be trusted; /etc/passwd and /etc/shadow must be files, etc.
Local Backup
Your machine, and your Home Directory, may contain secret keys such as ~/.ssh/identity or ~/.pgp/secring.pgp. Get an extra local disc, and backup from disc to disc.
No programming language offered as a service to outsiders
So no setuid shells offered as a TCP service from inetd, no Word6, etc.

Interworking with the Rest of your Site

Your trustworthy host containing your HOME directory will probably have to interwork in a site which has insecure infrastructure. This poses a whole series of practical system administration questions relating to files like ~/.forward, ~/.afpvols, and functionality questions relating to your access to the facilities of the site. Here is one way to do it . . .

Assume you come from a site where you have an NFS, automounted HOME called /home/bloggs, and use YP passwd and group maps and YP automounter maps, so it's about as bad an environment as you could devise. Probably pretty typical, though.

So . . . your trustable host runs no nework daemons at all. No inetd, no nfsd, no telnetd, no tftpd, not even sshd; refuses connections on all ports. On this machine, have an /etc/passwd entry putting your $HOME there on local unexported disc. This local $HOME contains your secret keys, such as ~/.ssh/identity and ~/.pgp/secring.pgp; the other hosts can't see it. For convenience, it can also contain ~/home which is a symlink to /home/bloggs, your site-wide NFS home.

/home/bloggs/.ssh contains only authorized_keys, not identity, so the sshd's running on the other site hosts allow you to ssh everywhere and do what needs to be done outside your home machine.

For mail, either

In effect, this uses the default insecure home directory to broadcast your public keys, while keeping your secret keys in your real home directory on unexported local disc. It's a fairly practical way of working, you don't have to redesign the environment (which has a lot of inertia even if you're the SysAdmin !).

Closer to the Wind . . .

If your trustable host must export information, then you will have to run some network daemons. If you're careful, you can still maintain the trustable status of your host. For example, read-only NFS or httpd can be set up securely. Run them chroot'ed if you can. Don't use the portmapper, which has security holes.

Then you will be able to have confidence in the integrity of the information you're exporting. Of course, other hosts using that information won't be quite so confident, because some third party may be impersonating your IP address.

Summary

Excellent tools are now available to

Whether you are user or system administrator, you may install these tools without disruption to an existing site.

Peter Billam    © Copyright 1997, CSIRO Australia

Back to P J B Computing or to www.pjb.com.au . . .