April 2020 - WLUG - wlug.mailman3.com

Re: [BBLISA] audit root/sudo users for RHEL 6 server

by Lois Blood Bennett

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(a)stoffel.org> wrote: > >>>>> "John" == John Malloy <jomalloy(a)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(a)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(a)bblisa.org > John> http://www.bblisa.org/mailman/listinfo/bblisa > > _______________________________________________ > bblisa mailing list > bblisa(a)bblisa.org > http://www.bblisa.org/mailman/listinfo/bblisa

April 17, 2020

Re: [BBLISA] audit root/sudo users for RHEL 6 server

by John Stoffel

>>>>> "John" == John Malloy <jomalloy(a)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(a)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(a)bblisa.org John> http://www.bblisa.org/mailman/listinfo/bblisa

April 17, 2020

Re: [BBLISA] audit root/sudo users for RHEL 6 server

by John Malloy

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(a)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

April 17, 2020

Re: [BBLISA] audit root/sudo users for RHEL 6 server

by John Stoffel

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

April 17, 2020

Re: [BBLISA] audit root/sudo users for RHEL 6 server

by Dan Ritter

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-

April 17, 2020

audit root/sudo users for RHEL 6 server

by John Malloy

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(a)gmail.com

April 17, 2020

Re: April WLUG virtual meeting was a resounding success!

by Doug Mildram

tim> While it wasn't the same as a physical meeting, when we do manage to get ourselves all back in the same room.... doug>......by next meeting, maybe the wow factor of our WLUG Jitsi meeting will have faded. Or not! Either way, as we continue, i say THANKS, Very Cool (so far!) to have household members bop in to say hi. FEATURE: potential quick peek/hi's to/from your family/etc, some of whom we might know, + some we'd never "meet" otherwise! So get your laptop webcam working if you dare in May. Or...especially when lacking a pc-with-webcam, you might easily USE YOUR CELLPHONE to connect to Jitsi, as a couple of us did last week. I merely pointed my cellphone browser (google phone, if that matters) at the WLUG Jitsi link and it immediately offered me the free app ! (Part of the "too easy"if I don't mind "buying" a $0.00 app to attend meeting, battle cabin fever, show my ugly face and see my esteemed friends). TECH TWEAK for such meeting(s):? we should start with "audio/volume check", since our 10-or-so crowd unfortunately had "some kinda loud, others very weak" variables, and one might even get confused between weak/low-volume, vs other noise/combined-output issues. On Fri, Apr 10, 2020 at 8:51 AM Tim Keller via WLUG <wlug(a)lists.wlug.org> wrote: > Hey Everybody, > > I just wanted to give a shout out to everybody who showed up to the > virtual meeting last night. It was cool to see Maddog show up, I'm glad > he's staying safe and healthy. > > Yeah, there were a couple of audio/video hiccups, but I thought overall it > went great. > > I shared my screen a couple of times and that worked just fine as well. > > One cool thing that was brought up doing the meeting and I thought was > worth talking about is "vscodium" which is a 100% open source recompile of > the visual studio code editor. The big difference is that the vscode as > shipped from microsoft contains telemetry tracking data that gets sent back > to the mothership... https://vscodium.com/ solves that problem. > > We obviously jibber jabbed about COVID19 and folding@home and Logan > showed off the facemasks he's been printing as well as the antennae he's > building to contact a long lost satellite in geostationary orbit. > > While it wasn't the same as a physical meeting, when we do manage to get > ourselves all back in the same room, I think it's something we'll > definitely incorporate into the physical meetings. > > Stay safe, stay healthy and wash your hands! > > We'll see what May brings us and decide from there... > > Tim. > WLUG President > > > > -- > I am leery of the allegiances of any politician who refers to their > constituents as "consumers". > _______________________________________________ > WLUG mailing list -- wlug(a)lists.wlug.org > To unsubscribe send an email to wlug-leave(a)lists.wlug.org > Create Account: https://wlug.mailman3.com/accounts/signup/ > Change Settings: > https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ > Web Forum/Archive: > https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/VMGQ6… >

April 13, 2020

ansible layout thoughts

by John Stoffel

Guys, I'm starting to work on deplying ansible at $WORK to start managing a bunch of existing servers. The goal is to A) get them consistent, B) learn ansible, and C) automate deployments so if I get hit by a bus, they can have a hope of keeping things going. So my first thoughts are about organization. Ansible is a file/directory heavy setup. And I understand how a task has one or more roles. And then a playbook can have one or more tasks. But it's how to manage the overall site or bundles of playbooks that I want to understand. I've looked at: https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices… and I think I can deal with the first layout suggestion, but I'd porbably put playbooks into a playbooks/ directory. But... how to keep them organized as my collection grows. Do I want a new directory structure for each group of playbooks? For example I want to do: - add ssh-keys for logins - make sure right repo(s) are configured - ntp client config - postfix config - NIS config - fstab config - nsswitch.conf config So ideally all of the above would be a playbook each, since for example ntp config, would/could include: - install ntp - install default client config - restart ntpd once configured - etc... Where it all comes down to is keeping all this organized nicely, especially as it grows ever more complicated. All the silly examples of setting up a LAMP stack completely gloss over the actual pushing of content, which is really what we want to do. So, thoughts? Real life experience? Suggestions for good training classes? Unfortunately it would have to be online now, not my preferred in-person training.... John

April 13, 2020

Re: Has anyone here built a jitsi server?

by Daniel Walsh

On 4/10/20 14:30, Michael Voorhis via WLUG wrote: > On 4/10/20 2:23 PM, Emiliano Lopez via WLUG wrote: >> I didn't try but may be you can try the container alternative: >> https://jitsi.org/news/jitsi-meets-docker/ > Too easy. Docker's quicker... easier; more seductive. I would only > learn how to use docker, and I want more than that. > > Thank you though, > > --MCV. > _______________________________________________ > WLUG mailing list -- wlug(a)lists.wlug.org > To unsubscribe send an email to wlug-leave(a)lists.wlug.org > Create Account: https://wlug.mailman3.com/accounts/signup/ > Change Settings: https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ > Web Forum/Archive: https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/7X7J5… > You could also try Podman, just as simple as Docker. (Same CLI) and works in a more secure fashion. You can use it without being root. containers run in your homedir.

April 13, 2020

Re: Has anyone here built a jitsi server?

by Michael Voorhis

On 4/10/20 2:23 PM, Emiliano Lopez via WLUG wrote: > I didn't try but may be you can try the container alternative: > https://jitsi.org/news/jitsi-meets-docker/ Too easy. Docker's quicker... easier; more seductive. I would only learn how to use docker, and I want more than that. Thank you though, --MCV.

April 10, 2020