Restricting Users

I l @ ve RuBoard

Reducing the number of user accounts on a system reduces the number of entry points into the system which can be exploited. Every authorized user must maintain the secrecy of his password and the administrator must provide a secure user environment and services. User accounts are often used by intruders as a place from which to work. Minimizing the capabilities of user accounts will minimize the intruder's ability to misuse the accounts.

Privileged Users

Privileged users are those accounts which are granted privileges above the minimum set of privileges for all accounts. These additional privileges give the user extra capabilities and are targets of hackers so that they can utilize these extra capabilities.

The root user, UID 0, on UNIX systems is an all-powerful user who does not have to obey the security restrictions which apply to all other users. For this reason, the root user's access should be limited to the system.

Securetty is a UNIX feature which defines secure terminals which the root user can use. A secure terminal is a configuration that limits the superuser's access to the system to a list of terminals that are considered secure. This limits only the login process. A user may still log in as a regular user and change to the superuser with the su command. Other access methods , such as X windows , do not adhere to the secure terminal settings.

It is advisable that root not be allowed to log in from any unsecured terminal. Only the system console, /dev/console , should be considered secure. Instead, require that users log in as themselves and switch user to root, thereby giving you a log of who is root. You can restrict root's access by using the secure terminal facility. This facility is implemented in a number of different ways, depending on the version of the UNIX operating system.

If the system is a System V derivative, such as Linux or HP-UX, it will have a file, /etc/securetty or /etc/default/login on Solaris, which will contain a list of the terminals that are considered secure. Only directly connected terminals whose connection does not leave the secured area should be included as a secure terminal. Often the console should be the only secure terminal.

If the implementation is a Berkeley Software Distribution (BSD) derivative, then you will need to add the secure parameter to the console line in the /etc/ttys or /etc/ttytab file. This line will look something like the following:

 console "/etc/getty std.9600" vt100 on local secure 

Time-based Access Control

With time-based access controls, the system administrator may specify times-of-day and days-of-week that are allowed for login for each user. When a user attempts to log in outside the allowed access time, the event is logged (if auditing is enabled for login failures and successes) and the login is terminated .

Most UNIX systems will implement time-based access controls through PAM features.

On HP-UX, enabling trusted systems enables this feature. A superuser can log in outside the allowed access time, but the event is logged. The permitted range of access times is stored in the protected password database for users and may be set with SAM. Users that are logged in when a range ends are not logged out.

Device-based Access Control

In the early days of interactive computing, the only connection to the computer was over serial lines. These serial lines allowed users to access the computer with terminals that were directly connected to the serial line or through a modem. Adding dialers to the modems allowed computers to dial out as well as receive incoming calls. Soon computers were calling other computers and serial networking was born.

Today most multiuser systems still use serial line access. The system console is almost always directly connected to the system by a serial line. If the system is a data entry system, it is likely that most of the users are using directly connected terminals. Also, many systems have modems attached to them. These are almost always attached via serial lines.

The /etc/securetty configuration file can be used to limit to specific terminals on which the root user can log in. The login program on Red Hat and Mandrake Linux also uses the /etc/usrtty configuration file to define from which terminals and from which remote systems each user can log in.

Dial-up Access

Trying to guess logins and passwords is the most dangerous and unproductive way for a hacker to access a system. This type of bell ringing, the repeated calling of a modem and attempting to login, will undoubtedly be noticed by any system manager. So unless the hacker has some insight into logins and passwords, it is unlikely that he will get anywhere . The attempts to log in will be logged, whether they are successful or not, by the accounting system.

Correctly configured, the system will hang up the modem after three failed login attempts and will also terminate a session that is disconnected.

For the login program to hang up the modem, the modem must be appropriately connected to the system, with a cable that supports full modem control, and attached to a port on the computer that also supports full modem control. The entry for the modem connection in /etc/gettydefs must also be correctly configured. The gettydefs entry must have a HUPCL (Hang-Up and Clear) entry in both sections of the entry as shown:

 2400 # B2400 HUPCL IGNPAR ICRLN IXON OPOST ONLCR CS8      CREAD ISIG ICANON ECHO ECHOK ISTRIP IXANY TAB3      # B2400 HUPCL SANE CS8 ISTRIP IXANY TAB3      # login:  #2400 

Even with all these precautions , you must understand that phone lines are not secure: Some hackers are also able to hack the phone network, thereby being able to eavesdrop on communications, reroute calls, or steal a phone connection right out from under you, so the hacker is now connected to the session to which you were connected.

The ability to trace access through a dial-up line is now increased, since Caller ID is available in most areas. This means it is no longer necessary to get a court order or file a harassing caller complaint to get the phone number of the calling individual.

Today Caller IDTM devices are available that will record the time and phone number of all the calls received. There are also Caller ID modems that present the computer with the phone number prior to connecting. These can be used to further authenticate users for a dial-back system, or to notify someone when there is an unauthorized access in progress.

One way to enhance the authentication is through dial-up security. This feature, which is implemented on some versions of UNIX systems, asks the user for two passwords. Even though this is referred to as dial-up security, it can be applied to any terminal or modem port on a port-by-port basis. The first password requested is the user's password; the second is a password based on the user's default shell. This requires the configuring of two files: /etc/dialups and /etc/d_passwd . The dialups file contains the list of ttys, terminal ports, on which the second password will be required.

 /dev/tty0p0  /dev/tty0p1 

The d_password file contains the default shell and the encrypted password for that shell. If a user's shell is not listed in this file, the dial-up password is not tested .

 /bin/sh:dpscen80aKWa2:  /bin/ksh:dpJm/BwWmbsJg: 

One of the difficulties with maintaining the d_passwd file is the process of encryption of the passwords. Here is a program that will encrypt a password given on the command line and write the encryption to standard out. This can be used to create the encrypted password in the d_passwd file.

 main(argc,argv)  int argc;  char **argv;  {    char *salt="dp"; /* use your favorite salt */    printf ("%s",crypt(argv[1], salt);  } 

Direct-connect Terminals

Compared to dial-up lines, direct-connect terminals have two disadvantages in keeping out a hacker. The first is a minor disadvantage ” not having to redial after three failed login attempts. The second is a very real disadvantage ” the ability of a hacker to get access to an unattended session when terminals are logged on and left alone. In a matter of seconds, a hacker can utilize an unattended session to gain access to a system or to gain privileges.

All inactive sessions should be logged off. This is generally more difficult than simply setting the shell time-out variable to a time-out value. This is because some programs' activity will not be measured and some applications will appear active to the shell even if there is no user interaction. In these cases, the terminal is allowed to lock while it is being used or to not lock when it is not being used. Some terminal locking software that has the ability to spawn a "screen saver" program may open back doors by using this feature if the spawned programs are not well- constructed .

On an HP-UX Trusted System, the system administrator can specify a list of users allowed for access each dedicated port on a MUX or DTC. When the list is null for a device, all users are allowed access. The device access information is stored in the device assignment database, /tcb/files/devassign , which contains an entry for each terminal device on the Trusted System. A field in the entry lists the users allowed on the device.

I l @ ve RuBoard