How a Modem Handles a Call

In order for a user to gain access to Linux through a modem line, the system uses the getty process. The getty process itself is spawned by the init process for each serial line. The getty program is responsible for getting user names, setting communications parameters (baud rate and terminal mode, for example), and controlling time-outs. With Linux, the serial and multiport board ports are controlled by the /etc/ttys file.

Some Linux systems allow a dialup password system to be implemented. This forces a user calling on a modem to enter a second password that validates access through the modem. If it is supported on your system, dialup passwords are usually set in a file called /etc/dialups.

The Linux system uses the file /etc/dialups to supply a list of ports that offer dialup passwords, while a second file (such as /etc/d_passwd) has the passwords for the modem lines. Access is determined by the type of shell utilized by the user. The same procedure can be applied to UUCP access.

UUCP

The UUCP program was designed with good security in mind. However, it was designed many years ago, and security requirements have changed considerably 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 it is working properly and securely.

If you don’t plan to use UUCP, remove the uucp user entirely from the /etc/passwordfile 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.

You should 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. The group and username for all files should be set to uucp. Check the file permissions regularly.

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. Further sub-directories can be created for each system that is on the valid user list, if you want to go that far.

Local Area Network Access

Most LANs are not thought of as a security problem, but they tend to be one of the easiest methods of getting into a system. If any of the machines on the network has a weak access point, all of 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 LANs is that it’s impossible to have a secure machine on the same network as nonsecure 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 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 might 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, which 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 ever use because other people can use them to access your system.

Tracking Intruders

Many intruders are curious about your system but don’t want to do any damage. They might get on your system with some regularity, snoop around, play a few games, and leave without changing anything. This makes it hard to know that you are being broken into, and it leaves you at the intruder’s mercy should he decide 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. Not all Linux versions support auditing, so consult your man pages and system documentation for more information.

If you do rely on auditing, you should scan the logs often. It might be worthwhile to write 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. A simple shell script to analyze the log can be written in gawk. In addition, some audit reporting systems are available in the public domain.