Hack 25 Protect the Boot Process
|
Thwart unauthorized physical access to a system. Creating a snazzy boot environment for users is one thing. However, when it comes to booting up servers, your mind automatically shifts gears to security mode. Your goal is to ensure that only a very precious few on very rare occasions ever see the boot process on a server. After all, the golden rule in security land is "physical access equals complete access." Here's a prime example consider recovering from an unknown or forgotten root password. Go into the server closet, reboot that system, and press a key to interrupt the boot process to change the password. A few moments later, the system continues to boot as normal. This can be a real lifesaver if an admin leaves without divulging the root password. However, consider the security implications of an unauthorized user gaining physical access to that server: instant root access! 3.3.1 Limiting Unauthorized RebootsLet's start by ensuring that regular users can't reboot the system either inadvertently or maliciously. By default, if a user presses Ctrl-Alt-Delete, the system will clean up and reboot. Typically this isn't an issue for servers, as most administration is done remotely and the server is safely locked away in a server closet. However, it can wreak havoc on workstations, especially if the user is used to working in a Windows environment and has become accustomed to pressing Ctrl-Alt-Delete. It's also worthwhile disabling on a server, as it ensures that a person has to first become the superuser in order to issue the reboot command.
Disabling this feature requires a kernel rebuild. (See [Hack #54] for detailed instructions.) Add one of these lines to your kernel configuration file, then rebuild and reinstall the kernel: options SC_DISABLE_REBOOT # if using syscons console driver # or options PCVT_CTRL_ALT_DEL # if using pcvt console driver You're probably thinking, "If I wanted to reboot a system and didn't know the superuser password, I'd simply hit the power button." Yup! That kernel option certainly won't prevent that, but a carefully thought out CMOS[1] configuration will decide if and how that system will reboot.
At a minimum, the CMOS configuration should allow only one boot device. This is to prevent an intruder from trying to boot an alternate kernel from a floppy, CD-ROM drive, or other supported boot device. Additionally, you should set a password for CMOS and record it in a safe place. This will prevent an intruder from simply changing the CMOS configuration. Keep in mind that this is not fail-proof; you are merely adding layers of inconvenience. A determined intruder can simply pop open the case and drain the CMOS battery, but that takes time and additional effort. 3.3.2 Password Protecting Single-User ModeAll the magic happens when you interrupt the boot process. This is where you can change the superuser password without having to first know the superuser password. This is where you can unload the currently loaded kernel and replace it with another. This is where you can change any configuration file or binary without worrying about securelevels or system flags [Hack #56] . This is the reason why you lock up your servers, monitor access to the server room, and run them headless [Hack #26] . Fortunately, interrupting the boot process requires keyboard input, meaning the user needs physical access to the system. What happens when a malicious user does bypass your physical security measures, gaining physical access to the system? All she has to do is interrupt that boot process, and the system is hers to do as she wishes. On a system without the graphical boot menu [Hack #24], pressing any key at the timer will pause the boot process. If the system has the graphical boot menu, pressing 6 to Escape to loader prompt will show the same timer. The timer option looks like this: Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 10 seconds... If you press any key other than Enter, you'll receive this: Type '?' for a list of commands, 'help' for more detailed help. OK boot -s Type boot -s to enter single-user mode. The kernel will appear to load normally, but, instead of processing the rc scripts, this prompt will appear: Enter full pathname of shell or RETURN for /bin/sh: # Once you've finished making your desired changes, simply type exit. The system will continue to boot into multiuser mode. Now, how do you prevent a user from doing that? Password protect single-user mode by editing /etc/ttys. Find this line: # If console is marked "insecure", then init will ask for the root password # when going to single-user mode. console none unknown off secure Follow the comments and change the word secure to insecure. While that may seem nonintuitive, you're saying the system is considered to be insecure, thus you want a password. The next time a user attempts single-user mode, the kernel will load, but the user will receive this prompt instead: Enter root password, or ^D to go multi-user Password:
3.3.3 Password Protecting loaderLet's return to the timer section of the boot process. A user can type more than boot -s after interrupting the boot process. In fact, if you press ? at that OK prompt, you'll see that you can unload the current kernel, load another kernel, load and unload kernel modules, and view and change variables. You can muck about with just about every part of the boot process that would normally be controlled by the loader command. Fortunately, you can also require a user to input a password before receiving that OK prompt. Set the password by adding this line to /boot/loader.conf: password=12345 Of course, your password should be harder to guess than 12345. Now the boot process will prompt the user for a password. Without that password, you cannot enter single-user mode or load or unload kernel modules. You can still boot; you just cannot interrupt the boot process. Also, if your CMOS supports it, you can require a password to boot the machine. However, this is often considered to be a bad thing, especially on a co-located web or mail server.
3.3.4 See Also
|
