Tài liệu Unix for Security Professionals docx

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 *
Deer Run Associates * PO Box 20370 * Oakland, CA 94620-0370
+1 510-339-7740 (voice) * +1 510-339-3941 (fax)
/>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 More
information about NTP setup and configuration is available at
/>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).
5 - 11
Unix Security - SANS
©2001
11
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
• 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 - 12
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.
5 - 13
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.
5 - 14
Unix Security - SANS
©2001
14
The at Command
•atallows 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
•atjobs 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.
5 - 15
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.
5 - 16
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 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 - 17
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.
5 - 18
Unix Security - SANS
©2001
18
/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)
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,
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 - 19
Unix Security - SANS
©2001
19
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 …]
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 - 20
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.
5 - 21
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!
5 - 22
Unix Security - SANS
©2001
22
Other Logging
• utmp and wtmp files keep track of
logins– query with the last command
• btmp (Linux) keeps track of failed
logins– query with lastb
• Admin may also choose to enable:
– System accounting
– Process accounting
– Kernel-level auditing
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). The administrator can get a list of all logins to the system using the last

command. Here's a sample:
% last
hal ttyp2 moose.deer-run.c Wed Dec 26 17:21 still logged in
laura ttyp2 rocky.deer-run.c Wed Dec 26 15:35 - 15:35 (00:00)
hal ftp moose.deer-run.c Wed Dec 26 12:14 - 12:14 (00:00)
laura ttyp3 rocky.deer-run.c Tue Dec 25 10:47 - 10:50 (00:03)
laura ttyp2 rocky.deer-run.c Tue Dec 25 10:21 - 10:50 (00:29)
laura ttyp2 wapiti.deer-run. Tue Dec 25 08:56 - 09:01 (00:05)
Notice that the system logs the login and logout times, as well as the source of the connection.
Linux systems also keep track of failed login attempts in the btmp file. The administrator uses lastb to look
at this file. Note that users sometimes get "out of sequence" and end up typing their password into the
username portion of the login. Since the btmp file stores the username that the user tried to log in with, this
means that the btmp file often ends up containing clear text passwords for some of your users. Obviously
useful to an attacker!
Unix systems also support other types of data collection mechanisms if the administrator chooses to enable
them. System accounting keeps track of performance-related metrics on an ongoing basis (CPU usage, disk
I/O, etc.). This is useful for creating a system baseline and can be used to detect unusual or malicious activity if
the system ever departs from that baseline. Process accounting logs information about every command that
runs on your system. It creates a heavy performance drag on the machine and should only be used sparingly–
like when you've caught somebody on your system and you want to see what they're doing. Kernel-level
auditing tracks every system call going through the kernel. This is a huge amount of data, but is invaluable
forensic material after a break-in.
5 - 23
Unix Security - SANS
©2001
23
Unix Printing
1. User submits jobs to printer queue
(with lp 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
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 enough to make even
experienced system administrators run screaming from the room. Historically, early SYSV machines
didn't even have support for network printing and various hacks have resulted (none worse than
Solaris).
In any event, the Unix printing model is fairly straightforward. Users submit print jobs using the lp
(SYSV) or lpr (BSD) commands (there are other commands for watching the print queue,
canceling jobs, etc.). Submitted jobs are stuffed in a queue directory. Periodically the system printer
daemon (lpsched under SYSV, lpd under BSD) looks in the queue directory and processes any
outstanding jobs. A print job may be run through a filter (such as a filter which converts text or
troff files to Postscript for printing on a Postscript printer) and then sent off to the printer– which
may be attached locally to a serial device or may be somewhere on the other side of the network.
Assuming the appropriate sacrifices have been made and the planets are in alignment, the user's print
job pops out on the correct printer.
5 - 24
Unix Security - SANS
©2001
24
History of Security Issues
• Printing system 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
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, then a symlink is made from
the queue directory to the actual file to be printed. One older attack is submitting a large print job
and then moving the large file out of the way and replacing it with a link to another file. An attacker
can often cause the print system to print out any file at all (like /etc/shadow) because the printing
system used to run with superuser privilege! These days, an attacker could use a similar attack to
print out any file owned by the special "lp" user that the print system typically runs as– potentially
allowing the attacker to print anything going through the system's print queues including sensitive
documents being printed by other users.
Print filters might allow an attacker to run arbitrary commands as whatever user the print system is
running as unless the printer daemon is careful about where it gets its filter programs from
(nowadays print filters are generally stored in a single directory that only the superuser has access
to).
The list goes on and on. The BUGTRAQ mailing list archives at www.securityfocus.com
have plenty of details and exploit code.
5 - 25
Unix Security - SANS
©2001
25
Printing Recommendations
• Don't allow users near print queues:
– Deploy dedicated print server machines
– Limit machine access to admins only
• Try using lprNG:
/>• Make secure document shredding bins
are widely available at your site
Much of the mischief that results from the Unix printing system is caused by users having access to
the system where the print jobs are spooled pending being formatted and sent to the printer. In order

to narrow the window of vulnerability, one good tactic is to create dedicated print servers (cheap PCs
running Linux are fine) with strict access controls. All other machines send their jobs over the
network to these servers. While there is still a small window of vulnerability while jobs are waiting
to be sent over the network to the central print servers, at least the users won't be on the systems
where the filter commands are run.
lprNG is a portable printing system for Unix which has security as one of it's design goals. Aside
from being more secure, running lprNG means you can run the same printing system on both your
SYSV and BSD machines. This means you only have to learn to control one overly complicated
monstrosity, rather than two.
Lots of dangerous information leaves your company by way of its trash bins. Make sure you have
locked metal bins near all of your printers and copiers and get a reputable company to come and
empty these bins into their shredder and/or incinerator on a regular basis.