Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >

User activity attribution even after they "sudo to root"

11 April,19 at 11:50 AM

User activity attribution even after they "sudo to root"


This article covers the Advanced Monitoring functionality new to Centrify Server Suite 2017 Enterprise Edition. Embedded at the end of the blog is a brief video demonstration of the functionality.


IT Challenge/Issue

You can't manage what you can't see. And when it comes to securely managing your business and the applications that enable your business... it is essential you know specifically who is doing what on the machines hosting your business data and applications. For example, out of the box Linux server logs can tell you which account ran a privileged command on a given server. However, you lose identity context in the OS activity logging if someone "elevates" to the root user (e.g. "sudo su -"). So, if after running "sudo su -" someone restarts the web server or edits a sensitive OS file, it's very difficult to piece together what happened without the essential "identity context"... In other words, who was sitting behind the keyboard and what were they doing when that incident occurred?


PCI change management requirements. For example, 12.11 states that at the service providers perform at minimum quarterly reviews to demonstrate that personnel comply with security policy and procedure such as change management processes. It calls out that procedures include daily log file reviews So for example, someone makes change to critical OS file... We need to connect the dots by answering: 1) How do we identify system file changes; 2) Does the file change align with a stated change management request; and 3) Who was actually sitting behind the keyboard making the change?


Background/Primer info 

In Linux, we use sudo or dzdo (Centrify's enhanced implementation of sudo) to grant IT staff's individual named accounts with rights to run specific OS commands that require "elevated" permissions normally associated with accounts like "root". Let's say a web administrator logs in to a Linux machine with her named account to perform some action that requires root level permissions, such a restarting the web server.  To execute the privileged command, it's prefixed with "dzdo" or sudo. Running a command this way does two things: 1) dzdo/sudo confirms with the OS that the user has the rights to run the command (first screen shot); and 2) dzdo/sudo records in the /var/log/messages the action and the OS account that ran the command (second screenshot). 


Figure 1: dzdo while logged in with named user account

dwirth_dz.pngFigure 2: Output in /var/log/messages resulting from command run in Figure 1. 
dwirth_var_mess_no_ad_mon.pngIt's best to see this in action to really appreciate what's going on here... See the embedded YouTube video at the end of this blog. Jump to the 6'30" mark. 


That's great assuming your privilege elevation rules are "high-n-tight" and everyone has just enough rights to do their jobs. That said, as we strive towards least privilege, you'll  find users with more access than needed. Consider, for example, Linux admins with the broad permissions to run "sudo su -".  Once a user exercises this right, we're in the dark with respect to native OS logging. You lose identity context at this point.  You can try this yourself by tailing /var/log/messages, then in a separate window run "sudo su - " or "dzdo su -".  If you attempt to run a command as root, you won't see activity recorded in the log. 


Centrify Solution - Session Recording and Advanced Monitoring 

For years Centrify Server Suite Enterprise Edition helped to solve this problem in part by recording UNIX sessions. During a session replay, we could see a named user "dzdo su -" and still follow along with the subsequent actions once the user became root. 


Starting with Centrify Server Suite 2017 (Enterprise Edition), we compliment this functionality with our "Advanced Monitoring" capability. So, along with the session recording, Centrify now also preserves the identity context of the user in the Linux OS activity log (e.g. /var/log/messages) even after the user runs "dzdo su -" and becomes the root user. 


The next two screen shots illustrate what happens within the /var/log/messages once the Centrify Advanced Monitoring feature is enabled. In Figure 3, you see a user run "dzdo su -" and become root. While logged in as root, the user then restarts the web server. In Figure 4, you can still see that it was user dwirth that executed the command even though she was logged in as root. Furthermore, Centrify's Advanced Monitoring captures more detail compared to native privileged OS activity logging. For example, let's compare Figure 2 above (which depicts the end user restarting the web server while logged in as herself) against Figure 4 (which depicts the end user now logged in as root and then restarting the web server). You'll see that Figure 4 specifically captures the fact the user ran "/sbin/service httpd restart". Whereas in Figure 2 (without Centrify Advanced Monitoring enabled), you can only see that the user ran "/sbin/service"; we can't tell what service was involved and what action the user took against the service. 


Figure 3: With Advanced Monitoring enabled, the user switching to the root account via "dzdo su -", then restarting the web server



Figure 4: Output in /var/log/messages resulting from command run in Figure 3.



 Centrify Advanced Monitoring intro functional demonstration