Controlling Unix & Linux Account Privileges: 9 Best Practices

As a Unix/Linux system administrator or security professional your main purpose is to manage the users of your information system and allow only limited access based on a user’s needs. As you are aware though, users can make mistakes. It could be anything from a novice administrator exceeding their knowledge level, an application developer running a script with root privileges, or a hacker accessing your system. Ultimately you are responsible and you don’t want to have to explain how a breach or loss of information occurred on your watch. Nor do you want to have to clean up the mess.

Controlling what users can and cannot do once they have accessed your Unix or Linux server is your main goal. Unix and Linux systems require an account for users to access the system, and are typically only accessed directly by users when they are performing administrative activity on the operating system, an application or data. Your system requires certain accounts to function properly and applications require some form of account on a server to work properly.

Managing these privileges can be done in many ways, and with many tools. One of the best methods though, is with a privileged access management tool, preferably one that allows for centralized management.

This article discusses nine best practices for Unix/Linux privileged identity and access management. Get a more in-depth view of all TWELVE best practices in my latest, interactive, on-demand webinar: 12 Best Practices for Controlling Linux and Unix Account Privileges.

1) Actively Manage Your Linux/Unix Accounts

Creating accounts is, in general, a pretty easy task. Disabling or removing accounts that are no longer required is more challenging. This task introduces risk by leaving accounts active that shouldn’t be. Unix and Linux systems require an account, somewhere, for users to access the system when they are performing administrative activity on the OS, and application or data. The system, itself, requires certain accounts to function properly; like the all-powerful ‘root’, and applications require some form of account on a server to properly function.

Although managing ‘people’ accounts is what most people think of when thinking of account management, leaving system and functional/application accounts out of the planning and process for account management leaves a gap and introduces risk to your enterprise.

2) Implement Least Privilege

The principle of least privilege, when applied to privileged accounts, restricts the rights and access of a user to the minimal amount to perform their role, which is an important practice to limit insider threats. Users should only be allowed to do what is appropriate for their job. The risk of allowing access is far less important than controlling what people can do.

Consider the following:

• Does every system administrator need to be logged in as ‘root’?
• Do they need to be able to run every command that ‘root’ has privilege to run?
• Do database administrators need root access?
• Does one computer talking to another require access to every command that could be run?

3) Manage all of Your Passwords

Your ultimate goal is to reduce the use of passwords overall. However, there are times and places where passwords still are, and must be, used. Where passwords exist they need to be managed. Managing passwords includes all of the basics: require the password to be changed periodically, do not allow the reuse of old passwords, require that they be of some level of complexity. These are all the basics of password management. Managing passwords means ALL the passwords: users, application/functional/service accounts, and the all-powerful “root” password.

4) Eliminate the Use of Shared Accounts

Administrators of a system should not share accounts. You need separate accounts for traceability and accountability for actions performed, not just for your administrators, but for anyone who accesses a system. Every Unix/ Linux system has a root account, and many applications have an account set up to associate its process with and limit the application’s privilege on the system; and sometimes an OS application or data administrator will need to perform some activities with the privilege of the OS, application, or data service. You should implement a system where a person can execute commands as another account, without having to login as, or become, that identity. The traditional Unix/Linux ‘sudo’ command allows you to do this. Your administrator can elevate a user’s privilege without allowing a shared account, and it provides the required traceability and accountability for activities performed on the system.

5) Control Account Access

Not every account available to a system needs to be able to access that account over the network. If you have properly implemented privilege control, then nobody needs to log in as root when they SSH to the system to perform maintenance. Not every account needs to access every server from every computer on the network either. Those automated authentications, from app-to-app or system-to-system, don’t need to be available from everywhere. In fact, they should only be allowed from the system that is performing the task.

6) Log Everything

Logging is very important and you should log everything, changes, access, privilege and failures, to name a few. It takes time and resources to store and evaluate all of those messages, but it is a task that must be completed.

You need to be able to report on who has access to what and when. This is required by many forms of regulation. Logging all changes to accounts, changes to entitlements, additions/deletions or other activity in a logging trail, and should be recorded so that the administrator that changed the rules can be identified.

7) Manage and Record Privileged Activity

Knowing who accessed what host, when, from where, and how, are great to know, but knowing that account's privileges is of utmost importance. It is essential to be able to analyze the data and figure out who did what on your system.

Managing who has the right to what, where they can do it, and when, is a powerful tool. Administrators often need to run commands with privileges other than those assigned to them. This could be application or database administrators that must perform maintenance or configuration operations, or it could be a system administrator. Excessive privilege by these administrators can cause serious problems. Tightly managing your administrator access may appear as if you don’t trust you administrator, but it must be done. These insider ‘accounts’ must be treated with suspicion. Not because of the people who they are assigned to, but because they are the most valuable asset to attackers.

8) Alert and Notify of Suspicious Activity

One you have established and implemented your logging and audit system, you should set up automated alerting and notification of suspicious activity within your system. Not every minor violation needs to be reported, but there certainly are those that should.

Your alerting and notification system should be well-defined with rules that stop inappropriate behavior. Logging will show us that activity is occurring that should not, and alerting and notification will allow us to build rules to prevent it from happening, allowing us to be proactive rather than reactive. This is the concept of detection through enforcement, meaning that the same rules that you write to detect bad behavior can also be used to prevent bad behavior.

9) Centralize and Unify

Linux and Unix allow you to do all the things I have recommended so far natively. For instance, SSH allows for the local configuration to control who can access, from where, how and what can they can do with that access. You can do these things manually if you are dealing with only one system with a few users. However, each additional server amplifies the effort to maintain the proper configuration exponentially and, a manual host-by-host approach can be prone to error.

Tightly coupling access control and privilege management has distinct advantages over trying to manage them separately, and in the Unix/Linux world, access control should be tightly coupled with account control. For that, you need a tool that allows you to centrally manage all three key aspects of access and privilege: account management, access control and privilege management.

Information security is constantly evolving. Having a good privileged access management plan for your Unix/Linux environment is essential to your security objectives. Get a more in-depth view of all TWELVE best practices in my latest, interactive, on-demand webinar: 12 Best Practices for Controlling Linux and Unix Account Privileges.