|
Specific advice on hardening a server depends to some extent on its intended role. A Web server connected to the Internet requires different treatment than, say, a storage area network server isolated from the LAN in a closed, physically secure environment. There are, though, hardening practices that are common to any type of server, of course.
A couple useful resources to help you through the process of hardening a Unix-based Web server are the Unix Security Checklist and Unix Security Technical Implementation Guide, which includes a section specifically on Linux.
I would also recommend that you evaluate your configuration using the free benchmark and scoring tools from the Center for Internet Security (CIS). These tools provide a quick and easy way to evaluate your system and compare its level of security against the CIS minimum due care security benchmarks. These benchmarks are unique, not because the settings and actions are unknown, but because consensus among hundreds of security professionals worldwide has defined these particular configurations. Various reports guide you in how to harden both new and active systems to ensure that security settings conform to the configuration specified in the benchmark. The configurations are kept up to date as new vulnerabilities are discovered.
The CIS Level-I benchmarks set a prudent level of minimum due care, and can be applied with little security knowledge, as they are unlikely to cause an interruption of service to the operating system or the applications that run on it. The CIS Level-II benchmarks go beyond the minimum level and are aimed at system administrators who have sufficient security knowledge to apply them with consideration for the operating systems and applications running in their particular environments.
Other good guides include the Guide to General Server Security and Guidelines on Securing Public Web Servers, which cover the recommendations of the National Institute of Standards and Technology (NIST).
If this is the first time you've had to manage Linux servers, and if they are running mission-critical applications, then I would consider bringing in expert help, at least to get started. Securing a server requires knowing what each service does and what happens when it's disabled or changed from its default settings. Only then is it possible to recognize and appreciate how different settings affect the operation of the server and how they affect its overall security. Working with someone who has the necessary OS experience will give you the knowledge and confidence to make decisions on what needs to be locked down to achieve an appropriate security level.
Your initial hardening and configuration will be based on the known vulnerabilities and best practices at the time of setup. You will, of course, need to reassess your servers on a continuous basis to ensure their security adapts and evolves to keep up with changes in technology and attack vectors. To make sure this happens, you need a lifecycle-management process to ensure tasks are executed in an orderly and predictable manner, and that none are forgotten or left uncompleted. Patch management will, of course, play a key part in keeping your servers secure.
You should also develop and maintain your own list of information sources about security problems and software updates relevant to your system and application software, and more importantly, establish a procedure for monitoring these information suppliers. The Debian Wiki, for example, shows several compile-time options that can be used to help harden a resulting binary against memory-corruption attacks, or provide additional warning messages during compiles.
|
