CloudBerry Lab Resources
Get started with cloud backup and management solutions

Linux Server Hardening: Best Practices

Published: by on Post Type:

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 needs 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 then 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. Over all of this, 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 hardening practices for your Linux system.

Linux Machine Level Hardening

Drive Encryption

Drive encryption will render any disk that is stolen totally 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 a number of 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 then 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, a number of different partitioning options are given, including custom partitioning. A safe rule of thumb would be to keep the following directories in seperate 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 a number of 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 setup 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.

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 totally 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.

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 a number of 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 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 terribly difficult. Time invested goingthrough steps like the ones laid out will return dividends in 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 issue resolvement. Don't wait another day verify that your system is secure!

Schuyler Traudt avatarAuthor
Schuyler Traudt
Schuyler is a husband, father, tech enthusiast, and freelance blogger living in Saratoga County, New York. Schuyler has spent the past 10 years (and counting!) honing his technical skills traveling the United States as a technical specialist for a software company out of Albany, NY View all posts
Published: by on Post Type:
Ratings:
1 Star2 Stars3 Stars4 Stars5 Stars (3 votes, average: 5.00 out of 5)
Loading...