Unix for Security Professionals

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

Thêm vào BST

Báo xấu

134
lượt xem 28
download

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

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)....

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Unix for Security Professionals

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/ 5-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. 5-2
Agenda (cont.) • Unix Processes • Networking • System Services • Unix Backups • Wrap-up Unix Security - SANS ©2001 3 This page intentionally left blank. 5-3
System Services Unix Security - SANS ©2001 4 In this section, we discuss configuration and security issues relating to some of the more common Unix system services. 5-4
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 Unix Security - SANS ©2001 5 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-5
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 Unix Security - SANS ©2001 6 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-6
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 Unix Security - SANS ©2001 7 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-7
/etc/ttys Device Command Default Start at to Execute Term Type Boot Time? 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 Root Login [… many more lines deleted …] Allowed Unix Security - SANS ©2001 8 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-8
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 Unix Security - SANS ©2001 9 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-9
Anatomy of a Crontab Entry Day of Day of Minute Month Week 5 4 * * 6 /usr/lib/newsyslog Hour Month Command Unix Security - SANS ©2001 10 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). 5 - 10
Sample Crontab Entries # Run backups nightly 0 3 * * * /usr/local/bin/do-backups.sh # Log rotation 0 2 * * 0,4 /etc/cron.d/logchecker 5 4 * * 6 /usr/lib/newsyslog # Adjust system clock 1 2 * * * [ -x /usr/sbin/rtc ] && \ /usr/sbin/rtc –c >/dev/null 2>&1 # Uncomment these lines to enable system accounting # 0 * * * 0-6 /usr/lib/sa/sa1 # 20,40 8-17 * * 1-5 /usr/lib/sa/sa1 Unix Security - SANS ©2001 11 • The first entry invokes a script at 3am every morning which apparently performs a system backup (it's a good idea to give scripts meaningful names and put good comments in your crontabs) • The next two entries deal with log files. The first entry is used to rotate cron's own log file (usually /var/cron/log) twice per week (Sunday and Thursday)– note that cron logging is not usually enabled by default (the logs get too large too quickly) so man cron to find out how to turn on logging for your system. The second entry is used to rotate the standard Unix /var/log/syslog file once per week. Incidentally, the newsyslog script is a good model for your own log rotating scripts. • The next cron entry is used to adjust the system's hardware clock to be in line with the software clock kept in the kernel (this is necessary on some Unix systems (Solaris) running on Intel hardware). Note the Bourne shell syntax for both the test portion of the command line ([ - x /usr/sbin/rtc ] – does the rtc program exist and is it executable) and the output redirection (>/dev/null 2>&1 – send the output of the command to /dev/null and send the error output of the command to the same place as the normal output). • Finally we see some inactive entries which are used for gathering system stats. These entries are interesting because they are written to work together in a peculiar way. Regardless of the day of the week or the time, we want to gather system stats every hour. However, during working hours (8am-5pm, M-F) we want to gather data every 20 minutes. Well the first line gathers the data at the top of the hour, so the "weekday" line only needs to gather the additional data on the 20 and 40 minute marks. 5 - 11
Manipulating Crontabs • DO NOT edit crontab files directly because changes will not be picked up • Instead use crontab command: crontab –l (show contents of user's crontab) crontab –r (remove crontab for user) crontab –e (fire up EDITOR to modify crontab) Unix Security - SANS ©2001 12 It is important that you never edit the crontab files in the cron directory. On many Unix systems, the crontabs are only read at boot time. Furthermore, any changes you make by hand may end up being overwritten by other administrators using the "correct" mechanisms for manipulating crontabs. The right way to modify a crontab is with the crontab command. crontab –l merely displays the crontab for the current user and crontab –r removes the entire crontab for the current user. Most useful is the crontab –e command which runs an editor on the current crontab file for the user (the editor which should be run is specified by the EDITOR environment variable). Once the user exits the editor, the new crontab file is syntax checked and (if valid) is installed as the user's new crontab. Note that the superuser may use the –u option 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 (usually in /var/cron on BSD systems and /etc/cron.d on SYSV, man crontab for the exact locations on your system) specify which users are and are not allowed to run the crontab command. Note that they don't specify which users are allowed to run cron jobs– the administrator could still set up cron jobs to run as these users, even if the user was prevented from running the crontab command themselves. The semantics of cron.allow and cron.deny are a little confusing. If the cron.allow file exists, then only users who are listed in that file are allowed to use the crontab command (regardless of any settings in cron.deny). If cron.allow doesn't exist, then users who are listed in cron.deny are not allowed to use the crontab command, but all other users can use the command. Probably the most straightforward tactic is to simply list allowed users in cron.allow and forget about cron.deny. Note that on many systems, the only user listed in cron.allow should be root. There usually isn't much reason for normal users to be running cron jobs. 5 - 13
The at Command • at allows users to run a single command at some point in the future • at.allow and at.deny files allow the administrator to restrict user access • at jobs usually run by the cron daemon Unix Security - SANS ©2001 14 The at command allows a user to schedule a command to be run just once at some time in the future. Jobs can be scheduled by time of day, day of week, etc. but also according to other parameters such as "run this job when the system load drops below a certain threshold I specify" (the batch command on many Unix systems is just an alias for the at command to run jobs when the system is idle). at uses at.allow and at.deny files in the same fashion as cron to determine which users are allowed to schedule at jobs (you may 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 (syslogd) is started at boot time and usually creates two different communications channels. For messages within the system, syslogd reads from a special device called /dev/log (which is technically an object called a Unix domain socket rather than a normal kernel device). syslogd also listens on port 514/udp for messages from other systems. In addition to receiving messages from other machines, syslogd is capable of sending its own messages to other systems (and even forwarding messages from one system to another). It should be noted, however, that syslogd will happily accept messages from any source without any sort of authentication, so one denial of service attack is to fill up a system's logging partition with bogus messages. This can help an attacker hide their real activity from the administrator. Be sure that your corporate firewall blocks external connections on 514/udp. Note that the freely available syslogNG tool (see www.balabit.hu/products/syslog-ng/) allows IP-based access control and TCP-based communications (which can be a big win in certain firewall environments that do not allow UDP to traverse the firewall) The file /etc/syslog.conf tells the Syslog daemon what to do with various messages. Messages are identified by a facility and a priority as we will see in the next several slides. 5 - 15
Message Facilities • kern – kernel errors • user – messages from user processes • mail – messages from mail servers • cron – messages from cron/at jobs • daemon – other system daemons • auth – authentication warnings • local[0-7] – other services as needed Unix Security - SANS ©2001 16 Syslog defines several different message facilities. The most common ones are listed here, but other facility names are defined as well (man syslog.conf for more information). A given process defines what facility it will use when it opens up communications with syslogd (i.e., the facility that the program uses is entirely up to the programmer), but certain conventions do exist. The kern facility is used for messages from the system kernel. These messages are often important. Older mail servers used to use the user facility, but now tend to use the mail facility. Most user messages can be ignored but messages sent to the mail facility should be captured for debugging. The daemon facility is used by other system daemons (named, NTP, etc.) except for 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 routers with Syslog logging enabled will log on the local7 facility). 5 - 16
Message Priorities • emerg – system is unusable • alert – take action immediately • crit – critical condition • err – general error condition • warn – system warnings • notice – normal but significant condition • info – "FYI" or informational messages • debug – debugging output Unix Security - SANS ©2001 17 There are eight defined Syslog priority levels, defined here in descending order. Unfortunately, strong conventions have not been established as far as what constitutes an "emergency" versus say a "critical condition", so the above descriptions are at best suggestions. Not every programmer follows these guidelines religiously. emerg, err, notice, and info are probably the most commonly used priorities. 5 - 17
/etc/syslog.conf *.err;user.none /dev/console kern.notice;auth.notice /dev/console *.err;user.none /var/adm/messages kern.debug;daemon.notice;mail.crit /var/adm/messages *.alert;kern.err;daemon.err;user.none operator *.alert;user.none root *.emerg;user.none * mail.debug ifdef(`LOGHOST',/var/log/syslog,@loghost) Unix Security - SANS ©2001 18 The syslog.conf file is written in two columns: the first column is a semi-colon delimited list of facilty/priority combinations and the second column is where messages which match those parameters should be sent. Two critical reminders: 1. It is absolutely imperative that the whitespace between the two columns is made up of tab characters only. If not, then the file will not be parsed correctly and no logging at all may be done. 2. Syslog logs all messages for the given facility at the listed priority and higher. If you specify auth.info, for example, then all auth messages of info priority and above will be logged to the location you specify. Facilities may be specified with a wildcard ("*") and .none may be used to suppress messages from certain facilities when a wildcard is specified (notice in the example above, we use user.none with all wildcards because we don't care about messages sent to the user facility). Messages may be sent to a device (/dev/console for example to print the message on the system console, or perhaps a line printer attached to a TTY device), a file (/var/adm/messages), another machine (@loghost, but better to use an IP address which can't be spoofed), or a particular user if that user happens to be logged in at the time (root, operator, or all users "*"). Note that macros may be used (the macro language is m4, man m4 for more details) so you can write "if" statements as shown on the last line (which says if the variable LOGHOST is defined (meaning this machine is a central logging server) then deposit mail logs in /var/log/syslog, otherwise send them to the machine named loghost). 5 - 18
Alternate syslog.conf Idea kern.* /var/log/kern kern.* @loghost auth.* /var/log/auth auth.* @loghost mail.* /var/log/mail mail.* @loghost daemon.* /var/log/daemon 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 break-in, it is sometimes interesting to compare the logs on the cracked system with an externally maintained copy of the log files. The discrepancies can show you what the attacker was trying to hide). 5 - 19
Other syslogd Notes • kill –HUP running syslogd after modifying syslog.conf file • syslogd will not create new files– create empty files before restarting Unix Security - SANS ©2001 20 Note that when syslog.conf is modified for any reason, you must kill –HUP the syslogd process to get it to re-read its configuration file. You should also note that syslogd will not create new log files if they do not exist. It will simply not log your messages. Hence it is necessary to create an empty log file (touch or cp /dev/null ) before restarting syslogd. 5 - 20