This chapter covers the basics of keeping your system secure. It takes a quick look at the primary defenses you need to protect yourself from unauthorized access through telephone lines (modems), as well as some aspects of network connections. In addition, it explains how to protect your user files and ensure password integrity.
This chapter doesn't bother with complex solutions that are difficult to implement because they require a considerable amount of knowledge and apply only to a specific configuration. Instead, it looks at basic security methods, most of which are downright simple and effective.
The most commonly used method for breaking into a system either through a network, over a modem connection, or sitting in front of a terminal is through weak passwords. Weak (which means easily guessable) passwords are very common. When system users have such passwords, even the best security systems cannot protect against intrusion.
If you are managing a system that has several users, implement a policy requiring users to set their passwords at regular intervals (usually six to eight weeks is a good idea) and to use non-English words. The best passwords are combinations of letters and numbers that are not in the dictionary. Sometimes, though, having a policy against weak passwords isn't enough. You may want to consider forcing stronger password usage by using public domain or commercial software that checks potential passwords for susceptibility. These packages are often available in source code, so you can compile them for Linux without a problem.
What makes a strong password (one that is difficult to break)? Here are a few general guidelines that many system administrators adhere to:
Producing a strong password isn't that difficult. Get your users into the habit of mixing letters, numbers, and characters at random. Suppose a user wants to use lionking as a password. Encourage modification to lion!king!, l_ionk_ing, lion5king, or some similar variation. Even a slight variation in a password's normal pattern can make life very difficult for someone trying to guess the password.
Change the root password often and make it very difficult to guess. Once someone has the root password, your system is totally compromised.
Check the /etc/passwd file at regular intervals to see whether there are entries you don't recognize that may have been added as a route in to your system. Also make sure each account has a password. Remove any accounts that you don't need anymore.
Security begins at the file permission level. Whether you want to protect a file from the prying eyes of an unauthorized invader or another user, carefully set your umask (file creation mask) to set your files for maximum security. You should have to make a conscious effort to share files.
Of course, this precaution is really only important if you have more than one user on the system or have to consider hiding information from others. If you are on a system with several users, consider forcing umask settings for everyone that set read-and-write permissions for the user only and give no permissions to anyone else. This procedure is as good as you can get with file security.
Consider encrypting really sensitive files (such as accounting or employee information) with a simple utility. Many such programs are available. Most require only a password to trigger the encryption or decryption process.
For most Linux users, protecting the system from access through an Internet gateway isn't important because few users have an Internet access machine directly connected to their Linux box. Instead, the main concern should be to protect yourself from break-in through the most accessible method open to system invaders: modems.
Modems are the most commonly used interface into every Linux system (unless you are running completely stand-alone or on a closed network). Modems are used for remote user access, as well as for network and Internet access. Securing your system's modem lines from intrusion is simple and effective enough to stop casual browsers.
The safest technique to prevent unauthorized access through modems is to employ a callback modem. A callback modem lets users connect to the system as usual, and then hangs up and consults a list of valid users and their telephone numbers and calls back the user to establish the call. Callback modems are quite expensive, so this solution is not practical for many systems. Callback modems have some problems, too, especially if users change locations frequently. Also, callback modems are vulnerable to abuse because of call-forwarding features of modern telephone switches.
The typical telephone modem can be a source of problems if it doesn't hang up the line properly after a user session has finished. Most often, this problem stems from the wiring of the modem or the configuration setup.
Wiring problems may sound trivial, but many systems with hand-wired modem cables don't properly control all the pins; the system can be left with a modem session not properly closed and a log-off not completed. Anyone calling that modem continues where the last user ended. To prevent this kind of problem, make sure the cables connecting the modem to the Linux machine are complete. Replace hand-wired cables that you are unsure of with properly constructed commercial ones. Also, watch the modem when a few sessions are completed to make sure the line hangs up properly.
Configuration problems can also prevent line hangups. Check the modem documentation to make sure your Linux script can hang up the telephone line when the connection is broken. This problem seldom occurs with the most commonly used modems, but off-brand modems that do not have true compatibility with a supported modem can cause problems. Again, watch the modem after a call to make sure that it is hanging up properly.
One way to prevent break-ins is to remove the modem from the circuit when it's not needed. Because unwanted intruders usually attempt to access systems through modems after normal business hours, you can control the serial ports the modems are connected to by using cron to change the status of the ports or disable the port completely after hours. If late-night access is required, one or two modem lines out of a pool can be kept active. Some larger systems keep a dedicated number for the after-hours modem line, usually different than the normal modem line numbers.
For a user to gain access to Linux through a modem line, the system must use the getty process. The getty process itself is spawned by the init process for each serial line. The getty program is responsible for getting usernames, setting communications parameters (baud rate and terminal mode, for example), and controlling time-outs. In Linux, the /etc/ttys file controls the serial and multiport board ports.
Some Linux systems allow a dialup password system to be implemented. This kind of system forces a user calling on a modem to enter a second password that validates access through the modem. If this feature is supported on your system, it is usually with a file called /etc/dialups. The Linux system uses the file /etc/dialups to supply a list of ports that offer dialup passwords; a second file (such as /etc/d_passwd) has the passwords for the modem lines. Access is determined by the type of shell used by the user. You can apply the same procedure to UUCP access.
The UUCP (Unix to Unix CoPy) program allows two Linux systems to send files and e-mail back and forth (see Chapter 27, "UUCP"). Although this program was designed with good security in mind, it was designed many years ago and security requirements have changed a lot since then. A number of security problems have been found over the years with UUCP, many of which have been addressed with changes and patches to the system. Still, UUCP requires some system administration attention to ensure that it is working properly and securely.
UUCP has its own password entry in the system password file /etc/passwd. Remote systems dialing in using UUCP log in to the local system by supplying the uucp login name and password. If you don't put a password on the system for the UUCP login, anyone can access the system. One of the first things you should do is log in as root and issue the command
passwd uucp
to set a UUCP password. If you want remote systems to connect through UUCP, you have to supply them with your password, so make sure it is different than other passwords (as well as difficult to guess). The slight hassle of having to supply passwords to a remote system administrator is much better than having a wide-open system.
Alternatively, if you don't plan to use UUCP, remove the uucp user entirely from the /etc/password file or provide a strong password that can't be guessed (putting an asterisk as the first character of the password field in /etc/passwd effectively disables the login). Removing uucp from the /etc/passwd file doesn't affect anything else on the Linux system.
Set permissions to be as restrictive as possible in all UUCP directories (usually /usr/lib/uucp, /usr/spool/uucp, and /usr/spool/uucppublic). Permissions for these directories tend to be lax with most systems, so use chown, chmod, and chgrp to restrict access only to the uucp login. Set the group and username for all files to uucp as well. Check the file permissions regularly.
UUCP uses several files to control who is allowed in. These files (/usr/lib/uucp/Systems and /usr/lib/uucp/Permissions, for example) should be owned and accessible only by the uucp login. This setup prevents modification by an intruder with another login name.
The /usr/spool/uucppublic directory can be a common target for break-ins because it requires read and write access by all systems accessing it. To safeguard this directory, create two subdirectories: one for receiving files and another for sending. You can create more subdirectories for each system that is on the valid user list, if you want to go that far.
A neat trick to protect UUCP is to change the UUCP program login name so that random accessing to the uucp login doesn't work at all. The new name can be anything, and because valid remote systems must have a configuration file at both ends of the connection, you can easily let the remote system's administrator know the new name of the login. Then no one can use the uucp login for access.
Most LANs are not thought of as a security problem, but they tend to be one of the easiest methods into a system. If any of the machines on the network has a weak access point, all the machines on the network can be accessed through that machine's network services. PCs and Macintoshes usually have little security, especially over call-in modems, so they can be used in a similar manner to access the network services. A basic rule about LANsis that it is impossible to have a secure machine on the same network as non-secure machines. Therefore, any solution for one machine must be implemented for all machines on the network.
The ideal LAN security system forces proper authentication of any connection, including the machine name and the username. A few software problems can contribute to authentication difficulties. The concept of a trusted host, which is implemented in Linux, allows a machine to connect without hassle assuming its name is in a file on the host (Linux) machine. A password isn't even required in most cases! All an intruder has to do is determine the name of a trusted host and then connect with that name. Carefully check the /etc/hosts.equiv, /etc/hosts, and .rhosts files for entries that may cause problems.
One network authentication solution that is now widely used is Kerberos, a method originally developed at MIT. Kerberos uses a very secure host that acts as an authentication server. Using encryption in the messages between machines to prevent intruders from examining headers, Kerberos authenticates all messages over the network.
Because of the nature of most networks, most Linux systems are vulnerable to a knowledgeable intruder. There are literally hundreds of known problems with utilities in the TCP/IP family. A good first step to securing a system is to disable the TCP/IP services you don't use at all, as others can use them to access your system.
Many intruders are curious about your system but don't want to do any damage. They may get on your system with some regularity, snoop around, play a few games, and then leave without changing anything. This activity makes it hard to know you are being broken into and leaves you at the intruder's mercy should he decide he wants to cause damage or use your system to springboard to another.
You can track users of your system quite easily by invoking auditing, a process that logs every time a user connects and disconnects from your system. Auditing can also tell you what the user does while on your system, although this type of audit slows the system down a little and creates large log files. Not all Linux versions support auditing, so consult your man pages and system documentation for more information.
If you do rely on auditing, scan the logs often. It may be worthwhile writing a quick summary script program that totals the amount of time each user is on the system so that you can watch for anomalies and numbers that don't mesh with your personal knowledge of the user's connect times. You can write a simple shell script to analyze the log in gawk. You can also use one of the audit reporting systems available in the public domain.
If someone does break in to your system, what can you do? Obviously, backups of the system are a help, as they let you recover any damaged or deleted files. But beyond that, what should you do?
First, find out how the invader got in and secure that method of access so it can't be used again. If you are not sure of the access method, close down all modems and terminals and carefully check all the configuration and setup files for holes. Also check passwords and user lists for weak or outdated material.
If you are the victim of repeated attacks, consider enabling an audit system to keep track of how intruders get in and what they do. If you are concerned about damage, force off any intruders as soon as you see them log in.
Lastly, if the break-ins continue, call the local authorities. Breaking into computer systems (whether a large corporation or your own home system) is illegal in most countries, and the authorities will usually know how to trace the intruders back to their calling points. They're breaking into your system and shouldn't get away with it!
For most Linux systems, security isn't an issue because you are the only one who is using the machine. If, however, you share your machine with others or make it available for on-line access to anyone on the network (or the Internet), don't underestimate the chances of someone trying to break in; they will. Make your system as secure as you can. Common sense helps a lot, but don't forget that hackers are a wily, industrious, and tenacious bunch.
