Tài liệu Unix for Security Professionals pptx

Most Unix systems now keep encrypted passwords in a protected file called /etc/shadow sometimes other names are used.. Unix Security - SANS ©2001 8"Blocking" Accounts • Standard encrypte

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/

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

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

• 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 Unixsystems 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

Unix Security - SANS ©2001 6

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

Other Administrative Fields

Here's a sample /etc/shadow entry from a Solaris machine The format of this file on otheroperating 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 yoursystem) 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

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/shadowwith 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 Thechown 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?

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

• Superuser access provides ability to

control all files, processes, and devices

• By convention, the superuser account is

named root

The Unix security model basically has two classes of people: normal users who can pretty much only mess with their own files, and a single all-powerful "superuser" (administrator) who can do anything

to any object on the system The superuser can read any file, change the permissions and ownership

on any file, delete any file, change user passwords at will, add and remove devices, etc The goal of

an attacker trying to break into a Unix system is to get superuser access because then they "own" the system

From the early days of Unix, the primary superuser account has been the root user (think

"Administrator" under Windows) Unix folks use "root" and "superuser" interchangeably

Unix Security - SANS ©2001 12

UIDs and the Superuser

• Any account with UID 0 has superuser

privileges

• Other UID 0 accounts may exist besides

the root account – usually locked

• Attackers often try to create new UID 0

accounts to get root access

However, the superuser account could just as easily be called "mack" or "buddy"– as far as the Unix operating system is concerned, any account with UID 0 has superuser privileges The author has actually seen sites where many users had UID 0 accounts in the /etc/passwd file– this is a terrible idea since it ruins any chance of auditability you might have had Plus any one of those accounts might have an easily guessable password that will allow some outside attacker unlimited access to your system

Now some Unix operating systems include a few UID 0 accounts besides root for special purposes Generally these accounts will either run some special shell which performs a certain task, or will have an invalid password field so that no user may log in under these accounts A favorite tactic of attackers is to put live passwords or valid shells on UID 0 accounts that are normally locked– audit your extra UID 0 accounts on a regular basis or remove them from the system entirely if you don't need them

Another ploy on systems with large password files is to add accounts with UID 0 in the middle of the password file someplace Administrators may not notice the new account Remember the sortcommand which prints the password file in ascending order by UID? This is why that's an important

• Use /usr/bin/su command

– Better audit trail

• Limited access with sudo

– Excellent audit trail and fine-grained controls

Generally, there are three legitimate ways of getting superuser access on a Unix system ("going root" in the lingo)

The first mechanism is to log into the system as root with the root password This is generally

thought to be a bad idea since you have no idea who is using the root password– if the system

crashes right after somebody logs in as root, who do you track down to find out what happened?

It is occasionally necessary to log in as root on the system console when the system becomes really wedged, but this should be the only place where root logins are allowed In particular,

never allow root logins over the network– particularly over insecure protocols like telnet or

rlogin where an attacker with a password sniffer can grab the root password

The /usr/bin/su command allows a normal user to become any other user on the system, as long as they know the other user's password su is most commonly used to become root,

however Every time a user successfully changes their UID with su, a line of logging info gets put in the system logs– this way you can find out who did what in the case of system problems Always type the full pathname of the su program to avoid getting trapped by Trojan horse suprograms designed to capture the root password

The sudo tool (http://www.courtesan.com/sudo/) allows a user to run a single command with root privilege as long as they are listed in the /etc/sudoers file sudo

prompts the user for their own password, rather than the root password– at many sites which use sudo most of the user's and administrators don't even know the root password for the systems they work on! sudo produces copious logging and allows extremely fine-grained access control Use it

Unix Security - SANS ©2001 14

Groups

• Users are assigned to a default group

according to their /etc/passwd entry

• Users may also belong to other groups

as defined in /etc/group

• groups command tells you which

groups you are currently a member of

• Some groups have special privileges

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 thought to be "snobbish")

Each user belongs to at least one group– the group defined in their /etc/password entry A user may belong to other groups as well– more on this on the next slide To find out which groups you belong to at a given moment, simply run the command groups with no arguments and a list of your group memberships will be printed

Certain groups have special privileges On some Unix systems the operator group is allowed to run the privileged commands which backup and restore files On BSD systems, members of the wheel group (the "big wheels" on the system) are the only people on the system allowed to use the

su command to become root (if the wheel group has no members, then any user may su to root as long as they know the root password)

Password (rarely used)

Group ID (GID)

Group Members

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 they had accessed the system)

The last field of the group entry is a comma-separated list of users who are members of a given group (this list may be empty) A single user may appear 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

Unix Security - SANS ©2001 16

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!

Let's review what 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 the users who you want to be able to su

before proceeding any farther For our example, we'll use the root group (GID 0) which exists on

most modern SYSV machines

The trick is to make sure that the su program's group owner is whatever group we've chosen and then to simply turn off the execute bit for the "other" category on the su binary The su program can now only be executed by the root user (the owner of the binary) and members of group root! Unfortunately, this means that "normal" users (those not in group root) can't even use the suprogram to become some unprivileged user– this may not be a "feature" from your perspective