MSP Business
Linux Server Hardening: Best Practices
There’s a common misconception out there today: Linux is safe - Windows is not. This simply isn’t true. While there may be more vulnerabilities and risks out there for Windows operating systems - our ways of looking at this need to change. Instead of looking at the chances of risk, a more binary approach needs to be taken.
Do vulnerabilities for Linux systems exist? Yes, they do. Therefore, we must do everything that we can to make our systems as safe as possible.
In computing, hardening is the term that we use for describing the securing of a system. This process generally doesn’t involve completely securing a system. Rather than locking the system down entirely, and therefore rendering it useless, the practice of server hardening addresses the best ways to minimize the points of vulnerability to the smallest number possible.
There are a few different ways to approach this process. At the machine level, drives can be encrypted and the BIOS can be secured. At a system level, login security can be considered and password policies can be enacted. At the network level, ports can be blocked and firewalls can be configured. Overall, alerting can be configured, logging can be set up, and audits can be performed.
The end goal of this process is balancing security with effectivity and accessibility. A completely open system may be the easiest to use - but is a security risk and may not be usable for long. A completely locked down system, while secure, offers no value if it can’t be accessed when called upon. Here’s a breakdown of the best practices for hardening Linux servers.
Linux Machine Level Hardening
Drive Encryption
Drive encryption will render any disk that is stolen useless by a would-be data thief. An encrypted drive is unreadable by anyone who doesn’t have the encryption password or key. Many Linux distributions offer drive encryption as part of the installation process. Distributions that don’t offer drive encryption can still be secured by using third-party encryption applications.
One popular encryption application is dm-crypt. This can be installed with the following commands:
- yum install cryptsetup-luks - package installation on Red Hat/Fedora systems
- apt-get install cryptsetup - package installation on Debian-based systems
Once installed, you can begin the encryption process with the following command:
cryptsetup -y -v luksFormat (partition)
There are several options to follow after beginning the encryption process, so be sure to read the man page and follow instructions closely.
BIOS Security
The most important part of BIOS security is the easiest and most obvious - a secured BIOS should require password authentication for access. Use a secure password that follows the same policy that the rest of your operating-system-level passwords use. Pick a password that is different than any of the other passwords that you use for your system.
In addition to securing the BIOS with a password, booting to any external devices should be disabled. This includes not only a CD/DVD, but a USB device as well. The threat of allowing an intruder to plug-in a USB stick and boot into the system fairly quickly is a vulnerability that is resolved by making this change.
Partitioning
When setting up a Linux system for the first time, many different partitioning options are given, including custom partitioning. A safe rule of thumb would be to keep the following directories in separate partitions:
- /
- /boot
- /usr
- /var
- /home
- /tmp
- /opt
Disk partitioning allows for the limitation of damage when file system errors occur. Generally, OS-level disk errors will not travel from one partition to the other, minimizing the damage done.
Further reading How to Resize Partition in Linux
Access levels can be separated by partition as well. The boot directory, for example, contains several important files that are related to the Linux kernel. This directory should be set to read-only so that the data on this partition can be accessed, but not changed unless the server is booted into single-user recovery mode.
To set the /boot directory to read-only, open the /etc/fstab file and add the following line at the bottom:
LABEL=/boot /boot ext2 defaults,ro 1 2
Linux System Level Hardening
System Updates
When a Linux system is built for the first time, a system update should be run so that all of the software packages are running the latest versions. Updates should be run using the native RPM package manager, such a yum for Red Hat Enterprise Linux systems and apt-get for Debian-based systems, such as Ubuntu.
After the initial updates have been run, the system should continually be kept up-to-date. Most distributions can be set up to automatically run updates, or notify system administrators via e-mail when system updates when available. Many of these updates address security vulnerabilities found by the Linux community, so keeping systems as up-to-date as possible is essential.
Further reading System Hardening Checklist
Root Login Security
Disabling, or limiting, root logins has multiple benefits. Forcing users to use the sudo command to execute administrative-level commands creates a level of auditing that doesn’t exist if multiple different users are logging in as root to perform the same tasks. Additionally, forcing users to have to use the sudo command to make major system changes causes them to think twice before acting, verifying the necessity of every system-level change.
The most secure process would be to disable all root access. This can be set up in a way that only allows root login in single-user mode recovery situations. If this isn’t suitable in a specific situation, remote logins as root should be disabled. All users accessing the system via FTP, SSH, or any other remote protocol should be forced to use their own username for login.
Password Policies
Behind every secure system is a strong user password policy. First of all, every user should be required to use a password. System administrators who are taking over an already established system can use the following command to verify that there aren’t any accounts set up with empty passwords:
awk -F: '($2 == "") {print}' /etc/shadow
Any passwords that have been found blank can be disabled with this command:
passwd -l (account-name)
Users should also be forced to use strong passwords. A general rule for a strong password would be one that is at least 8 characters long and has at least one letter, one number, and one special character. Password aging can be established to force users to change passwords after a specific amount of time. Finally, password history can be recorded and users can be forbidden from using the same passwords over again.
The poster pack includes:
- Best practices for creating strong passwords
- Reminders on how secure passwords should look like
- Chart to check if your password is secure enough
Linux Network Level Hardening
Port Security
Simply stated, network ports that aren’t being used shouldn’t be left open. Specifically vulnerable ports, such as port 23 for Telnet connections, should be closed on all systems. The ports that each Linux system needs open will depend on the use of the system.
To secure ports the remaining port that will be let open, a few practices can be used.
- Changes the default port. For example - instead of using port 22 for SSH access, use port 2222.
- Restrict port access to specific host IP addresses. This can be done at a few different levels.
- Disable remote logins by root.
Simply stated, network ports that aren’t being used shouldn’t be left open.
A good place to start with port security is to find out which ports your server is listening on. Use the following command to find a listing of the listening ports:
netstat -tulpn
With this information, you can determine which listening ports are needed, and which ones should be disabled.
Firewall Configurations
There are many different software firewalls that can be used to further secure Linux servers.
IPTables is a program that allows you to use the firewall provided by the Linux kernel. You can use IPTables to permit or deny traffic by source IP address and port. Incoming, outgoing, and forwarded packets can be filtered as needed.
SELinux is an access control firewall that is effective for traffic filtering as well. The three configuration modes of SELinux are:
- Enforcing - The default configuration for SELinux. In this mode, SELinux is online and will block traffic that isn’t specifically allowed in the configuration.
- Permissive - SELinux will allow all traffic through. Traffic will be monitored and logged. Notifications and warnings will be communicated.
- Disabled - SELinux is turned off. Traffic is not monitored at all, and nothing is logged.
The best policy is to leave SELinux set to enforcing mode at all times and to use permissive mode to troubleshoot any issues that may arise with your configurations. To check to see what mode SELinux is currently configured to, use the following command:
-
- sestatus
To set the SELinux mode to enforcing, use this command:
- setenforce enforcing
You can use the same command to change the mode to passive mode as well if needed.
Linux Alert Level Hardening
Audit Configuration
The most effective way to respond to threats when they happen is to be able to have a good understanding of what happening before, during, and after the threat occurred.
Auditing your Linux system can be set up using auditd. Auditd will write audit records to disk for review when needed. Two different utilities, ausearch and aureport can be used for viewing audit logs, and the auditctl utility can be used for audit configuration.
Log Configuration
Knowing where the logs that you need for troubleshooting are located will also help your investigation into security vulnerabilities. A majority of the log files on Linux systems are stored in the /var/log directory. Here are a few of the logs that can be referenced when looking into threats:
- /var/log/messages - a general log for Linux systems
- /var/log/auth.log - a log file that lists all authentication attempts (Debian-based systems)
- /var/log/secure - a log file that lists all authentication attempts (Red Hat and Fedora-based systems)
- /var/log/utmp - an access log that contains information regarding users that are currently logged into the system
- /var/log/wtmp - an access log that contains information for all users that have logged in and out of the system
- /var/log/kern.log - a log file containing messages from the kernel
- /var/log/boot.log - a log file that contains start-up messages and boot information
A good way to monitor log activity is to use third-party log monitoring software, such as LogWatch, for log analysis and notifications. Notifications and daily digests can be sent to administrators via email.
Conclusion
While securing your Linux system is important, it’s not difficult. Time invested going through steps like the ones laid out will return dividends in the future. The surface area of attack will shrink, threats that make it through your system will be minimized, and you will have the proper documentation to respond to intrusions and prevent them in the future.
Approaching system hardening with a four-level approach is an effective way to secure your system in multiple areas. Locking down the BIOS and separating partitions sets a secure foundation at the machine level. System-level hardening, including keeping your system updates current and enforcing strong passwords helps to prevent the newest threats on the web. Network-level hardening helps reduce your system’s points of failure, and alert level hardening helps us to stay informed.
It’s essential to do everything you can to keep your Linux system safe. Ignoring threats can have resounding consequences that will live on long past issues resolvement. Don't wait another day verify that your system is secure!
- Best practices in system setup and management
- Ways to properly secure your Linux system
- Guide to optimal file structure organization
