decorative image for blog on linux security
July 11, 2024

Linux Security Best Practices

Operating Systems
Security

By

Linux security is top of mind these days as CentOS Linux, one of the most popular open source Enterprise Linux distributions, just sunsetted its final version. No more updates or patches will be released from the community, and it is estimated that there are still tens of thousands of servers running end-of-life CentOS. 

Whether you are still on CentOS or on another Linux distro, knowing how to secure your Linux server is essential to protecting your systems and keeping unauthorized people and malicious code/malware out.

In this blog, read about Linux security best practices, including some setup/configuration "shortcuts" that can actually weaken your security and increase your risk.

Table of Contents

  1. Linux Security: Overview
  2. Common Linux Security Vulnerabilities 
  3. 8 Steps to Secure Your Linux Server
  4. Final Thoughts 
Back to top

Linux Security: Overview

There are many reasons why you should (or must) secure your Linux servers, but the top two that immediately come to mind are compliance and accountability. 

Compliance Requirements

There are a number of scenarios where securing your Linux server is mandatory. For example:

  • If you process or store any credit card information, there are requirements to secure your server.
  • If you handle medical data, there are HIPAA security requirements.
  • You may have security policies within your company that you need to adhere to.
  • If you interface with 3rd parties, there may be security agreements that all parties need to comply with.

If any of the above apply to your organization, securing your Linux server is not optional. 

Get more information about open source compliance >>

Accountability

  • Having tight security can furnish you with favorable answers when prospects or customers ask about your company’s security history, which is far better than the alternative (aka having a bad reputation due to lax security).  
  • If a security issue does occur, your company could be legally liable to have implemented certain security measures. 

Regardless of why you feel it is necessary to keep your Linux server secure (or how you justify it to others in your company), properly implemented Linux security measures will undoubtedly benefit your business beyond any potential inconveniences that may come to mind when security is mentioned.

Back to top

Common Linux Security Vulnerabilities 

When most people think about Linux vulnerabilities, they think of bugs in software which can result in potential security risks. Recently, CVE-2024-6387 and CVE-2024-6409 were disclosed, and both are vulnerabilities within the OpenSSH package on EL9 (and EL9-based distributions). Very few systems use insecure remote access methods like Telnet these days, but it used to be that you had a choice of having the default Telnet access and/or installing SSH. Luckily, SSH became the default for remote access, but it is still necessary to keep it up-to-date in order to continue enjoying the security that using it provides.

Security vulnerabilities can show up in almost any package. For instance, CVE-2021-43527 is a CVSS score 9.8 remote code execution vulnerability in nss, CVE-2022-25315 is a CVSS score 9.8 overflow/DoS/arbitrary code execution vulnerability in expat, and CVE-2021-35942 is a CVSS score 9.1 overflow/arbitrary memory read vulnerability in glibc. Last year, the high severity Looney Tunables vulnerability (CVE-2023-4911) impacted numerous Linux distributions including CentOS 8, and a critical libwebp vulnerability (CVE-2023-4863) allowed essential heap data structures to be overwritten in CentOS 7 and 8, as well as other open source software that uses the popular code library (NGINX, WordPress, Node.js, and others). 

Note: OpenLogic provides CentOS patches for CVEs with CVSS score of 7 or higher for our CentOS LTS customers.

Vulnerabilities (and the bad actors that exploit them) are somewhat beyond our control — but there are other things that can weaken Linux security we can address. I'm talking about choices that get made to save time/effort and make implementation easy, or issues that are do not seem high priority enough to get taken care of in a timely manner. 

Here are a few examples:

  • Using passwordless ssh keys so you don’t have to type your password over and over each day or having the system auto-login when it boots ("Nobody is allowed to touch my workstation.")
  • Leaving root logged in at the console ("I'm the only one who comes into the data center.")
  • Turning off SELinux ("It’s too difficult to get it working properly.")
  • Not updating some or all of the packages on a system ("It’s working right now and I don’t want to risk breaking anything.")
  • Leaving accounts on a system after an employee has left the company (“They can’t get into our network anymore so there’s no rush to remove their accounts.”)
  • Keeping mission-critical systems running on End-of-Life distributions (“I have too many other things on my to-do list and these have been working just fine for years!”)

Main point: cutting corners when it comes to Linux security is never a good idea and can come back to haunt you.

Back to top

8 Steps to Secure Your Linux Server

In addition to not doing any of the shortcuts above, here are 8 best practices that you should consider:

  1. Harden systems to specific security standards (CIS Benchmarks, PCI-DSS, STIG, etc.) 

Even if there aren’t any explicit requirements to do this, it's a good idea. This can be made easier by using pre-hardened images. These images can either be created in-house or obtained from a trusted 3rd party like OpenLogic.

Most benchmarks will test and configure the system through hundreds of checks, such as automatically disconnecting idle sessions, and raise flags if auto-login is enabled, or accounts without passwords are detected, and so on. 

    2. Use (and require) strong passwords

Social media is filled with fun little quizzes about your pet’s name, your childhood address, what year you were married, and so forth. First of all, don’t fall for these social engineering tricks that try to get you to share information commonly used in passwords or security questions. If you do accidentally share info like this, a strong password means hackers won’t have enough information to easily figure out how to access your accounts.

Security benchmarks typically configure the system to enforce this, too.

    3. Keep systems updated

You not only need to keep the OS updated but also all of the apps (and any dependencies) on the system.

The fear of breaking something due to an update can be alleviated by having a lab/staging environment where you can test updates (and other changes) in isolation before deploying to production.

If a lab/staging environment is not available, consider a phased deployment to a few systems that, if problems occur, can be taken offline, repaired, and then brought back online.

    4. Plan to migrate systems before they reach end of life (EOL)

True Enterprise Linux distributions have known lifecycles from release through end of life. This information can be used to plan when to upgrade from one OS to another from the start instead of near (or after) the published EOL date.

If they do reach EOL, procure long-term support for the OS and packages/services (such as the CentOS support available from OpenLogic for 5 years after the EOL date).

    5. Implement MFA (Multi-Factor Authentication)

MFA adds another layer of access security for each account so a misplaced Post-It note with your new password on it or a lost thumb drive that contains an SSH key doesn’t automatically allow access to whomever sees/finds it.

    6. Use system configuration to deploy and validate configuration and security consistently

Not only can tools like Ansible or Puppet help with the initial launch of your systems, they can also be used to maintain ongoing compliance and updates of those systems, and reduce MTTR in Disaster Recover (DR) situations in the event that systems need to be rebuilt from scratch.

Comparing configuration management tools for enforcing Linux security? Here’s what to know about Ansible vs. Puppet >>

    7. Incorporate SELinux from the start (and don’t disable it or leave it in passive mode)

The most common SELinux-related problems that are difficult to resolve are due to development and testing (and sometimes, staging) being done with SELinux disabled and the placement of files and directories being where SELinux doesn’t know how to handle them. Then, when SELinux is finally enabled (typically in staging but sometimes in production), everything breaks and SELinux is disabled again and left that way. By placing your files in locations that adhere to SELinux’s expectations, local SELinux policies can be minimized or eliminated.

    8. Stay on top of account maintenance

By incorporating centralized authentication such as some combination of FreeIPA, Directory Services, SSO, Kerberos, and RADIUS, it becomes very easy to activate, deactivate, or update accounts and their permissions. Most high-end network gear also supports centralized authentication so your entire infrastructure can be secured the same way.

If you don’t have centralized authentication, use tools (like the aforementioned Ansible or Puppet) to keep accounts stored locally on each system in-sync.

Back to top

Final Thoughts 

Unfortunately, there is no shortage of bad actors looking to compromise your system to steal data or otherwise cause harm to your business. Having a secure Linux server and strong Linux security measures means you can sleep well at night because you’re not worried about all of the potential attacks that you have no defenses against, and you’re not prepared for. 

24/7/365 Enterprise Linux Support Backed by SLAs

OpenLogic offers technical support for all major open source Linux distributions. There's no limit on tickets or team members who can submit them. Let our Enterprise Architects solve your toughest Linux challenges! 

Explore Linux Support

Additional Resources

Back to top
headshot-rich-alloway

Rich Alloway

Enterprise Linux Developer, OpenLogic by Perforce

Rich Alloway has over 25 years of professional Linux experience in academic, Internet service provider and telco carrier environments. He has filled many production roles: SysAdmin, Systems/Network/RF Engineer and CTO. He is currently a member of the Enterprise Linux Team at OpenLogic by Perforce, and serves as a contributor on the Rocky Linux QA and Testing Team.