Tài liệu Unix for Security Professionals docx

Unix Security - SANS ©2001 5Covered In This Section • Unix terminal login system getty • cron for running scheduled jobs • Syslog , the system logging facility • Printing under Unix • Th

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/

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

Unix Security - SANS ©2001 3

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

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 attached terminals

serial-• 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

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

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

Unix Security - SANS ©2001 8

/etc/ttys

console "/usr/libexec/getty Pc" vt220 off securettyC0 "/usr/libexec/getty Pc" vt220 on securetty00 "/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 …]

to Execute Term Type Default Boot Time? Start at

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 gettyinvocations 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

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:

Unix Security - SANS ©2001 10

Anatomy of a Crontab Entry

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

Unix Security - SANS ©2001 11

Sample Crontab Entries

# Run backups nightly

/usr/sbin/rtc –c >/dev/null 2>&1

# Uncomment these lines to enable system accounting

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

Unix Security - SANS ©2001 12

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)

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 <user> option with any of these commands to manipulate the crontab file for any user on the system

Unix Security - SANS ©2001 13

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

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

Unix Security - SANS ©2001 14

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

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

Unix Security - SANS ©2001 15

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

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.

Unix Security - SANS ©2001 16

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

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 usermessages 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 (loginand 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)

Unix Security - SANS ©2001 17

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

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

Unix Security - SANS ©2001 18

/etc/syslog.conf

*.err;user.none /dev/console

kern.notice;auth.notice /dev/console

*.err;user.none /var/adm/messageskern.debug;daemon.notice;mail.crit /var/adm/messages

*.alert;kern.err;daemon.err;user.none operator

mail.debug ifdef(`LOGHOST',/var/log/syslog,@loghost)

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 <facility>.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,

Unix Security - SANS ©2001 19

Alternate syslog.conf Idea

kern.* /var/log/kernkern.* @loghost

auth.* /var/log/authauth.* @loghost

mail.* /var/log/mailmail.* @loghost

daemon.* /var/log/daemondaemon.* @loghost

[… continue pattern for other facilities …]

The "*" wildcard can also be used for priority codes Some sites choose a simpler syslog.confscheme 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)

Unix Security - SANS ©2001 20

Other syslogd Notes

• kill –HUP running syslogd after

modifying syslog.conf file

• syslogd will not create new files–

create empty files before restarting

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 <filename> or cp /dev/null <filename>) before restarting syslogd

Unix Security - SANS ©2001 21

Security Issues With Syslog

• Denial of service:

– Anybody can spam your Syslog port – Overwhelm daemon, fill up logging area – Block access to 514/udp

• Buffer overflows:

– Potential remote root compromise – Can be triggered via other apps and without direct system access by attacker

As we mentioned earlier, one of the biggest problems with Syslog is that it will accept messages over the network from any host that's able to reach the Syslog port (514/udp) on your system This means that an attacker can blast messages at your Syslog daemon non-stop until either the daemon is overwhelmed and can't log any other messages or the partition where the logging is happening fills

up (or both) Make sure that your network firewalls block outside access to 514/udp and see if your vendor provides an option to syslogd so that it doesn't listen on 514/udp for messages

syslogd has also had a history of buffer overflow problems One fact that makes Syslog buffer overflow issues so nasty is that an attacker need not have direct network access to the system whose Syslog daemon is being compromised For example, Sendmail logs huge amounts of data via Syslog An attacker can construct an email message, send it to an internal mail server inside of your firewall, and trigger a buffer overflow in Syslog via the message logged by Sendmail about the attacker's message!