Improving systems security

Part 2 – Computer security is a process of making many patches to many little holes: There is no single solution – it requires vigilance. A systems administrator gives advice to peers on practical solutions

Will Morse, Anadarko Petroleum Corp., Houston

ast month, Part 1 discussed a variety of risks, myths, misconceptions and some non-solutions. Part 2 is a list of practical solutions for reducing vulnerabilities of daemons, passwords and other common security weaknesses, without unduly hampering exploration applications. It is written for upstream-based IT professionals and developers of scripts and applications; the focus is on Unix-type systems, especially Solaris.

SECURITY POLICIES
Improving security is pointless if top management does not empower the security administrator to do his job and create / fund security policies essential for success. If security management is just another difficult and obscure chore in a long list for an overworked systems administrator, it isn’t going to be done.

If an exploration manager can go to the security administrator and demand something that compromises security – and get it – then there might as well not be a security administrator.

UNUSED SOFTWARE AND FUNCTIONS:
Many people think of security as a constraint, but modern operating systems come with lots of bundled software – much of which you may not even be aware of, let alone use. This software is a big risk because, since you don’t use it, you are not familiar with its vulnerabilities and won’t notice if it gets modified. Turning this software off by changing ownership, permissions and commenting lines in /etc/inetd.conf is a big win because it greatly reduces vulnerability with no pain to the users.

APPROPRIATE USE BANNERS
Appropriate use banners put up a message when you login (or better, before you login) that says something like: "For business use by authorized persons only." Talk to your legal department about exact wording. Some courts have found that if you don’t say no, you can’t sue or complain – or at least not as effectively. You also avoid giving potential intruders hints as to what operating system or version is in use.

For Solaris systems:

• The banner for login is in /etc/ motd. Put the banner here.
• The banner for telnet is in /etc/ default/telnetd. Use the BANNER= parameter.
• The banner for ftp is in /etc/ default/ftpd. There is also a BANNER= parameter, but it can only be one line.
• Display a banner during the dtlogin or xdm login by modifying the appropriate Xsession file to display an xmessage screen before the window manager starts. It is not necessary to have the window manager running to display an xmessage.
• The dtlogin or xdm login window should not say "Welcome." This title can be changed in /etc/dt/config/C/Xresources. Change Dtlogin*greeting.

For IRIX systems:

• The banner is in /etc/issue. This works for login, ftp and telnet. Also modify the line in /etc/inetd.conf for telnetd to put an "-h" at the end.
• Display a banner during the xdm login by changing /var/X11/xdm/Xsession to include an xmessage before the start of 4DWM.
• The xdm login window should not say "Welcome." It should not give a list of possible login names. The xdm title is defined in /var/X11/xdm/Xresources. Change Login*greeting.
• Turn off the visual login list using the chkconfig command.

SECURITY PATCHES
Both Sun Microsystems and SGI make free security patches available on their websites. For Sun, the URL is:

For SGI:

CDE has four major security vulnerabilities. These are documented in CERT Advisory CA-99-11 dated Sept 13, 1999.

• Tooltalk ttsession uses weak RPC authentication mechanism.
• CDE dtspcd relies on filesystem-based authentication.
• CDE dtaction can have a buffer overflow.
• CDE Tooltalk shared-library buffer overflows in ttsession.

Also, there are a series of programs in /usr/dt/bin – including dtappgather and printinfo – that are set-uid and have buffer-overflow vulnerabilities.

/ETC/INETD.CONF
The Unix "superdaemon" is inetd. It monitors messages for various programs and starts that program if needed. The list of ports and programs is in /etc/inetd.conf. If a program is commented out in /etc/inetd.conf, inetd won’t start it.

There are programs listed in /etc/inetd.conf that are not likely to be used in petroleum-exploration systems. These include: rusersd, fingerd, sprayd, walld, tftpd and bootp.

Even if these programs are needed on some servers, they are probably not needed on all servers or desktops. It is likely that you use some ftp or telnet, but perhaps only on a limited set of systems. You can telnet or ftp out from a machine that cannot answer. The more things you restrict, the harder it is to break in.

/ETC/SYSTEM SETTINGS
A very large percentage of security problems come from stack overflows or buffer overflows. Many of these attacks can be stopped by putting the following two lines in your /etc/system file (for Solaris 2.6 and above):

SET-UID PROGRAMS
A set-uid program runs as owner of the program file rather than as the program user. Programs owned by root are the problem. Some programs have to be set-uid to do their job. You might not need that job to be done, however. A good example would be ufsdump and ufsrestore. If you use a tape backup system such as Veritas Netbackup, make ufsdump and ufsrestore non-root and turn off the set-uid and setgid and execute permissions. The same for other set-uid programs you do not use. You can always turn them back on if you need them.

Never permit shell scripts to be set-uid. It is NOT a good idea to execute shell scripts as root, even if you are driving. A shell script may call a compromised (Trojaned) program, which could then be executed as root. Make sure all shell scripts that might be run as root specify the PATH – -even better, a hard-coded path – -for each command. Make sure environment variables like IFS and ENV are unset. If you must use csh, make sure to specify the "-f" option to avoid reading a .cshrc or .login that may be compromised.

SUDO/SUPERUSER ACCESS PROGRAMS
Sudo and other limited superuser access programs use a rule base of permissions to allow an otherwise unprivileged user to perform tasks that normally require root privilege. For example, a normal data administrator may need to switch user to an Oracle account for certain maintenance work. Rather than give him the Oracle user password or the superuser password, just create a rule like:

The user can type su - oracle (but only on system elvis), and sudo will let this happen. The user (joeuser) will have to enter his own password, not the Oracle password. The Oracle password can be changed from time to time without this user needing to know it. The password can be something hard to guess and the user won’t need to write it on a yellow sticky pad.

There are important things to watch out for when using sudo. Never let a user use vi or more as superuser, because you can "shell out" of these programs and that will be a root shell. You could also use the sudo vi to change /etc/passwd or other files that would defeat security.

You can make patterns with sudo that will prevent a lot of security problems. For instance, it is common for data administrators to need chmod and chown. You can give them a rule such as:

This gives joeuser the ability to change permissions on elvis to 770, but only in directories starting with /data, which of course excludes /etc and /usr.

HOSTS.EQUIV AND .RHOSTS
Books on security recommend eliminating /etc/hosts.equiv and ~/.rhosts. Other authors suggest that, since there is nothing you can do to prevent a user from putting a .rhosts file in his home directory, you allow this method for users who actually require this feature rather than making it generally available using /etc/hosts.equiv.

Some authorities recommend avoiding wildcards (plus signs) in the hosts.equiv or .rhosts files. The problem with this is that you have to explicitly list each computer name and user on individual lines on each computer. For a network of any size, this quickly becomes completely unworkable and cannot be kept current.

Never have a /etc/hosts.equiv entry for root, nor a /.rhosts file. You can set the system with a crontab entry to periodically check for these and delete them. The crontab should log any that it finds, and a systems administrator should periodically check such logs.

LICENSE MANAGERS
License managers are subject to buffer-overflow attacks. They do NOT need to be owned or run by root. Set your startup script to look something like this:

where lmadmin is a special username that is not in the group staff; lmadmin should have a minimal environment and home directory.

Have a group lmadmin and use the additional security options for lmgrd:

The -p option says that only users in the lmadmin group can do the lmdown and lmremove commands. The -2 option controls the startup and enables the -p command.

FREQUENTLY ATTACKED USERNAMES
Unix systems generally have a number of utility accounts that are used to own programs, but no one ever actually logs in on these accounts. Some of these accounts are:

Make sure these accounts have "x" in the password field of /etc/passwd and "NP" in the /etc/shadow file. You may also want to list them in /etc/ftpusers, so that nobody can ftp using them.

PASSWORDS AND PASSWORD AGING
A Unix password is limited to eight characters. You can use more, but only the first eight matter. You can set the minimum of how many characters a password must have in /etc/default/ passwd. The default is six. Remember that this file must be set on every machine in your network to be effective.

The passwd entry in /etc/passwd is not the actual encrypted password; it is a result of using the password to encrypt another number, usually zeros. For more details, consult a good book on Unix security such as Practical Unix and Internet Security, 2nd edition, Garfinkel and Spafford, O’Reilly, ISBN 1-56592-148-8.

If you have NIS, you can use the ypcat passwd command and get a list of all the passwords in the NIS database. For this reason, root passwords should NEVER be stored in NIS.

Password "cracking" is a fairly simple calculation. The protection comes from the many, many times an intruder must do this calculation to crack a specific password. The brute-force calculation starts with password "aaaaaa" and goes through all possible iterations until it calculates an encrypted password that matches one in the password file; the math is then simple. If you have passwords that can be six, seven or eight characters long, and the total characters to work from is 106 (on a typical English system in North America), the number of possible passwords is (assuming no other constraints on the characters chosen):

So, on average, the intruder will have to calculate half those passwords to find a match. This will take a while – even on a powerful computer. Of course, if your password is "aaaaaa," it won’t take very long at all.

Unix complicates this process by using up to 4,096 "seeds" based on the number of entries in the password file. These seeds make the encryption more complicated. They are the first two characters shown in the "password" part of /etc/passwd. This increases the size of the password space. Of course, if the intruder already knows your password entry, they also know your salt, so although this makes things harder on the novice hacker, it does not deter anyone with sophisticated password-cracking software.

To try to keep people from using passwords that occur early in the calculation scheme, some companies require that passwords contain at least one number or national character ($#@!*^, etc.). This actually reduces the overall search field, but helps put the result later in the search. If you require at least one number or national character, your overall search size becomes:

This is smaller than the unrestricted size, but may force your password to be later in the calculation. Note that you could do almost the same thing by simply having a "Z" in your password.

To cut back on calculations, intruders often do not start from "aaaaaa", but rather try easily guessed passwords. If your username is joe, they will try combinations of joe with other letters and numbers. They will also use common local sports team names, company names, pet names, and other guesses, and will include replacing letters with numbers (zero for oh, one for el), etc. So passwords like "R0ckets," "01iers" or "Astr0s" are easily guessed. The cracker will then go through a dictionary of common words to shorten the time to find easily guessed passwords. Brute-force methods have to be used to calculate a less obvious password such as "V(a)_301."

Most Unix systems come with several unneeded accounts in /etc/passwd. Among these might be:

Do not delete these accounts. Just make sure they have an "x" in the password field and "NP" in the /etc/shadow file. You can also set their default shell to /bin/false, or /bin/noshell. Do not just remove the default shell, as that is the same as setting the default shell to /bin/sh!!

Passwords are important, but they are not everything. If a person can get into your system by breaking a daemon and going straight to root, they aren’t going to care about ordinary user accounts. Some places go overboard and insist on so many letters, so many numbers and so many special characters. These passwords can backfire by making it EASIER to guess passwords once the pattern is known.

DEACTIVATING ACCOUNTS
Once a person has an account on your system, NEVER delete this account. NEVER reuse this account. You have at least 65,000 userids. There is no reason to actually delete an account. Change the password in /etc/shadow or in your NIS shadow database to "NP". For a little extra safety, change the default shell (in /etc/passwd) to /bin/false or /bin/nologin.

File ownership in Unix is kept by userid, a number, not by the username. If you delete a passwd entry, you may have files owned "by a number" and no idea who that number is relates to. If you reuse the number, the new owner will suddenly own files he knows nothing about.

MORE-ADVANCED SOLUTIONS
More-advanced solutions are available and can add considerable security. These solutions must be installed on every computer in your network, and the appropriate version of each solution must be installed for every OS in your network. If you have 10 systems, this is pretty easy. If you have 100 systems, it can be done. If you have 1,000 systems, there is a good chance that at least one system will not have the appropriate solution at any given time.

TCP wrappers. TCP wrappers augment the inetd superdaemon. When a service is accessed, inetd does not start the service directly, but rather calls a "wrapper" program to evaluate whether the service should be started. TCP wrappers use a set of rules in the files /etc/hosts.allow and /etc/hosts.deny to determine if the computer requesting the service is trusted.

Secure Shell (ssh). Secure Shell is the current darling of the security industry. It improves the security of "r" commands, rsh, rlogin and so on. It improves the security of telnet, ftp and even X-Windows applications. It does not protect against other exposures such as NFS.

The security of standard ssh is greatly reduced if the user’s home directory is available via NFS. The user’s keys are normally stored in $HOME/.ssh/, and the user can also have a $HOME/.shosts similar to a .rhosts file. Ssh is free for non-commercial use. It is NOT free for most petroleum-exploration shops.

Tripwire. Tripwire is software that monitors characteristics of certain important files and reports if they are changed. Tripwire is NOT free for commercial users.

Authoring an authentication module. The Pluggable Authentication Module (PAM) is rapidly becoming a standard with Linux as well as Solaris. The trick with PAM is that you can "stack" modules; so you can apply multiple rules to authorize a session. You can eliminate the .rhosts and hosts.equiv problem by simply deleting the line in /etc/pam.conf:

You can write your own PAM module to do things like:

• Use a file other than .rhosts or hosts.equiv. This file could be somewhere other than in the user’s home directory.
• Limit users to a specific machine or to specific times.

Denial-of-service checker. The FBI and PacketStorm have released software to determine if your system has been compromised for launching denial-of-service attacks. For information, go to:

ONLINE HELP RESOURCES
You can get e-mail for security announcements through vendors and through CERT. CERT was formerly the "Computer Emergency Response Team," but has widened its function and is now just CERT (a registered tradename). Get e-mail notification by subscribing at:

Hacker (cracker) sites. The overwhelming majority of potential intruders are not very clever; they just have access to tools and techniques provided by the sharpest 2%. These tools and techniques are generally available on the Internet and, thus, to security administrators as well as intruders.

Security administrators need to keep track of these sites for two reasons: 1) to determine if your site is vulnerable to intrusion, and 2) to test your system’s defenses.

Web sites. A web site with an unbelievable list of exploits and tools is "packetstorm.securify.com" (that is "securify" not "security").

CONCLUSIONS
Security for petroleum exploration involves specialized understandings. Many recommendations made in computer-security books are not workable in petroleum-exploration systems. There are, however, many sensible methods that can lead to a practical level of computer security if applied consistently and reviewed periodically.

The risk is not necessarily that someone will steal or delete your data. There is also the risk that someone will use your computers to further attack others or (in some other way) discredit your company. If you have to shut down your computers and reinstall operating systems and data from scratch to eliminate an intruder, this can cost much more than replacing data from backup tapes.

Security has many facets. Don’t focus on one facet to the exclusion of others. There is no single solution that solves all security problems. Computer security is a process of making lots of little patches to lots of little holes.

Applications developers – particularly developers of installation scripts – need to understand their roles in providing secure applications. One cannot just leave it to the operating system or the customer’s systems administrator. Particular vulnerabilities are daemons and dynamic libraries. Never have ANY files owned or executed by root, and do not ask for root to install the application.

The single, most-critical success factor for a secure system is top management that takes responsibility by creating and supporting realistic security policies and then funds and supports the security function. Security is not something that you "turn on" and forget.

The author

Will Morse is a senior systems advisor for Anadarko Petroleum Corp. involved in exploration Unix systems. He is also an instructor at the Geoscience Technology Training Center at North Harris College in Spring, Texas. Morse has a long history with geoscience applications and papers. He has spoken at every Landmark Worldwide Technology Conference since its inception (winning best paper award twice) and every GeoQuest North and South America Forum since its beginning. He was program director for five years for the Energy Related Unix User’s Group (ERUUG) and editor of the ERUUG Unix Cookbook. Morse is also a co-founder of the sci.geo.petroleum newsgroup.

	Part 1