Chapter 12. Server Security

Servers are the last layer of defense against attackers . If an attacker does manage to bypass the security restrictions in place on the routers and firewalls, the servers have to be hardened enough to keep the attacker from gaining unauthorized access to information on the network.

The server security problem is complicated by the fact that some servers are, by nature, public servers, so everyone ”even people outside the organization ” has to be allowed access. Even if all the servers on your network are private, security measures still need to be put in place to prevent unauthorized users from gaining access. This includes access from unauthorized employees .

A server is any machine to which multiple network users must connect in order to perform their jobs. Generally these machines have more memory, storage capacity, and faster processors (or multiple processors) than end user machines, also called workstations. Servers usually run different operating systems than workstations, though not always. Microsoft, for example, has created Windows 2000 Professional and Windows XP Professional for workstations and Windows 2000 Server, Windows 2000 Advanced Server, and Windows 2000 Datacenter Server for servers. In a similar manner Red Hat Linux 8.0 Professional is designed for workstations, while Red Hat Linux Advanced Server is designed for servers. On the other hand, Sun Solaris and FreeBSD use the same operating system for both servers and workstations.

That is not to say that all these server operating systems should be in use on the network, simultaneously . Running several different operating systems within the network can actually be detrimental to network security. Chances are the company's server administrative staff has a core expertise with one or two operating systems. If a third or fourth server operating system is added to the network ”for whatever reason ”there may not be enough staff members who have the knowledge to secure it properly.

For this reason, many security experts recommend using no more than two server operating systems on a network. There are, of course, exceptions to this guideline. If an organization has separate administrative staff for different servers, then the staff will presumably have expertise in the server operating system. For example, if the administrators for the web farm have experience with FreeBSD then running FreeBSD poses no security problems, even if it is not in use anywhere else in the network. This guideline applies primarily to organizations where server management is centralized in one group .

There is a lot of debate about operating system security within organizations, and over the Internet. ^[1] The truth is that all server operating systems can be properly secured when managed by an administrator who understands the operating system and how to secure it. No server operating system is inherently more secure than any other, but some are more secure out of the box, making the security process easier.

^[1] Debate is the nice way of saying "flame war."

If an administrator does not know what he or she is doing, it is very easy to weaken the security of a server, especially a public server. That's why it is so important to ensure that all members of the server administration staff within an organization are properly trained on good server operating system security procedures. These procedures should be operating system specific, and organization specific. General guidelines, such as those present in this book, are a good start for forming internal best practices for server security, but each organization has specific needs, and the internal documents should reflect them.

Remember, too, open source does not automatically equate to less secure. There is a lot of misinformation about the security of open-source projects, but it basically boils down to same mantra: Because everyone has access to the source code, anyone can find security holes and exploit them.

The people who point this out usually forget to mention the opposite : Because everyone has access to the source code, anyone can find security holes and fix them. The vast majority of developers fall into the latter category. Open-source projects like Apache, Sendmail, BIND, and Linux have been tested , reviewed, picked over, and beaten on by so many developers that they are both stable and secure. Do security holes still arise? Absolutely, but those holes are quickly patched and the code updated. More importantly, long-standing open-source projects, like the ones mentioned, do not report security incidents more frequently than their closed-source counterparts.

This is not to suggest that an enterprise network should dump all closed-source products in favor of open-source solutions. There are open-source products that have abysmal security records. Instead, organizations should not be afraid to evaluate open-source products alongside closed-source products for use in the network. If an open-source product can meet the security requirements of an organization there is no reason not to use it. If the product cannot meet the security requirements, let the developers know about the problems experienced , and maybe the next time an evaluation is performed, it will be able to meet the requirements.

The first section of this chapter covers general guidelines for server security, including some operating-system-specific guidelines. The other sections focus on different types of servers. Web, mail, file, and other servers are all discussed in general and specific terms.