Like UNIX, at its core, Linux’s secure model is basically monolithic. You either have root access or you don't. But root access is too powerful for so many reasons. And routinely using the actual root account – while easy and still frighteningly common – is so dangerous it borders on negligent. Auditors know about root and what questions to ask. In fact, some auditors already have their risk findings written up regarding root and privileged access before they even begin assessing your environment. Ultimately, if a root account on a Linux host is compromised, that’s the ball game.
The good news is that there are a variety of things built on top if Linux to make privileged access more granular, more accountable, more auditable and overall, more secure and in this webinar, I'll show you how root access and least privilege management works in Linux. You will learn about how administrators can still do their work efficiently without logging on as root. I will show you how sudo works and how you can use sudo to:
- limit which commands users can execute
- ensure accountability between admins
- eliminate logons as root
- create least privilege profiles that allow people to get their work done without sacrificing security
But at the end of the day sudo is a foundation technology for controlling privileged actions on a given system. Sudo supports the idea of controlling policy on multiple systems but it doesn't manage or facilitate managing least privilege policies on multiple systems. What's the difference? Well, you can design your sudoers file so that the same file is valid against many different systems. You just specify a Host_List in your rules (aka User_Spec) and those rules are applied to the specified hosts. So, for rules that apply to all hosts you simply omit Host_List specified from the rule. And include Host_List to allow other commands for a subset of specific hosts.
In this real training for free ™ webinar, I'll review how sudo works and then dive into how you craft a single sudoers file to rule them all. But how do you deploy that sudoers file to each system? And what about version control and change management? Sudo does not address that. Your options are:
- Leverage an existing systems management solution like Chef or Puppet
- Store sudoers in a ldap directory (not!)
- Put some scripts together
- Implement a solution that leverages the extensibility of sudo
Once you centralize your sudoers policy file you next need to think about centralized logging. Even with sudo you don’t achieve accountability or fulfill compliance requirements unless you have a high-integrity audit trail of what was done via sudo. And the problem is that by default sudo writes out both logs to local storage. Sudo writes out a log each command users try to run through sudo to syslog so that is relatively easy to centralize. But sudo also produces IO logs which is basically a full fidelity security camera recording of everything that happens after the command starts. You can't leave IO logs on the same system where they are created because they are vulnerable to the very people over which the logs are intended to provide a control. So, we'll also look at centrally collecting and archiving IO logs.
BeyondTrust is the perfect sponsor for this real training for free session because their solution: Privilege Management for Unix and Linux (PMUL) which enables admins to easily set up policies that allow and deny actions and use policy-based controls to elevate privileges as needed. Patrick Schneider is with me again from BeyondTrust and he will briefly demonstrate how PMUL provides:
- Centralized policy management for all Unix & Linux clients
- Granular controls of elevation adding controls and boundaries to overuses of root.
- Centralized events and logs (IO Logs) management eliminating the risk of tampering.
- Support for SIEM solutions such as Elastic (ELK) and provide a dashboards view of all events by users.
This is very technical real training for free ™ event focused on Linux/Unix security. Don't miss it. Please register now.