What exactly do we mean by host hardening? It has several meanings in the field of computer security, such as limiting network access to a system by the traditional method of turning off unnecessary network services, by firewalling, or by enforcing authentication to use a service. Almost everyone who has installed recent versions of Microsoft Windows has been exposed to a rudimentary firewall system. An easy-to-use firewall is also built into Mac OS X. Modern versions of Linux contain powerful firewall capabilities. You can read more about firewalls in Chapter 13.
Host hardening can also mean that existing services are available only to certain users at certain times. This can mean that a user will operate under a lower privilege and be granted higher-level privileges as the need arises. Most Unix users are familiar with the command su, and you might at least know about the sudo program. On Windows, you have the option to run the system as an unprivileged user and only run processes as an Administrator using the Run As... service. (Most people don't, and choose to log into their systems as an Administrator.)
You can also harden a system by testing common weak points and make security changes accordingly. For example, you can check that all your users have strong passwords, ones that are difficult to guess or stumble upon. You can run automatic update software to ensure that the system has incorporated security updates from your vendor, or trusted third parties. You can audit the system's configuration settings and enable or disable the internal subsystems you need to secure the machine.
Host hardening can also mean limiting potential damage if something does go wrong. On Unix-like systems, this could mean that you disallow executing files (or scripts, or applications) in public directories such as /tmp. Going deeper, another hardening technique involves making changes to the system kernel to prevent executing memory flagged as non-executable. Or you can limit damage by separating or sandboxing a process or network service via chroot. Taken to somewhat of an extreme, you can even separate a service from the system it runs on using an entire virtual machine.
Since the topic is so varied, we're going to look at host hardening as:
Controlling listening services and ports (maybe using a firewall)
Turning off things that do not need to run
Using some kind of access control
Limiting the damage a vulnerable program can cause
Shutting down services should be straightforward, but unfortunately, it seems that almost every program you install wants to be activated on system startup or user login—your chat client, your music player, your browser, everything wants to feel like it's important.
On a Windows machine, there are probably a dozen ways to start an application at system startup or user login. Autoruns from the Sysinternals suite is the best tool I've encountered for ferreting out what your system is going to automatically load. If you are running Windows, you should download Autoruns (see Figure 14-1) immediately from Microsoft (http://www.microsoft.com/technet/sysinternals/utilities/autoruns.mspx).
On a Unix-like system, the situation is slightly more complicated. Almost all of the programs that automatically load are started through the system init and the inetd daemons. Some Linux distributions, such as Red Hat Linux and Ubuntu, have excellent GUI utilities that show you what the system will load, but others, such as Slackware, are configurable only at the command line. In any event, you should also check if anything odd is being started via the cron or at daemons as well. You'll have to check with the documentation that came with your particular distribution on where your various daemons place their files. If you don't know for certain, you can start your hunt in /var using the find command:
find /var -iname "*cron*"
The toughest part in controlling your service daemons is deciding what you need to run the system, and what you can turn off. If you are not altogether familiar with your system, the tendency is to leave everything as it is out of fear that you may turn off something necessary for the system to start. In actuality, most *nix systems need very little to start up and run. Too many distributions start up all kinds of X11 stuff (the font server, an event daemon, the X display manager, etc.) or unnecessary print services and so forth. If this is a server, accessed remotely, turn them off. Does the system really need a mail server or do you need only the ability to relay mail to another SMTP server? The obvious advice is "run only what you need."
Here's the list of services that I run on my laptop when it boots:
sshdsyslognullmailer(for SMTP relay)cronudevd