Greetings ISC Readers, Today's "Standards" topic for Cyber Security Awareness Month will begin a Two Part Diary that ties in standardization and UNIX Privileged Accounts. Part One will get our conversation started and tie some things together. Part Two will lay out some technical options for consideration. I touched upon this in my 2011 October Diary on "Critcal Control 8 - Controlled Use of Administrative Privileges" [1]. Both parts in whole will be an overall extension of the discussion last year as they overlap quite a bit.
-- ISC Handler on Duty |
Kevin Shortt 85 Posts ISC Handler Oct 3rd 2012 |
Thread locked Subscribe |
Oct 3rd 2012 8 years ago |
I run a small network with 2 internet facing servers and 3 firewalls, a dhcp server, 2 wifi routers, a backup server, and a small bunch of assorted user machines. I *AM* the sysadm -- the *ONLY* sysadm. Is there any advantage to be gained by using sudo over just logging in as root?
|
Moriah 133 Posts |
Quote |
Oct 3rd 2012 8 years ago |
We're managing all sudo access on over 150 servers with LDAP. Time to dump managing a sudoers file on each system.
http://www.sudo.ws/sudo/sudoers.ldap.man.html |
Anonymous |
Quote |
Oct 3rd 2012 8 years ago |
@ Moriah. Even when you only have a few systems to administer and you are the only one it is always a bad idea to log on to root. I use sudo everywhere, even if often it is only to prevent the oops factor. Being logged on as myself rather than root has saved, I dare say, many a sysadmins bacon.
I go as far as preventing root from logging on through anything other than the console on most systems. If you set a strong looooong password on the root you will also be more resilient to brute force password attacks. When assessing sites, those that log on to root invariably have comparatively bad passwords. Regards Mark H |
Mark 391 Posts ISC Handler |
Quote |
Oct 4th 2012 8 years ago |
We grant sudo access to a few commands and scripts to our tier one support so they can perform basic tasks without gaining full root access. Aside from that it's not utilized for sysadmins (root).
Most admin I know simply sudo shell (or su) once they login as themselves (root login disabled) to do work that generally require root anyway. As for preventing catastrophe, I think unless you have password prompt set to always on, it's probably not going help much. |
Anonymous |
Quote |
Oct 4th 2012 8 years ago |
Well, we are right now administering around 800 Unix Servers, Linux, AIX, Solaris and HP-UX, in the banking sector (for different banks). We are legally required to log admin actions. And we can't really.... We are right now evaluating a solution based on something like the shell control box from Balabit (basically a ssh MITM System).
Right now our interims solution is based on sudo, allowing all commands with your own password (ubuntu like), for all systems hooked to the central ldap server (in the future, we will deliver the sudoers from ldap, right now it's a centrally created package for all system types). The log goes to syslog and directly to a SIEM system. On strictly controlled systems (pci-dss, other environments being highly controlled), we aliased su to a command echoing a warning and disallowed a sudo su - in sudoers. This is not really an all encompassing solution, but at least it is accepted by auditing and banking controllers... |
Anonymous |
Quote |
Oct 4th 2012 8 years ago |
Thanks for the sudoers.ldap tip, Jerry. Right now at my day job we have a very large collection of linux/unix systems that we manage local accounts and sudoers files on using some internally developed scripts. Not zactly ideal. I've been intending to switch that all over to OpenLDAP, once I have time to sort out securely replicating only a portion of our LDAP data to an LDAP server in the DMZ (ie, just enough to do authentication/authorization, not the rest of all the data in our LDAP server). And sudoers.ldap will prove useful...
Though I'm betting I'll have to compile new nss_ldap and pam_ldap and sudoers from source for some of our older, UNIX systems to make it work... ![]() For those looking at switching from NIS to LDAP, be sure to use pam_ldap for authentication and nss_ldap for accounts, services, groups, etc. If you use just nss_ldap you wind up having to grant read/write privs of all the userPassword attributes to root on your systems - any system that someone roots can then fetch all the password hashes to try to crack - not a lot more secure than NIS. If you use pam_ldap you can restrict read/write access to userPassword to just owner (an authenticated user can see/modify their own userPassword attribute but even root can't fetch or modify 'em). |
Brent 123 Posts |
Quote |
Oct 4th 2012 8 years ago |
Sign Up for Free or Log In to start participating in the conversation!