Recognize basic recommended access methods

Reviewer: name contact BSD flavour

Concept

Be familiar with standard system administration practices used to minimize the risks associated with accessing a system. These include:

using ssh instead of telnet
denying root logins
(possibly) using the third-party sudo utility instead of su, and
minimizing the use of the wheel group.

Introduction

Many BSD machines are used as "servers" in locations away from the system administrator. Since the earliest days of networking, methods have been developed to access one machine from a terminal or another machine. Access to remote machines, particularly those accessible from the public Internet, must be secured from access by unauthorized personnel. In addition, good security practice demands that we limit the number of people who know (or need to know) root's password at all.

Use `ssh` instead of Telnet or `rsh/rlogin`

Telnet(1) was an early implementation of a "remote control" application. Another early program set for remote administration was rsh(1) and rlogin(1). While these are still valid for limited uses today, they should never be used to administrate a machine over a network, because all data in telnet or rsh and rlogin is transmitted without encryption, or in "plain text". Anyone with the ability to run a "packet sniffing" program could read your password and all other transactions between you and your system if you use telnet or rsh/rlogin. Except in limited circumstances, such as in a locked-down facility with hungry guard dogs and a single armored cable which no one else can access between you and the server, which is in plain sight and surrounded by an electric fence, don't use rsh, rlogin or telnet, OK? Use ssh instead!

ssh consists of two programs developed by the OpenBSD team, ssh(1) and sshd(8). ssh is a client program which provides terminal access (and other features) to another machine. sshd is a server daemon which runs on the "other machine". Together, these two programs provide all the features (and more) of rsh/rlogin and telnet, and also provide you with more security --- using ssh ensures your sessions are protected by strong encryption.

More about ssh appears in the following paragraphs and the next three sections.

Deny Root Logins

Since the "root" account can do anything at all to a system, good security practice requires that root logins be restricted to the physical console of the machine itself, and, usually, only in dire circumstances. Both local and remote (SSH!) logins should be as a "normal" user, and normal users who need to run programs that require root's authority should use an alternate method to "get root".

Reasons for this are many, vary in importance to various individuals, and are frequently discussed in newsgroups, e-mail lists, internet forums, and other materials. Briefly, here are some things to think about:

The "onion" principle of security: if someone compromises remote access, is it better that they get limited capabilities, or root privileges? What if they have access to the machine's console and have seen someone login a few times? If so, what if their memory is photographic?
The "oh my!" principle of sanity: someday, sometime, someone will have a bad day. If someone is logged in as root when that happens, the possibility for much more damage exists. The classic example of this argument is in the use of rm(1), but plenty of havoc can be wreaked with chown(8), chmod(1), and other programs as well. File permissions are one protection from these types of errors, but permissions don't do any good if you're logged in as root when a mistake occurs.
The "oh no!" principle of spitefulness: in real life and real work, people get fired, canned, terminated, and, sometimes, angry about it. If your superior fires a team member on a day when you're not there to turn off their access to the system, and they know the root password, there is a chance, no matter how "nice" that person may seem, of them manifesting a streak of vindictiveness prior to cleaning out his/her desk or cubicle, with potentially damaging results.

For more on this subject, keep reading. To set sshd to deny root logins, see the next section Configure an SSH server according to a set of requirements.

`su`, the "wheel" group, and `sudo`

Since we want all logins to be by "normal" users, how will we accomplish tasks like software installation, modifying system-wide configuration files, restarting daemons, or rebooting the system?

Traditionally, anyone who has a need to do this sort of chore is a member of the "wheel" group. Only members of this group are allowed to use su to gain root privileges. In order to "get root" with su, you must enter the root password and "become" root.

More recently, many system administrators use sudo to allow root privileges. Sudo was developed at SUNY/Buffalo in 1980 and is currently maintained by OpenBSD; it is available in their default install, or via the ports/packages system on other BSD flavors.

sudo is highly configurable, contains extra notification and security mechanisms, and can even be configured to allow groups of users access to a limited set of commands (for example, to allow the webmaster to restart httpd, but not restart the system, or to allow normal users to mount and umount media but not newfs them, etc.)

For more information about sudo, install it and read the manpage, or visit http://www.sudo.ws/.

Examples

Connecting to a remote machine:

""$ telnet myserver.example.com

Trying 6.7.8.9...
telnet: connect to address 6.7.8.9: Connection refused
Trying 6.7.8.9...
telnet: connect to address 6.7.8.9: Connection refused
telnet: Unable to connect to remote host

Good! Telnetd isn't enabled on your remote machine!

""$ ssh me@myserver.example.com

You may see a banner message at this point. If you are using password-based authentication, you will be prompted:

Password:

Enter your passphrase and you will see information from various files and programs; among them, last(1), uname(1), and /etc/motd:

Last login: Wed Jan 10 11:29:26 2007 from 9.8.7.6

Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
    The Regents of the University of California.  All rights reserved.

FreeBSD 6.0-RELEASE-p13 (GENERIC) #3: Thu Sep 28 20:02:55 CDT 2006

Welcome to FreeBSD!

If you use key-based authentication, no password is required. Your shell resource scripts will be called, your environment set up, and you should receive a shell prompt:

You are now "logged in".

a word about `user@host` syntax

In the example above we used user@hostname with ssh to specify the remote account and remote server to connect to. Other methods to specify the username include editing the local ~/.ssh/config file or using the "-l" flag when calling ssh. If you simply ssh hostname, ssh will attempt a login using the name given by id(1).

Using `su` and `sudo` to gain root privileges:

Let's do a chore that requires root's power to accomplish. Suppose we want to enable natd(8), the "Network Address Translation Daemon", at the next bootup:

""$ echo 'natd_enable="YES"' >> /etc/rc.conf /etc/rc.conf: Permission denied.

As a "normal" user, you can't append (or edit) /etc/rc.conf; it's owned by root and "chmodded" to 744 for security reasons (and should be!) So, use su:

""$ su Password:

If you are in the wheel group, you are prompted for the root password (if you are not in the wheel group, you simply get Su: sorry). If you enter root's password correctly, you get a new shell with root's prompt and environment. Now try the command:

""# echo 'natd_enable="YES"' >> /etc/rc.conf

It succeeds silently, and the directive is added to the rc.conf file.

If sudo(8) is on your system, you must edit the sudoers file as root before attempting to use sudo. Use the visudo(8) program to invoke $EDITOR on sudoers and set permissions appropriately. After this, allowed users should be able to accomplish "root level" tasks with sudo like this:

""$ sudo shutdown -r now

Depending on sudo's configuration, the command may succeed silently, or the user may be prompted for their own password (instead of the root password). Coinfiguring sudo to work without a password prompt is very convenient, but the password prompt is also a great behavior for at least two reasons: 1] it means that the administrators don't have to actually know the root password to do "important" tasks, thereby protecting password integrity, and 2] the user is reminded that he/she is about to do something using root privileges, and will hopefully think carefully about the command before continuing.

Using the first example above, something strange seems to happen when prefaced by sudo:

""$ sudo echo 'natd_enable="YES"' >> /etc/rc.conf /etc/rc.conf: Permission denied.

This is because sudo executes the echo command, but stops at the redirect, so the "normal user" is attempting to redirect to the protected file. It's a tad tricky (watch the quotes!), but here's a way around this problem:

""$ sudo sh -c "echo 'natd_enable="YES"' >> /etc/rc.conf"

We have sudo call a single command, "sh -c", as root, and this /bin/sh process takes care of both the echo call and the redirection using root's UID. You could have similar problems if you try something like sudo foo && bar - you would need to call sudo for both commands, or do some quoting magic.

Practice Exercises

Attempt to use telnet to a remote machine. If you get a password prompt, disconnect immediately and call the machine's administrator as soon as possible.
Use ssh to connect to a remote machine.
If you are the system administrator/owner or a member of the wheel group on a system, login as a normal user and use su to get root. Edit /etc/rc.conf and add the line:

# This line added by me on date
If you are the system administrator/owner or a member of the wheel group, install sudo and configure it to allow you to use it. Call sudo $EDITOR /etc/rc.conf at your prompt, then remove the line you added in exercise 3.

More information

ttys(5), sshd_config(5), ftpusers(5); the (possibly third-party, depending on your BSD flavor) utility sudo which includes visudo(8), suedit and sudoers(5).