Xem mẫu
- Unix for Security Professionals
Security Essentials
The SANS Institute
Unix Security - SANS ©2001 1
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/
2-1
- Agenda
• A Brief History of Unix
• Booting Unix
• The Unix File System
• Manipulating Files and Directories
• Unix Privileges
Unix Security - SANS ©2001 2
This page intentionally left blank.
2-2
- Agenda (cont.)
• Unix Processes
• Networking
• System Services
• Unix Backups
• Wrap-up
Unix Security - SANS ©2001 3
This page intentionally left blank.
2-3
- The Unix File System
Unix Security - SANS ©2001 4
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.
2-4
- 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
Unix Security - SANS ©2001 5
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.
2-5
- 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
% ls -l
total 16
-rw-r--r-- 1 hal deer-run 0 Jun 10 10:56 foo bar
-rw-rw-r-- 1 root sys 4476 May 17 15:41 ps_data
% rm foo*
Unix Security - SANS ©2001 6
Another problem with the permissive nature of the Unix file naming scheme is that spaces may be
embedded in Unix file names (you see this most frequently on files imported from Windows and
Macintosh machines). Unfortunately, the Unix shell interprets space as a separator between
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 naï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.
2-6
- Did You Say "Any Character"?
% touch foo\^Hbar
% ls
fobar
% rm fobar
fobar: No such file or directory
% ls -b
foo\010bar
% rm foo\^Hbar
Unix Security - SANS ©2001 7
Perhaps more evil is embedding non-printing characters in file names. In particular, the backspace
sequence (-H, represented here with ^H) can cause particular fun (attackers often
create files with embedded control characters to make eradication difficult).
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.
2-7
- 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
Unix Security - SANS ©2001 8
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.
2-8
- 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
Unix Security - SANS ©2001 9
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.
2-9
- /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 …]
Unix Security - SANS ©2001 10
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.
2 - 10
- /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
Unix Security - SANS ©2001 11
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 will search the on-line manual
page descriptions for pages which match .
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.
2 - 11
- /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
Unix Security - SANS ©2001 12
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/ (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.
2 - 12
- 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
Unix Security - SANS ©2001 13
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.
2 - 13
- File Attributes
File
Owner Group Name
Owner
% 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
Link
Count Last
File Size Modified
Type Permissions (bytes)
Unix Security - SANS ©2001 14
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.
2 - 14
- Symbolic Links and Devices
Path to
Real File
% ls -l /dev/kmem /devices/pseudo/mm@0:kmem
lrwxrwxrwx 1 root other 25 Jun 8 12:58
/dev/kmem -> /devices/pseudo/mm@0:kmem
crw-r----- 1 root sys 13, 1 Jun 8 12:58
/devices/pseudo/mm@0:kmem
Device
File Numbers
Type
Unix Security - SANS ©2001 15
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).
2 - 15
- Unix File Permissions
File Group Everyone
Owner Owner Else
r w x r - x r - x
Write Read Execute
Permission Permission Permission
Unix Security - SANS ©2001 16
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.
2 - 16
- Other Permission Bits
File Group Everyone
Owner Owner Else
r w s r - s r - t
Set-UID Set-GID "Sticky"
Unix Security - SANS ©2001 17
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.
2 - 17
- Files vs. Directories
File Directory
Read can read file contents can get directory listing
Write can modify file contents can create/remove files
may access files in
Execute may execute file
directory
file executes with
Set-UID privileges of file's owner
N/A
as above but for group group ownership of
Set-GID owner new files is inherited
only owner may
"Sticky" N/A
remove files
Unix Security - SANS ©2001 18
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).
2 - 18
- Absolute File Modes
File Group Everyone
Owner Owner Else
r w x r - x r - x
1 1 1 1 0 1 1 0 1
7 5 5
Unix Security - SANS ©2001 19
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).
2 - 19
- Using Absolute Modes
• With chmod command:
chmod 666 myfile
chmod 1777 /tmp
• "Inverted" for umask command
umask 022
umask 077
Unix Security - SANS ©2001 20
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.
2 - 20
nguon tai.lieu . vn
