System Administrator Security

From Security Wiki
Jump to navigationJump to search

SDSC's System Administrator Security Guidelines The following are recommended guidelines for securing your privileged account and hosts from unauthorized access. Following these guidelines will not guarantee your account or host will not be compromised, but are useful in reducing your risk.

System Administrators are held to a higher standard than regular users due to their access to privileges on some resources.

Report any deviation of SysAdmin behavior from these guidelines to the Manager of Security Technologies as soon as possible. [The above is for SDSC Sysadmin's not general public.]

SysAdmin User Account Behavior Guidelines

  • Your user account password should be different than your password on any other systems outside of your home site (SDSC).
  • If you use sudo, Your sudo password must be different than your user account password to protect privilege escalation when your user account is compromised. SDSC uses and recommends a Kerberos sudo. Kerberos passwords can be long in length. [We will find out the max length and document it here.]
  • It is recommended that your kerberos user password (if you have one) be different than your user account password and different from your sudo password. This is actually very important for system administrators and people with privileges to keep user account compromises from leading to privilege escalation.

Yes, that is three passwords that you need to maintain and be different.

  • Pick passwords that are not easily guessed by password guessing programs like "crack". We recommend your passwords and passphrases be 8 characters or longer with mixed case and at least one special character ($, %, ^, etc.).
  • DO NOT set your user account or other passwords to previous passwords. Implement password history if possible.
  • If you use a home computer or laptop, use two factor authentication for logging in to SDSC systems from a remote computer or from your home networks. One way to do this is to create ssh keys with a passphrase. We recommend the passphrase be 8 characters or longer with mixed case and at least one special character ($, %, ^, etc.).

DO NOT make this password the same as any other of your other sites passwords.

Two factor authentication is something you know (the passphrase) and something you have (the private key you generated). The private key should be protected and not be distributed to any other machine except the laptop or home computer. If you believe the keys have been compromised, generate new keys.

THIS DOES NOT APPLY TO READING YOUR EMAIL. Just remote login to SDSC resources.

  • DO NOT use ssh keys with no password. The ssh key generation mechanism allows you to set the passphrase to an empty string. This allows logins with only one factor authentication (the private key). This is not strong authentication and should be avoided at all costs.
  • DO NOT put your password in any file to automate some login process. We have seen users use tools like "expect" and put their username and password in a readable shell script or perl program. This is HIGHLY discouraged. If the Security Technologies group discovers passwords in programs, we will consider the account compromised and take appropriate action to secure the account. Security Technologies can be consulted for alternative methods for application authentication (instead of reading a username/password from a file).
  • DO NOT send any password in unencrypted email. You are a SysAdmin and should know better than this. If you didn't before, you know now.
  • When logging in to outside computers from your home systems, IF POSSIBLE, do not use Secure Shell client commands (scp, sftp, etc.) from these systems to your home systems. The risk here is outside systems may have a trojaned ssh client that can steal your home site password. IF POSSIBLE, it is much more desirable, to perform the function from your home to any system, ESPECIALLY, if your starting place originates at your home site.
  • Report any strange behavior, especially when we are experiencing a security incident, to the Security Technologies group professionals, no matter how trivial.

SDSC's Administrator Guidelines for Maintaining Systems Privileged (root) access

  • *NO* remote root logins. PERIOD. No excuses. Log in as a user and use sudo or su. You are a SysAdmin and you should be able to construct a way to get your job done without logging in directly to systems as root.

For SDSC Admin's. At the time of this writing there is only one exception to this and it will not be documented here. Contact Security Technologies for information.

  • If direct root login is required, then do it at the console. There should not be an excuse for remote root access. Sucks to be a SysAdmin sometimes. Always try to think of another better way to do this. Inconvenience for you may mean reducing risk to your resources.

Do not give friends, vendors, contractors or others any root password or sudo. There should be a process for these type of people to gain privileged access. Construct and Fill out a privileged user form. Security concious system administrators should understand this.

  • Do not su from root to a user account. Security Technologies monitors for this behavior and will contact the systems administrator to inquire about all such changes from privileged users to user accounts. This activity is not prohibited, but is strongly discourage.
  • Admin access should be from "secure" locations. Whatever that means. Don't go to a cybercafe machine or a public library workstation to login to your systems and do privileged work.
  • Root password is changed whenever anyone who had it leaves the job or changes roles and no longer needs it on your home systems.
  • Do separate user login authentication from privileged access authentication. In other words, the user password MUST be different from the privileged access password (su or sudo password).
  • Any activity that might inadvertently expose the root password, e.g. accidentally typing it in as a username, *must* be followed by a root password change. Immediately contact the Security Technologies staff if you suspect root password exposure or potential root compromise.

Files and File Systems

  • Audit all setuid root binaries and remove the setuid bits from unnecessary programs. Unnecessary programs include ones that you do not know what they are or do.
     find / -mount -perm -004000 -user root -exec ls -lg {} \;
  • All world writable directories should have the sticky bit set.
     drwxrwxrwt   4 root     sys          571 Apr 13 15:17 /tmp/
  • In general, files owned by root should not be world writable, and usually not group writable.
  • Most current day operating systems have this but, audit root's path, make sure dirs are owned and only writable by root. minimize as much as possible, e.g. /sbin:/usr/sbin:/bin:/usr/bin
  • Use RCS, Revision Control System, to maintain important configuration files, such as, hosts.allow, inetd.conf, hosts, sshd_config, etc.
  • DO NOT mount file systems with SETUID enabled. DO NOT export file systems with root user privileges. Export your NFS file systems to specific hosts, do not export to the world or use wildcards in the config files. READ Chapter 15 Network Filesystems, in the S. Garfinkel, G. Spafford and A. Schwartz, Practical Unix and Internet Security, 3rd Edition, O'Reilly and Associates, Feb 2003

Output from mount command: 

     /usr/local on mynfs:/usr/local/generic remote/read only/nosuid/vers=3/bg/intr/xattr on Tue Apr 13 07:47:32 2004
                                                             ^^^^^^

Example entry for fstab file: 

     mynfs:/usr/local/generic   - /usr/local nfs - yes rw,bg,intr,nosuid,quota

Other

  • Machines should be installed off the network until they are fully and safely configured to be on the network.
  • It is very important to keep up-to-date with security patches. Most systems are compromised by obtaining privileges through known exploits for which there already exists a patch.
  • Log your syslog data to local disk and to your centralized log server. Your Security Technologies people can help monitor your system for known bad guys and signs of intrusion. Here is an example syslog entry:
     *.debug              /var/log/messages
     *.debug              @lager.sdsc.edu       (this is SDSC's central log host)

These log files should only be root readable. Owned by root with permissions of 600. If you must, allow the root group or some other group you create to read the log files and put only necessary users in this group.

  • Do understand and use TCP Wrappers for access control to network services on your systems.
  • Perform, maintain and audit your backups. You may need them to restore your system back to a known state.
  • All Secure Shell daemons should only support protocol version 2 or higher. This is implemented by modifying the sshd_config file to specify protocol 2 only. The default protocol if not specified allows fallback to version 1.
Retrieved from "https://security.sdsc.edu/mediawiki/index.php?title=System_Administrator_Security&oldid=2294"