Lock Down Strategies for Linux Servers
Most of the security defenses on Linux, are based on the earlier performed hardening activities. By locking down components on the system, the chance of a full compromise is lowered. This step-by-step locking down is a time consuming process. Time to review some of the strategies which can be applied when you want to secure your systems.
Strategy 1: Locking down processes
The first area to lock down are system processes. After all, each system needs processes, to fulfill its roles. It is common to see systems are running too much processes. Not in the sense of numbers, but mainly the required processes including non-functional processes. These last group of processes have a clear goal, but are not applicable for the machine. It might be a NFS daemon which is simply not used. Another example might be a power saving utility, while the system is virtualized, and a better power management tool is used on the host system.
When to use
Processes can be locked down in different way. From memory management, disk and file permissions, up to the resources. This strategy is in particular useful for systems which allow its user to start their own processes. Another type of system which benefit is systems being part of a web cluster, or act as individual web servers.
Execution: processes
To execute this strategy, follow at least the next steps:
- Determine which processes run as root
- Check which users can start processes on the system, directly or indirectly
- Determine an appropriate security framework like SELinux or AppArmor
- Determine allowed directories/files, limit access as much as possible
- Limit file descriptors, memory and other system resources which can be quickly exhausted
Locking down networking
For most information nowadays, it enters and leaves the system via the network. Therefore this is another area which needs locking down. The most obvious measure is traffic filtering, which can be achieved with iptables tooling. For newer systems, this might be replaced with nftables. Both are possible with the kernel feature named Netfilter.
When to use
This strategy is useful for most systems, especially those directly or indirectly being available via the internet. The strong area in this strategy is the focus on allowed paths, while (by default) blocking all others. Traffic you don’t want, should not be able to enter or leave the system.
Execution: networking
- Configure a firewall
- Disable interface not used or allowed (e.g. WiFi)
- Limit ARP, DNS and routing to allowed paths only
- Configure logging for possible intrusion detection or forensics
While an initial set-up might take a while to analyze, configure and tune, it can be reapplied on other systems with similar functionality. Since this strategy is useful for almost all systems, it is well invested time.
Locking down users
Users and processes are often considered “subjects” on a system. They are active entities, who want to use “objects”, like a file. While not every system has users directly on the system, it often has indirect users. This may be an anonymous user visiting the website, or an authorized user which submits a print job.
When to use
This strategy is especially important for systems with local user accounts. Without proper measures, they might be able to start programs, or access data, they are not supposed to. For other systems basic measures should be taken.
Execution: users
- Determine allowed users
- Set default permissions
- Limit access on directories and files with sensitive data
- Properly implement authentication, authorization and accounting measures. Usage of PAM, Linux audit framework and logging.
Locking down the kernel
The inner part of the system, the kernel, is responsible for resource management. It will check the available resources and determine what a subject can do to an object. In other words, is a user allowed to access file X, or can a network packet be accepted for a later delivery at a service.
When to use
This strategy is useful for almost all systems. It does however require a more defined subset of measures. For example the usage of the earlier mentioned SELinux or AppArmor. Not all systems require this, yet it can be a very powerful mechanism to restrict access to authorized requests.
Execution: kernel
- Determine if SELinux or AppArmor can be used
- Check what kernel settings should be altered, to prevent resource exhaustion
- Determine the importance of file integrity and what measures should be taken
- Examine the need for auditing resources with Linux audit framework
Locking down software
Every system has software installed. Unfortunately systems are often not properly patched, or installed with the default settings. The result is a system with vulnerable software and another possible hole in which data can be leaked to unauthorized people.
When to use
This strategy in particular should always be properly investigated. The only exception might be fully isolated systems, with a dedicated and standalone goal. Even then, the risks should be well-known and proper measures taken. For the other 99.9% of systems, a proper patch management process and configuration hardening should be performed.
Execution: software
- Regular software patching
- Checking for vulnerabilities
- Perform audits on configurations to determine weaknesses
Conclusion
Every system is different. When you want to lock down a Linux system, ensure that the primary role of the system is known. Then select the right measures to go along this role. In the end security is about maximizing availability, integrity and confidentiality. While some performance hits might be expected, the system should always be focused on fulfilling its role.
