Tài liệu Unix for Security Professionals pptx

3 - 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)
/>3 - 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.
3 - 3
Unix Security - SANS
©2001
3
Agenda (cont.)
• Unix Processes
•Networking
• System Services

•Unix Backups
•Wrap-up
This page intentionally left blank.
3 - 4
Unix Security - SANS
©2001
4
Unix Privileges
This section covers the Unix model for security and access control. Unix has historically had a
tendency towards simplicity and openness, which means that its security model doesn't easily lend
itself to high-security environments. Much work has been done in the last decade to develop Unix-
like operating systems with stronger and more complex security models (for an example, consider
Sun's "Trusted Solaris" product).
3 - 5
Unix Security - SANS
©2001
5
Usernames and Passwords
• Every user has an assigned username
and password
• Usernames and passwords are case-
sensitive
• Passwords are silently truncated at
eight characters
• Usernames generally limited to eight
characters for backwards compatibility
Every user on the system has an identity assigned to them in the form of a unique username, and
associated with each username is a password that the user must enter in order to be able to log into
the system.
Usernames are case-sensitive, so "Hal" and "hal" are different user names. However, most Unix

installations use all lower-case usernames by convention. Unix passwords are also case-sensitive
(one of the most common user errors is attempting to type one's password while the caps-lock key is
on). Note that the Unix password routines generally silently truncate passwords at eight characters,
so even if you enter a password like "this is a really long password", your password
will be "this is " ("this is"-space) as far as the system is concerned. Similarly, older Unix
systems assumed that usernames would be eight characters or less (certain programs died horribly
upon encountering longer user names) and many sites run with usernames of eight characters or less
just to be on the safe side.
Usernames can contain any alphanumeric characters; passwords generally allow at least any
printable character, with some Unix systems allowing non-printable control sequences in passwords
as well.
3 - 6
Unix Security - SANS
©2001
6
An /etc/passwd Entry
hal:*:100:20:Hal Pomeranz:/home/hal:/bin/csh
Username
Password Field
(not used)
User ID
Group ID
Full Name
User Home
Directory
User's
Shell
We've already seen a couple of entries from the user database in /etc/passwd earlier in the course, but
let's examine one in more detail.
The first field is the username field.

The second field is used to contain the encrypted password for the user. However, putting encrypted
passwords in a world-readable file like /etc/passwd allows attackers to crack your passwords and
impersonate other users. Most Unix systems now keep encrypted passwords in a protected file called
/etc/shadow (sometimes other names are used).
The next two fields are the user's numeric user ID (UID) and group ID (GID)– more on these a little bit
later in this section.
The fifth field is the full-name field (sometimes called the GECOS field because the early Unix machines
at Bell Labs used this field to store information needed to submit batch jobs to a mainframe running the
GECOS operating system).
Field six is the path to the user's home directory and field seven is the user's default login shell. A list of
valid login shells is normally kept in the file /etc/shells–if /etc/shells doesn't exist then the
system defaults to the "standard" shells provided with the OS (sh, csh, ksh, et al). The moral of this
story is, if you add a shell like tcsh or bash to your Unix machine, you'd better create an
/etc/shells file and add the new shell plus all of the standard system shells.
3 - 7
Unix Security - SANS
©2001
7
An /etc/shadow Entry
hal:papAq5PwY/QQM:10588::::::
Username
Encrypted
Password
Other
Administrative
Fields
Here's a sample /etc/shadow entry from a Solaris machine. The format of this file on other
operating systems may vary wildly.
First we have a username field to tie this entry back to the user's entry in /etc/passwd. Next we
see the user's encrypted password. On Solaris machines, the password field is followed by several

other fields which control password expiration, etc. We won't concern ourselves with the exact use
of these fields because they are so OS-dependent.
Generally the /etc/shadow file (or whatever file contains the encrypted passwords on your
system) is readable only by the administrative user. This works out fine because the processes which
log users into the system run with administrative privileges and user commands like passwd (for
changing passwords) have the set-UID bit set. Again, if your encrypted password strings are
readable by anybody on the system, then they will be stolen and cracked offline.
3 - 8
Unix Security - SANS
©2001
8
"Blocking" Accounts
• Standard encrypted password strings
are 13 characters long
• Editing /etc/shadow and using an
invalid password string to block logins
• Can also set an invalid shell in
/etc/passwd for additional protection
•
Never
use an empty password string in
/etc/shadow!
The standard Unix password encryption algorithm creates a string which is always 13 characters
long, and made up of the set of alphanumeric characters plus "." and "/". When the administrator
wishes to block logins to a particular account, they simply edit /etc/shadow and change that
user's encrypted password string to anything which doesn't meet those criteria. Standard choices are
strings like "=NP=" or "*BLOCKED*" or sometimes just "*", though the longer strings are easier to
pick out in a large password database.
Never under any circumstances use an empty field in the /etc/shadow file, however. An empty
field means that user is allowed to log in without providing any password at all!

In addition, the administrator sometimes chooses to set the user's shell (in the last field of
/etc/passwd) to an invalid or non-existent executable like /bin/false or /nosuchshell.
This adds an extra layer of security and can also tell the administrator if the account is supposed to be
blocked just by looking at the /etc/passwd file (rather than having to look at /etc/shadow
with administrative privileges). Of course, an attacker with administrative privileges on the system
might replace this "invalid" shell binary with an actual copy of a valid shell executable– for this
reason, many administrators like to use /dev/null here because if /dev/null is replaced by a
copy of a shell executable then the system stops working properly and the administrator is alerted to
the change.
3 - 9
Unix Security - SANS
©2001
9
Usernames vs. User IDs
• Usernames are purely for the
convenience of human beings
• Unix systems store ownership info in
terms of User IDs (UIDs)
• Commands like chown will accept either
usernames or UIDs
As far as the Unix operating system is concerned, the UID entry in the passwd file is what's
important, not the username. Usernames are essentially only for the convenience of the human
beings who use the system– all data about file ownerships, etc. is stored internally by UID. The
passwd file is used by the system to relate UIDs to usernames– if a user's entry is deleted from the
passwd file, the ls command displays the numeric UID on files that were owned by that user. The
chown command accepts either usernames or UIDs as arguments.
Note that UIDs on most Unix systems are two byte (16 bit) quantities, so there is a maximum of
65,535 users on a Unix system. Fortunately or unfortunately, we've reached a point now where large
Unix installations are having to deal with total user populations of over 65,000 users– in these cases
not all users can have accounts in the same UID space. It's difficult to imagine going to longer UIDs

because of all of the Unix machines already in the field with 16 bit UIDs– how do you maintain
backwards compatibility?
3 - 10
Unix Security - SANS
©2001
10
UIDs and Networked File Systems
• John has UID 100 on his machine
• Mary has UID 100 on her machine
• Administrator mounts John's home
directory on Mary's machine via network
• Mary can read all of John's files!
Moral: If you're using NFS, make sure you
ensure unique UIDs!
Care must be taken not to overlap UIDs in the same company because Unix access controls are based
on UIDs and not usernames. This is even more important on modern Unix machines running NFS or
other file sharing protocols. If two users share the same UID and can cross-mount each other's home
directories, then they can access each other's files!
Now let's reflect on the lives of user's at companies where there are more than 65,535 users. The
administrators at this site had better make sure that they divide the users up into small self-contained
groups that don't need to share files with the other groups or chaos will set in fairly quickly.
3 - 11
Unix Security - SANS
©2001
11
The Superuser
• Unix systems have an "all or nothing"
security model
• Superuser access provides ability to
control all files, processes, and devices

• By convention, the superuser account is
named root
The Unix security model basically has two classes of people: normal users who can pretty much only
mess with their own files, and a single all-powerful "superuser" (administrator) who can do anything
to any object on the system. The superuser can read any file, change the permissions and ownership
on any file, delete any file, change user passwords at will, add and remove devices, etc. The goal of
an attacker trying to break into a Unix system is to get superuser access because then they "own" the
system.
From the early days of Unix, the primary superuser account has been the root user (think
"Administrator" under Windows). Unix folks use "root" and "superuser" interchangeably.
3 - 12
Unix Security - SANS
©2001
12
UIDs and the Superuser
•
Any
account with UID 0 has superuser
privileges
• Other UID 0 accounts may exist besides
the root account – usually locked
• Attackers often try to create new UID 0
accounts to get root access
However, the superuser account could just as easily be called "mack" or "buddy"– as far as the
Unix operating system is concerned, any account with UID 0 has superuser privileges. The author
has actually seen sites where many users had UID 0 accounts in the /etc/passwd file– this is a
terrible idea since it ruins any chance of auditability you might have had. Plus any one of those
accounts might have an easily guessable password that will allow some outside attacker unlimited
access to your system.
Now some Unix operating systems include a few UID 0 accounts besides root for special purposes.

Generally these accounts will either run some special shell which performs a certain task, or will
have an invalid password field so that no user may log in under these accounts. A favorite tactic of
attackers is to put live passwords or valid shells on UID 0 accounts that are normally locked– audit
your extra UID 0 accounts on a regular basis or remove them from the system entirely if you don't
need them.
Another ploy on systems with large password files is to add accounts with UID 0 in the middle of the
password file someplace. Administrators may not notice the new account. Remember the sort
command which prints the password file in ascending order by UID? This is why that's an important
command to know.
3 - 13
Unix Security - SANS
©2001
13
Becoming Superuser
•Log in as root
– Bad! No accountability
•Use /usr/bin/su command
– Better audit trail
• Limited access with sudo
– Excellent audit trail and fine-grained controls
Generally, there are three legitimate ways of getting superuser access on a Unix system ("going
root" in the lingo).
The first mechanism is to log into the system as root with the root password. This is generally
thought to be a bad idea since you have no idea who is using the root password– if the system
crashes right after somebody logs in as root, who do you track down to find out what happened?
It is occasionally necessary to log in as root on the system console when the system becomes
really wedged, but this should be the only place where root logins are allowed. In particular,
never allow root logins over the network– particularly over insecure protocols like telnet or
rlogin where an attacker with a password sniffer can grab the root password.
The /usr/bin/su command allows a normal user to become any other user on the system, as

long as they know the other user's password. su is most commonly used to become root,
however. Every time a user successfully changes their UID with su, a line of logging info gets
put in the system logs– this way you can find out who did what in the case of system problems.
Always type the full pathname of the su program to avoid getting trapped by Trojan horse su
programs designed to capture the root password.
The sudo tool ( allows a user to run a single
command with root privilege as long as they are listed in the /etc/sudoers file. sudo
prompts the user for their own password, rather than the root password– at many sites which use
sudo most of the user's and administrators don't even know the root password for the systems
they work on! sudo produces copious logging and allows extremely fine-grained access control.
Use it.
3 - 14
Unix Security - SANS
©2001
14
Groups
• Users are assigned to a default group
according to their /etc/passwd entry
• Users may also belong to other groups
as defined in /etc/group
• groups command tells you which
groups you are currently a member of
• Some groups have special privileges
We've seen previously that Unix files have both an owner and a group owner. Unix groups allow
sets of users to share files among themselves but not necessarily give access to other users on the
system. Unfortunately, most sites don't make proper use of Unix groups (again the Unix model has
been towards openness and groups are thought to be "snobbish").
Each user belongs to at least one group– the group defined in their /etc/password entry. A user
may belong to other groups as well– more on this on the next slide. To find out which groups you
belong to at a given moment, simply run the command groups with no arguments and a list of your

group memberships will be printed.
Certain groups have special privileges. On some Unix systems the operator group is allowed to
run the privileged commands which backup and restore files. On BSD systems, members of the
wheel group (the "big wheels" on the system) are the only people on the system allowed to use the
su command to become root (if the wheel group has no members, then any user may su to root as
long as they know the root password).
3 - 15
Unix Security - SANS
©2001
15
An /etc/group Entry
wheel:*:0:root,hal
Group
Name
Password
(rarely used)
Group ID
(GID)
Group
Members
Like the passwd file, the /etc/group file is used primarily to relate human-readable group
names to group IDs (GIDs) for use by the operating system. Note that there is a password field in the
/etc/group file but it is almost never used in practice (older Unix systems allowed users to "log
in" to certain groups once they had accessed the system).
The last field of the group entry is a comma-separated list of users who are members of a given
group (this list may be empty). A single user may appear in the group lists for many different groups
in the /etc/group file. The groups command prints the user's default group from
/etc/passwd plus any other groups the user is listed in from /etc/group.
3 - 16
Unix Security - SANS

©2001
16
Group wheel for SYSV
# cd /usr/bin
# chgrp root su
# chmod o-x su
# ls -l su
s x 1 root root 15832 Mar 8 1998 su
Don't give up your root shell until
you've tested this one!
Let's review what we've learned about file permissions and the Unix security model by doing a cute
hack for SYSV machines. SYSV machines generally do not have the concept of a wheel group to
limit su access like BSD systems do. However, we can "fake it" in the following way.
First, choose a group that will be our "pseudo" wheel group, or create an entirely new group in
/etc/group for this purpose– update the group list with the users who you want to be able to su
before proceeding any farther. For our example, we'll use the root group (GID 0) which exists on
most modern SYSV machines.
The trick is to make sure that the su program's group owner is whatever group we've chosen and
then to simply turn off the execute bit for the "other" category on the su binary. The su program
can now only be executed by the root user (the owner of the binary) and members of group root!
Unfortunately, this means that "normal" users (those not in group root) can't even use the su
program to become some unprivileged user– this may not be a "feature" from your perspective.
3 - 17
Unix Security - SANS
©2001
17
Unix Processes
A process is a program running on a Unix system. As we mentioned earlier, even though a Unix
machine appears to be running many processes concurrently on the same CPU, the kernel's process
scheduler is actually time-slicing the processes onto the CPU so each one gets a small fraction of the

available computing power of the machine. The Unix process abstraction is a means of making these
executable images easier to manage for the underlying operating system.
3 - 18
Unix Security - SANS
©2001
18
BSD-style Process Listing
# ps aux
USER PID %CPU %MEM VSZ RSS
root 2791 0.0 0.3 264 200
TT STAT STARTED TIME COMMAND
p2 RN+ 11:10AM 0:00.01 ps -aux
Process
Owner
Process ID
(PID)
CPU
Utilization
Memory
Parameters
TTY
Status
Start
Time
Command
Info
Total
CPU Time
The ps command is used to get a list of the processes currently running on the system. Interestingly,
one of the few remaining differences between BSD-derived systems and SYSV machines (other than

the boot process we discussed earlier) is the output format of the ps command and the arguments it
accepts. On BSD machines, the "a" option means show processes for all users (rather than just your
own) and "x" means show system processes which are not tied to any particular user login session.
The "u" flag generates the detailed listing shown above (normally the output fits on a single line, but
it was too wide to fit on the slide).
The two most important columns are listed first– the owner of the process and the process ID (PID).
We'll see how these are used shortly. The next column shows current CPU utilization (the ps
command uses so little CPU that it doesn't register here). The next three columns indicate how much
memory the process is using (man ps for more details). The next column shows the terminal line or
network pseudo-terminal the process was started from (helpful when you want to stop the command
shell for one particular user on the system). The next column is the process status registers (again,
man ps for more info). Next we see the time the process was started and how much total CPU time
the process has consumed as of this listing. The last column shows the first 10 characters or so of the
command line that was executed (this is so the output fits into 80 characters– 132 column output
format can be obtained with ps auxw, and unlimited width output is ps auxww).
3 - 19
Unix Security - SANS
©2001
19
SYSV-style Process Listing
# ps –ef
UID PID PPID C STIME TTY TIME CMD
root 5397 5289 1 11:31:57 pts/5 0:00 ps -ef
Process
Owner
Process ID
(PID)
Parent
Process ID
Start

Time
TTY
Total
CPU Time
Command
Info
SYSV machines use ps –ef rather than ps aux (there is no way to force "extra-wide" command
output like ps auxww). Note that ps –ef does not display process memory data like ps aux–
on SYSV machines, ps –efl displays more detailed output (including memory information) but
can be hard to read.
Like the BSD output, the SYSV output lists the process owner and PID first. However, the SYSV
output also shows the process ID of the parent process which spawned this one. Often this is the
user's command shell but it can sometimes be some daemon process– for example the inetd
process spawns other network daemons like telnetd. You can use the parent process ID to
"backtrack" to the originator of a particular set of processes. The fourth column is legacy and not
used any longer. Next we see the process start time and controlling TTY as we did in the BSD
output, as well as the total CPU time consumed by the process. Lastly we see the first 80 characters
of the command line that was executed (again there's no "extra wide" option to see the whole
command).
3 - 20
Unix Security - SANS
©2001
20
Looking for Processes
• By user (BSD-style ps):
% ps auxww | grep hal
hal 25505 0.0 0.5 344 288 p0 Is 7Dec01 0:00.14 -csh (csh)
hal 31133 0.0 2.0 588 1312 p0 I+ 12:14PM 0:00.11 mutt
hal 31376 0.0 0.4 332 276 p2 Ss 5:21PM 0:00.06 -csh (csh)
hal 15934 0.0 0.4 288 220 p2 R+ 5:21PM 0:00.01 ps –auxww

hal 12458 0.0 0.7 144 468 p2 S+ 5:21PM 0:00.01 grep hal
• By process name (SYSV-style ps):
% ps -ef | grep inetd
root 140 1 0 Nov 24 ? 0:00 /usr/sbin/inetd -s
hal 23834 23796 0 17:21:27 pts/15 0:00 grep inetd
You often use the ps command in combination with the grep command which we talked about in
the last section. By combining the two commands it's easy to pick out specific processes– for
example all processes being run by (or as) a specific user, or to find a particular process by name.
3 - 21
Unix Security - SANS
©2001
21
kill! kill! kill!
•The kill command sends a signal to a
running process (by PID)
• Signal usually causes process to
terminate, but may have other effects
• Must be process owner or the superuser
to kill a process
• kill accepts either numeric or
symbolic signal names
The PID is used as an argument to the kill command. As you can tell by the name, the kill
command was designed to terminate processes abnormally. The Unix operating system does this by
sending a signal to the running process– most signals will cause processes to terminate, although the
application developer can choose to trap certain signals and either ignore them and continue
execution or take some other action (such as re-reading configuration files and/or re-opening new log
files as many network daemons do). Most Unix machines define 32 different signals which have
numeric values from 0-32 but which also have human readable names– kill can take either signal
numbers or names as an argument.
The superuser may kill any process. Normal users can only kill their own processes.

3 - 22
Unix Security - SANS
©2001
22
Signals and Their Meaning
Terminate process, signal may
be ignored (default kill signal)
15TERM
Process terminates, signal
cannot be ignored
9KILL
Process terminates and leaves
core file for debugging
3QUIT
Some processes terminate,
others re-read config info
1HUP
ActionNumberSignal
By default kill <pid> will send a SIGTERM to the running process– this will cause most
processes to terminate but the application developer may choose to ignore SIGTERM and keep right
on going. SIGKILL kills a process and cannot ever be trapped by an application– the process is
dead and no fooling around. To specify an alternate signal, simply enter it right after the kill
command: kill –KILL <pid> or just kill –9 <pid>. "kill –9" has entered the Unix
lingo as "terminate with extreme prejudice" as in "kill –9 this stupid meeting" or "I'd like to '–9'
that freaking user".
SIGQUIT causes a program to terminate (the signal may be ignored) but the program drops a core
file as it dies. A core file is a record of the process' memory at the time the signal was received– this
can contain much useful debugging information. Unfortunately, core files (which are usually world-
readable) can often contain information that is useful to an attacker as well as pieces of the
/etc/shadow file or other sensitive data.

Software developers often code network daemons (name servers, Web servers, Sendmail, inetd,
syslogd, etc.) to handle the SIGHUP signal specially. Upon receiving a SIGHUP, these daemons
will re-read their configuration files to pick up recent changes and/or close and re-open their log files
(useful when "rotating" logs). However, other system processes (which have not been specially
coded by the developer) will terminate upon receiving a SIGHUP.
3 - 23
Unix Security - SANS
©2001
23
Some Examples
Simple case:
kill 3245
kill –9 10345
Restarting your name server
kill –HUP `cat /etc/named.pid`
Killing processes by pattern
kill `ps –ef | awk '/sshd/ { print $2 }'`
In the first example we're sending a SIGTERM to process ID 3245 and the second example sends
SIGKILL to process 10345. The usual tactic here is to run ps (often piped into the grep
program to find a particular process or user) and then cut-and-paste the PID from the ps listing
into the kill command.
Many network daemons drop a "PID file" which contains the process ID of the server process.
This is particularly useful because it allows the administrator to easily send signals to a process
without first doing a ps listing to find the PID. For example, to send SIGHUP to the running
name server process on the system, we simply run the command cat /etc/named.pid using
backwards quotes ("backticks" in Unix lingo) which cause the output of this command to be
redirected to the argument list of the kill command (go output redirection! go! go! go!).
We can elaborate on this tactic by putting entire pipelines inside of backticks. In the last example
we're piping the output of ps to the awk command (if you've never used it, awk is sort of like an
early version of the Perl programming language). awk takes a pattern (just like grep) and an

action which should be performed on lines matching the pattern– in this case we're matching the
string "sshd" and printing the second field of the ps listing (the PID) on lines which match.
This has the net effect of returning the PID of all sshd processes running on the system. This
output gets substituted onto the command line of the kill command– we've just killed every
SSH daemon on the server and knocked off all users logged in via SSH (including, possibly,
ourselves… bummer!).
3 - 24
Unix Security - SANS
©2001
24
Process Priority
• The "nice level" of a process guides
system on how much CPU to give job
• Nice levels range from –19 to 19, higher
priority goes to lower nice numbers
• Only the superuser can assign negative
nice values
• Users may only set nice values on their
own processes, and only for the worse
Unix systems have a notion of process priority or niceness value (so named because you get to choose
how nice you want to be to other users on the system). Most processes run at priority 0 and get time-
sliced onto the CPU about as frequently as every other priority 0 process. However, a process with a
lower (i.e., negative) priority value will always get the CPU before any process with a higher priority
value– if the process with the lower priority number is not ready to execute instructions (it's waiting for
disk I/O or in some similar "blocked" state), then the higher priority processes get a chance to use some
CPU time. Similarly, a process can be run with a nice value higher than zero, in which case it only gets
CPU time when no other process needs to execute. Nice values range from –19 to 19 on most Unix
systems (some use –20 to 20) but in practice nice values are most often 0, -19, or 19 and nobody fools
around much with the intermediate values.
The superuser is allowed to reset the priority on running processes using the renice command and is

the only user allowed to set negative nice values. Normal users may run new commands via the nice
program to set their process' nice level, but they can only set positive nice values (i.e., give up their
rights to the CPU to other higher-priority processes).
3 - 25
Unix Security - SANS
©2001
25
Examples
Set off a long-running job at low priority:
nice –n 19 catman 12345678ln
Control a runaway process:
renice –n 19 9873
Take over the machine:
renice –n –19 3078
nice is generally used when running commands which can take a long time but which are not
particularly critical. The catman command reformats the Unix on-line manual pages from their
troff sources (troff is an early text-formatting language popularized on Unix systems) to
formatted text files and caches these files under /usr/man. This saves the man command from
having to reformat the manual pages every time somebody wants to read them at the expense of a
couple dozen megabytes of disk space. catman can take a long time to run and the troff
formatter can consume lots of CPU time, so most folks tend to fire this off as a low priority process
and let it run to completion as CPU load allows.
The superuser can renice a process that's consuming too much CPU time (the last argument is a
PID ala kill). For example, if you find somebody trying to run crack to break passwords on your
system, you might renice their process while gathering other evidence about their activities.
Chances are, the attacker will never notice that their process priority has been reset.
renice-ing a process down to priority –19 can cause the system to effectively "lock up",
particularly if the process is very CPU-intensive and doesn't do much I/O. Don't say you weren't
warned.