Tài liệu Unix for Security Professionals pdf

Trang 1

Unix for Security Professionals

Security Essentials The SANS Institute

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/

Trang 2

Agenda

• A Brief History of Unix

• Booting Unix

• The Unix File System

• Manipulating Files and Directories

• Unix Privileges

This page intentionally left blank

Trang 3

Trang 4

The Unix File System

In this section, we look at the Unix file system, starting at the logical layers and working down to the physical configuration of the Unix file system Access control and file permissions are discussed and Unix commands for manipulating files are introduced

Trang 5

Unix File System Limits

• File names can contain any characters

except "/" and null (ASCII 0)

• File names cannot be longer than 255

characters

• Can't specify directory pathnames

longer than 1024 characters

Like most operating systems in the last 40 years, Unix uses a hierarchical "tree-structured" file system (interestingly, tree-structure and other aspects of the Unix file system are a direct result of the original Unix developers being influenced by the Multics project they had been working on) Directories contain files and subdirectories which, may in turn, contain other files and

subdirectories, and so on The Unix file system was explicitly designed to be permissive as far as file and directory names, so any character is allowed in a file or directory name except "/" (which is used to specify full path names such as /etc/passwd) and null (ASCII 0, which is the Unix string termination character)

File names can be up to 255 characters long (longer than anybody would possibly want to type) Most Unix programs, however, won't accept pathnames longer than 1024 characters Longer paths than this may exist on Unix systems, but must be referenced as relative pathnames rather than full, explicit pathnames from the root of the file system One trivial denial of service attack

is to write a recursive program which creates a directory, changes directories into the new directory, then creates another subdirectory, and continues this process until all file system resources are exhausted Clearing up such a mess is fairly tedious due to the 1024 character pathname limit

Another problem occurs when trying to share files from a Unix system to a machine with a more limited file name vocabulary (like MS-DOS machines) Some algorithm must be created to morph Unix file names into locally useful file names The same problem happens in reverse on MacOS systems which allow "/" to appear in folder names

Trang 6

File Names Containing Spaces

% touch 'foo bar'

% ls

foo bar ps_data

% rm foo bar

foo: No such file or directory

bar: No such file or directory

command arguments unless the command line is properly quoted

In the first line of our example, we see somebody using the touch command to create a file with a space in the name (touch is normally used to update the last modified time on a file, but as a side-effect it will create an empty file if no file with the given name exists) A nạve user getting a directory listing might assume that the directory actually contained three files– two of which were named "foo" and "bar" However, attempting to remove these "two files" (or attempting to remove the file "foo bar" without proper quoting) yields an error message A "long listing" of the

directory shows that there are in fact only two files here, one of which has an embedded space

At this point, the user has the option of simply issuing an rm command with proper quoting (per the first line of the example) or using a wildcard (*) to specify "all files beginning with foo" Since there are no other files in the directory which match foo*, this is safe to do

Trang 7

Did You Say "Any Character"?

The user creates a file called "foobar" with a backspace between the "o" and the "b" (the

backslash "protects" the backspace from being interpreted by the Unix command shell) When an

ls is performed on the directory, the file name shows up as "fobar", not "foobar", because the embedded backspace causes the "b" to overwrite the last "o" However the file name is really

"foo^Hbar" and cannot be removed by using the name "fobar"

On SYSV systems, ls –b shows file names with non-printing characters represented by their octal ASCII value You'll need an ASCII table to find out that \010 octal is ^H (man ascii on many Unix systems will give you a Unix on-line manual page with the ASCII tables in decimal, hex, and octal) The administrator may then remove this file using the proper key sequence Note that modern BSD systems generally automatically show non-printable characters as "?" in the output of ls

Trang 8

Know Your Unix File System

/ – root file system, top of directory hierarchy /dev, /devices – directory containing

"files" used to talk to system devices

/usr – primary OS directory, "read-only"

/var – contains log files, queues, etc.

/tmp, /var/tmp – "scratch" directories

/usr/local, /opt – third-party software

/home, /export/home – user home dirs

Where there used to be a lot of variance in where different files were located in different Unix

"flavors", modern Unix variants have settled down to using the same general file system layout

At the top of the directory tree is the root directory, / Below this directory are various important subdirectory trees The /dev directory (SYSV systems often use /devices in addition to /dev) contains the special files which programs running on the system use to communicate with hardware devices controlled by the kernel /usr is where most of the critical components of the operating system live This directory structure can be thought of as being "read-only"– that is, after the operating system is loaded, not much changes under /usr unless the operating system is upgraded or patches are installed /var is where the system keeps data that changes frequently, such as log files and queues for services like email and printing /tmp and /var/tmp are directories where any user or process on the system can write "scratch" files (many systems automatically clean out files in /tmp that haven't been used in the last day or so) On some systems /tmp is actually a RAM disk (in-memory file system) to increase performance of applications that write a lot of temporary files (e.g., compilers) Non-OS software is often installed in /usr/local (BSD convention) or /opt (SVR4), though at different sites many, many different naming schemes are used User home directories are often found under /home(/home is often an NFS mounted directory with /export/home being where the files

physically reside), though /users and /u1, /u2, … are not uncommon

Trang 9

The Root File System

• Unix kernel under root directory or in

subdirectory such as /kernel

• BSD systems store boot loader in /boot

• /sbin directory contains programs

critical for boot sequence

• /etc contains system configuration files

As we mentioned in the previous section, the root file system is where components critical for system boot are located In particular, the kernel itself resides near the top of the root file system: either directly under / as /unix, /bsd, or /vmunix, or in a subdirectory such as /kernel/unix

On BSD systems, the boot loader which actually executes the kernel during the bootstrapping

process is stored as /boot (a nasty denial of service attack is to remove the /boot program and reboot the system– the administrator must boot off of the OS media and restore the /boot program manually)

The /sbin directory contains the init program and the programs which init needs to configure the system These programs include the Unix command shell (/sbin/sh), the mount command for mounting file systems, and the ifconfig command for configuring network interfaces

/etc is where essentially every configuration file on the system resides (this directory tends to get

very cluttered) Note that files are often written in /etc during the boot process, so this directory

(unlike /usr) is generally considered a "read-write" directory

Trang 10

/dev and /devices

% ls /dev

MAKEDEV fd1a rfd0Ga rwd0g tty03

MAKEDEV.local fd1b rfd0Gb rwd0h ttyC0

acd0a fd1c rfd0Gc rwd0i ttyC1

acd0c fd1d rfd0Ha rwd0j ttyC2

apm io rfd0Hb rwd0k ttyC3

apmctl ipl rfd0Hc rwd0l ttyC4

arandom ipnat rfd0a rwd0m ttyC5

audio ipstate rfd0b rwd0n ttyc0

bpf0 joy0 rfd0c rwd0o ttyc1

bpf1 joy1 rfd1Ba rwd0p ttyc2

bpf2 klog rfd1Bb rwd1a ttyc3

bpf3 kmem rfd1Bc rwd1b ttyc4

[… continues for pages …]

This is the directory listing from a BSD-style /dev directory As you can see, the directory is full of cryptically named files (SVR4 /devices directories are even more confusing) Generally, device files which share the same prefix, refer to the same type of device For example, the tty* files are all Unix TTY drivers for different network "pseudo-terminals" The letters and numbers after a device refer to a particular instance of the given device– for example, your system might have four SCSI disk devices, sd0, sd1, sd2, and sd3

Note that attackers just love to hide files and directories in /dev and /devices because they tend

to get lost in the "noise" One way to detect these directories is to write a process which periodically calls the du (disk usage) command to report the size of the /dev directory Generally, the size of this directory doesn't change under normal operations, so if the disk usage spikes up (even a little), it might be an indication that something illicit is happening in /dev

Trang 11

/usr

• Standard OS tools in /usr/bin,

administrative programs in /usr/sbin

• System (shared) libraries in /usr/lib

• Documentation in /usr/man or

/usr/share/man

• Header files for software development

in /usr/include

Most Unix variants keep the bulk of the operating system programs in /usr/bin, however

"administrator-only" commands are often in /usr/sbin The system libraries used to compile programs on the system are stored in /usr/lib Note that most modern Unix systems use the

concept of shared libraries where the library code is not actually stored in the executable itself, but

loaded out of the /usr/lib directory when the program is executed– this creates a dependency on /usr/lib for most programs on these systems (administrators should note that programs under /sbin are compiled without shared library support so that they can be run during the boot process before /usr/lib is available)

On-line documentation is available in /usr/man (/usr/share/man is a SunOS convention that

is used on some other operating systems) On-line manual pages can be read using the man

command (man man for more information) man –k <keyword> will search the on-line manual page descriptions for pages which match <keyword>

Software developers (in addition to the system libraries in /usr/lib) will need various header files from /usr/include These files describe system calls and data structures used by the functions

in the system libraries

Trang 12

/var

• System logs in /var/log (and /var/adm)

• User mail boxes in /var/mail or

/var/spool/mail (on mail servers)

• Mail queue in /var/spool/mqueue,

printer queues in /var/spool/lp*

• Files for cron daemon in /var/cron or

/var/spool/cron

BSD systems generally keep all of their log data in /var/log SYSV systems use both

/var/log and /var/adm Often /usr/log and /usr/adm are links to the actual directories under /var, but the /usr pathnames are retained for backwards compatibility with older systems

On mail servers, user mailbox files are generally stored in /var/mail (SYSV) or

/var/spool/mail (BSD) Some systems are actually configured by the administrator to put user

mailboxes in the user's home directory (generally these systems also enforce disk quotas which limit

how much disk space individual users get)

Queue directories are locations where various system processes write temporary files For example, print jobs in progress are put in /var/spool/lp (SYSV) or /var/spool/<printer> (BSD), while mail messages in transit usually end up in /var/spool/mqueue These systems use private queueing directories rather than /tmp because the contents of the queue files are often private and/or sensitive

The cron daemon keeps its configuration information in /var/cron (BSD) or

/var/spool/cron (SYSV) In particular, the list of jobs to be executed for each user is often found in /var/cron/tabs or /var/spool/cron/crontabs

Trang 13

What Attackers Go For

/etc – back doors in inetd.conf, new

entries in passwd and shadow files

/dev, /devices – hidden directories and

config files from "rootkits"

/usr – Back-doors and changed functionality

in OS binaries after rootkit installs

/var – attackers edit log files to remove

evidence and traces of their attack

/home – rhosts and netrc files

From a security perspective, it's a good idea to know some of the common files and directories that attackers will modify as part of an attack on a Unix system The information below is just a sampling of some common problem areas

In the /etc directory, attackers will often try to add entries to various configuration files to give themselves access Look out for new entries appearing in the /etc/inetd.conf– this could

be a remote back-door into your system New accounts in /etc/passwd and /etc/shadow,

or a change to an existing system account (like the uucp or lp accounts) might be a way for the attacker to log into your system whenever they want

As we mentioned earlier, attackers like to hide files in /dev because they're difficult to detect Often these will be the configuration and data files for "rootkits"– collections of tools attackers like to bring onto your system These rootkits often include malicious programs which replace various common system binaries in the /usr file system For example, the attacker might bring

in a replacement Syslog daemon which doesn't log information about the attacker’s activities!

After a successful attack, attackers will also edit your log files in the /var file system to cover their tracks It's often a good idea to log information to another system as well as the local machine, so you can compare copies of the logs after a break-in

.rhosts files in a user's home directory can allow an attacker to access the system as that user remotely without providing a password– as long as the system that the attacker is coming from is listed in the rhosts file .netrc files are used by FTP to do automated login "scripts"– they can contain passwords that an attacker can use to break into other systems

Trang 14

File Attributes

% ls -ld /etc /boot

-r-xr-xr-x 1 root wheel 45056 Nov 3 1998 /boot

drwxr-xr-x 12 root wheel 2048 Jun 10 11:35 /etc

File

Type Permissions

Link Count

Owner Group

Owner

Size (bytes)

Last Modified

File Name

Now let's turn our attention to Unix file attributes as shown by the ls program The –l argument (that's an "el" not the numeral 1) forces the detailed output listing shown above, and the –d flag tells

ls to list information about a directory rather than information about the contents of the directory (the default)

The first column of the listing is a block of letter codes showing the type of file and the access permissions set on the file We'll return to file permissions soon, but as far as file types go there are

7 one-letter codes: '-' (regular file), 'd' (directory), 'l' (symbolic link– that's an "el" for "link", not a one), 'c' and 'b' (special Unix device files– see next slide), 'p' and '|' (named pipes and FIFOs which will not be discussed in this course) The next entry is the link count field which will be discussed towards the end of this section

The next two columns show the owner of the file and the group owner of the file These combine with the file access permissions to tell the system who has access to the file

The fifth column is the file size in bytes Next comes the last modified time on the file Note that dates within the last year display the actual time of modification while older dates simply display month, day, and year This is simply a human readable formatting decision– actual Unix dates are stored in a completely different internal format

The last column displays the file name

Trang 15

Symbolic Links and Devices

Path to Real File

Certain special types of files provoke slightly different output formats from the ls command The convention of having a symbolic link in /dev pointing at a real device file under

/devices is a SVR4 mechanism for backwards compatibility for Unix applications expecting certain device names under /dev

Symbolic link files (note the 'l' in the first position of the listing) display both the name of the link as well as the name of the file that the link points to Notice that there are 25 characters in the path name /devices/pseudo/mm@0:kmem and that the size of the symbolic link "file"

as reported by ls is 25 bytes– symbolic link "files" simply contain the path of the file that they point to

Device files on a Unix system don't contain any actual data, so instead of displaying a file size, the ls command displays the device numbers corresponding to the device The first number (the

major device number) indicates what sort of device this is (the number is actually the index of the

device driver code in the Unix kernel for the given device) and the second number (the minor

device number) specifies a particular instance of the device Generally speaking, all devices of a

certain type– SCSI tape drives for example– will have the same major device number but the individual tape drives connected to the system will each have their own minor device number Note that device numbers are architecture-specific and not portable from vendor to vendor or even between different hardware platforms from the same vendor (can't use the same device numbers for Sun Ultra5s and E10Ks)

Trang 16

Unix File Permissions

x - r x

r x

-w r

File Owner Owner Group Everyone Else

Write Permission Permission Read Permission Execute

Unix file permissions use a fairly coarse granularity security model Read, write, and or execute permissions can be set for three different categories of people: the file's owner, people belonging to the Unix group listed as the group owner of the file, and "everybody else" (or "other")

Read permission means the ability to look at the contents of the file, write permission means the ability to modify the contents of the file, and execute means that the file may be run as a program Note that a user may execute a file as long as they have execute permission, even if they cannot

"read" the file

Trang 17

Other Permission Bits

t - r s

r s

-w r

Set-UID Set-GID "Sticky"

There are three other permission flags that may be set on a file

Certain programs need to run with special access privileges not available to normal users– for example, the passwd command which changes a user's password needs administrative privileges so

it can update the system password database The set user ID (set-UID) and set group ID (set-GID)

flags cause the program to run as the owner or group owner of the file, rather than as the user that executed the program– the passwd program is set-UID and owned by the Unix administrator account (root), so that it can update the password database when executed by a normal user Set-UID and set-GID programs are often a source of security problems on Unix systems but are still one of Unix's most useful innovations

The so-called "sticky bit" was originally developed in the early days of Unix on slower machines The idea was that any program which had the sticky bit set was supposed to "stick around" in the memory of the operating system after the program had finished executing This was a win on

programs that needed to be executed frequently because they didn't need to be constantly read back into memory Modern Unix systems (which use shared libraries, have better caching algorithms, and run on faster hardware) generally ignore the sticky bit on executables However, the sticky bit now has a different special meaning when applied to directories

Trang 18

Files vs Directories

only owner may remove filesN/A

"Sticky"

group ownership of new files is inherited

as above but for group

ownerSet-GID

N/A

file executes with privileges of file's ownerSet-UID

may access files in directorymay execute file

Because the Unix file permissions model is fairly limited, the meaning of each of the permissions flags we've seen so far is "overloaded", having different behavior depending on whether or not the object is a file or directory

For example, being able to "read" a directory means that the user can run the ls command (or other similar commands) to get a listing of the files in the directory Write permissions on a directory give the user permissions to change elements of the directory "file"– as we will see shortly, Unix directories contain file names and pointers to files, so being able to modify

directories means being able to change file names and/or add and remove files The execute bit

on a directory gives the user the ability to change directories into the given directory and to access files out of that directory, but a directory listing cannot be obtained unless the read permissions are also set Generally speaking, directories need the execute flag turned on to be useful but it is sometimes appropriate to give a user only execute rights on a directory (if you want the contents of the directory to be private and give the user just one explicit file path to access)

If the set-GID bit is set on a directory and a user creates a new file in that directory, then the group owner of that file will be the group owner of the directory rather than the primary group that the user belongs to– this is useful when you are using Unix groups as a mechanism for sharing files in a large project When the sticky bit is set on a directory, then only the owner of a given file may remove that file from the directory– this bit is often set on /tmp and other temporary directories to prevent users from stomping on each other's files (either accidentally or

on purpose)

Trang 19

Absolute File Modes

x - r x

r x

-w r

1 0 1 1

0 1 1

1 1

Unix access permission flags are often referred to as "bits" because their representation in the Unix operating system is as binary value– a one means the given flag is turned on and a zero means the flag is not set Unix commands which affect the permissions on files usually use octal notation to represent the clusters of bits for the owner, group owner, and "other" categories The octal notation

completely specifies all of the permission bits on a file and so is generally referred to as the absolute

mode of the file.

In the example above, the owner of the file has read, write, and execute permission: all bits are turned on so the binary representation is "111", which is octal 7 (4+2+1) The group owner and

"other" category only have read and execute set, but not write permissions: the binary is "101" which

is 5 octal (4+1)

Trang 20

Using Absolute Modes

• With chmod command:

chmod 666 myfile chmod 1777 /tmp

• "Inverted" for umask command

umask 022 umask 077

The chmod (change mode) command sets permissions on a file or directory The first example

shows how we can use absolute mode to set read and write permissions for all categories of users on

a given file and "give away" that file to anybody on the system Making a file "world-readable" in

this way is dangerous– particularly if the file contains logging information or system configuration

data Note that the set-UID, set-GID, and sticky bits are represented in a fourth optional octal digit at the beginning of the absolute mode (set-UID is 4, set-GID is 2, and sticky is 1) In our second example we set the normal permissions on the /tmp directory– anybody on the system has read, write, and execute permissions on the directory but the sticky bit is set so that users can't clobber each other's files

The umask command allows a user to specify what permissions they want to be set by default on the

files that they create The umask command specifies the bits that should be turned off when the file

is created For example, a umask of 022 specifies that the write bit should be turned off for the group owner and the "other" category This means that new regular files will be created with the read bit turned on (absolute mode 644) and that new programs will be created with the read and execute bits turned on (mode 755) umask 022 is the standard "friendly" umask However, some users may wish to not allow anybody but themselves to access their files by default, so setting the umask to 077 turns off all bits except those which apply to the file's owner

Trang 21

Symbolic Mode with chmod

• Remove set-UID flag:

chmod u-s myfile

• Add group write permissions:

chmod g+w myfile

• Don't let other people read the file:

chmod o-r myfile

• Turn off execute bit for everyone:

chmod a-x myfile

chmod also supports symbolic mode which allows administrators to turn individual bits on and off The first part of the symbolic expression specifies the category of the bit: 'u' (user) for the file owner permissions, 'g' for the group owner, 'o' for the "other" or "everybody else" category, and 'a' for all

categories Next is a plus or a minus which says whether the bit should be turned on or off Finally the actual bit is specified ('t' is used to denote the sticky bit because 's' is used for set-UID and set-GID)

Note that the "a" group specifier can usually be dropped Thus chmod a-x myfile and chmod –x myfile do the same thing on most Unix systems

Trang 22

User and Group Ownership

• chown changes file ownership

chown hal /home/hal

• chgrp changes group ownership

chgrp other /home/hal

• Usually, you can do both at once

chown hal.other /home/hal # old BSD chown hal:other /home/hal # modern

The chown command changes the owner of a file, the chgrp command changes the group owner Actually, the chown command can set both the owner and group owner simultaneously as shown above– on 4.3BSD-derived systems (and older, e.g SunOS) the separator between the owner and group owner is '.', but on newer machines (and SYSV-derived machines in general) the character is ':'

On some Unix machines any user can run chown On these systems, however, running chownusually clears the set-UID and set-GID bits or else normal users could create files that were set-UID

to the administrator account and compromise the system Allowing users to run chown to "give away" their files can cause many other problems as well– including thwarting the disk quota system (users can chown their files to somebody else to give themselves more disk space or wage a denial-of-service on another users) Modern BSD-derived Unix systems generally only allow chown to be run by the Unix administrative user

Trang 23

Common Settings

• Most system files should be owned by

the root user

• Group owner is often sys, bin, or root

• Files should generally only be writable

by their owner

• Look out for set-UID files – especially

set-UID files that "suddenly" appear

Most executable files on a Unix system are mode 755, while regular files tend to be mode 644 Certain "private" files on the system, however, are only readable by the owner– for example

/var/log/secure under Linux (contains sensitive log data) which is owned by the

administrative user and is mode 600, or the /etc/shadow file on many Unix systems (stores

encrypted passwords) which is mode 400 Generally files should never be "world-writable" (mode

666), because then any user on the system could modify them Also be on the look out for files that have the set-UID or set-GID bits set, since these have the highest potential for causing harm Be especially concerned if a new set-UID program suddenly appears on your system– maybe in a user's home directory or in some other unusual location A little bit later, we'll give you a command that allows you to locate all of the set-UID and set-GID files on your system

Binaries and other files that ship with your operating system are most often owned by the Unix administrative user, root Usually the group owner is sys or root, but sometimes bin Be on the look-out for files in the standard operating system directories that are owned by other users

Tiêu đề	Unix for Security Professionals
Tác giả	Hal Pomeranz, Deer Run Associates
Chuyên ngành	Security
Thể loại	Tài liệu
Năm xuất bản	2001
Thành phố	Oakland

Định dạng
Số trang	47
Dung lượng	557,56 KB