3 - 1 Unix Security - SANS ©2001 1 Unix for Security Professionals Security Essentials The SANS Institute All material in this course Copyright © Hal Pomeranz and Deer Run Associates, 2000-2001. All rights reserved. Hal Pomeranz * Founder/CEO * hal@deer-run.com Deer Run Associates * PO Box 20370 * Oakland, CA 94620-0370 +1 510-339-7740 (voice) * +1 510-339-3941 (fax) http://www.deer-run.com/ 3 - 2 Unix Security - SANS ©2001 2 Agenda • A Brief History of Unix • Booting Unix • The Unix File System • Manipulating Files and Directories • Unix Privileges This page intentionally left blank. 3 - 3 Unix Security - SANS ©2001 3 Agenda (cont.) • Unix Processes •Networking • System Services •Unix Backups •Wrap-up This page intentionally left blank. 3 - 4 Unix Security - SANS ©2001 4 Unix Privileges This section covers the Unix model for security and access control. Unix has historically had a tendency towards simplicity and openness, which means that its security model doesn't easily lend itself to high-security environments. Much work has been done in the last decade to develop Unix- like operating systems with stronger and more complex security models (for an example, consider Sun's "Trusted Solaris" product). 3 - 5 Unix Security - SANS ©2001 5 Usernames and Passwords • Every user has an assigned username and password • Usernames and passwords are case- sensitive • Passwords are silently truncated at eight characters • Usernames generally limited to eight characters for backwards compatibility Every user on the system has an identity assigned to them in the form of a unique username, and associated with each username is a password that the user must enter in order to be able to log into the system. Usernames are case-sensitive, so "Hal" and "hal" are different user names. However, most Unix installations use all lower-case usernames by convention. Unix passwords are also case-sensitive (one of the most common user errors is attempting to type one's password while the caps-lock key is on). Note that the Unix password routines generally silently truncate passwords at eight characters, so even if you enter a password like "this is a really long password", your password will be "this is " ("this is"-space) as far as the system is concerned. Similarly, older Unix systems assumed that usernames would be eight characters or less (certain programs died horribly upon encountering longer user names) and many sites run with usernames of eight characters or less just to be on the safe side. Usernames can contain any alphanumeric characters; passwords generally allow at least any printable character, with some Unix systems allowing non-printable control sequences in passwords as well. 3 - 6 Unix Security - SANS ©2001 6 An /etc/passwd Entry hal:*:100:20:Hal Pomeranz:/home/hal:/bin/csh Username Password Field (not used) User ID Group ID Full Name User Home Directory User's Shell We've already seen a couple of entries from the user database in /etc/passwd earlier in the course, but let's examine one in more detail. The first field is the username field. The second field is used to contain the encrypted password for the user. However, putting encrypted passwords in a world-readable file like /etc/passwd allows attackers to crack your passwords and impersonate other users. Most Unix systems now keep encrypted passwords in a protected file called /etc/shadow (sometimes other names are used). The next two fields are the user's numeric user ID (UID) and group ID (GID)– more on these a little bit later in this section. The fifth field is the full-name field (sometimes called the GECOS field because the early Unix machines at Bell Labs used this field to store information needed to submit batch jobs to a mainframe running the GECOS operating system). Field six is the path to the user's home directory and field seven is the user's default login shell. A list of valid login shells is normally kept in the file /etc/shells–if /etc/shells doesn't exist then the system defaults to the "standard" shells provided with the OS (sh, csh, ksh, et al). The moral of this story is, if you add a shell like tcsh or bash to your Unix machine, you'd better create an /etc/shells file and add the new shell plus all of the standard system shells. 3 - 7 Unix Security - SANS ©2001 7 An /etc/shadow Entry hal:papAq5PwY/QQM:10588:::::: Username Encrypted Password Other Administrative Fields Here's a sample /etc/shadow entry from a Solaris machine. The format of this file on other operating systems may vary wildly. First we have a username field to tie this entry back to the user's entry in /etc/passwd. Next we see the user's encrypted password. On Solaris machines, the password field is followed by several other fields which control password expiration, etc. We won't concern ourselves with the exact use of these fields because they are so OS-dependent. Generally the /etc/shadow file (or whatever file contains the encrypted passwords on your system) is readable only by the administrative user. This works out fine because the processes which log users into the system run with administrative privileges and user commands like passwd (for changing passwords) have the set-UID bit set. Again, if your encrypted password strings are readable by anybody on the system, then they will be stolen and cracked offline. 3 - 8 Unix Security - SANS ©2001 8 "Blocking" Accounts • Standard encrypted password strings are 13 characters long • Editing /etc/shadow and using an invalid password string to block logins • Can also set an invalid shell in /etc/passwd for additional protection • Never use an empty password string in /etc/shadow! The standard Unix password encryption algorithm creates a string which is always 13 characters long, and made up of the set of alphanumeric characters plus "." and "/". When the administrator wishes to block logins to a particular account, they simply edit /etc/shadow and change that user's encrypted password string to anything which doesn't meet those criteria. Standard choices are strings like "=NP=" or "*BLOCKED*" or sometimes just "*", though the longer strings are easier to pick out in a large password database. Never under any circumstances use an empty field in the /etc/shadow file, however. An empty field means that user is allowed to log in without providing any password at all! In addition, the administrator sometimes chooses to set the user's shell (in the last field of /etc/passwd) to an invalid or non-existent executable like /bin/false or /nosuchshell. This adds an extra layer of security and can also tell the administrator if the account is supposed to be blocked just by looking at the /etc/passwd file (rather than having to look at /etc/shadow with administrative privileges). Of course, an attacker with administrative privileges on the system might replace this "invalid" shell binary with an actual copy of a valid shell executable– for this reason, many administrators like to use /dev/null here because if /dev/null is replaced by a copy of a shell executable then the system stops working properly and the administrator is alerted to the change. 3 - 9 Unix Security - SANS ©2001 9 Usernames vs. User IDs • Usernames are purely for the convenience of human beings • Unix systems store ownership info in terms of User IDs (UIDs) • Commands like chown will accept either usernames or UIDs As far as the Unix operating system is concerned, the UID entry in the passwd file is what's important, not the username. Usernames are essentially only for the convenience of the human beings who use the system– all data about file ownerships, etc. is stored internally by UID. The passwd file is used by the system to relate UIDs to usernames– if a user's entry is deleted from the passwd file, the ls command displays the numeric UID on files that were owned by that user. The chown command accepts either usernames or UIDs as arguments. Note that UIDs on most Unix systems are two byte (16 bit) quantities, so there is a maximum of 65,535 users on a Unix system. Fortunately or unfortunately, we've reached a point now where large Unix installations are having to deal with total user populations of over 65,000 users– in these cases not all users can have accounts in the same UID space. It's difficult to imagine going to longer UIDs because of all of the Unix machines already in the field with 16 bit UIDs– how do you maintain backwards compatibility? 3 - 10 Unix Security - SANS ©2001 10 UIDs and Networked File Systems • John has UID 100 on his machine • Mary has UID 100 on her machine • Administrator mounts John's home directory on Mary's machine via network • Mary can read all of John's files! Moral: If you're using NFS, make sure you ensure unique UIDs! Care must be taken not to overlap UIDs in the same company because Unix access controls are based on UIDs and not usernames. This is even more important on modern Unix machines running NFS or other file sharing protocols. If two users share the same UID and can cross-mount each other's home directories, then they can access each other's files! Now let's reflect on the lives of user's at companies where there are more than 65,535 users. The administrators at this site had better make sure that they divide the users up into small self-contained groups that don't need to share files with the other groups or chaos will set in fairly quickly. [...]... member of • Some groups have special privileges Unix Security - SANS ©2001 14 We've seen previously that Unix files have both an owner and a group owner Unix groups allow sets of users to share files among themselves but not necessarily give access to other users on the system Unfortunately, most sites don't make proper use of Unix groups (again the Unix model has been towards openness and groups are... 19 9873 Take over the machine: renice –n –19 3078 Unix Security - SANS ©2001 25 nice is generally used when running commands which can take a long time but which are not particularly critical The catman command reformats the Unix on-line manual pages from their troff sources (troff is an early text-formatting language popularized on Unix systems) to formatted text files and caches these files under... the binary) and members of group root! Unfortunately, this means that "normal" users (those not in group root) can't even use the su program to become some unprivileged user– this may not be a "feature" from your perspective 3 - 16 Unix Processes Unix Security - SANS ©2001 17 A process is a program running on a Unix system As we mentioned earlier, even though a Unix machine appears to be running many...The Superuser • Unix systems have an "all or nothing" security model • Superuser access provides ability to control all files, processes, and devices • By convention, the superuser account is named root Unix Security - SANS ©2001 11 The Unix security model basically has two classes of people: normal users who can pretty much only... we've learned about file permissions and the Unix security model by doing a cute hack for SYSV machines SYSV machines generally do not have the concept of a wheel group to limit su access like BSD systems do However, we can "fake it" in the following way First, choose a group that will be our "pseudo" wheel group, or create an entirely new group in /etc/group for this purpose– update the group list with... (GID) wheel:*:0:root,hal Password (rarely used) Group Members Unix Security - SANS ©2001 15 Like the passwd file, the /etc/group file is used primarily to relate human-readable group names to group IDs (GIDs) for use by the operating system Note that there is a password field in the /etc/group file but it is almost never used in practice (older Unix systems allowed users to "log in" to certain groups once... computing power of the machine The Unix process abstraction is a means of making these executable images easier to manage for the underlying operating system 3 - 17 BSD-style Process Listing CPU Utilization # ps aux USER root Memory Parameters PID %CPU %MEM 2791 0.0 0.3 Process Owner Process ID (PID) TT p2 TTY VSZ 264 RSS 200 STAT STARTED RN+ 11:10AM Status Start Time Unix Security - SANS ©2001 Total CPU... column output format can be obtained with ps auxw, and unlimited width output is ps auxww) 3 - 18 SYSV-style Process Listing Process ID (PID) # ps –ef UID PID root 5397 Process Owner Start Time PPID 5289 Total CPU Time C STIME TTY 1 11:31:57 pts/5 Parent Process ID TTY Unix Security - SANS ©2001 TIME CMD 0:00 ps -ef Command Info 19 SYSV machines use ps –ef rather than ps aux (there is no way to force "extra-wide"... from –19 to 19, higher priority goes to lower nice numbers • Only the superuser can assign negative nice values • Users may only set nice values on their own processes, and only for the worse Unix Security - SANS ©2001 24 Unix systems have a notion of process priority or niceness value (so named because you get to choose how nice you want to be to other users on the system) Most processes run at priority... in the group lists for many different groups in the /etc/group file The groups command prints the user's default group from /etc/passwd plus any other groups the user is listed in from /etc/group 3 - 15 Group wheel for SYSV # cd /usr/bin # chgrp root su # chmod o-x su # ls -l su -s x - 1 root root 15832 Mar 8 1998 su Don't give up your root shell until you've tested this one! Unix Security - SANS ©2001 . 3 - 1 Unix Security - SANS ©2001 1 Unix for Security Professionals Security Essentials The SANS Institute All material. left blank. 3 - 4 Unix Security - SANS ©2001 4 Unix Privileges This section covers the Unix model for security and access control. Unix has historically