source code UNIX

Security on a Source Code UNIX System

by Bob Gray

Bob Gray is co-founder of Boulder Labs, a software consulting company. Designing architectures for performance has been his focus ever since he built an image processor system on UNIX in the late1970s. He has a Ph.D. in computer science from the University of Colorado.

<[email protected]>


The focus this time is security. The primary issues are not unique to computers; society has always had its thieves and vandals. And the solutions are not new—we use a combination of deterrence, monitoring, and penalties for violators. The appropriate amount to spend on security is a function of the value of your assets and the hostility of your environment. Just as New Yorkers are likely to use bigger, stronger, and more locks than Midwesterners, so too will companies have more elaborate security than the occasional-evening Web surfer.

Most of the measures suggested here are applicable to vendor-supplied, binary operating systems as well as Source Code UNIX. But the latter systems have a big advantage; they can't confuse security with obscurity. Good security is like a well-designed, high-quality lock on a jimmy-resistant door. Sure, it can eventually be overcome by a highly skilled locksmith or by using enough brute force, but we have confidence that those are the only likely methods. Obscurity is like the forgetful bank president who hides the safe combination on the back of his desk blotter.

Protection with obscurity is a disaster waiting to happen. Peter Neumann has reported numerous cases in his "Risks" columns in Communications of the ACM. We've seen the famed "Clipper Chip" (encryption with government back-door access) succumb to Matt Blaze's clever black-box techniques at Bell Labs. The reliability of questionable systems can be quickly scrutinized by the community with source code—without it, the scrutiny happens after an incident, with much embarrassment.

Security is hard work; you need to dedicate hours to it every week. Your level of security is a continuum, and everything you do properly will increase the difficulty of penetrating your system defenses. The best situation is one in which one or more people in your organization specialize and can leverage their skills across the company. Consultants can handle your security needs or assist your staff. But even without the experts, there are a handful of things you personally can do to fortify your defenses.

First, alter your mindset; assume that your system is not completely secure and then act accordingly. What is it worth to you to be protected against most threats? How badly will you be hurt by mischief or vandalism? Will your system prevent most of the frequently used attack techniques? What is the value of keeping your system running reliably? Is it a transaction-processing system that must run nonstop? Do you have financials, precious secrets, formulae, inventions, ideas, algorithms, and source code online to protect from competitors? What contingencies do you have in place in the event of a successful denial-of-service attack? For example, the recent Melissa virus didn't directly harm UNIX systems, but some gateways and mail servers became useless as a result of the volume of virus-generated mail.

Careful, deliberate, verified backups provide insurance against disasters. For most of us, a break-in usually wouldn't be a crisis because it is unlikely that the bad guy would know what information was sensitive or would find it. If the bad guy is just curious, you only have to deal with the insult of being violated and the inconvenience of fixing the problem. But there are the angry or revengeful hackers who aim to destroy your information or disrupt your operations.

Recommendations for First-Line Defenses

If high security is required, dedicate specialists to the task. The issues are far too complicated for the "weekend" system/network administrator. Consultants can perform security audits and help fortify your defenses on a continuous basis. If you are on a tight budget and cannot afford to spend much on security, a few simple steps can help prevent the insult of graffiti on your system. I recommend tightening passwords, using secure remote-access tools, clamping down on provided servers, and monitoring for intrusions. Even the home dialup PPP user should implement some of the suggestions below.

Passwords

Establish good passwords for every user. Make sure pseudo users such as uucp, lp, and news have "impossible" passwords (usually designated with * in the encrypted password field). Do you know everyone who has an account on your system? Is that access needed? Firewall or mail-server machines should not allow user accounts. For the remaining accounts on regular systems, educate the users on how to choose a good password. Recently I performed a security audit for a client and uncovered 95% of the passwords in less than a day's worth of PC time. I gave the following advice:

Select a personal, memorable 6- or 8-word phrase, then choose letters from it and permute them. The following phrase is an example:

"5 Sisters, one dog + two hampsters" (yeah, it's true :-)

Taking successively later letters from the words we get

5S,ng+os

If my phrase contained only alphabetics, I would permute a couple of letters. For example, you could use "$" for "S," "@" for "a," etc.

Cracking programs would have required a hell of a long time to guess this password. Software such as Secure Shell (ssh) and Pretty Good Privacy (PGP) allow the user to type long phrases as the cryptographic key. Well-known sayings or movie titles are poor choices for pass phrases. Years ago, Grady Ward wrote in a news article:

"Shocking nonsense" means to make up a short phrase or sentence that is both nonsensical and shocking in the culture of the user, that is, it contains grossly obscene, racist, and impossible or other extreme juxtaposition of ideas. This technique is permissible because the passphrase, by its nature, ought never to be revealed to anyone with sensibilities to be offended.

If you don't use your password regularly, you might be concerned about forgetting it. (But that's why you picked a memorable phrase as the base.) Don't type your otherwise strong password in a computer file. You might get away with burying the phrase in a text file somewhere, but don't store the permutation in the same place. Also, don't type the password in cleartext over a network, since it's trivial to collect keystrokes on Ethernet and only slightly harder to filter these down into passwords.

All Source Code UNIX systems allow shadow passwords—the encrypted part of the password file is generally not readable. Without the encrypted part, cracking programs are almost worthless because it takes much too long to verify a guess. (A login attempt per guess is required.) As a motivation, recall that the 1988 Morris Internet Worm read password files and hunted for easy pickings from a downloaded list and from the system dictionary file. Don't make it easy.

Create a strong password and be careful with it. I'm against periodically expiring passwords and forcing users to select new ones. I think it encourages people to choose weaker passwords or to write down hard-to-remember ones.

Secure Remote Access

You are likely to use network-connected computers that are under different administrative domains. For example, in addition to accessing machines at Boulder Labs, I connect to the University of Colorado computers, client computers, and computers belonging to relatives. Directory services (such as Novell's NDS or LDAP) and single sign-on systems won't help in these cases. In the past, we comfortably logged on with mechanisms such as rlogin and telnet. Passwords were typed in clear text over the Internet to establish the connection.

Today, these procedures are considered unsafe, because it is easy to intercept passwords along the route. One-time password systems are effective. You've probably seen "security cards" with number sequences that are synchronized with an authentication server. The Security Dynamics cards (SecurID) have six-digit numbers that are valid for about 60 seconds before they are ineffective. Once the user is successfully logged on with a particular code, the code becomes invalid for successive attempts. Therefore, a bad guy who sniffs a code cannot use it. Further, a series of these codes won't help predict the next valid code (at least that is the claim). These types of secure ID cards are somewhat pricey—both for the actual credit-card sized device and for the authentication-server software. Note that one of SecurID's weaknesses is that it is also not "source-code available," which is security by obscurity. If somebody were to crack the sequence-generating algorithm such that sequences could be predicted, the mechanism would be compromised.

S/key, which is freely available, also provides one-time passwords. Your destination host will provide a "challenge" for which you must generate a password on your local computer. That password, which you type over the Internet, is valid only one time. You can precompute passwords for a series of challenges. When I travel, I carry a paper list with me. I establish a partial connection with the remote S/key server, it challenges me, I lookup the corresponding password, and I type it to complete the connection.

One-time passwords are inferior to "encrypted tunnels" because the information you send and receive over the network is cleartext. Virtual private networks or encrypted tunnels hide all of the transmitted data. Essentially all of my remote work is conducted with Secure Shell (ssh) software. In addition to secure login sessions, you can securely transfer files (scp) or conduct any other client/server transactions, including securely POPing mail and running X11 sessions. (On FreeBSD it's in /usr/ports/security/ssh; it's on the Web at <http://www.ssh.fi>.)

Encrypted Mail and Data

To communicate securely with a person over insecure networks, public-key encryption is a good choice. This is the mechanism where a person's public key can be published or widely distributed. Once a message is encrypted with the person's public key, it can only be decrypted with the person's corresponding private key. (See Greg Rose's PGP Key Signing article in ;login:, <http://www.usenix.org/publications/login/1998-4/pgp.html>.) PGP (Pretty Good Privacy) software is a good choice for private communication. Note that PGP also provides "conventional" encryption, in which a single key is used both to encrypt and to decrypt a file. This mechanism is a good way to protect files on your computer if you don't have good physical security. It's also a good method for exchanging sensitive data if you have a mechanism for distributing the keys.

Network Services

Inetd is known as the Internet "super-server." It starts at boot time and listens for connections on certain sockets. When a connection is established on one of its sockets, it decides what service the socket corresponds to and invokes a program to service the request. Many vendors ship the configuration file, inetd.conf, with lots of services enabled by default. Because it is hard to be sure that the individual server programs are all perfectly secure, and because inetd itself could have flaws, it is wise to excise as much as possible from this whole mechanism. To improve security, disable any inetd service that your system shouldn't be providing. For example, do you need to provide bootp services? How about POP, NNTP, NTALK, UUCP? If you use ssh and scp, then you may be able to disable telnet, rlogin, rexec, and ftp. The default configuration may enable remote execution of about 40 different programs; consider eliminating most of them. Many people find that they don't need to run inetd at all. (See /etc/inetd.conf and INETD(8).)

A few server processes don't use the inetd mechanism. They start up at boot time and directly listen on ports for service requests. Sendmail is the primary example, but you'll frequently see RPC mechanisms, including NFS, remote print spoolers, system logging (syslog), DNS, and time systems (xntp). Inspect your system to ensure that unnecessary servers don't exist on your system. Look in the bootup scripts (usually /etc/rc.*), use the ps command, and run netstat -a to see what services your system is currently providing over the network. Essentially, if you don't think you need it or don't know what it does, then turn it off. Of course, coordinate this carefully with users who may depend on these suspect services. Be methodical when disabling services that you don't understand, so that you do understand the ramifications.

Network Filters and Firewalls

Additional protection is attained by "wrapping" your inetd servers to monitor and filter incoming requests. TCP wrappers provides tiny daemon wrapper programs that log the name of the client host and the requested service. Further, you can specify access control—to restrict what systems can connect to what network daemons. It's available from <ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6.tar.gz> or on FreeBSD in the ports collection under security/tcp_wrapper.

TCP wrappers only deals with TCP connections established with the inetd mechanism. IP Firewalls (ipfw) give you low-level control of all IP traffic into and out of your machine. Generally, the packet-filtering rules are initiated at boot time. Decisions to accept or reject packets are made early and in the kernel network layer. It's much harder to break into a system if many attacks are thwarted at this level. Here are some of the filtering rules from one of our machines:

1 allow ip from myIPaddr to any
2 allow ip from 123.45.67.89 to any
3 allow tcp from any to myIPaddr 25 setup
4 allow tcp from any to myIPaddr 80 setup
5 allow udp from any 53 to myIPaddr
6 allow udp from myIPaddr to any 53
7 deny ip from any to any

Rule 1 allows our machine to send IP packets to any other address. Rule 2 gives the 123.45.67.89 machine the right to pass packets through this gateway. Rules 3 and 4 allow mail and http connections. Rules 5 and 6 permit DNS exchange, and rule 7 disallows every other packet. For more details, read the manual pages: IPFW(8).

Firewall and filtering mechanisms don't have to be erected on your general-purpose computers. You can use a commercial router or build your own using software, such as:

• natd—Network Address Translation Daemon.
• wtk—FireWall Took Kit, filter services at a level higher than just packet filtering. It provides proxies that can be secured with single-use passwords.
• PicoBSD—a standalone, one-floppy-based router with PPP and NATD.

Once your protection is set up, have an external review of your measures. An outside consultant is recommended, but a competent colleague is acceptable. Also, run some of the public-domain security-auditing tools such as SATAN, RSCAN, and COPS. (See the Resource sidebar below.)

Monitoring for Intrusions

After you erect barriers and defenses, monitor for break-in attempts so that you can fortify the weaknesses and even counterattack. Reading system log files, tcp_wrapper logs and ipfw logs will enlighten you. You'll be surprised who connects or attempts to connect to your machine. If it's questionable, track it down. Make some calls to system administrators at companies or Internet service providers (ISPs) if one of their people is bombarding your machine with attacks. The mail logs and the http logs might also be eye-opening. Report incidents to the Computer Emergency Response Team (CERT, <http://www.cert.org>). They also provide tips and advisories for security.

An accomplished hacker is capable of breaking into your system, implanting viruses, back-doors, Trojan horses, or specialized software ­ and then covering his tracks so that everything appears normal when you examine the log files. How can you deal with this rare but extremely serious threat? You can get a lot of mileage with tripwire ­ it's easy to set up and run. Tripwire will traverse specified hierarchies and compute "signatures" for every file. The signatures that you already have available are the file size, permission, owner, and dates. The experienced hacker can replace one of your programs and patch the file size and dates enough to pass a casual filesystem inspection. But as checksums and "message digests" are added to the identity, faking becomes impossible.

Here is how you use tripwire. First, on a clean, uninfected system, generate the signatures for crucial hierarchies and save this information in a read-only database or an offline database. Periodically, run tripwire to recompute the signatures and compare them to the original ones. The differences are flagged. So, if you see that several programs in /bin have new signatures, but nothing about them should have changed, you know that something has happened. Once the obvious reasons for their change are eliminated (like another administrator installing new versions), you can suspect the worst and initiate the analytical process of looking for the break-in. Note: here is an application of the 4.4BSD chflags mechanism. You can create a file that is designated as IMMUTABLE—it may not be changed. Similarly, "chflags sappnd" creates a file that may be appended to, but even root processes cannot modify earlier portions of the file. Tripwire is in the ports collection under security/tripwire and available from <ftp://coast.cs.purdue.edu/pub/COAST/Tripwire/tripwire-1.2.tar.Z> .

Purdue's COAST project, now subsumed by CERIAS, provides for information assurance and security. See <http://www.cerias.purdue.edu>.

Operating System Choice

We see naive users connecting wide-open machines to the Internet. Security mechanisms, which tend to hinder work, need to be set up and administered. The inverse relationship between ease of use and security is likely to continue. Vendors favor shipping easy-to-use, feature-laden systems over secure systems because many end users are not able to handle the additional complexities. Imagine yourself as a sales engineer at MULTIVAQ (SUN, Compaq, Dell, HP . . . ) trying to sell a server machine to a small Acme company. At a pre-sales meeting you want to tell Acme that your server is a great value and easy to set up. You don't want to get bogged down discussing the skill required to administer firewalls, eliminate viruses, and patch vulnerabilities, Further, MULTIVAQ doesn't want its technical service lines jammed with customers that aren't up to speed on security administration; therefore, the corporate policy tends to favor shipping products with all features enabled, at the expense of security.

OpenBSD boasts that security is one of its principal goals. If a facility cannot be made secure by default, OpenBSD doesn't incorporate it. The OpenBSD group has a major advantage over many of the other operating-system suppliers. Based in Canada, they are not subject to the ridiculous U.S. crypto export rules. OpenBSD can incorporate strong security mechanisms into their release and ship it anywhere. U.S.-based companies allow only weak cryptography to be exported. Rather than have a U.S. version and an export version, most companies produce the least common denominator. Then you must add higher levels of security. For example, you have to separately obtain software such as PGP and 128-bit strong encryption (SSL on Netscape). All of this is in the base for OpenBSD.

Update to Last Year's "Selecting PC Hardware"

The June 1998 issue of ;login: included my article on selecting PC hardware for Source Code UNIX. (It's also online at <http://www.usenix.org/publications/login/1998-6/source.html>.) I'll briefly highlight some of the changes of the last 12 months.

As before, I'll discuss components in terms of three levels of target systems: LOW, MEDIUM, and HIGH. We'll define a "system" as a CPU, motherboard, disk, memory, CD, floppy, Ethernet, video/graphics card, keyboard, mouse, power supply, and case. Add a monitor and you have a complete workstation.

The LOW system has dropped in price to around $600-$1000, and its speed and capacity have doubled. I like the ASUS P5A Super Socket 7 motherboard with a K6-300 AMD processor. You'll get a 4-10GB IDE drive, 20-40x CDROM, 4-8MB graphics card, 32-64MB of S100 RAM and an Ethernet card in the package. In January, we bought a couple of these systems. Their generic memory didn't work under heavy loads. Clocking back to 95MHz seemed to help. Once we switched to high-quality memory, we were able to run again at 100MHz. (We have success with memory from <http://www.crucial.com>.) Parity/ECC memory is a bit of a problem with this low system—you have to clock back to 66MHz to get ECC running. For such a cheap system, I'd recommend just getting high-quality memory and running in risky mode.

I've had success with the ultra-inexpensive Spacewalker Shuttle HOT-591P motherboard, AMD K6-2 300, and a Trident 3DImage975 4MB AGP video card. With 4GB disk, 32MB RAM, mouse, keyboard, floppy, CD-ROM, and case it comes to just $500. I got this system because a local PC shop had all of the items in stock, and they were willing to customize the components for me. From their base system costing $770, I got credited for Windows 98: ($70), a Faxmodem ($30), a 15" monitor ($130), and a sound card with speakers ($25).

Many small, local PC shops will work with you to build what you need. I'm sure you can find what you need at the national chains or online shopping, but I have found it hard to get details on what components they are using. The motherboard and video cards are so important but are often not specified. To date, the big guys insist on charging you for Win98, although I expect this will rapidly change.

What was the HIGH system is now the MEDIUM system, and its price range has dropped to $1200-$1800. You'll have the fast 100MHz system bus using the 440BX chipset. SCSI disks will give you more performance and reliability. Be sure to get high-quality S100 ECC memory and run with parity or ECC enabled. I like the ASUS P2B series motherboards, which can handle the Pentium II or Celeron processors. The P2B-S has onboard SCSI; you can run 40MB/s Ultra SCSI and/or the newer 80MB/s LVD SCSI (low voltage differential). The P2B-LS has SCSI plus an onboard Intel 10/100 Ethernet.

The HIGH systems have the fastest, most expensive processors and/or multiple processors. You can run with multiple Pentium IIs (or IIIs) or Xeons. There is no need to stay in the x86 line. Linux and BSD systems running on Alphas (DEC/Compaq) are becoming common. There are UltraSPARC ports, and even SGI has publicly announced support for Linux on their hot new Visual PC 320.

General Comments

You save a lot by using processors such as AMD's K6-2/350 or Intel's Celeron 333A instead of the Pentium II. For just a little more you can get the Celeron 433 MHz, which matches the Pentium-II-400 for some benchmarks. (Note that it only runs at the 66MHz bus speed.) SCSI disks continue to be more reliable and higher-performing than IDE disks, but a SCSI controller and the disks will add $100-$300 to the cost of the system. Pay attention to the graphics card—while many generic cards will work, you'll spend lots of time fussing with them. At the new 100MHz bus speed, brand-name memory can save you headaches. Try to find a motherboard that will handle ECC at full speed. Monitor prices have dropped 25 percent or more. If you still have a small, fuzzy, flickering screen, treat yourself to a better one with higher quality, bigger size, more resolution, and a faster refresh rate.

For more details and some fascinating discussion of government intrusion of privacy see
<http://www.boulderlabs.com/clipper>
<http://www.cs.indiana.edu/classes/a106/readings/clipper.faq.html>
<http://csrc.nist.gov/encryption/skipjack-kea.htm>

Once again, Source Code UNIX saves the day. I had an urgent situation that required network booting of a maintenance "miniroot" for a binary-only vendor-supplied system. Both bootp and tftp protocols were needed over the network. I followed the vendor's instructions as best I could but kept getting obscure, meaningless, error messages like "cannot load," "error 7," "failed to boot," "format error." But having Source Code UNIX, I was able to put a couple of printfs into the bootpd and tftpd code and was able to reverse-engineer the process to get the mechanism working.

Thanks to the following reviewers: Tom Poindexter, Mike Durian, Janet Braccio, Barb Dijker, Joel Rem, and Steve Gaede.

Resources

<http://www.openbsd.org/security.html>: Security policy and implementation.

<http://www.freebsd.org/security>: Security advisories, tips, guidelines.

<http://www.sans.org>: Tools for security protection, detection, guidelines.

<http://www.cerias.purdue.edu>: Research institute for security.

<http://www.cert.org>: Coordination center for break-ins.

<http://www.eff.org>: Electronic Frontiers Foundation to protect civil liberties, including privacy.

<http://www.daemonnews.org>: On line magazine advocating Source Code UNIX, especially BSD flavors.

<http://www.counterpane.com>: Passwords, crypto essays.

<http://www.crypto.com>: Privacy education site.

Nemeth, Evi; Snyder, Garth; Seebass, Scott: and Hein, Trent. UNIX System Administration Handbook. Prentice Hall, 1995.

Schneier, Bruce. Applied Cryptography: Protocols, Algorithms and Source Code in C, 2nd ed. John Wiley & Sons, 1996.