Every server process you run on your system provides another potential point of compromise. That's why it's so often recommended that you turn off unnecessary services on Windows machines and deactivate unneeded daemons on UNIX operating systems.
You can't simply turn off all services and daemons, however, as the ability to use your operating system environment would be severely crippled if you did. As a result, it becomes necessary to attempt to secure the operation of the server processes you need.
When you provide a server system on which multiple clients rely, that can become even more important. Every one of the systems that connects to your server relies on its security -- in effect, trusts it, to some extent.
If your server is compromised, it may then become a vector for attacks on clients that connect to it. When you run a server system, you become responsible not only for the security of that system, but at least in part for the security of every computer that connects to it.
An example of such a case is a UNIX or Linux DNS server. Just like any other server software, the BIND server daemon named process may occasionally be subject to security vulnerabilities that may allow a malicious security cracker to gain unauthorized access to your system. It is thus important to configure your system to minimize the damage a security cracker can do when he or she exploits such a vulnerability.
One way to do so with the named process on UNIX and Linux systems is to ensure that it doesn't run as the root user. If the process runs as a less privileged user account, the damage it can do when compromised by a malicious security cracker is greatly reduced.
To do so, the first thing you need to do is ensure that there's a named user and group -- create one of each if you must. Next, make sure all files and directories necessary to the ongoing operation of the named are set to user and group ownership of named. Finally, ensure that when the named process is started, it sets its user and group permissions to named after it's done with the initial startup operations that require root permissions, using the -u and -g options.
Depending on the specific UNIX-like system you're using -- such as Solaris, FreeBSD, Red Hat Enterprise Linux, Debian GNU/Linux, or AIX -- the specifics can vary, so giving precise examples is difficult. In general, the steps should look something like the following.
First, change ownership of the /var/named directory (you may have to create it first):
# chown -R named:named /var/named
Next, make sure the directory option in the named.conf file places all necessary files in the /var/named directory, or that it is otherwise available to the named process running under the named user account. Some files that may be relevant include:
The dump-file file is an example of a file that can be placed in the /var/named directory, and the named-xfer file is an example of one that may not need to be placed there, as it may very well be world-executable with 755 permissions (do not set it to 777). Finally, pid-file may be an example of a file that should be relocated to the /var/named directory. Upon doing so, your named.conf file may contain these lines:
Running the named process "manually" with the user and group accounts explicitly set to named would look like this:
# named -u named -g named
Ensure that the startup scripts for your system that initiate the named process do so using the -u and -g options. Even this does not quite go as far as you could to lock down your named process. For instance, the named process could be run inside a chroot jail, stateful firewall rules can be used to protect the server against certain types of DNS-directed attacks, and DNSSEC (a DNS security protocol) can be implemented for additional protection.
The above is in no way intended to be a comprehensive set of instructions for setting up a secure DNS server, of course. It lacks many specifics that would need to be researched independently by someone who wishes to secure a DNS server. The point of this description of limiting named permissions is two-fold:
- Give an experienced system administrator who normally runs the BIND server in its default configuration an idea of how to increase the security of the system.
- Give everyone else some idea of the sort of thinking that's necessary to improve the security profile of any system running a server process -- which is, in effect, everyone who uses an Internet-connected computer.
A specific, step-by-step set of instructions for achieving these ends on a specific UNIX-like operating system such as Fedora Core 4 or FreeBSD 6.2-RELEASE would in fact be considerably shorter and more directly applicable for those using that system in particular. On the other hand, the information provided would probably be out of date almost the day it was written, and it would not make the central point I wanted to convey.
More than anything else, the lesson you should take from this is about how you should think of security in relation to how you configure your system -- and the fact that simply relying on the software itself is often insufficient.