audit root/sudo users for RHEL 6 server
What is the best way to provide proof to an audit person who needs to know all the root/sudo users for a RHEL 6 server? (I am new at this company, and don't have access to all their resources) We can provide the /etc/passwd & /etc/sudoers file (the auditor may not know how to read these files) We also have the RedHat Identity Management running here, but I am not familiar with this tool. Any suggestions would be appreciated. Thanks! John Malloy jomalloy@gmail.com
John Malloy wrote:
What is the best way to provide proof to an audit person who needs to know all the root/sudo users for a RHEL 6 server?
(I am new at this company, and don't have access to all their resources)
We can provide the /etc/passwd & /etc/sudoers file (the auditor may not know how to read these files)
We also have the RedHat Identity Management running here, but I am not familiar with this tool.
What question did they ask? It's important. -dsr-
John> What is the best way to provide proof to an audit person who John> needs to know all the root/sudo users for a RHEL 6 server? It depends on what they take as "proof" of your audit process. Our current auditors want screen shots of files with a clock in the corner, which makes *zero* sense, so we're working to educate them and to put a better system in place. It might be that tripwire is the possible solution, started off first in a very targeted way. John> (I am new at this company, and don't have access to all their resources) John> We can provide the /etc/passwd & /etc/sudoers file (the John> auditor may not know how to read these files) The probably don't *care* what the files say, but more "what is your process to monitor and keep track of changes?". And of course management of adding and removing acounts. John> We also have the RedHat Identity Management running here, but John> I am not familiar with this tool. Never used it. Auditing is documenting a process and having controls and being able to show you use them and of course can justify them. John
They just want to know who can login as route or sudo These are both Oracle servers and they only have a route and Oracle account There’s no additional users in the Sudo file On Fri, Apr 17, 2020 at 1:39 PM Dan Ritter <dsr@randomstring.org> wrote:
John Malloy wrote:
What is the best way to provide proof to an audit person who needs to know all the root/sudo users for a RHEL 6 server?
(I am new at this company, and don't have access to all their resources)
We can provide the /etc/passwd & /etc/sudoers file (the auditor may not know how to read these files)
We also have the RedHat Identity Management running here, but I am not familiar with this tool.
What question did they ask? It's important.
-dsr-
-- John Malloy
"John" == John Malloy <jomalloy@gmail.com> writes:
John> They just want to know who can login as route or sudo And so do you! :-) John> These are both Oracle servers and they only have a route and Oracle account That you know of. Auditing, while painful and not fun unless it's automated, is the solution here. John> There’s no additional users in the Sudo file It's not that easy, since you also need to look in /etc/sudoers.d/ and also need to parse out group membership and check the sudoers* files for group entries. It's *not* trivial. But again, it's the auditing part that the auditors will be concerned about. How to do validate your results? How do you know that us powerful sysadmins aren't hacking the reports and ignoring certain accounts in the reports so that we can hide stuff? How do you know someone *else* hasn't hidden a SUID script or program somewhere else on the system? It's a damn rathole honestly, and there's a cost vs benefit call you need to make. Or more accurately, management needs to make. 100% security is when the server is off, unplugged from everything and buried in a hole. In concrete. :-) Be thankful you're not having to go through PCI compliance audits for handling credit cards, I've heard they're even worse! John John> On Fri, Apr 17, 2020 at 1:39 PM Dan Ritter <dsr@randomstring.org> wrote: John> John Malloy wrote:
What is the best way to provide proof to an audit person who needs to know all the root/sudo users for a RHEL 6 server?
(I am new at this company, and don't have access to all their resources)
We can provide the /etc/passwd & /etc/sudoers file (the auditor may not know how to read these files)
We also have the RedHat Identity Management running here, but I am not familiar with this tool.
John> What question did they ask? It's important. John> -dsr- John> -- John> John Malloy John> _______________________________________________ John> bblisa mailing list John> bblisa@bblisa.org John> http://www.bblisa.org/mailman/listinfo/bblisa
I find it interesting that the auditors don't know all of this stuff or have their own experts to tell you what they need. On Fri, Apr 17, 2020 at 4:24 PM John Stoffel <john@stoffel.org> wrote:
"John" == John Malloy <jomalloy@gmail.com> writes:
John> They just want to know who can login as route or sudo
And so do you! :-)
John> These are both Oracle servers and they only have a route and Oracle account
That you know of. Auditing, while painful and not fun unless it's automated, is the solution here.
John> There’s no additional users in the Sudo file
It's not that easy, since you also need to look in /etc/sudoers.d/ and also need to parse out group membership and check the sudoers* files for group entries. It's *not* trivial.
But again, it's the auditing part that the auditors will be concerned about. How to do validate your results? How do you know that us powerful sysadmins aren't hacking the reports and ignoring certain accounts in the reports so that we can hide stuff? How do you know someone *else* hasn't hidden a SUID script or program somewhere else on the system?
It's a damn rathole honestly, and there's a cost vs benefit call you need to make. Or more accurately, management needs to make. 100% security is when the server is off, unplugged from everything and buried in a hole. In concrete. :-)
Be thankful you're not having to go through PCI compliance audits for handling credit cards, I've heard they're even worse!
John
John> On Fri, Apr 17, 2020 at 1:39 PM Dan Ritter <dsr@randomstring.org> wrote:
John> John Malloy wrote:
What is the best way to provide proof to an audit person who needs to know all the root/sudo users for a RHEL 6 server?
(I am new at this company, and don't have access to all their resources)
We can provide the /etc/passwd & /etc/sudoers file (the auditor may not know how to read these files)
We also have the RedHat Identity Management running here, but I am not familiar with this tool.
John> What question did they ask? It's important.
John> -dsr-
John> --
John> John Malloy
John> _______________________________________________ John> bblisa mailing list John> bblisa@bblisa.org John> http://www.bblisa.org/mailman/listinfo/bblisa
_______________________________________________ bblisa mailing list bblisa@bblisa.org http://www.bblisa.org/mailman/listinfo/bblisa
You need to report who has the root passwords and who is in the sudo files, and whether there are any other means of becoming root. Powerbroker or other tools including Tivoli, puppet etc are included. If you can run a puppet script as root, you’re root. Sent from my iPad
On Apr 17, 2020, at 11:56 AM, John Malloy <jomalloy@gmail.com> wrote:
What is the best way to provide proof to an audit person who needs to know all the root/sudo users for a RHEL 6 server?
(I am new at this company, and don't have access to all their resources)
We can provide the /etc/passwd & /etc/sudoers file (the auditor may not know how to read these files)
We also have the RedHat Identity Management running here, but I am not familiar with this tool.
Any suggestions would be appreciated.
Thanks!
John Malloy jomalloy@gmail.com _______________________________________________ bblisa mailing list bblisa@bblisa.org http://www.bblisa.org/mailman/listinfo/bblisa
participants (5)
-
Dan Ritter -
Dean Anderson -
John Malloy -
John Stoffel -
Lois Blood Bennett