Just as the best mechanics tinker to improve the performance of an automobile, the best Linux geeks tinker to improve the security and speed of the operating system on their computers. When a Linux geek tinkers with the start sequence, he changes the configuration of his system, starting with the boot process, and continues with user logins.
There are a number of potential annoyances that affect the speed and security of a Linux system. Default configurations start too many services. We show you how to minimize this risk.
I spend a lot of time on passwords in this chapter because it's important to get them right at the very start, and because problems with root passwords can require you to reboot the system. In this chapter, I show you ways to require users to choose strong passwords. I also show you how to recover if you've lost your root password. Unfortunately, the same method that allows you to bypass the root password may allow a cracker to take control of your system. Therefore, this chapter also discusses physical and system boot security.
Defaults in terminal and service configurations allow too many people to log in, even with blank passwords. All of this work may be for naught unless you remember to keep your systems physically secure.
Current versions of Windows boot fairly quickly, faster than most Linux configurations. But the reason Linux is slower to boot is that most distributions install, by default, a lot of software that few users need—and to make things worse, the distributions are configured to have them start automatically. If you can get rid of this software, you have a win all around: the system boots faster, demands less of your hardware, and is more secure.
Many users don't know, for instance, that they are running a sendmail or Postfix mail daemon all the time. (One system I tried takes more than a minute just to get the sendmail daemon started.) For all except a handful of servers in a larger network that really deliver mail, running such a daemon is a waste of time and perhaps a security risk.
Several distributions (notably SUSE and Red Hat/Fedora Linux) hide the startup messages associated with the Linux kernel and Linux services when their systems boot. Many feel that hiding these messages (as is done during the Microsoft boot process) is less intimidating to novice users. But as a Linux expert, you need to know what's happening during the boot process. In this section, I'll show you how to find out what's running, decide what you need, and shut down the rest.
There are two approaches to this annoyance: uninstall services that you'll never need, and deactivate services that you aren't currently using. Both approaches are straightforward and should be familiar to most Linux geeks. Once you complete this process, you've reduced the time required to boot and improved the security of your systems.
The commands for uninstalling a service are straightforward; the dpkg -r
packagename or rpm
-e packagename command removes
the specified package from the system. But that leaves support
packages and libraries on the system that you don't need. You can use
command-line or GUI tools to uninstall them.
Tip
If you're annoyed by dependencies, read the related annoyances in Chapter 8.
If you don't share directories and printers with Microsoft Windows computers, you don't need Samba on your Linux computers. In this case, you can uninstall Samba. However, if you want to disable all connections to Microsoft Windows computers, you'll also need to uninstall related packages such as samba-common.
You can uninstall Samba packages from the command line. First, you need to know what to uninstall. To find Samba-related packages on Red Hat/Fedora or SUSE, just run:
r -qa | grep samba
Alternatively, to find Samba-related packages on a Debian-based distribution, run:
dpkg -l | grep samba
Either command provides a list of installed packages associated with Samba, which you need to uninstall to remove Samba from your system.
When you manage packages from the command line, Debian goes one better. The apt series of commands allows the Linux geek to clean packages and associated dependencies. For example, the following command deletes not only the samba package but also the SWAT configuration package that accompanies it:
apt-get remove samba
If you've installed the yum (Yellowdog Updater, Modified) package management tool, you can remove all related packages with a similar command:
yum remove samba
But among the major distributions analyzed in this book, yum is installed by default only for Fedora Core. For more information, see "Avoid Dependency Hell with apt" and "Avoid Dependency Hell with yum" in Chapter 8.
Most systems have several hundred packages installed. If that's bewildering, a visual overview of related packages can help. The GUI tools from Debian, Red Hat, and SUSE organize packages in groups. With the embedded comments, these tools can help you review the purpose of each package.
GUI tools can help define, review, and uninstall packages by groups, which makes it less likely that you'll leave an orphaned package. Unfortunately, just about every distribution uses a different GUI tool: Debian offers Synaptic, SUSE offers YaST2, and Red Hat-based distributions offer the Package Management tool, also known as system-config-packages (Red Hat is moving toward pirut, at least on Fedora Core, as it integrates well with yum.) One advantage of the Red Hat, SUSE, and Debian GUI package-management tools is that they highlight any dependencies associated with packages you might want to uninstall. Thus, when you remove a tool, you can also remove these dependencies (libraries or other related software), assuming that they're not required for other packages you want to keep. Unfortunately, this is not foolproof. The GUI tools may not be able to identify dependencies if you've installed packages not built for your distribution.
Both command-line and GUI tools are effective in managing installed packages. Whether you use the command line or the GUI is a matter of personal taste.
On a Red Hat Enterprise Linux 3 computer I administer, I've uninstalled the mail, web, and DNS server package groups because I don't normally run those servers. This cleanup alone reduced the boot time for this computer by two minutes.
As a Linux geek, you've probably installed packages from a tarball. This is commonly associated with a package organized and compressed into a single file archive. Common tarball formats include .tar.gz, .tgz, and tar.bz2. All can be unpacked with the tar command; the -z and -j switches apply the gunzip and bunzip2 commands to these compressed formats.
When you unpack a tarball, the packaged files are opened in a subdirectory that is easy enough to clean up. But when you compile the files and install the software, the installation process often distributes the files to a number of different directories. Cleaning up these files is generally more trouble than it's worth. That's one reason the RPM and DEB package-management systems are preferred.
Generally, it's best to just remove any services that you don't need. Once you uninstall a service, you almost eliminate the risk that a cracker will use that service to break into your system.
However, if you're starting to configure a service such as vsFTP, you may want the service installed during the test process. In that case, you should disable that service to make sure it is not currently running and doesn't start up automatically the next time you boot Linux.
We've described how you can remove packages associated with a service. But if you want to deactivate a service, the process is a bit more complex.
First, list installed regular services. In Red Hat/Fedora, Debian, and SUSE, you can do so with the following command:
ls /etc/init.d
There are also other services associated with the so-called Internet "super server." By default on Red Hat/Fedora and SUSE, the super server is xinetd, which controls services in the /etc/xinetd.d directory, and individual scripts can be listed with:
ls /etc/xinetd.d
In Debian Linux, super-server services are configured directly in the /etc/inetd.conf configuration file. The way you deactivate a service varies between the Red Hat/Fedora/SUSE and Debian distributions.
With Red Hat/Fedora and SUSE, the simplest solution is to turn off the noted service. For example, if you're in the process of configuring Samba, you want to keep the packages installed, but you want to keep the daemons inactive. The following commands deactivate the Samba daemon and make sure that it doesn't start the next time you boot Linux:
/etc/init.d/smb stop chkconfig smb off
Once you've configured Samba, you'll want to make sure it starts in appropriate runlevels. The following command makes sure Samba starts in at least runlevels 3 and 5 in Red Hat/Fedora and SUSE Linux:
chkconfig smb on
Managing scripts in Debian distributions is similar. In these cases, it's easiest to turn a service off in all runlevels. The following command deactivates Samba and then makes sure it does not start the next time you boot Linux:
update-rc.d -f samba remove
You can then restore Samba service in the runlevels of your choice. The following command restores it in the standard runlevels:
update-rc.d -f samba start 20 2 3 4 5 .
Tip
The 20 in the above command determines the order in which services are started and stopped in each runlevel. Lower numbers are run first. For example, my Debian /etc/rc2.d directory starts the S15bind9 service before S21sendmail, as sendmail may depend on DNS.
Debian handles runlevels differently from Red Hat/Fedora or SUSE. If you've installed a GUI for Debian, it automatically boots into the GUI login screen, unless you choose to boot into single-user mode. Unlike Red Hat/Fedora and SUSE, Debian runlevels 2 through 5 normally start and stop the very same services.
Major distributions provide GUI tools for managing runlevels and services. Like the package-management GUI tools described earlier in this chapter, the tools vary by distribution: Debian can use ksysv, Red Hat provides the Service Configuration tool, and SUSE embeds its runlevel editor in YaST. Unlike the package-management tools, the tools for managing services are usually considered eye candy and not as convenient for system administrations as doing things by hand on the command line, but you are free to try them and see whether they do the trick for you.
Developers are adapting the Linux kernel for larger amounts of RAM. Traditionally, a 32-bit address space (4 GB) has been divided so that user-space applications have access to 3 GB and the kernel has access to 1 GB of memory. The so-called 4G/4G patch is designed so that both the kernel and user space can make full use of more than 4 GB of RAM on 32-bit systems.
The developers believe that this patch is not worth the overhead for 32-bit systems with less than 16 GB of RAM (http://lwn.net/Articles/39283/). I agree. I've found that the 4G/4G kernel slows down the boot process significantly on my systems (all with 1 GB of RAM or less). I therefore use Linux kernels without this feature and suggest that you do not install this patch unless you have appropriate levels of RAM.
One more problem that can slow the boot process is a remotely mounted network directory. Certainly, remote mounts are valuable in many LANs; it is common practice to mount critical directories—even the users' home directories—from a central server. However, if you have connectivity problems on your network or if the server is prone to going down (hint: replace your Windows server with Linux), the systems mounting the directories can experience slow boots or even complete system hangs during the boot process.
The problem is most significant with shared NFS directories. If a server or network is down, Linux keeps trying to mount a remote NFS directory. If you've configured a hard mount, connectivity problems can stop your boot process for minutes—or even, in some cases, stop it cold. In contrast, while NFS soft mounts are slower under optimal conditions, they expire by default after 60 seconds. If you have network problems, a NFS soft mount won't stop your boot process. However, soft mounts can lead to data corruption on some programs.
Tip
For a description of hard- and soft-mounted NFS directories, see the NFS HOWTO at http://nfs.sourceforge.net/nfs-howto/client.html.
There are two major bootloaders associated with Linux: GRUB and LILO. If you have a problem with a bootloader, it's important to know how to go through the associated configuration files with a fine-tooth comb.
The Grand Unified Bootloader (GRUB) has become something of a standard in Linux. It's the default for Red Hat/Fedora, SUSE, and Debian. As you might expect, there are differences in the way it's configured on different distributions. For example, while Red Hat/Fedora uses grub.conf, SUSE and Debian use menu.lst. In either case, the file is stored in the /boot/grub directory.
GRUB typically comes in three stages, known as 1, 1.5, and 2. Stage 1 is a pointer from the MBR to the boot sector of the hard drive. Control is transferred to stage 1.5, associated with /boot/grub/*1_5 files. Control is then taken by stage 2, which displays the menu and options as defined in the main GRUB configuration file.
When you read the GRUB configuration file, be aware that many
GRUB numbers start with 0. For example, the first partition on the
first SCSI or SATA hard drive is known as sd(0,0), the second partition on the first
SCSI or SATA hard drive is sd(0,1),
and so on. In addition, default=0
defers to the first kernel stanza in the file. Because we're just
diagnosing the standard versions of this file, I won't examine too
many special directives within GRUB.
Both Red Hat/Fedora and SUSE include special directives that go over and above the standard GRUB directives as defined by its author, the Free Software Foundation. For more information, see http://www.gnu.org/software/grub.
Tip
Fedora Linux now adds rhgb
quiet to the kernel directive line. SUSE Linux adds
splash=silent to the
corresponding line. These directives substitute a relatively blank
splash screen for the hardware-detection and service start messages
associated with previous versions of Red Hat-type distributions. You
can still monitor these messages by pressing the Esc key during the
boot process.
The following is an excerpt from my Red Hat Enterprise Linux 3 version of the GRUB configuration file, with comments:
password --md5 $$1$7/P7g0$eJKez1Tddjfl498.!kd. default=0 timeout=10
This GRUB menu is password-protected. If the user doesn't
select an available option, GRUB boots the operating system
associated with the first stanza (default=0) after 10 seconds. If you have a
second stanza and wanted to make that the default, you'd set
default=1.
splashimage=(hd0,1)/grub/splash.xpm.gz
Red Hat displays its own version of the GRUB menu as a
splash image. It's located in the
/boot directory, which happens to be on the
first IDE hard drive, on the second primary partition (hd0,1).
title Red Hat Enterprise Linux ES (2.4.21-15.EL)
root (hd0,1)It's easy to get confused here. The root directive has two meanings in
GRUB. By itself, it refers to the partition associated with
the /boot directory. When used with the
kernel or initrd directives, root refers to the actual root directory
(/) on your filesystem.
kernel /vmlinuz-2.4.21-15.EL ro root=LABEL=/ hdd=ide-scsi initrd /initrd-2.4.21-15.EL.img
The kernel directive
defines the kernel to load. In this case, it's the
/boot/vmlinuz-2.4.21-15.EL.img file. The
Initial RAM disk (initrd) file
loads a read-only filesystem (ro)
into RAM, before Linux loads drivers and other modules.
If you have multiple kernels, you may have more than one Linux stanza. Here is a sample alternative stanza:
title Red Hat Enterprise Linux ES (2.4.21-20.EL)
password --md5 $1$9U66g0$nFbkwahtdojv2JXLIEj7i1
root (hd0,1)
kernel /vmlinuz-2.4.21-20.EL ro root=LABEL=/ hdd=ide-scsi
initrd /initrd-2.4.21-20.EL.imgYou'll note that the contents of this stanza are nearly identical to the directives shown at the start of this section; besides the password protection, only the version number of the kernel and Initial RAM disk have changed. A Linux geek who is testing a new kernel on a user's workstation may want to protect that new kernel with a password. I'll show you how you can create an encrypted password shortly.
If you're unfamiliar with GRUB, read the previous
section on the Red Hat GRUB configuration file for basic
information. In general, SUSE discourages manual configuration of
files such as the GRUB configuration file. Nevertheless,
understanding the directives in the file can help you diagnose any
problems that may arise. SUSE uses a slightly different set of
configuration files. It starts with the
/boot/grub/device.map file, which translates
the GRUB name for the hard drive (hd0) to the Linux device name for that
drive (/dev/hda):
(hd0) /dev/hda
SUSE continues with a simplified /etc/grub.conf configuration file, designed to set the stage for installing the bootloader. My version includes the following directives:
root (hd0,6)
In this case, (hd0,6)
refers to the main root directory, associated with partition device
/dev/hda5.
install --stage2=/boot/grub/stage2 /boot/grub/stage1 (hd0) \ /boot/grub/stage2 0x8000 (hd0,6)/boot/grub/menu.lst quit
The install directive takes
control from the bootloader. Once the filesystem files in
/boot/grub are installed, the file hands over
control to the menu.lst configuration file. The
following are the basic directives from my version of this
file:
color white/blue black/light-gray default 0 timeout 8
These directives set up a color scheme. They also configure the first stanza as the default, which is started automatically if there's no user input within eight seconds.
gfxmenu (hd0,6)/boot/message password linux4me
The SUSE-designed splash menu is known as gfxmenu. If you use YaST to edit GRUB, you won't be able to enter an encrypted password. You can still use the grub-md5-crypt command to encode an MD5-encrypted password, as I described in "Password-protecting GRUB," earlier in this chapter.
Tip
SUSE disables the gfxmenu
menu if you configure GRUB with a password. The alternative menu
looks similar to the Red Hat GRUB menu.
title SUSE LINUX 9.2
kernel (hd0,6)/boot/vmlinuz root=/dev/hda7 vga=0x314 selinux=0 \
splash=silent resume=/dev/hda6 desktop elevator=as showopts
initrd (hd0,6)/boot/initrdThis stanza configures the default SUSE 9.2 installation. The
kernel root directory is ( hd0,6 ), also known
as /dev/hda7. The Linux kernel is associated
with the /boot/vmlinuz file (which happens to
be linked to the actual kernel). The vga=0x314 option forces 800 × 600
resolution (easier on my eyes). As shown by selinux=0, security-enhanced Linux
policies are disabled.
As with the latest Red Hat installations, SUSE hides the
hardware detection and service start messages (splash=silent). The resume option specifies the swap
partition. The elevator=as option
defines a kernel access algorithm to the hard disk. (For more
information on this algorithm, load the kernel source code and read
the as-iosched.txt file in the
/usr/src/linux/Documentation/block directory.)
The showopts option lists boot
options on the GRUB command line.
Finally, the initrd
directive starts the Initial RAM disk. It's listed on partition
/dev/hda7, in the /boot
directory.
SUSE includes a fail-safe stanza by default:
title Failsafe -- SUSE LINUX 9.2
kernel (hd0,6)/boot/vmlinuz root=/dev/hda7 showopts ide=nodma \
apm=off acpi=off vga=normal noresume selinux=0 barrier=off \
nosmp noapic maxcpus=0 3
initrd (hd0,6)/boot/initrdThe kernel command line includes additional options that are
straightforward. DMA is disabled for IDE devices. APM and ACPI power
management are both disabled. No special VGA options are noted. No
applications are suspended to the swap partition (noresume). Symmetric multiprocessing, APIC
(Advanced Programmable Interrupt Controller), and the use of
multiple CPUs are disabled. Finally, the kernel is set to start in
runlevel 3.
Debian's GRUB bootloader is quite similar to SUSE's. Both use the /boot/grub/menu.lst configuration file. Just as you can configure the SUSE GRUB bootloader with YaST, you can configure the Debian GRUB bootloader with the update-grub command, which reads kernels listed in the /boot directory.
But a Linux geek learns the code within the configuration files. The standard Debian (Sarge) menu.lst file is well commented. For this annoyance, I'll examine a portion of the directives from my own Debian menu.lst file. It starts with the same standard commands as other GRUB bootloaders:
default 1 timeout 5 color cyan/blue white/blue password --md5 $1$7/P7g0$eJKez1Tddjfl498.!kd
If you've read the previous two sections on the Red Hat and
SUSE versions of GRUB, you should be familiar with these directives.
The default 1 directive points to
the second stanza; it's automatically booted if there's no user
input within five seconds. A typical blue color scheme is defined
for the boot menu, and the menu is password-protected.
If you want to make the user's previously selected boot option
the default, change default 1 to
default saved. It works with the
savedefault directive later in
the file.
title Debian GNU/Linux, kernel 2.6.8-1-386 root (hd0,4)
This illustrates a /boot directory on the first IDE hard drive, on the fifth partition, which is also known as /dev/hda5.
kernel /vmlinuz-2.6.8-1-386 root=/dev/hda6 ro
The kernel directive cites
the kernel to load from the /boot directory,
followed by the partition with the real top-level root
directory.
initrd /initrd.img-2.6.8-1-386
The initrd directive loads
the Initial RAM disk from
/boot/initrd.img-2.6.8-1-386.
savedefault
The savedefault directive
works only in conjunction with a default
saved directive earlier in this file. With savedefault, if a user selects this
operating-system stanza, it becomes the default the next time this
computer is rebooted.
boot
The boot directive, which
uses all defaults because it bears no options, proceeds to boot
Linux with the given parameters in the stanza.
The LILO bootloader has fallen out of favor. It's not as easily customizable as GRUB, and it doesn't offer a command interface during the boot process. It does not support encrypted passwords. However, it's often the only bootloader that works with many different SCSI disks, so it is still in fairly common use.
LILO can be protected with two commands:
password=somepass restricted
The first command, when alone, requires users to enter a
password to boot an operating system. When you add the second
directive (restricted), it keeps
crackers from entering a command such as init=/bin/sh at the boot prompt, where they
could then change the root password.
As LILO can recognize only passwords in clear text, you should limit read and write access to the root user with a command such as:
chmod 600 /etc/lilo.conf
Once you've added the commands of your choice to /etc/lilo.conf, you'll need to write it to the MBR with the /sbin/lilo command.
Red Hat and Fedora distributions try to make it easy to convert from GRUB to LILO. They include a template configuration file, which you can find in /etc/lilo.conf.anaconda, based on the operating systems detected during installation.
Most Linux systems actually offer multiple boot options. The most common dual-boot configuration allows you to boot either Linux or Microsoft Windows. And in fact, most modern Linux distributions automatically detect a pre-existing Windows operating system during the installation process. The Windows partition is left alone, and the installation program adds a stanza to the bootloader to facilitate booting into Windows.
You don't have to have a second operating system to have a dual boot. If you've installed new kernels from an RPM or DEB package, it has set up alternate kernel selections in GRUB or LILO. Alternatively, if you installed a new kernel from a tarball, you need to know how to configure a new kernel selection in your bootloader.
In this annoyance, I'll show you the basics of configuring a dual boot for multiple Linux kernels, as well as a configuring a dual boot on GRUB and LILO for Linux and Microsoft Windows. This annoyance provides fundamental bootloader basics for the one that follows.
If you have just configured a new Linux kernel, you'll want to be able to boot both the old and the new kernel. At least until you've completely tested the new kernel, you need access to the old one just in case something goes wrong.
If you install (not upgrade) a Linux kernel from a modern RPM or DEB package, the process automatically adds the new kernel to your current bootloader. If you're using a distribution with one of these systems, you generally should use the kernels as compiled by the distribution company. This helps make sure that drivers get to the right directories. In addition, Red Hat (and others) often include "backports" from more advanced kernels, especially in its enterprise series of distributions.
Warning
Do not use the "upgrade" option for kernel RPM or DEB kernels. It overwrites your existing kernel. If the new kernel doesn't work on your system, you'll have to boot into some rescue or Knoppix recovery system in order to download and reinstall the original kernel. And that can be annoying.
However, if you want the latest in functionality, you may need to use the latest kernel, in tarball format, from http://www.kernel.org or one of its mirrors. When you unpack and compile the kernel from the source code, it does not automatically upgrade your bootloader, so you'll need to upgrade it yourself. For more information, see "The Kernel Needs an Upgrade" in Chapter 7.
Fortunately, GRUB and LILO stanzas associated with the former kernel can help. Generally, all you need to do is modify the version numbers associated with the kernel and initial RAM disk.
For example, if you've upgraded from a Debian 2.6.8-1-386 kernel
to a kernel.org 2.6.11 kernel,
you'll need to set up another stanza in your bootloader. When you
compile a new kernel, it's useful to modify the EXTRAVERSION variable in the
Makefile, which you can find linked from the
/usr/src/linux or
/usr/src/linux-2.6 directories.
Tip
Starting with Fedora Core 3 and Red Hat Enterprise Linux 4, Red Hat no longer includes a binary kernel source code package. You'll have to install from the kernel source code .src.rpm package. The resulting Makefile can be found in the /usr/src/redhat/BUILD/kernel-2.6.9/linux-2.6.9 directory (the version numbers will vary). For details, see Chapter 7.
For instance, if you set:
EXTRAVERSION=-new
before you compile a kernel, you'll get a file with a name such as vmlinuz-2.6.11-new. Take a kernel with the following stanza in a GRUB configuration file:
title Debian GNU/Linux, kernel 2.6.8-1-386 root hd(0,5) kernel /vmlinuz-2.6.8-1-386 root=/dev/hda7 ro initrd /initrd.img-2.6.8-1-386 savedefault boot
After you've compiled the new kernel from source and created an associated Initial RAM disk, you can set up a new stanza for that kernel. I'm assuming that you're storing the kernel and Initial RAM disk files in the standard location, /boot. The new stanza would look almost identical to the previous stanza:
title Debian GNU/Linux, kernel 2.6.11-new root hd(0,5) kernel /vmlinuz-2.6.11-new root=/dev/hda7 ro initrd /initrd.img-2.6.11-new savedefault boot
Generally, if you've created a new kernel, you should create a new Initial RAM disk using the new kernel version number. For example, if your new kernel is vmlinuz-2.6.11-new, you'd use the following command:
mkinitrd 2.6.11-new
The changes in a LILO configuration file follow the same pattern, and the modifications are elementary.
There are several annoying reasons why you might have to rebuild GRUB or LILO in a dual-boot configuration. A junior administrator might have deleted the file. Hard drive corruption might have made the file unusable. Someone else might have edited the bootloader incorrectly.
Tip
In the next section, we'll examine a bigger annoyance: what happens to the bootloader (and what you can do about it) when someone reinstalls Microsoft Windows.
Fortunately, the Linux bootloader directives associated with Microsoft Windows are fairly simple.
If you need to set up Microsoft Windows in a dual boot, you need to know the partition with the basic Microsoft Windows system filesystem. If you're in Linux, you can make a good guess with an fdisk -l command. That will show the partitions with Microsoft-based filesystems. Some examples include:
Device Boot Start End Blocks Id System /dev/hda1 * 1 20012 10929039+ 7 HPFS/NTFS /dev/hda2 20012 77520 30453674+ f W95 Ext'd (LBA) /dev/hda5 20012 40024 10929039+ c W95 FAT32 (LBA)
fdisk recognizes the format of each partition and displays it in the final column. Yes, the System label associated with the first partition is vague. HPFS is short for the High Performance File System, which is associated with IBM's OS/2 operating system. I don't have one of these operating systems available, so I haven't tested it. But as it's designed for partitions of 200–400 MB and can't be read by Windows NT 4 and above, you're unlikely to encounter it today. The alternative is NTFS, Microsoft's New Technology File System. Linux's fdisk does not distinguish between Microsoft's NTFS standards, which have changed as Microsoft operating systems have evolved from NT 4 to 2000 and then XP/2003.
A simple GRUB stanza for Windows begins with a title, which can specify anything you'd like to jog your memory:
title Windows
Because the first partition is bootable, it should contain an operating system. In GRUB, this can be associated with the following directive. While it points to the first partition on the first IDE hard drive, it does not attempt to mount it in a Linux fashion:
rootnoverify (hd0,0)
A GRUB pointer to a Microsoft operating system requires one more
directive. The chainloader
directive points to the first sector (+1) of the
noted partition, from where just about any operating system continues
the boot process:
chainloader +1
The results are straightforward. A typical GRUB stanza for a Microsoft Windows operating system is:
title Windows NT/2000/XP root (hd0,0) chainloader +1
A LILO stanza for Windows also contains a line for a title, such as:
label = Windows
To specify the bootable partition containing Windows, you need two directives. The first indicates you're booting a non-Linux operating system located on the /dev/hda1 partition, and the second keeps LILO from looking for a Linux boot image:
other=/dev/hda1
optionalAll together, a typical LILO stanza pointing to a Microsoft Windows operating system looks like:
other=/dev/hda1
optional
label = WindowsThere are other commercial bootloaders that can load Linux on a computer. Some aren't directly related to any operating system. The leaders in this area include Partition Magic (http://www.symantec.com/partitionmagic) and Partition Commander (http://www.v-com.com). The alternative is to boot Linux with the Microsoft Windows bootloader, NTLDR.
If you want to use NTLDR, most documents strongly recommend that you do so with a boot disk. In NTLDR, the basic menu is associated with the C:\boot.ini file. Normally, it includes commands such as:
[boot loader] timeout=5 default=multi(0)disk(0)rdisk(0)partition(1)\WINNT [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINNT="Microsoft Windows XP Professional" /fastdetect /NoExecute=OptIn
If you're familiar with Linux bootloaders, you may recognize the basic format of this file. Essentially, these commands boot Microsoft Windows XP Professional from the first IDE hard disk, after a five-second delay. To configure a pointer to Linux, you need two things. First, add the following line to boot.ini:
c:\linux.bin="Linux"
Next, create a linux.bin file. One method of doing so is with a disk dump from the /boot partition. For example, if /dev/hda7 is mounted on /boot, you can create linux.bin with the following command:
dd if=/dev/hda7 of=linux.bin
Then copy linux.bin to the partition associated with the Microsoft C: directory on your hard drive.
Just remember, Linux bootloaders are designed for multiboot environments, especially with Microsoft Windows. NTLDR is not. You're less likely to be annoyed if you use GRUB or LILO.
One thing some advanced Microsoft users do when their systems slow down is reinstall their version of Windows. Microsoft filesystems do get fragmented frequently, which can affect key Microsoft system and library files. Installations and removals of various applications can also overwrite and even delete these files. Users are frequently annoyed.
But therein lies the problem. If a user reinstalls Microsoft Windows on a dual-boot computer, he or she automatically overwrites any existing non-Microsoft bootloader. Microsoft installation programs do not detect Linux installations. The user loses access to any Linux installations on that computer.
That brings us to the annoyance—what do you do when a user installs Microsoft Windows on a Linux computer? He may have bypassed your security, and he may have installed Microsoft on a computer previously configured in a dual boot with Linux. And now, the Linux bootloader is gone, as well as regular access to the Linux operating system. But that does not necessarily mean you have to reinstall Linux.
If you find that the reinstallation of Windows has overwritten the Linux partitions, then you have no choice. You'll have to reinstall Linux. But chances are good that the Linux partitions are still there, just hidden, and you can recover your Linux system. But you won't know if that's the case until you boot your computer with a rescue disk, as described in the following sections.
Tip
I recently tried Symantic's Partition Magic without reading the instructions. It rearranged the order of partitions on my computer, which led to an error when I tried writing my GRUB configuration to my MBR. Improper use of other partition-configuration tools can lead to the same problem. I'll show you how to deal with this problem in the last part of this annoyance.
For now, we'll assume that your Linux partitions are still there. In this case, recovering a Linux bootloader is a straightforward process. If you're running Red Hat/Fedora or SUSE Linux, the associated installation CDs automatically search for existing Linux installations. If a Red Hat/Fedora or SUSE rescue disk detects its own distribution, it will mount your partitions automatically.
The objective is to reload your GRUB or LILO bootloader. Therefore, you need access to the associated configuration files on the /boot directory, as well as the executable (/sbin/grub-install or /sbin/lilo), which writes the appropriate part of the bootloader to your MBR.
A Red Hat/Fedora rescue installation, if it finds Linux on your computer, mounts your Linux partitions on the /mnt/sysimage directory. Otherwise, you may be able to check for Linux partitions with the fdisk -l command. If there are no Linux partitions on your computer, you're probably stuck. The reinstallation of Microsoft Windows has overwritten your Linux system, and you'll have to restore from backup or reinstall Linux.
But let's assume that Linux is still on your system. After going through the Red Hat/Fedora rescue installation process described in "My Server Is So Secure I Can't Log In as Root," later in this chapter, you'll see a command prompt. Run a df command at the prompt. You'll see output similar to:
Filesystem 1K-blocks Used Available Use% Mounted on rootfs 4151 848 3066 22% / /dev/root.old 4151 848 3066 22% / /tmp/cdrom 132160 132160 0 100% /mnt/source /dev/hda3 6756712 5323020 1090468 83% /mnt/sysimage /dev/hda2 102486 18902 78292 20% /mnt/sysimage/boot
The appropriate partitions are already mounted. To restore the original filesystem hierarchy, run the following command. Then you can run standard Red Hat/Fedora commands to repair your system:
chroot /mnt/sysimage
If the Linux installation is still there, the bootloader configuration files should be intact. You can then run the command to restore the appropriate Linux bootloader to your computer's MBR. For example, if your system uses the first IDE hard drive, run the following to recover GRUB:
/sbin/grub-install /dev/hda
Tip
If you see an error message, the grub-install command is having trouble finding your boot partition. See the last part of this annoyance for a solution.
or the following to recover LILO:
/sbin/lilo /dev/hda
A SUSE rescue installation is not quite as straightforward. It looks for existing Linux partitions. If it finds a SUSE installation, it boots your system in runlevel 3. You'll then need to mount the appropriate partitions. In my case, I have SUSE on just one partition, /dev/hda7. If I needed to rescue my system, I'd mount the partition with my root directory (/) on /mnt with the following command:
mount /dev/hda7 /mnt
The mount command allows you to specify the format of the filesystem, but I don't need to do so for this ReiserFS filesystem because the SUSE rescue system includes reiserfs in /etc/filesystems. If /boot were on a separate partition, I would need to mount that as well.
I then run the following command to set up my original SUSE filesystem:
chroot /mnt
After making sure that my bootloader configuration file is in the right place, I can then run the appropriate command, shown earlier in this section, to write the GRUB or LILO bootloader to the MBR.
Debian and Knoppix rescue systems are quite similar. As described in "My Server Is So Secure I Can't Log In as Root," later in this chapter, a Debian from Scratch CD loads an abbreviated command-line version of Linux, while Knoppix loads a fully functional operating GUI from a CD. However, as Knoppix is based on Debian, they include many of the same tools.
Tip
As described later in this chapter, you can download John Goerzen's Debian from Scratch CD at http://people.debian.org/~jgoerzen/dfs/.
When you boot from the Debian from Scratch CD, it loads a basic Debian operating system. While it's designed just to install Debian over a network, it has nearly full functionality at the command line. It allows you to log in as the root user without a password.
A Knoppix CD loads many of its own systems on a RAM disk. It lists, but does not mount, the appropriate partitions as GUI icons. It provides default mount points in its /etc/fstab. For example, if you have a /dev/hda2 partition, it detects the filesystem format and configures a mount point of /mnt/hda2. If you have directories mounted on different partitions, you may not want to accept the defaults.
For example, when I use Knoppix to boot my Debian installation, the screen shown in Figure 6-1 appears. You can see the available partitions on the left side of the screen. None of the partitions on your hard disks are mounted.
When you open a command-line interface in the Knoppix CD-based desktop, what you can do is similar to your options when you boot from the Debian from Scratch CD. You can su into root without a password. This is necessary, as commands such as mount and grub-install require root privileges.
Normally, you want to mount the partition associated with your root directory (/); in my case, that's located on /dev/hda7. Depending on the rescue system, it may also be /mnt or /mnt/hda7. Once mounted, check the associated files. Make sure it's the right directory. If you have multiple partitions configured for Linux, some trial and error may be required.
Next chroot to the associated directory mount point. Then mount the partition with the /boot directory—in my case, /dev/hda6. So on my Knoppix rescue system, I run the following commands:
mount /dev/hda7 /mnt/hda7 chroot /mnt/hda7 mount /dev/hda6 /boot
This assumes I want the bootloader on the MBR of the first IDE hard drive. After making sure that my bootloader configuration file is in the right place, I can then run the appropriate command, shown in the previous section, to write the GRUB or LILO bootloader to the MBR.
Before rebooting into your standard operating system, don't forget to remove the CD. You might also want to change your BIOS boot order so that you boot first from hard disk, not from CD.
When you use grub-install to write
your GRUB configuration to the MBR, it works only if it can find your
GRUB configuration files. If you see an error message, you may be able
to use the grub> shell to write
GRUB to the MBR.
As suggested earlier, because I did not read the instructions for Partition Magic, I had trouble with it. It renumbered the partitions on one of my laptop computers. I was booting four operating systems on that laptop (Windows, SUSE 10.0, Ubuntu, and RHEL 4 Workstation). I had three partitions with Linux /boot files.
Partition Magic changed the numbers on my partitions. For example, while I configured SUSE 10.0 on /dev/hda7, Partition Magic changed it to /dev/hda8. Partition Magic designated Windows as the active partition. The other partitions were renumbered in a similar fashion; I could not boot with GRUB.
In my case, I used a Knoppix CD to boot my system. I mounted a couple of partitions, in a similar fashion to the previous section. When I ran the grub-install command, I received the following error message:
The file /boot/grub/stage1 not read correctly.
I repeated the process with a SUSE installation CD and got the same result. To address this problem, I took the following steps:
I booted my system with a Knoppix CD, which mounted all partitions on my hard drive.
I searched through the partitions, and found the directory with my desired GRUB configuration file. After reading through the files on the other partitions, I edited GRUB to incorporate the partition settings to point to the four operating systems on that computer.
I selected the /boot and root directory (/) partitions for one of my Linux installations.
I mounted them on appropriate directories. For example, I found the root directory partition of my RHEL 4 Workstation on /dev/hda8, and the /boot partition on /dev/hda7, and ran the following commands:
mount /dev/hda8 /mnt/hda8 mount /dev/hda7 /mnt/hda8/boot chroot /mnt/hda8
I navigated to the /boot/grub directory, and started the GRUB shell:
cd /boot/grubgrubgrub>At the
grub>prompt, I looked for the aforementioned /boot/grub/stage1 file, and GRUB directed me to the right partition:grub>
find /boot/grub/stage1(hd0,7)Then I defined the partition with the bootloader configuration files. A space is required between
rootand the partition,(hd0,7). The output tells me that GRUB has found the bootloader files:grub>
root (hd0,7)Filesystem type is ext2fs, partition type 0x83Finally, I wrote GRUB to the MBR; don't forget the space between
setupand(hd0).grub>
setup (hd0)I rebooted my computer to make sure GRUB was properly written to my MBR.
Newer Linux users are fascinated by the chance to experiment with different components. For the most part, careful experiments should be encouraged in a test environment. How else can we learn Linux? But there are mistakes that can annoy the heck out of us, including the Linux computer that won't stop rebooting.
Grouped in this section are three low-level annoyances associated with the boot process:
The computer starts and then proceeds to shutdown without allowing a login.
The computer starts and then proceeds to reboot, continuously.
Something weird happens during the boot process.
These annoyances are normally associated with configuration problems in boot files. The first two of these annoyances are straightforward, as they relate to the default runlevel on your computer. In each of these cases, you'll almost certainly have to boot with a rescue disk or a system such as Knoppix, as described in the previous annoyance.
On occasion, these annoyances may be related to hardware issues. In those cases, you'll see similar behavior when you use a rescue disk or a system such as Knoppix to boot your system.
Tip
Red Hat has the elite certifications in the world of Linux, including that of the Red Hat Certified Engineer. One of the RHCE skills listed on the Red Hat web site suggests that RHCEs need to "diagnose and correct boot failures arising from bootloader, module, and filesystem errors." Does that sound like it addresses some of the annoyances in this chapter?
This annoyance is often easy to fix. Once you've booted with a
rescue disk and mounted the root directory (/), the
first thing to check is the default runlevel as defined in
/etc/inittab. If it's 0, as shown here, all you need to do is
restore the proper default runlevel, such as 2 for Debian, or 3 or 5
for Red Hat/Fedora or SUSE:
id:0:initdefault
If the id directive isn't set
to 0, you may have a different
problem that's described later in this annoyance.
This annoyance is also often straightforward. Again, boot with an appropriate rescue disk. Proceed by checking the default runlevel in /etc/inittab. If it's 6, as shown here, restore the proper default runlevel, such as 2 for Debian or 3 or 5 for Red Hat/Fedora or SUSE:
id:6:initdefault
If the id variable isn't set
to 6, you may have a different
problem described in the next section.
When Linux boots, it goes through more than just the /etc/inittab file. It reads the default runlevel and then starts the service scripts as defined in the associated /etc/rcx.d directory. While a problem here normally is associated with a configuration problem with a service, it's probably not serious.
If you want to add a program or script to the boot process, each distribution has a dedicated script in the /etc directory for this purpose.
Alternatively, most distributions have a user-definable script. You can use this script to add commands that you want applied to the computer during the boot process. For example, if you've configured a wireless network card using experimental code, you can add the command to start this card to the script. Various distributions define this script differently:
- Red Hat/Fedora
Commands in the /etc/rc.local file run after all other init scripts.
- SUSE
Commands in the /etc/init.d/boot.local file run after all other init scripts.
- Debian
Debian Sarge includes a pointer to /etc/init.d/local in all runlevels. Interestingly enough, this file is missing from the default Debian configuration. But you can create it and add the commands that you need.
One thing that annoys me about Linux is how the default configurations allow simple passwords. Yes, there are warning messages against dictionary words or passwords shorter than six characters. But these are just warnings. By default, most Linux distributions allow simple passwords. SUSE even allows blank passwords.
Fortunately, modern versions of Linux have put some barriers in the way of malicious intruders. For instance, passwords are no longer stored in /etc/passwd, which is world-readable. Instead, they are stored in /etc/shadow, which is readable only by the root user. Still, passwords are subject to dictionary attacks and social engineering (such as when a cracker tries a pet name or favorite term used by the victim). In this section, I'll show how to enforce strong passwords.
One way for an administrator to battle weak passwords is to take on the role of a cracker and run a command such as crack on user passwords. If a password is cracked, the user can be warned, his account can be disabled, or the user can be disciplined in some appropriate fashion. (Of course, management often provides the worst offenders.) But this section focuses on techniques to require strong passwords in the first place.
Tip
Keep in mind that the rules we set to protect the security of our passwords probably annoy most users. If the rules are too difficult, users may post their current passwords in the open, next to their workstations.
You can use the chage command to make users change their passwords periodically. You can even set chage to lock out users if passwords aren't changed within a certain period of time. For example, with the following command, you can restrict user michael. If he doesn't change his password every week, he will be unable to log in after that time:
chage -M 7 -I 7 michael
This command sets the maximum number of days (-M) for which the password is valid. In this case, user michael is prompted to change his password after seven days. If michael doesn't log in for another seven days, the account is rendered inactive (-I), and michael is locked out.
One way Linux distributions define effective password policies is through Pluggable Authentication Modules (PAM). One example of poor security is provided by the default SUSE configuration, which allows blank passwords with the following commands in /etc/pam.d/login:
password required pam_pwcheck.so nullok password required pam_unix2.so nullok use_first_pass use_authok
The first command allows users to enter blank passwords
(nullok). The second command
supports logins with blank passwords, then checks the first and last
time the user logged in for passwords.
Naturally, null passwords are not good when you want a strong
password policy. Therefore, if you're running SUSE, I recommend you
change the password directives
shown to the more secure ones described later in this section.
Linux includes a password strength checker with the cracklib or cracklib2 packages. When combined with PAM and the shadow password suite, this can force your users to choose stronger passwords. All you need is the right PAM module for the passwd command. In Red Hat and SUSE, PAM passwd modules are installed in /etc/pam.d/passwd; in Debian, they refer to /etc/pam.d/common-password.
The key directive in this file is password; the following example from the
Debian file checks the password against the
cracklib libraries, allows the user to try three
times, requires a minimum length of six characters, and allows a group
of three characters to be in common between old and new
passwords:
password required pam_cracklib.so retry=3 minlen=6 difok=3
Naturally, you can make this more complex. The following directive gives the user credit for two characters toward the minimum length of the password for each digit or uppercase character she includes; it gives the user credit for three characters if she includes a punctuation character such as an "!":
password required pam_cracklib.so retry=3 minlen=10 difok=3 \ dcredit=2 ucredit=2 ocredit=3
In other words, this module command would allow the following passwords:
acprksgtlm acp2rgk3 Acp2rgsm Ap2gr!
By default, when users are required to choose a password, the
prompt "New UNIX password" appears. It's a nice enhancement to make
the prompt more appropriate for a Linux system by changing "UNIX" to
"Linux." Do so by adding the type=Linux option to the password directive just after the pam_cracklib.so entry. For example, the
previous command would now be:
password required pam_cracklib.so type=Linux retry=3 minlen=10 difok=3 \ dcredit=2 ucredit=2 ocredit=3
The Red Hat/Fedora version of this file refers to the system-auth PAM configuration file, as shown here:
password required pam_stack.so service=system-auth
When you open /etc/pam.d/system-auth, you
can add type=Linux to the following
password directive:
password requisite /lib/security/$ISA/pam_cracklib.so type=Linux retry=3
Debian has an excellent guide to this process, which is available online in Chapter 4 of http://www.debian.org/doc/manuals/securing-debian-howto.
To explore the standards you can enforce using the
password directive, let's examine
each option in more detail:
debugAdds information to the kernel's logfile, which may be /var/log/messages or /var/log/auth.log.
type=xxxConfigures a new password prompt. The default prompt is "New UNIX password:". I use
type=Linux, which creates a "New Linux password:" prompt.retry=nPrompts the user
ntimes before returning an error.difok=nDefines the degree of similarity between old and new passwords, defined by a group of characters they hold in common; if
difok=3, you're allowed to use three of the same characters between passwords.difignore=nIf the password is at least n characters, the PAM module ignores the
difokvariable.minlen=nDefines the minimum number of characters in the password. This minimum, however, is affected by the
dcredit,ucredit,lcredit, andocreditvariables.dcredit=nDefines the weight of digits in a password. For example, if
dcredit=2, a number in a password gets credit for two characters against theminlenvariable.ucredit=nDefines the weight of uppercase characters in a password. For example, if
ucredit=2, a capital letter in a password gets credit for two characters against theminlenvariable.lcredit=nDefines the weight of lowercase in a password. For example, if
lcredit=2, a lowercase letter gets credit for two characters against theminlenvariable.ocredit=nDefines the weight of other characters (basically punctuation) in a password. For example, if
ocredit=3, a character other than a letter or number gets credit for three characters against theminlenvariable.
As Linux geeks, we have a responsibility to set a good example and avoid easy passwords. However, if you have to change your password frequently, there's a chance that you'll forget it.
If you've misplaced your root password but can reboot your system, recovery is simple:
Boot your computer into single-user mode, which logs you in as the root user, without network connections or server services.
Linux mounts only the root filesystem (the / directory) in single-user mode, but you can mount other filesystems manually with the mount command if you need them.
Use the passwd command to reset the root password.
This useful workaround unfortunately allows a cracker with physical access to your system to get access to the root account. In the next section, I'll show you what you can do to at least slow a cracker in his attempts to break into your system.
To boot your computer in single-user mode, you need to access the kernel command line from your Linux bootloader. I'll show you how you can add your option to the kernel command line in Red Hat/Fedora and SUSE shortly.
Tip
The Debian Linux boot menus include a "recovery mode" option, which automatically boots the system in single-user mode. The SUSE "recovery mode" boots into runlevel 3, which normally includes full functionality without the GUI.
Any of the following commands, if added to the kernel command line, boot into single-user mode:
single s 1
These three options boot Linux into runlevel 1, which is associated with single-user mode.
Some distributions, however, require the
root password in order to boot into single-user
mode. So the options just shown won't help you if you don't know the
root password. However, another option you can
add to the kernel command line bypasses the password check, along with
all other activities associated with the init process, and immediately puts you into
a shell in single-user mode:
init=/bin/sh
Tip
Red Hat distributions do not require the
root password to log in using the single, s, or 1
options. I consider this a security hazard, and therefore an
annoyance. SUSE and Debian both require the
root password to log in using these commands.
However, the root password is not required if
you boot with init=/bin/sh.
When you boot with init=/bin/sh, the
passwd command is disabled by default. But it's
easy to get around this. Just remount your root directory
(/). For example, if
/dev/hda2 is mounted on /,
run the following command:
mount -o remount /dev/hda2 /
You can then change the root account password with the passwd command. While some might consider this to be a flaw, you'll be grateful to know it when you forget a root password or have to do emergency administration on a system where you haven't been told the root password.
Because it's possible to change the root password on our major Linux distributions via single-user mode, additional security is wise. You can take the following steps to further secure your system:
- Set a BIOS password
Modern BIOS systems support passwords, which can keep a cracker from bypassing your bootloader with a boot disk. One drawback is that there are methods to reset a BIOS password. Some of these methods require removing the BIOS battery, which requires opening up a computer case. That may be enough to discourage an attack. For details, see the documentation for your BIOS.
- Set a password on your bootloader
The GRUB and LILO bootloaders also support passwords, which can prevent single-user-mode logins.
- Keep the timeout on your bootloader to a minimum
If you have a minimal timeout on your bootloader, it can prevent a cracker from starting your system in single-user mode, where he or she can then change your root account password.
Password protection for the bootloader may not be enough. If a cracker has access to the reset button and can set your BIOS to boot from a CD/DVD or floppy drive, she can insert a boot disk or even a Knoppix CD to crack your system. We'll describe some of the physical methods you can use to prevent this crack in "The Boss Told Me to Secure the Server Without Locking the Room," at the end of this chapter.
You can add encrypted passwords to GRUB with the grub-md5-crypt command, as follows:
As root, run grub-md5-crypt.
At the command prompts, type the password you want to use to log in, and confirm.
With your mouse, highlight the encrypted password printed by grub-md5-crypt and paste it into the GRUB configuration file. There are two places where you can paste the GRUB password:
If you want to protect the GRUB menu from changes, enter the password as the first line in the GRUB configuration file.
If you want to protect a specific boot option, paste it after the title line of the stanza.
In either case, the
passworddirective will appear as follows; the--md5switch tellspasswordto expect an MD5-encrypted password.password --md5 $1$cg36g0$HgArcGTyynzZhPidnlTe.0
You can add a password to the LILO bootloader to protect the menu or specific operating-system options. Unfortunately, LILO does not support encrypted passwords; you'll have to enter the password of your choice in clear text. Be aware of the security risk. The directive that you'll add to lilo.conf is straightforward:
password=mysecret
As with GRUB, if you want to protect the LILO menu, place the
password directive in the first
part of lilo.conf. If you want to protect a
specific boot option, place the password command after the label directive in the associated
stanza.
If you've forgotten your GRUB and root passwords, you're not stuck. You do not have to reinstall Linux. The problem may be as simple as a misconfigured bootloader, a mislabeled kernel, or an incorrect partition. Or the problem may be more complex, such as a bug-laden kernel or problematic files associated with the boot process. I describe some of these issues in Chapter 7.
The techniques described in this annoyance can help you solve all of these problems. Rescue disks can help you get around boot problems and get into your system. Once you've booted into Linux, you can repair any problems that you see.
You should also read this annoyance from the point of view of the cracker. If you need a really secure system, you need to think like someone who enjoys breaking into computers. It will help you understand the reasons behind the last annoyance in this chapter.
Every Linux distribution that I've used includes some sort of rescue-disk system. It can help you recover from problem kernels, lost root passwords, misconfigured installation files, and more. In this annoyance, I show you how to use the basic rescue disks. I cover how you might use these rescue disks for a troubled system in Chapter 7.
Some rescue disks are more self-contained than others. The Red Hat/Fedora rescue system works from the first installation CD. As shown in Figure 6-2, it can boot your system in several ways, which I'll describe shortly.
Rescue disks load minimal systems onto a RAM disk. The tools contained on those systems are often quite limited. At least the vi text editor (which should be all that a Linux geek needs) is included so you can edit key configuration files after booting.
Rescue systems support password-free root user access. Once you've mounted your root directory (/) in read-write mode, you can recover (or change) the root password. The first step is to restore the standard filesystem hierarchy. Normally, this is possible with the chroot command. The directory that you use depends on the rescue disk, which I'll describe shortly.
Tip
Because of the capabilities of a rescue disk, security-conscious Linux geeks will have a physical lock on critical server CD/DVD drives—and disable USB boot access. We'll detail the importance in "The Boss Told Me to Secure the Server Without Locking the Room," at the end of this chapter.
There are two different kinds of rescue disks that you can create on Red Hat/Fedora distributions. The best kind is customized for your system, and you can create it with the mkbootdisk command. The alternative is already available as part of the first Red Hat/Fedora installation CD, and I describe how you can use that as a rescue disk shortly.
To customize a rescue disk for your system, all you need is the active kernel version number, which you can check with the uname -r command. Insert a floppy disk, and you can create a customized rescue disk with the following command, which takes the output from uname -r, the active kernel version number, and applies it as input to mkbootdisk:
mkbootdisk `uname -r`
In most cases, the boot image is too big for a 1.44 MB floppy drive; most PCs no longer have floppy drives. If you don't have a floppy drive but do have a CD burner, you can create a customized rescue CD with the following command, which writes at standard (1x) speed:
mkbootdisk --iso --device rescue.iso `uname -r` cdrecord -v speed=1 rescue.iso
Naturally, if your CD writer can handle faster rates, you can
increase the value of speed.
Alternatively, you can use the first Red Hat/Fedora installation
disk as a rescue disk.
The procedure for rescuing the latest Red Hat/Fedora distributions is straightforward. If you have a rescue disk, you can use it to boot your system directly. Otherwise, all you need is the first installation CD, using the procedure described here.
At the installation boot screen, enter the linux rescue command. You're taken through the first few steps associated with installation, including language and keyboard. Once you reach the screen shown in Figure 6-2, you have three choices:
- Continue
The rescue system tries to mount your partitions, as defined in your /etc/fstab, on the /mnt/sysimage directory. For example, if you have a separate /boot partition, you'll find those files in the /mnt/sysimage/boot directory. You can then restore your original filesystem configuration with the chroot /mnt/sysimage command and then fix your bootloader or reset your root password as needed.
- Read-Only
The rescue system tries to mount your partitions as listed in /etc/fstab, as read-only. While you can still restore your original filesystem configuration with the aforementioned chroot command, it does not allow you to write to the associated directories. You'll need to remount the appropriate directories in read/write mode with a command such as mount -o remount /dev/hda2 /mnt/sysimage before you can fix your bootloader or reset your root password.
- Skip
The rescue system takes you to a bash shell prompt. None of your standard partitions are mounted; it's as if you started in single-user mode with the
init=/bin/shdirective. You can then mount your partitions, one at a time, until you isolate a problem. Make sure to mount in read/write mode; then you can fix your bootloader or reset your root password.
After you make your choice, no login is required. You have root privileges on this system.
In a similar fashion, you can rescue a SUSE system by booting from the first installation CD or DVD. For example, with SUSE 9.2/9.3/10.0, the procedure is easy: just highlight and run the Rescue System command from the first GUI boot menu. But if you have fatal problems with hardware or drivers, you may need to run the manual rescue method:
From the installation boot menu, run the Manual Installation command.
Select the appropriate language and keyboard when prompted.
From the Linuxrc Main Menu, run the Kernel Modules command.
Load only the drivers that you need to start your system, and then go back to the Linuxrc Main Menu when you're finished.
Select the Start Installation or System command. Select the Start Rescue System command from the menu that appears. Select the source for the installation files (CD, Network, or Hard Disk).
At the Rescue login:
prompt, you can log in as the root user. A
password is not required. None of your existing partitions are
mounted. But if the partitions are error-free, you should be able to
mount them on a directory such as /mnt. Make
sure to check that you're mounting the right partition; remember,
you can list the current partitions on the first IDE drive with the
fdisk -l /dev/hda command. If you've read the
previous section on Red Hat/Fedora, its rescue mode automatically
mounts your configured directories.
Once you've mounted appropriate directories, you can restore your original filesystem with the chroot command. If you've made a mistake, you can always return to the rescue filesystem with the exit command.
Now you can repair your bootloader or reset your root password as needed.
The Debian from Scratch CD was developed by John Goerzen as an alternative to the standard Debian installer. When you boot from this CD, it loads a not-too-minimal version of this operating system.
Warning
When using the Debian from Scratch CD as a rescue disk, don't use the partition tools associated with the installation menu, unless you are ready to lose all your data and reinstall Debian from scratch.
Once loaded, Debian from Scratch includes a wide variety of tools, including fdisk, parted, development environments, full networking support, CD/DVD burning tools, print tools, and even the mutt mail reader.
As I described in the previous section on SUSE rescues, you should be able to mount your root (/) partition on a directory such as /mnt. Make sure to check that you're mounting the right partition; remember, you can list the current partitions on the first IDE drive with the fdisk -l /dev/hda command.
Once you've mounted appropriate directories, you can restore your original filesystem with the chroot command. If you've made a mistake, you can always return to the rescue filesystem with the exit command.
Now you can repair your bootloader or reset your root password as needed.
The Knoppix CD (http://www.knoppix.org) is gaining popularity as the universal rescue disk. It boots a complete Linux system from the CD with an array of excellent tools that you can use to rescue almost any PC. As you can see in Figure 6-3, Knoppix loads a complete Linux operating system from the CD.
Knoppix can even help you rescue Microsoft operating systems. As with any Linux distribution, it includes native support for FAT-style formats (FAT16, FAT32, VFAT). If you have an NTFS-formatted partition with Microsoft Windows, Knoppix can load the associated Microsoft NTFS drivers, which can make the associated partitions writable from this Linux system.
You can configure many PCs to boot from a USB device, including floppy, CD, and key drives. If USB boot options are not available in your BIOS, look for an upgrade. You may be pleasantly surprised.
If you can boot from a USB drive, there are several Linux distributions customized for USB keys. They include:
- Feather Linux
A fully featured embedded operating system based on Knoppix that takes up about 60 MB. You can download this distribution from http://featherlinux.berlios.de.
- Flonix
A complete Linux operating system (http://www.flonix.com), which is sold on a 256 MB key drive. While it is built with GPL components, it does not appear to be available for download. It's currently sold only within the European Union.
- Flash Puppy
Another complete Linux operating system, which boots completely into a RAM disk. For more information, see http://www.goosee.com/puppy/index.shtml.
If your system can't natively boot via USB, some distributions have 1.44 MB boot floppies that can help you boot from the USB drive. With the advent of 1 GB and larger USB keys, you can configure a complete bootable distribution such as Knoppix or SUSE Live CD on a USB key.
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 up—but it can also be a security risk.
Tip
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.
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.
Tip
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.
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.
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.
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
Tip
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@enterprise4aI 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.
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.
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.
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.
Security is a balancing act. For example, you can reduce the risks to your network by disconnecting it from the Internet. But that network would no longer be useful to most users.
As annoying as it may seem, physical security is sometimes appropriate and even required for servers. For example, it's a fairly common practice to limit access to servers in locked rooms. But what if others need access to this room? There are other things you can do to physically secure your server. Some of them have been noted as part of other annoyances in this chapter. I list them here for your convenience:
Consider a card-key system, which would track users in the server room.
Add passwords to your BIOS and bootloader.
Disable detection/access to USB drives in the BIOS (if possible). Linux can detect them after it boots.
Lock or remove any floppy, Zip, or CD/DVD drives on your server. With the availability of network installations, such hardware isn't absolutely necessary. (The exception is if you want to use the rescue modes described in "My Server Is So Secure I Can't Log In as Root," earlier in this chapter.)
Restrict physical access to network equipment. Open physical ports on a hub are like open doors in a bank vault. With a capable Trojan horse, a cracker could connect a laptop computer, collect data such as usernames and passwords, and have the data sent outside your network.
Limit access to wiring, especially network cables, and keep wiring and network equipment organized so it's easier to spot unauthorized equipment. Shield equipment from electromagnetic monitoring, if possible.
Secure any removable drives.
Disable or remove any telephone modems.
Consider removing the monitor and keyboard. As you're not using the server as a workstation, you can administer it remotely using a secure communications protocol such as SSH.
Consider a closed-circuit camera to monitor and identify unauthorized users.
Don't forget other aspects of physical security, such as windows, ducts, thin walls, etc.
If you're not allowed to take some of these steps, document what you can and cannot do, and write up a proposal on how you would increase security. It may get some attention if there's actually a break-in!