Securing Windows servers is a relatively simple task these days, compared with the effort it required just a few years ago. Microsoft has made notable progress in delivering Windows servers that are reasonably secure as long as you keep the system patched and use a firewall. However, many other companies haven't made the effort to deliver applications in secure default configurations or even offer documentation about how to secure that software. I often see third-party Web, FTP, mail, or messaging server applications that put otherwise secure environments at risk because of poor default configurations.
The most common mistake is that many third-party services run under the context of the built-in System account, although the services rarely need this elevated level of access. If the application were ever compromised, an attacker might use the full system access to wreak havoc. Other common problems are that applications install with lax NTFS permissions or don't make enough effort to protect sensitive data. For example, many third-party applications store their configuration data or even account passwords in the registry or local configuration file but don't adjust permissions to prevent regular users from reading these files. If the software doesn't use strong encryption or other methods to protect sensitive data, that data could end up in the wrong hands.
You might try asking the vendor whether it has any specific hardening recommendations for securing its products. Unfortunately, many companies don't offer such recommendations.We as administrators often must take it upon ourselves to secure these third-party service applications. Doing so is easier than you might think, if you follow the steps I outline.
Keep in mind that these steps won't work for every application, because you might be using the product in a manner that wasn't fully tested by the developer. Furthermore, the amount of tweaking required to get a particular application to work might not be reasonable. Nevertheless, many applications run fine with just a few modifications, and the resulting security benefits can make your work worthwhile. These benefits include a greatly reduced attack surface that significantly limits how an attacker might be able to exploit an application.
Installing the Software
The first step is to install the software as an administrator, using the default configuration. Installing the software as an administrator is important because many applications create configuration files or registry entries the first time they start—a process that's more easily accomplished with the elevated privileges of the System or Administrator account.
When you install the application, carefully consider where you place the application's files within the Program Files directory on your computer. Most applications will have a variety of file types associated with it, such as program executables, support libraries, Help content, configuration files, log files, and user data files. Some applications dump all these files in a single directory, whereas others let you customize the location of each file type. If your application lets you customize settings, take the time to consider the effect of file locations and place each file type in its own directory. For example, log files often contain sensitive information that might be useful to an attacker, so I prefer to put them all in a central location and use scripts to archive them to another system. Sometimes it's best to place user-accessible files (but not the application itself) on an isolated drive partition. Usually, I perform such isolation for publicly accessible servers (e.g., Web servers, FTP servers) that expose a portion of the file system in the application. This isolation prevents hackers from exploiting any future vulnerabilities that might let them access files outside the application's boundaries, such as being able to access system or other sensitive files.
I recently secured a third-party mail server for a client. I installed the software in the server's Program Files directory, but because the software provided Web mail access to mail files, I placed the mailbox files on a separate partition, which also made the files easier to manage. While configuring the program, I noticed that it gave me the option to specify the location of the log files, so I placed them in a central location with the client's other system log files, which makes it easier for my client to manage and archive the logs all in one place.
When you install a software application, you also need to consider which features you should install. If you don't have an immediate need for a particular feature, but you think you might require it in the future, avoid installing it now. You can always install it later when you actually need it. On a production server, you should also avoid installing unnecessary sample or documentation files.
Post-Installation Tasks
Immediately after installing an application, explore the files installed in its Program Files directory. Often, you'll see extra files that aren't necessary for the program's operation: readme files, .doc files, add-ons, installation logs, and temp files. Clutter is an enemy of security, so be sure to delete or relocate as many of these files as you can.
Finally, set application passwords. Many server applications require some kind of user or administrator logon. Often, these applications install accounts with default or blank passwords that can put a server at risk. Set a strong password. If the program lets you customize the username, avoid common and predictable names such as administrator, postmaster, root, and admin. Finally, be sure to remove all default user and demo accounts in the application.