A Modern Take on Best Practices for Unix and Linux Security

Derek A. Smith, Founder, National Cybersecurity Education Center
February 20th, 2018

For a discussion and demonstration of this topic, please be sure to check out the on-demand version of my webinar, “A Modern Take on Best Practices for Unix & Linux Security“.
view now

Organizations that utilize Unix/Linux systems face some unique challenges when it comes to privileged access management (PAM). Both of these technologies make up the very foundation of many large to medium-sized IT environments and have been around longer than Windows and other newer operating systems (and will likely remain for years to come, even increasing in use due to stability, cost-effectiveness, and openness).

As with any technology, the real-world implications of adopting Unix/Linux in your environment present challenges during implementation. In a world where there exists cybercrime, insider threats, ransomware, and advance persistent threats – to name just a few – there is dire need for heightened security of technology that ventures much further than common practices from as recent as a decade ago. Today your Unix environments have to abide by increasingly stringent compliance requirements, various sophisticated threats, and the need to operate with a full range of non-Unix/Linux systems, such as Microsoft Windows.

In this blog, I will explore some of the most common security challenges facing Unix- based organizations and offer some tips on how these challenges can be overcome with some easily implemented practices and technologies. The measures I will provide can possibly lead to increased security, better compliance, and dramatically improved operational efficiency.

The Four Canons of Cybersecurity

When it comes to cybersecurity in any environment – whether Unix/Linux, Windows or any other – there are four canons that should be kept in mind for appropriate access. These cannons can be summarized in four A’s:

  1. Authentication – verifying the identity of the person or system requesting access to your Unix systems.
  2. Authorization – providing the appropriate level of access to the authenticated person or system.
  3. Administration – consisting of the tasks and activities associated with maintaining the lifecycle of the user identity.
  4. Audit – activities performed to satisfy compliance demands requiring authentication, authorization, and administration to transpire according to established rules and best practices.

Before I explore these concepts further, lets take a step back and examine Unix accounts a bit.

What’s the Problem with Unix?

When it comes to managing Unix/Linux accounts, especially privileged accounts, it is difficult to carry out with the native capabilities built into Unix. The fact of the matter is that managing identities and access for multiple Unix systems is complex and inefficient because each system is unconnected.

Unix uses a number of different types of user accounts, but every Unix-like system must have a root account. It is important to ensure that each user only has a single account on the system. Unix also uses what are known as “privileged” accounts. Privileged accounts have two main characteristics:

  1. Privileged accounts are the most powerful users in any organization
  2. Privileged accounts include shared accounts and super user accounts

These privileged accounts are identities that have the capability to perform administrative functions, configuration changes, install and execute programs. If you do not manage your privileged accounts appropriately, you can, and likely will, put your organization at risk through the following:

  • Lists of passwords circulating in an organization
  • Passwords that have never been changed
  • Employees that have left the organization and know the passwords
  • No entitlements process to verify that users should have necessary privileges
  • Change in jobs or roles where additional privileges are granted
  • Employees copy and share SSH keys
  • Users inadvertently granting access to the wrong people
  • Difficulty identifying the number of privileged accounts currently within a network
  • Insider threats

I mentioned previously that every Unix/Linux-like system uses a “root” account. The root account is also what we call a “super user” account, and is basically the default account that comes pre-built on the Unix/Linux operating system. The root account has unlimited access to do anything on the system. It has full read, write, and execute access to perform the following actions:

  • Installing
  • Modifying
  • Deleting
  • Running programs

With this type of power, there are serious challenges. It’s a fact that at most organizations administrators share privileged accounts. Natively, the sudo command helps with these challenges, but it has serious limitations. Mismanaging the root and other user privileges pose great risks to your organization – including financial losses, reputational damage, regulatory penalties and customer loss.

The 5th “A” – Accountability

For you to reduce the risk around shared and privileged accounts, there is another “A” I should mention, and that is accountability. Users must be held accountable for how they use their privileges. Mainly, you want to use the “‘least privilege” concept to restrict access to these accounts.

Restricting access to mission critical servers does not mean that system administrators will not be able to perform their responsibilities. Access will simply be better controlled by controlling the users’ file permissions. Every file and directory on a Unix-style system is marked with three sets of file permissions that determine how it may be accessed, and by whom:

  1. The permissions for the owner, the specific account that is responsible for the file
  2. The permissions for the group that may use the file
  3. The permissions that apply to all other accounts

And, each set may have none or more of the following permissions on the item:

  • Read
  • Write
  • Execute

Keep in mind that “root” ignores file permissions, allowing full access to every file on the system, regardless of the permissions attached to that file, so be very careful when granting root access. The majority of files on a Unix/Linux-like system are owned by the root account and have permissions that restrict or block access from all other accounts.

Unix Authentication Procedures

Let’s examine for a moment how Unix/Linux handles authentication. In Unix/Linux there is no native single sign-on for users. To access accounts, users have to have multiple accounts and passwords, and administrators have to provision each account separately. They can use an Active Directory (AD) bridge solution to extend Unix’s authentication and administration, but must be sure to choose their AD bridge solution carefully, so as not to complicate the other “A’s.”

Unix Authorization Procedures

For authorization, each Unix system requires its own authorization. Again, it’s important for you to choose an AD bridge solution that enables AD-based authorization. When it comes to access management administration for Unix/Linux, there are a few things to keep in mind.

  • Provisioning is time consuming for administrators
  • Manual de-provisioning processes entail significant risks
  • Password management is a drain on users and administrators alike
  • Unifying identities across the enterprise with Authentication Services yields significant savings

Unix Audit Procedures – Seven Actionable Safety Tips

Auditing is one of the most important aspects of your Unix/Linux security for two reasons. First, your audit logs help you to diagnose problems you may have within our environment. Second, compliance and security demand increasing levels of visibility into the access rights of individuals and the activities they perform with those rights.

I would like to provide you with seven actionable safety tips you can deploy within your Unix/Linux environment.

  • Step 1: Pick a good, supported operating system
  • Step 2: Stay current with patches
  • Step 3: Use a firewall
  • Step 4: Use file integrity monitoring and change auditing
  • Step 5: Keep your clocks in sync!
  • Step 6: Copy your logs to our central log server
  • Step 7: Use a privileged access management system

Privileged Access Management Concepts

Step seven, in my opinion, is one of the most important because controlling who has access to your servers in the first place lessens the chance for a breach or exploit. Privileged access management revolves around a few simple concepts:

  • Who can get to a server
  • How they can get to a server and
  • What they can do when they get there

Privilege management can be used for many things within your Unix/Linux environment. The following list are but a few, but should give you some items for further research. With PAM solution you can:

  • Manage accounts
  • Implement the least privilege principle
  • Manage the passwords within your Unix environment
  • Eliminate the dangerous use of shared accounts
  • Control access to your Unix/Linux environment
  • Log user activities
  • Manage and record privileged activity
  • Alert and notify you of unusual activity
  • And very important, allow you to centralize and unify administration

As the number of cyber-attacks increase, the need for organizations to increase their security posture has become more evident. Securing and managing privileged accounts by implementing a robust privileged access management system must be a high priority to ensure:

For a discussion and demonstration of these topics, please be sure to check out the on-demand version of my webinar, “A Modern Take on Best Practices for Unix & Linux Security“.

 

Derek A. Smith, Founder, National Cybersecurity Education Center

Derek A. Smith is an expert at cybersecurity, cyber forensics, healthcare IT, SCADA security, physical security, investigations, organizational leadership and training. He is currently the Director of Cybersecurity Initiatives for the National Cybersecurity Institute at Excelsior College, responsible to perform complex duties relating to the development and coordination of cyber initiatives at NCI. Formerly, he has worked for a number of IT companies including Computer Sciences Corporation and Booz Allen Hamilton. Derek spent 18 years as a special agent for various government agencies and the military. He has also taught business and IT courses at several universities for over 20 years. Derek has served in the US Navy, Air Force and Army for a total of 24 years. He completed an MBA, MS in IT Information Assurance, Masters in IT Project Management, and a BS in Education.