Unix for Security Professionals full

Chia sẻ: Huy Hoang | Ngày: | Loại File: PDF | Số trang:47

0
54
lượt xem
8
download

Unix for Security Professionals full

Mô tả tài liệu
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

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.

Chủ đề:
Lưu

Nội dung Text: Unix for Security Professionals full

  1. 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
  2. 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
  3. Agenda (cont.) • Unix Processes • Networking • System Services • Unix Backups • Wrap-up Unix Security - SANS ©2001 3 This page intentionally left blank. 2-3
  4. 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
  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 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
  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 % 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
  7. 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
  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 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
  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 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
  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 …] 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
  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 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
  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 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
  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 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
Đồng bộ tài khoản