Section 6.10. The Boss Told Me to Secure the Server Without Locking the Room

6.10. The Boss Told Me to Secure the Server Without Locking the Room

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!

Chapter 7. Kernel Itches and Other Configuration Annoyances

Even when you get a thoroughly tested and supposedly user -friendly distribution of Linux, things may not work the way you want out of the box. Superficial problems such as file shares that you can't access on other computers, or Microsoft partitions you want to read on your own computer, can usually be fixed with helper programs. But sometimes serious upgrades are required, which may include a new kernel module or even a new version of the kernel. A lot of this chapter, therefore, covers kernel configuration and compilation.

This chapter is rounded out with a couple of annoyances that don't fit into other chapters: allowing regular users to mount the CD, and configuring access to Microsoft-formatted VFAT and NTFS partitions.

7.1. The Kernel Needs an Upgrade

You don't need to change the kernel on your system often, but any Linux geek should be comfortable installing a new kernel without having to upgrade the entire distribution. The difficulty of the job depends on the reason you're upgrading. If a security flaw or other bug is found that merits an upgrade (which doesn't happen often), you may be able to simply download a package from your distributor with the new kernel. Support for new hardware may require the compilation of a new module, but usually not the entire kernel. The one major job you may run intorecompiling the whole kernelis usually necessary only when you want to add some major feature, such as a new networking protocol, and even that isn't so hard.

A new kernel may have unexpected effects on your system, and you may accidentally leave out a feature that was in the previous kernel, so make sure an upgrade is absolutely necessary before you go whole hog. Any time you upgrade a kernel, you're taking a risk. Kernel upgrades can change the way your operating system works with your hardware, services, and more. Be prepared to back off and return to the previous kernel until you have run the new one for quite some time and are sure it's robust.

When you upgrade the Linux kernel, you have several other decisions to make: how to add the new kernel to your system, selecting a source, and whether to patch the existing kernel. These options require you to consider a number of factors:

Upgrading from a package: Do you use the binary package provided by your distribution? If not, are you aware of the possible risks, such as changes in configuration defaults, incompatibilities with other software, or differences in default directories?
Selecting a source: Should you work from the source code provided by your distribution, or generic source code from kernel.org?
Patching the kernel: When should you patch the kernel? When should you avoid kernel patches?
Sharpen your tools: Do you have the tools you need to modify or recompile your kernel?

I explain each of these factors in detail in the following sections.

Kernel Numbering

The official version of the Linux kernel now has four numbers, such as 2.6.15.1. The first number is the kernel version, which is only revised with the most major changes to the kernel; the last revision (to 2.0) was in 1996. The second number is the major revision of the kernel; even numbers are associated with stable releases. The third number is the minor revision of the kernel; it is revised only to incorporate new drivers or features. The fourth number is revised for bug fixes or security patches.

When Linux kernels had three numbers, the third number incorporated new drivers, features, bug fixes, and security patches.

As of this writing, most Linux distributions use the old three-number system; however, they include additional characters associated with the way distributions customize the kernel. For example, a Fedora kernel might have a version such as 2.6.14-1.1688_FC5, and a Debian kernel might have a version such as 2.6.12-9-386. All distributions may include options that differ from the stock kernel available from http://www.kernel.org.

7.1.1. Upgrading from a Package

Red Hat, SUSE, and Debian all create binary kernel packages to incorporate security updates, add new features, address problems documented in bug reports , and more. When you install an updated binary kernel package, it automatically updates your active bootloader. You'll then have two kernels available, side by side, in your /boot directory.

Installing a new kernel is simple. For Red Hat and SUSE, use the -i or --install option associated with the rpm command:

rpm -i kernel-newversion

Alternatively, you can use the update tool associated with each distribution ( up2date , yum , YaST); when you select an updated kernel with those tools, by default they apply the install (and not the upgrade) option.

For Debian, connect to the network and use apt-get install to retrieve and install the new kernel:

apt-get install kernel-image-newversion

Debian is moving from kernel-image to linux-image as the name of their kernel packages.

Red Hat, SUSE, and Debian design their current binary kernel packages to add appropriate stanzas to GRUB or LILO bootloaders.

Use the install option instead of the upgrade option when you add binary kernel packages to your system. If you use the upgrade option, you'll overwrite your existing working kernel. In that case, you'll burn your bridges behind you. You'll be gambling that your system will work immediately with a new kernel, but that's very risky. There might be a hardware issue or other aspects of your particular system configuration that cause the kernel to fail. If your new kernel does not work, you may have to restore your system from backup. In contrast, if you save the old kernel by using the install option, you can simply choose the old one at the boot prompt and then try to fix the new kernel and recompile it.

7.1.2. Selecting a Source

There are a couple of situations when you can't depend on a binary package but have to download and compile source code.

The first situation is when the feature you need, such as the right modules for your hardware, is not available in your current kernel. You may need to download the modules as a part of another package. Especially if the package is available as a tarball, you may need to apply the instructions in any embedded script. Typical script names include Makefile and INSTALL , and may be detailed in a README file. One example of how this works is the "My Wireless Card Works on Another Operating System, but Not Linux" annoyance in Chapter 5.

The other situation is where the driver is already available as part of the kernel, either embedded in the kernel itself, or available as a module in the appropriate /lib/modules/` uname -r` directory. In that case, you'll need to download the source code for your kernel, use a menu to activate the appropriate features, and then recompile that kernel.

If at all possible, use the kernel source code developed specifically for your Linux distribution. While you may want to use the latest features available in the latest "stock" Linux kernel http://www.kernel.org, be careful. Each distribution compiles kernels with specific features that can interact and impact one other in subtle ways.

Several distributions work with special kernel sources. Some even include "backports" from more advanced kernels. So if you download a new version from http://www.kernel.org, you could lose the backports with other features that you need. It's therefore best to work with kernel sources provided for your distribution. For example, Red Hat Enterprise Linux 3 uses a specially configured Linux kernel that's nominally built from version 2.4.20, but includes backports from version 2.6. So if you install version 2.4.21 from http://www.kernel.org, you may actually lose features that you need.

Most distributions make the source code available in easily downloadable packages with names such as kernel-source . As we'll see shortly, though, Red Hat changed this convention starting with Fedora Core 3 and RHEL 4.

7.1.3. Patching the Kernel

If you download the original source code for a kernel from http://www.kernel.org, you can also use patches from that site. For example, if you've compiled and installed kernel version 2.6.15, you can upgrade to version 2.6.16 by downloading and installing patch-2.6.16 and compiling the combined source code.

At www.kernel.org, you can see patches labeled ac and mm . These are developmental patches released for general testing. The ac patches are released by Alan Cox; the mm patches are released by Andrew Morton. These patches include features not yet accepted by Linus Torvalds for the stable kernel.

If you choose to patch a kernel, the process may be more complex than you expect. Patches are applied to the kernel source code. Installing the patch is not enough. You still have to compile the combined source code into a new kernel.

Patches incorporate improvements between minor kernel revisions. In this section, I'll offer directions that work with most generic patches from http://www.kernel.org as well as patches provided by most distributions. However, the directories are different for Fedora Core 3 or later (we'll discuss this in the next annoyance). In general, here's what you do:

Install the source code for the current kernel (in this case, for version 2.6.15) in the /usr/src/linux-2.6.15 directory.
Download the desired patch (in this case, patch-2.6.16.gz or patch-2.6.16.bz2 ); make sure the patch is in the /usr/src directory.
Unpack the desired patch with the appropriate command ( gunzip or bunzip2 ).
Navigate to the current kernel source directoryin this case, /usr/src/linux-2.6.15 .
Apply the desired patch, using in this case the command:
```
patch -p1 < ../patch-2.6.16
```
Minor problems can arise when you try to apply a patch. Watch the output carefully for error messages. You may be able to diagnose a problem such as a compiler that is too old or a patch on a wrong directory.

It may help to back up a kernel when you apply a patch, by adding the --backup option:
```
patch --backup -p1 < ../patch-2.6.16
```
You can also create a log of error messages; the following command saves errors in the patch.log file:
```
patch --backup -p1 < ../patch-2.6.16> patch.log 2>&1
```

Some of you may know more efficient ways to run these commands, such as combining them on one line with pipes, and so forth. However, I think it's important to break out commands on something as important as kernel patches in detail.

{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}

Now you're almost ready to configure and recompile your new kernel. However, you need to make sure your tools are suitable for the software you're compiling.

Because Fedora Core 3 is the development platform for Red Hat Enterprise Linux 4, new features that you see for Fedora Core 3 normally also apply to Red Hat Enterprise Linux 4. This includes new conventions for kernel sources discussed in this chapter. Fedora Core 5 is reportedly the development platform for Red Hat Enterprise Linux.

7.1.4. Sharpen Your Tools

If you need to recompile your kernel, the source code is not enough. You also need the right tools. First, there are the tools that do the actual work, such as the GNU C Compiler. They vary by distribution and by major kernel version (2.4 and 2.6). More information is available in the Changes file, in the Documentation subdirectory of your kernel source directory.

Linux kernel 2.4 is still in common use on the Red Hat Enterprise Linux 3 series of distributions. Although that may seem dated, Red Hat has included appropriate "backports" of various kernel 2.6 features, and they have committed to support their customized kernel through the year 2008.

Then there are the packages that allow you to customize the kernel using graphical menus . Generally, these include the ncurses- devel library in the libncurses5-dev package for the lower-end menuconfig , and the TCL and TK libraries for the higher-end xconfig and kconfig menus. We'll look at these menus briefly in the next annoyance.

The ncurses-devel library is a good choice for a system that isn't running the X Window System, which is the case with many servers. Alternatively, there are three different menu configuration systems that take advantage of the X Window System GUI. If you use the GNOME desktop, find and install the GTK+ 2.0, Glib 2.0, or libglade 2.0 development libraries. The actual packages and their names vary by distribution. Alternatively, if you use the KDE desktop, download the QuickTime development libraries.