2 - 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/ 2 - 2 Unix Security - SANS ©2001 2 Agenda • A Brief History of Unix • Booting Unix • The Unix File System • Manipulating Files and Directories • Unix Privileges This page intentionally left blank. 2 - 3 Unix Security - SANS ©2001 3 Agenda (cont.) • Unix Processes •Networking • System Services •Unix Backups •Wrap-up This page intentionally left blank. 2 - 4 Unix Security - SANS ©2001 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. 2 - 5 Unix Security - SANS ©2001 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. 2 - 6 Unix Security - SANS ©2001 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* 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 - 7 Unix Security - SANS ©2001 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 Perhaps more evil is embedding non-printing characters in file names. In particular, the backspace sequence (<control>-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 - 8 Unix Security - SANS ©2001 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. 2 - 9 Unix Security - SANS ©2001 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. 2 - 10 Unix Security - SANS ©2001 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. [...]... Turn off execute bit for everyone: chmod a-x myfile Unix Security - SANS ©2001 21 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... File Type Permissions File Name Size (bytes) Last Modified 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)... Owner x Write Permission r - Read Permission Everyone Else x r - x Execute 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")... 1 1 1 0 1 1 0 1 7 5 Unix Security - SANS ©2001 5 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... 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... BSD-derived Unix systems generally only allow chown to be run by the Unix administrative user 2 - 22 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 Unix Security - SANS ©2001 23 Most executable files on a Unix. .. Directories • Directories are just special files • Each directory entry lists: – File name and type of file – Pointer to inode for the given file • Directories searched sequentially – poor performance on large directories Unix Security - SANS ©2001 27 One of the design goals for Unix is to as much as possible treat everything like a file, so directories are just a special type of file in the file system... Unix Security - SANS ©2001 30 Deleting a file under Unix doesn't necessarily mean that the data in that file is gone forever The inode and data blocks that made up the deleted file are merely put back on a list of available blocks for use by other files that may be created in the future Until the blocks are re-used, however, the data can still be read out of the "raw" file system interface in the Unix. .. -> foo Unix Security - SANS ©2001 32 Here we create a file called foo and then a hard link to the file called bar and a symlink called baz The command for making links is ln (-s for symlinks)– you list the "real" file first and then the link name Notice when we do an ls –l on these files, the link count for bar and foo is 2 (symlinks don't increment the link count) ls –i shows the inode numbers for each... 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 . 2 - 1 Unix Security - SANS ©2001 1 Unix for Security Professionals Security Essentials The SANS Institute All material. http://www.deer-run.com/ 2 - 2 Unix Security - SANS ©2001 2 Agenda • A Brief History of Unix • Booting Unix • The Unix File System • Manipulating Files and Directories • Unix Privileges This