Linux Annoyances for Geeks: Getting the Most Flexible System in the World Just the Way You Want It

2017-07-07 02:10:07

6.9. There Are Too Many Ways to Log In

Linux computers are designed as multiuser, multiterminal systems. Multiple users can log in to a Linux computer simultaneously, from different physical terminals. A person can normally log in as root on any terminal, or remotely, which makes Linux relatively easy to fix when a problem requiring superuser privileges comes upbut it can also be a security risk.

Ubuntu Linux actually disables root logins by default. I'll show you how you can adapt the Ubuntu technique on the distributions covered in this book.

Don't forget the other ways to log in to a Linux computer. There are a number of secure services for remote logins. Generally, SSH, which I describe in "My Other Computer Has No Monitor" in Chapter 11, is the most secure way to log in to and administer remote computers. As discussed in "I'm Afraid of Losing Data" in Chapter 2, rsync is an efficient way to maintain backups. The vsFTP server, described in "Users Need to Download Files" in Chapter 9, is a secure option used by Red Hat and SUSE to share their distributions. But remember, any remote access, even in encrypted format, may be a security risk.

And then there are the insecure ways to connect to a Linux computer. Telnet allows crackers to see user passwords in clear text. TFTP is not secure either. In addition, some Linux computers include terminals configured for modem and serial-line connections.

6.9.1. Restricting Remote Internet Services

There are three services associated with remote logins to a Linux computer: Telnet, FTP, and SSH. The safest option is to delete or disable these services if they aren't needed. But they are useful services that you sometimes don't want to disable.

Many distributions include standard commands in their default configuration files. In many cases, commands that you see commented out are defaults for that service. Many configuration files include their own manpages.

6.9.1.1. Limiting Telnet access

The use of Telnet is strongly discouraged in Linux because associated messages, including passwords, are sent in clear text. All a cracker needs is a simple protocol analyzer (a.k.a. packet sniffer), and he can read users' passwords directly on his screen.

However, there are users who are more comfortable with Telnet, and there is a Kerberos version of Telnet in use. For more information, see "Users Are Still Demanding Telnet" in Chapter 9.

Unless you use the secure version of Telnet, it is important to disable this protocol. For the distributions associated with this book, Telnet is a "super server," configured in /etc/inetd.conf or an appropriate file in the /etc/xinetd.d directory.

If you're using Red Hat/Fedora or SUSE, you can disable Telnet with one of the following commands (depending on the associated script in the /etc/xinetd.d directory):

chkconfig telnet off chkconfig krb5-telnet off

If you're running Debian, you can disable Telnet in the /etc/inetd.conf file. Just comment out the command that would otherwise start this service. By default, the line in Debian is:

telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/telnetd -a user

The users on some networks demand Telnet. I discuss the more secure Kerberos version in Chapter 9.

6.9.1.2. Limiting FTP access

If you're going to share serious amounts of data, you've probably considered FTP. Despite its age, it's still the most efficient protocol for transferring files. There are several different FTP servers available for Linux. Unfortunately, FTP can also leave you vulnerable to attack. If you need an FTP server, the best approach is to limit access. Specifically, you should consider whether to:

Limit access to anonymous or real users

Prohibit access to the root user

Disable uploads/writes to the FTP server

Log all access attempts

Set a timeout in case someone walks away and another person uses that login

Prevent access to higher-level directories (configure a chroot jail for the server)

Specify users who are allowed to access the server

Not all FTP servers allow you to regulate logins in these ways. For more detailed information, consult the manuals associated with the FTP server of your choice. I describe how you can configure the vsFTP server securely in "Users Need to Download Files" in Chapter 9.

6.9.1.3. Limiting SSH access

The key file for limiting access through SSH is the /etc/ssh/sshd_config file. There are two SSH protocols in general use, 1 and 2. As you might expect, SSH2 is more secure. However, both protocols are enabled by default. You can change this setup by adding the following directive to the SSH configuration file:

Protocol 2

A commonly recommended secure policy for remote logins is to add the following directives to this file:

IgnoreRhosts yes IgnoreUserKnownHosts yes

At minimum, you should disable root logins over a network. Sending a root password over a network is never a good idea. Even if encrypted, anyone who intercepts the root password can eventually decrypt it and log in to the administrative account. With the following directive in sshd_config, you can still log in as a regular user and then log in as root with su using SSH encryption.

PermitRootLogin no

One might think that a cracker could decipher the root password when an administrator runs the su command remotely. But with SSH encryption, there is no easy way to know when su is run.

Other directives can limit allowed users and groups; see the AllowUsers and AllowGroups directives as listed in the sshd_config manpage. For example, if michael is the only user who should be authorized to access a server via SSH, just add the following directive:

AllowUsers michael

There are a few other directives worth considering. For example, you may not want to use this directive, as it would let users log in without a password:

PermitEmptyPasswords yes

One of the strengths of the X Window System is that users can log in to a remote system, run a program on it, and interact with it from their terminal on the local system. As an administrator, this is particularly useful to you because you can gain access to remote GUI tools. On the system where the programs run, you can enable remote users to get access to them (known as X forwarding ) by including the following directive in the sshd_config file:

X11Forwarding yes

On SUSE, this line is included by default.

Once X forwarding is enabled on the system running the program, it's easy to set up remote access to GUI tools. All you need to do is log in to the remote system with the -X switch. For example, if I access my desktop named enterprise4a with the following command:

ssh -X michael@enterprise4a

I can then run GUI applications from the remote system. For example, if I'm running the Evolution email manager from the remote enterprise4a computer, I can then use the evolution command to display this email manager on the local computer.

6.9.2. Preventing Access via RADIUS, Modems, and Serial Ports

Internetwork access services such as SSH and FTP aren't the only remote ways to log in to a Linux computer. You also need to pay attention to access options over modems and serial ports.

Modem servers, which are commonly installed on servers to which users connect from remote locations, are a potential security risk. There are several different Linux modem servers based on RADIUS, which you should make sure are not installed with a command such as:

rpm -qa | grep radius dpkg -l | grep radius

Check also for the existence of /usr/sbin/radiusd; it's possible that another administrator installed this daemon from a tarball. For more information, see http://www.freeradius.org.

But RADIUS isn't the only way to enable modem access on a Linux computer. The modem getty service (mgetty) is already partially configured in /etc/inittab with a directive such as:

T3:23:respawn:/sbin/mgetty -x0 -s 57600 ttyS0

This command includes four fields, separated by colons. It starts with a command label (T3). It continues with the active runlevels (23) for this command. The third entry, respawn, reruns the mgetty command after every disconnect. Finally, the mgetty command is run, with no logging (-x0), at a port speed of 57600 bits per second (-s), on the first serial communications port (ttyS0).

Not many modern networks are connected through serial ports. But they're still available on many computers. If a cracker gets physical access to your computer, he can connect through a null modem serial cable unless you disable commands in /etc/inittab such as:

T0:23:respawn:/sbin/getty -L ttyS1 9600 vt100

This particular command supports a VT100-style connection at 9600 bits per second through the second serial port.

6.9.2.1. Limiting root logins via terminal

It's also important to limit remote logins with the root account. If a cracker has found your root account, you may be able to frustrate her efforts to gain access by minimizing the root-capable terminals on your system.

You can limit the consoles where the root user can log in through the /etc/securetty configuration file. Depending on your distribution, you'll see a number of lines, such as tty1, tty2, vc/1, vc/2, and so on. It's a good idea to prevent direct logins to all but the first console, by commenting out or deleting all but tty1 and vc/1 in this file (these terminals are required to support root access in single-user mode). You can still log in to other consoles as a regular user and then use the su or sudo commands to access the root account.

Alternatively, you can disable root logins by disabling the account. If you have an /etc/shadow file, passwords are stored there in encrypted format, in the second column. Replace the encrypted password for the root user with an asterisk (*) to disable that account, as shown in the following command. You can still access the administrative account with the su or sudo commands:

root:*:13089:0:99999:7:::

If you don't have an /etc/shadow file, you're not using shadow passwords, and you can disable the root account by substituting the asterisk in the second column of the root user's account directive in /etc/passwd.

6.9.3. Using PAM to Control the Console

One key contemporary skill for a Linux geek is the Pluggable Authentication Module (PAM) feature. Red Hat, SUSE, and Debian all store associated files in the /etc/pam.d directory. They each manage logins to the console through directives in /etc/pam.d/login. The details vary widely by distribution. But the default versions of this file share commonalities:

Standard console logins: With the pam_unix or pam_unix2 module, PAM allows text-mode console logins, which are essential if you have not configured a GUI.
Console restrictions for root: With the pam_securetty.so module, PAM limits logins to consoles specified in /etc/securetty. You can make a cracker's life more difficult by limiting the consoles in this file.

Red Hat and SUSE include README files associated with most PAM modules. For example, pam_securetty is documented in README.pam_securetty. The directory varies by distribution.

In contrast, Debian organizes PAM-related packages differently. While Red Hat and SUSE have all-encompassing packages with most PAM modules, Debian has a series of libpam packages that you can browse with the apt-cache search libpam command. Install the ones you need; the packages are individually documented.