5 - 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/ 5 - 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. 5 - 3 Unix Security - SANS ©2001 3 Agenda (cont.) • Unix Processes •Networking • System Services •Unix Backups •Wrap-up This page intentionally left blank. 5 - 4 Unix Security - SANS ©2001 4 System Services In this section, we discuss configuration and security issues relating to some of the more common Unix system services. 5 - 5 Unix Security - SANS ©2001 5 Covered In This Section • Unix terminal login system (getty) • cron for running scheduled jobs • Syslog , the system logging facility • Printing under Unix • The standard Unix routing daemons • inetd and related daemons In this section, we will be looking at six major subsystems: •the getty program, which provides the Unix login prompt on the system console and serial- attached terminals •the cron daemon, which runs programs for users at pre-arranged times of the day/week • the Unix Syslog system for collecting and processing system logging information • a brief introduction to the Unix printing system • coverage of the three most common daemons for managing dynamic routing information on Unix systems • inetd and the important network daemons it is responsible for starting 5 - 6 Unix Security - SANS ©2001 6 Covered Elsewhere • NTP for system clock synchronization • RPC-based services , including NFS and NIS • SSH for secure, encrypted logins •The Apache Web server • The Internet Domain Name Service ( DNS ) • Sendmail , the default Unix mail server Note that we are intentionally leaving out certain systems because they are too complicated to be appropriately handled in the time permitted. These services are covered in detail in courses from the SANS Unix Security curriculum: • NTP, Apache, DNS, and Sendmail are all covered in the Running Unix Applications Securely course (day four of the curriculum). • Topics in Unix Security (day three) spends half a day talking about SSH. • RPC-based applications (including NFS and NIS) and vulnerabilities are covered in more detail in the Common Unix Vulnerabilities class (day one). For more information regarding specific security issues with many of these services (along with recommendations for mitigating many of these problems), check out the SANS "Top 20 Vulnerabilities" document (available from http://www.sans.org/top20.htm). More information about NTP setup and configuration is available at http://www.deer-run.com/~hal/ns2000/ntp2.pdf 5 - 7 Unix Security - SANS ©2001 7 Unix Terminal Login Process 1. The getty daemon displays login: prompt and waits for input 2. On input, getty spawns login to get and verify user's password 3. The login program displays /etc/motd and starts user's shell 4. User's shell reads configuration files and displays command prompt On most Unix systems, one or more getty processes are spawned by init at boot time. Each getty process is associated with one of the serial TTYs connected to the system, and one is usually started for the console device as well (unless the console displays an X Windows based login display). When the getty program starts, it displays a login: prompt on the serial device it's attached to and then waits for user input on the line. When a user types in a username, the getty program gives up control of the TTY to the Unix login program. The getty passes the login program the username entered by the user as a command line argument. The login program then prompts the user for their password, making sure to manipulate the TTY so that the user's password isn't displayed. The login program verifies the password that the user typed in against the password stored in /etc/shadow. Assuming the passwords match, the login program displays the contents of the /etc/motd file (message of the day– it's a good idea to put some sort of legal disclaimer in this file to warn away potential system abusers) and then starts up the shell listed for the user in /etc/passwd. The shell reads the user's start-up files in their home directory (and possibly some system start-up files as well) and then the user gets the shell command prompt and is ready to start typing commands. It should be noted that (for reasons known only to developers at Sun) Solaris seems to have gratuitously decided to use a completely different mechanism for TTY-based logins. 5 - 8 Unix Security - SANS ©2001 8 /etc/ttys console "/usr/libexec/getty Pc" vt220 off secure ttyC0 "/usr/libexec/getty Pc" vt220 on secure tty00 "/usr/libexec/getty std.9600" unknown off tty01 "/usr/libexec/getty std.9600" unknown off ttyp0 none network ttyp1 none network ttyp2 none network [… many more lines deleted …] Device Command to Execute Default Term Type Start at Boot Time? Root Login Allowed init generally reads a file called /etc/ttys (sometimes /etc/ttytab) to know which serial lines to spawn getty processes on. getty processes should only be run on TTYs where you wish to allow user logins. Most Unix machines have one or more serial ports and gettys are usually started on these ports by default, but unless you have a legitimate need to connect a terminal, modem, or other login device to these lines, you should disable the getty invocations. No reason to provide more ways for an attacker to break into your system than you need to. Generally, there are five columns in an /etc/ttys file: first is the TTY device, followed by the getty command line to be run when spawning a daemon on this device, the type of terminal attached to the device, "on" or "off" indicating whether a getty should be started for this device at all, and the remainder of the line is additional options. In particular the "secure" option tells the system whether or not to allow somebody to log in directly as root on the given device. The only place you should allow root logins is on the system console! The first part of /etc/ttys usually lists the console device(s) on the system. Many Unix systems have a special /dev/console device, but this machine doesn't. Instead it's console is a special TTY called /dev/ttyC0. After the console devices, you will usually see listings for the physical serial ports on the machine. If you are not planning to connect a terminal or modem to the system's serial ports, then the getty on these ports should be set to "off" in order to stop normal users from connecting a modem to the machine as a back door. After the physical devices, you will see entries for the network "pseudo-TTYs.“ These pseudo TTYs do not normally run getty processes, being reserved for the use of programs like telnet, rlogin, etc. which either invoke login themselves (telnetd) or have their own built-in login routine (rlogin). 5 - 9 Unix Security - SANS ©2001 9 cron • cron daemon started at boot time • Consults per-user config files ( crontabs ) for job scheduling information • Jobs run with privileges of given user (careful with root cron jobs!) •Modern cron daemons can handle even fairly large time jumps The cron daemon is started at boot time and exists to run programs at certain specified times of the day/week/month. The programs to be run are listed in special per-user cron tables (crontabs for short). Common places to find crontab files are /var/cron/tabs or /var/spool/cron/crontabs. If there are jobs to be run for a given user, that user will have a file in this directory (the name of the file is the username). On startup, most modern cron daemons will read and parse all of the crontab files in its directory and then go to sleep for some interval. Some cron daemons wake up periodically regardless of whether or not there is a job to be run, others sleep until it's time to start the next scheduled job. In any event, if the cron daemon wakes up and realizes that the system clock has been reset substantially (e.g., for daylight savings time) it will attempt to do the "right thing" and either run jobs that were skipped (if the clock was jumped forward) or not-rerun jobs that have already happened (if the clock was jumped back). It is important to remember that cron runs each process with the privilege level of the user who scheduled the job. It is very common for the superuser to run automatic processes throughout the day (cleaning up disk space, rotating log files, cleaning queues, etc.) and often these processes are actually shell scripts written by the system administrator. The administrator must take care that no normal users can modify these files or else those users would be able to plant malicious code into the shell script which would give them root access or perhaps damage the system. For example, the attacker could add the following lines to a shell script: cp /usr/bin/sh /tmp/sh chmod 4555 /tmp/sh This code creates a set-UID copy of the shell in the /tmp directory. The attacker can then execute this shell and inherit the privileges of the user who runs the altered cron job (the attacker is obviously hoping this is the root account). The general rule is that programs and scripts being executed out of cron should either be owned by the user that the program is running as or by the root user. 5 - 10 Unix Security - SANS ©2001 10 Anatomy of a Crontab Entry 54**6 /usr/lib/newsyslog Minute Hour Day of Month Month Day of Week Command A crontab file is made up of individual lines– one line for each scheduled process. Comment lines are allowed (any line beginning with "#") and so it is possible to temporarily "comment out" cron jobs that are running amuck in some fashion. The first five columns of the crontab file say when the job is to be run: the minute (0-59), the hour (0-23), day of the month (1-31), month of the year (1-12), and the day of the week (0-7 with Sunday being either 0 or 7). The "*" character is a wildcard which matches any value for the particular column. Thus "30 * * * *" would run the given job at half past every hour, "45 23 * * *" would run the job at 11:45pm every day, etc. Our example above runs the given process at 4:05am every Saturday morning. Note that any field may contain a comma-separated list of values, so "0,15,30,45 * * * *" runs a job every fifteen minutes all day and every day. The remainder of the line is devoted to the command (along with any command line arguments) that cron should run. Note that cron runs all of its commands via the Bourne shell (/usr/bin/sh) so the command line syntax has to be appropriate for this shell (some examples on the next slide). [...]... under SYSV, lpr for BSD) 2 Printer daemon (lpsched for SYSV, lpd for BSD) manages queues 3 Print jobs may be run through one or more filters before printing 4 With luck, job eventually ends up on a nearby printer Unix Security - SANS ©2001 23 By all accounts, printing under Unix is one of the biggest horrors perpetrated in the history of modern computing Having to configure printing on a Unix system is... /var/log/mail @loghost daemon.* daemon.* /var/log/daemon @loghost [… continue pattern for other facilities …] Unix Security - SANS ©2001 19 The "*" wildcard can also be used for priority codes Some sites choose a simpler syslog.conf scheme where they simply log all messages for a given facility to a separate file under /var/log For extra credit, you can also log these messages to a central server (after a... often runs as privileged user and isn't careful about queue dirs • Typical security problems have included: – Overwrite any file on the system – Print any file (e.g., /etc/shadow) – Execute arbitrary commands with privilege Unix Security - SANS ©2001 24 The bad news is that the Unix printing facility has had tons of security problems For example, if a file is too large to be copied into the queue directory,... incinerator on a regular basis 5 - 25 Unix Routing • By default, many Unix systems start up a dynamic routing daemon • Routing daemon modifies route table based on info received via network • Route updates are usually accepted without authentication or verification • Dynamic routing is a security problem waiting to happen Unix Security - SANS ©2001 26 At boot time, a Unix machine will start up one of several... Simpler for hosts and less network intensive than RIP • Modern BSD machines implement IRDP as an option in routed Unix Security - SANS ©2001 28 A slightly more modern routing protocol is IRDP (Internet Router Discovery Protocol), usually implemented on Unix systems in rdiscd (some Unix systems implement both RIP and IRDP in routed) Under IRDP, routers advertise themselves as a default router for local... keeps track of failed logins– query with lastb • Admin may also choose to enable: – System accounting – Process accounting – Kernel-level auditing Unix Security - SANS ©2001 22 Unix systems generally log other information via channels other than Syslog For example, the login program logs all system logins into the utmp and wtmp files on your system (these files are usually located in /var/log or /var/adm)... with any of these commands to manipulate the crontab file for any user on the system 5 - 12 Restricting crontab Access • cron.allow and cron.deny control who may use the crontab command • Semantics are a little strange– stick with cron.allow for "default deny" • Even if user cannot use crontab, system will still run jobs for that user Unix Security - SANS ©2001 13 The cron.allow and cron.deny files... want to allow your users to set up at jobs for one-time processes) Note that on most modern Unix systems, at jobs are run by the cron daemon 5 - 14 Syslog • syslogd runs as a daemon and accepts messages from local programs • syslogd also listens on port 514/udp for messages from other machines • Final destination of messages is controlled in /etc/syslog.conf Unix Security - SANS ©2001 15 The Syslog daemon... cron, which has its own cron facility auth is used by programs that are part of the Unix authentication system (login and su for example) These messages are very important but many Unix systems (Solaris for example) aren't configured to capture these messages by default The local0, …, local7 facilities are reserved for use by programs written locally at a given site (just as an FYI, by default Cisco... disable dynamic routing daemons on your Unix machines 5 - 26 routed • routed implements RIP (v1) routing • Route updates are broadcast to all machines on LAN (on port 520/udp) • RIP is very "chatty" and performance is poor on large networks • If you must run routed, make sure you use the –q option Unix Security - SANS ©2001 27 The most common dynamic routing daemon on Unix systems is routed, which implements . 5 - 1 Unix Security - SANS ©2001 1 Unix for Security Professionals Security Essentials The SANS Institute All material. http://www.deer-run.com/ 5 - 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