How to Harden Unix/Linux Systems & Close Security Gaps

Ron Woerner, CISSP, CISM, ECSA, and Information Security Trusted Advisor
August 28th, 2018

Linux is all around us, whether we realize it or not. The majority of Internet services run on some form of it. Linux/Unix operating systems are lightweight, powerful, and designed to be highly secure. Of course, highly secure does not mean completely secure—not even close. Often, breaches are caused by simple misconfigurations or other errors, which introduce dangerous avenues for breaches, infiltration, or lost data.

This blog will walk you through many of the important basics of Linux security that are easy to address. For more details, please attend my BeyondTrust webinar, Expert Tips and Techniques for Closing Unix/Linux Security Gaps. In the webinar, once the basics are out of the way, we’ll kick-it-up a notch to help you bring your Linux/Unix systems administration and security program to the next level. Foremost, this discussion is exploring how to automate the steps listed below to ensure a consistent security approach. This includes properly configured identity, access, authentication, authorization, and auditing (IAAAA) with Linux systems.

A Linux security checklist provides step-by-step procedures for ensuring you’re not missing anything when setting a baseline. These recommendations aim to balance security decisions with functionality/usability. They’re listed in order of precedence based on criticality, risk, or ease of implementation. While there are many distributions (aka distros) or “flavors” of Linux, the steps are similar for any version, although the exact command or procedure may be slightly different. Check your documentation for exact commands and procedures. I’ll provide references where you can learn more expert tips &and techniques for closing Linux security gaps.

There is no 100% correct checklist. Your “mileage may vary” in using this. Please do your due diligence and confirm and test each step prior to implementing in a production environment. 

Steps for Closing Unix/Linux Security Gaps

1) Inventory Unix/Linux Assets – Inventory is the first step in both the NIST Cyber Security Framework (CSF) and the Center for Internet Security (CIS) Controls v7. The following information should be captured:

  • Machine Name
  • Function / Purpose Description
  • IP Address(s)
  • MAC Address(s)
  • Responsible parties (system owner)

Note: Answer Who, What, Where, and Why

2) Linux Commands – Get comfortable with the Linux Command line and editors. Most commands for securing the system are run from a Linux command prompt rather than a GUI. If you’re learning Linux, find a good Linux Command Cheat Sheet. This article lists some for free. The “man” command is your friend. Use it to learn the exact syntax of other commands (e.g., man man).

Notes:

  • Linux commands used in this tutorial will be in courier new
  • Many Linux hardening commands require root privileges. You will need to use sudo or su.

3) Secure the BIOS / Hard Drive – When initially installing the Linux system, you should take the following steps to protect the underlying hardware and systems drives.

a) Protect the BIOS of the host with a boot-loader password. This reduces risks to the underlying infrastructure from accidental or malicious changes. Secure the password in a safe location (password vault).

b) Also before OS installation, encrypt the hard disk. You can use an LVM or Logical Volume Manager.

c) Partition the system disk(s). Separate system file directories such as / (root), /boot, /usr, /opt, /var, /home, and /tmp into their own partition. This is another step for both performance and security.

d) If USB drives won’t be used, disable the port. This makes your server unable to recognize anything plugged into its USB ports which makes it harder to breach if an attacker gains physical access.

4) System Updates Updating the operating system is a fundamental security step. It’s often the quickest and easiest way to reduce vulnerabilities and the system’s threat surface. For package installation, use one of the commands based on your Linux distribution (e.g., apt-get, yum, rpm, zypper). For more information, I recommend TecMint’s 5 Best Linux Package Managers. Once you update, don’t forget to reboot your system.

The second part of this step is to remove any unnecessary software packages that aren’t used. Linux servers are often single-purpose systems. Having additional software weighs them down and presents a potential security liability. This keeps your threat footprint as small as possible.

5) Install Mandatory Access Control (MAC) on the kernel. To protect the host system from being compromised, both SELinux and AppArmor provide tools to isolate applications from interacting or interfering with each other. Each also allows more control over access control. AppArmor is easier to install and configure, so consider using that if you’re able. Note: you cannot have both installed or running at the same time.

After installation, use Linode’s Getting Started with SELinux Guide to learn the basics of SELinux security or refer to the web links above.

6) Secure boot-up – This step includes both locking the boot directory and disabling or removing any services from automatically starting that aren’t needed.

Lock the boot directory – The Linux boot directory contains critical files related to the kernel, so you need to make sure that this directory is set to read-only permissions. This prevents accidental or malicious changes.

Check services started on initial boot – This works with step 4, where you remove unnecessary software. You also need to make sure no processes are started on system boot that you don’t want for both security and system efficiency. sysv-rc-conf gives an easy to use interface for managing startup files found in /etc/rc{runlevel}.d/.

7) Secure network connections – The Linux system-level firewall provides extra network protection. This is done either using Linux’s Uncomplicated Firewall (ufw) command or iptables. UFW is an interface for iptables that offers an easier way to regulate incoming and outgoing traffic. You enable it with the ufw enable Depending on what you want to allow through (e.g. the purpose of the server), you can selectively allow ports, ranges of ports, or anything else. A firewall won’t stop everything, especially if something is allowed because of a configuration setting. Consider disabling IP forwarding, the Send Packet Redirects, and ICMP Redirect Acceptance and enabling Bad Error Message Protection within /etc/sysctl.conf.

8) Secure Access and Authentication – This step reduces the threat vectors associated with user-level access on the Linux system.

a) The first part is to review all users established by default and disable or remove any that are not needed for the functionality of the system. Any users you need must have a password.

b) The second step is to configure authentication settings. If you install SELinux or AppArmour, this is included with those packages. If not, you’ll need to modify the Pluggable Authentication Modules (PAM) configuration files found in /etc/pam.d. You can also link PAM with a centralized LDAP service. The PAM module is used to set the security policies of the Linux host. To set password policies, open the /etc/pam.d/common-password and /etc/pam.d/system-auth files and change settings to match the policy for your organization.

c) root users are considered “god-like” on the system, therefore you need to limit that access. Set a secure root password and lock it away to only be used for emergencies. Sudo is a native-Linux structure to allow specific users access to run specific commands.

d) File and directory permissions are one of the most daunting, yet critical tasks in securing Linux systems. You need to review any/all critical system files and set both file owners and permissions for each using the chown and chmod commands respectively. Check for any files that are world writeable and executable.

9) Secure remote access – How will users and administrators access the Linux system? It’s rarely directly on the console. You’ll need to establish a secure channel for that access and make sure there are no backdoors lurking.

a) The first step is to view all open ports and services on the running system using the netstat command. You can also check from outside the system using nmap (a must-have tool in your security toolkit). Services that aren’t required (like telnet, finger, and “r” commands – “r” commands rlogind, rshd, rcmd, rexecd) should be disabled.

b) The second part is to configure SSH (secure shell) for remote systems administrator access. You should only allow specific and limited users to have this level of access. You also need to properly manage the SSH keys. Another step here is to make sure that root cannot login remotely. Users will need to first access the system with their own id and then use sudo or su. This is done by editing the /etc/ssh/ssd_config file. The last step is to set permissions on that file so only root can edit it.

10) Set auditing – You cannot secure everything, so it’s equally important to establish auditing, logging, and monitoring.

a) The first step is to ensure the audit daemon (auditd) is installed using apt-get install auditd and started with /etc/init.d/auditd start. Next, set it to watch important files for changes and keep logs of who modified them and when using the auditctl command. See this guide for more information on auditing.

b) Set up alerts to notify you or your SOC or help desk when there’s an issue or anomaly.  Logwatch automatically provides daily log summaries in the server’s /var/logs directory, which can also be sent to your mail folder. Refer to the logwatch configuration file to change the level of detail and specific services monitored.

c) Rather than viewing log files on each Linux system, consider forwarding log files to a centralized log server. This server should have enough disk capacity and bandwidth to sustain peaks and be protected to ensure log file integrity. Configuration is required on the Linux log server through the syslog daemon (syslogd) by modifying the /etc/rsyslog.conf file. You can use auditd to output client logs on a remote host using the audit dispatcher audisp-remote plugin.

A down-side to the approach listed here is that it needs to be done on each separate Linux server without centralized management. That can lead to administrator nightmares. Automating these steps by either your own scripts or through tools like BeyondTrust PowerBroker for Unix & Linux can save money, time, and effort.

In this post, I touched on some of the basics of Linux hardening – a bare minimum of what should be done on each Linux system. There are many more complex configuration settings to get to the next level of Linux security. To learn more about how to harden your Linux servers for better security, see my recent BeyondTrust on-demand webinar “Expert Tips and Techniques for Closing Unix/Linux Security Gaps.”

Ron Woerner, CISSP, CISM, ECSA, and Information Security Trusted Advisor

Ron Woerner is a noted speaker and writer in the security industry and the Director of the M.S. Cybersecurity program at Bellevue University, an award-winning leader in educating adult learners online and in the classroom. He has 20 years of corporate experience in information technology and security, and he has worked for HDR, TD Ameritrade, ConAgra Foods, Mutual of Omaha, CSG Systems and the State of Nebraska. Ron earned his B.S. in computer science from Michigan State University and his M.S. in information resources management from Syracuse University. He is a Certified Information Security Professional (CISSP) and Certified Ethical Hacker (CEH). Certifications: CISSP, CISM, CEH, CHFI, PCI QSA