If you’ve ever looked at Linux server management companies, you often find a laundry list of “security” items that they apply to your servers. Many of these items are nothing more than standard practices while others are simply popular items gleamed from forums. Many of these “tweaks” have no real testing behind them; they are often applied with no real information as to why they are done.

Over the next few weeks, I will discuss some of these server hardening practices and try to determine which ones provide real benefit. This way, when you look at long list of server hardening items, you will know what is valuable or not.

As I noted before, the number of security updates typically declines as a OS matures. Keeping your system standardize by not tweaking things unnecessarily improves long term server stability and security by making ongoing management more coherent.

Host.conf Hardening
A quick check revealed more than a dozen companies listing “host.conf hardening” as part of their security package. Let’s review what’s actually being done, and then discuss if there is any value in doing this.

We will be using a standard CentOS5/RHEL 5 system for this comparison. For the “hardened” versions, I am using ones that I commonly see in various how-to’s and forums.
Before Host.conf Hardening
The host.conf file resides in /etc/host.conf. This is it before hardening:

order hosts,bind

After Host.conf Hardening

order bind,hosts
multi on
nospoof on

What’s Being Done?
A quick look at the man page for the host.conf file gives you a good idea of what this does: “The file /etc/host.conf contains configuration information specific to the resolver library.” In other words, this file controls, in part, how your system looks up DNS information.

The order directive tells the system in what order it should lookup information. By default, the system first checks the host file and then uses DNS information. In the hardened version, the system first checks DNS and then uses the hosts file.

The ‘multi on” directive simply allows the resolver, the system that translates hostnames into IP addresses, to return multiple listings if they are found in the hosts file.

The “nospoof on” setting will compare the IP address returned by a hostname lookup to the hostname returned by an IP address lookup. If the forward and reverse lookups do not match, then a spoof warning is generated.

Analysis
The Center for Internet Security (CIS) publishes a 130 page plus document on best security practices for Red Hat Enterprise Linux. Not once in these pages does it mention hardening host.conf.

One of the touted benefits of this tweak is to “Prevent IP Spoofing.” This tweak does nothing to prevent IP spoofing. What is does do is provide additional checks when using weak authentication mechanisms based on the host name or address of the remote computer. These “r-commands” should not be used anyway. With SSH widely available, rlogin, rsh, rcp commands should not be used.

Another benefit I’ve seen discussed says that it prevents someone from editing your hosts file and redirecting DNS. If someone can edit your hosts file, they have root, and they can do what they want anyway.

Conclusion
Host.conf hardening provides little value to the average server deployment used by SMB’s and web hosting firms. As such, you can pretty much scratch it off the list of items in the “server hardening” laundry list.

Some may say host.conf hardening does not hurt, so why not do it. I disagree. If the stock settings provide sufficient security for your needs, then do not change them. Keeping a system free of unneeded “tweaks” has inherit value to long term management.

Menu