|
This is the BSDA Study Guide Book written via a
wiki collaboration.
This is a work in progress. You may contribute to or discuss this specific page at http://bsdwiki.reedmedia.net/wiki/Recognize_basic_recommended_access_methods.html.
Recognize basic recommended access methods
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).
|