Cyber Security Awareness Month - Day 3 - Standard Sudo

Cyber Security Awareness Month - Day 3 - Standard Sudo - Part One
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. The ISO has a working draft under development for a Framework for Identity Management (IdM) named ISO/IEC 24760. A sub-component of IdM is Privileged Identity Management which addresses accounts used to administer servers and manage critical services. Privileged accounts carry a different risk profile than ordinary user accounts. It is still very common for organizations to accept these risks and continue operations with less accountability. This increased risk is created mainly by poor password management of the privileged accounts coupled with the poor accountability for its use. There are some products on the market that manage passwords for privileged accounts with varying OS support and degrees of accountibility . The difficulty of this task has varies greatly which can depend on an organizations budget and committment to provide this control. The use of tools to manage privileged account passwords is a growing expectation of auditors. The main objective of this effort is to limit routine need to have unfettered and unaccountable access. Now, as a former UNIX admin, I have been part and parcel to many meetings and debates on "limiting root access". The notion implies tying the hands of the very good people that keep the servers operating. However, we are in a new era that affords different challenges and opportunities. Using the UNIX "sudo" utility bridges gaps between access, need and accountability. Ultimately, it lowers the risk profile of the business. The sudo utility is currently free software [2] that operates on most flavors of UNIX. Sudo has been a staunch staple of the UNIX community since the early 1990's and is maintained by Todd C. Miller [3]. Today it ships on many UNIX distributions as a means to control privileged user escalation. Some of the newer features in sudo help managing a "Standard Sudo" environment much easier than in versions past. The reality is that some organizations will not true up sudo versions on every server, especially the larger environments (> 100 servers, or even 10oo UNIX servers!, yes they exist!). The basic idea is to create standard command sets that suit a given operating environment, then push them out with scp/rsync. Part Two of this diary will illustrate how to profile command sets by consistent format of the sudoers file. With standard command sets in place, the privileged account passwords can be protected further and only "checked out" when an event occurs that requires full command line access. This at a basic level is a perfect model for smaller environments (< 25 servers), yet very challenging for larger environments with too many needs of the business to meet. When the newer INCLUDEDIR [4] feature arrived, it made medium size environments (< 100 sever s) easier to reach. Again, this only works great as long as all of your servers have a sudo version with the INCLUDEDIR option avai lable. Most UNIX Admin's already have rsync scripts to adapt a new process like this one in a very short time period. So, if the INCLUDEDIR feature is there, then standardizing the sudoers file should be a snap. Larger environments are an entirely different story, without INCLUDEDIR, the simple suggestion above will lie dead on this page. There is hope however! In Part Two, I will lay out some options for implementation of standardizing your sudoers file. In the mean time, post a comment below to share what you're doing. If I can incorporate them in, then I will be sure to include it and credit you. -Kevin [1] https://isc.sans.edu/diary.html?storyid=11794 [2] http://www.sudo.ws/sudo/ [3] http://www.sudo.ws/sudo/history.html [4] http://www.sudo.ws/sudo/man/1.8.6/sudoers.man.html#includedir -- 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

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.

The ISO has a working draft under development for a Framework for Identity Management (IdM) named ISO/IEC 24760. A sub-component of IdM is Privileged Identity Management which addresses accounts used to administer servers and manage critical services. Privileged accounts carry a different risk profile than ordinary user accounts.

It is still very common for organizations to accept these risks and continue operations with less accountability. This increased risk is created mainly by poor password management of the privileged accounts coupled with the poor accountability for its use. There are some products on the market that manage passwords for privileged accounts with varying OS support and degrees of accountibility . The difficulty of this task has varies greatly which can depend on an organizations budget and committment to provide this control. The use of tools to manage privileged account passwords is a growing expectation of auditors. The main objective of this effort is to limit routine need to have unfettered and unaccountable access.

Now, as a former UNIX admin, I have been part and parcel to many meetings and debates on "limiting root access". The notion implies tying the hands of the very good people that keep the servers operating. However, we are in a new era that affords different challenges and opportunities. Using the UNIX "sudo" utility bridges gaps between access, need and accountability. Ultimately, it lowers the risk profile of the business.

The sudo utility is currently free software [2] that operates on most flavors of UNIX. Sudo has been a staunch staple of the UNIX community since the early 1990's and is maintained by Todd C. Miller [3]. Today it ships on many UNIX distributions as a means to control privileged user escalation. Some of the newer features in sudo help managing a "Standard Sudo" environment much easier than in versions past. The reality is that some organizations will not true up sudo versions on every server, especially the larger environments (> 100 servers, or even 10oo UNIX servers!, yes they exist!).

The basic idea is to create standard command sets that suit a given operating environment, then push them out with scp/rsync. Part Two of this diary will illustrate how to profile command sets by consistent format of the sudoers file. With standard command sets in place, the privileged account passwords can be protected further and only "checked out" when an event occurs that requires full command line access.

This at a basic level is a perfect model for smaller environments (< 25 servers), yet very challenging for larger environments with too many needs of the business to meet. When the newer INCLUDEDIR [4] feature arrived, it made medium size environments (< 100 sever s) easier to reach. Again, this only works great as long as all of your servers have a sudo version with the INCLUDEDIR option avai lable. Most UNIX Admin's already have rsync scripts to adapt a new process like this one in a very short time period. So, if the INCLUDEDIR feature is there, then standardizing the sudoers file should be a snap. Larger environments are an entirely different story, without INCLUDEDIR, the simple suggestion above will lie dead on this page. There is hope however! In Part Two, I will lay out some options for implementation of standardizing your sudoers file.

In the mean time, post a comment below to share what you're doing. If I can incorporate them in, then I will be sure to include it and credit you.

-Kevin

[1] https://isc.sans.edu/diary.html?storyid=11794
[2] http://www.sudo.ws/sudo/
[3] http://www.sudo.ws/sudo/history.html
[4] http://www.sudo.ws/sudo/man/1.8.6/sudoers.man.html#includedir

--
ISC Handler on Duty

Kevin Shortt

85 Posts
ISC Handler

Oct 3rd 2012

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

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

@ 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

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

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

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