Tài liệu Basic UNIX and Linux Auditing pptx

1
UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
1
Basic UNIX and Linux Auditing
John Green

Hello, my name is John Green. I consider it a privilege to be able to talk to you about a security
issue that is vitally important, and yet often overlooked. That topic is basic UNIX auditing.
(Editor’s note: Please note that your mileage may vary. Although we have tried to demonstrate
widely available techniques, it is possible that some of the tools shown here may not exist on your
particular flavor of UNIX or Linux, or may work slightly differently. - SE)
With so many sophisticated security tools on the market, it is easy to understand why administrators
are bypassing the basics in favor of these tools and the hype that surrounds them. Intrusion detection
systems, firewalls, and other perimeter defense systems promote the ease of single point protection.
But what happens when these countermeasures fail? How do we protect our systems and detect
intrusions once an intruder has breached our bulkhead? How can we assess the damage that has
occurred as a result?
The short answer is that we can’t, unless we have taken the time to install and configure some basic
auditing tools. Many of these tools come with the base operating system and those that don’t can be
downloaded from the Internet for free.
On the next slide, titled “Introduction”, I’d like to explain what I mean by basic UNIX auditing and
take a look at the areas that get a return on the investment of time taken to properly configure
auditing at the host level.
2
UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
2
Introduction
• Auditing is the process of keeping a recorded
history of events of interest on a system

• UNIX accomplishes this through system
processes, log files, and manual labor
• Audit trails serve a multitude of purposes
– Identifying system errors
– Detection of attempted intrusion
– Break-in discovery
– Damage assessment
Every UNIX system provides the capability to record information about various system events.
Boot-up messages, user activity, and network connections are only a few of the events that can be
recorded in system log files.
Auditing is the process of recording this information and, perhaps more importantly, reviewing it for
signs of unexpected activity. Since audit trails are useless if no one is looking at them, procedures
must be put in place to make this easy to accomplish on a daily basis. Throughout this presentation,
I’ll provide tips that can be implemented to ease the burden of audit trail review.
Think about the concept of ROI, or return on investment. The proper configuration of system
auditing processes only takes a little while, but the payoff can be significant. The information found
in log files is extremely valuable, and can be used for a lot of different things. To the system
administrator, log files can be a source of information about system errors and misconfigurations that
might otherwise have gone unnoticed. To the information system security officer, log files provide a
means to detect attempted intrusions and subsequently verify system integrity. If a break-in has
occurred, good audit trails help incident handlers assess the extent of the damage that may have
occurred.
On the next slide, I outline the topics that are covered in this course, and discuss why it is important
that they are understood.
3
UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
3
During This Course,
The Student Will:

• Learn how to discover suspicious account activity by
reviewing log files
• Understand syslog and how to configure it for
optimal system reporting
• Discover the importance of TCP Wrappers as an
access control device and how to integrate it with
syslog
• Be able to find programs that run as root and look for
hidden files
• Verify and monitor network services and Internet
connection
In my experience as the leader of a small DoD intrusion detection team, I have found that one of the
best intrusion detection sensors is a knowledgeable system administrator who reviews audit trails
daily.
As an example, a few weeks ago our whole class B address space was scanned on port 21 for ftp.
More than a dozen departmental administrators reported that they were seeing unauthorized activity.
Even if we had not had a single perimeter IDS in place, we still would have been aware of the scan.
This was a great confidence boost!
This type of host-based detection is possible because our system administrators take basic auditing
seriously. We have built it into the host accreditation process and made the system administrators
accountable.
During this course, I will explore the basic auditing functions provided by UNIX, as well as some
freely available packages that no system should be without. I will demonstrate how to configure and
tune various logging functions to provide the maximum benefit to the information security
professional and system administrator alike.
At the conclusion of this course, the student will be able to discover suspicious user account activity,
configure the syslog facility for optimal reporting, and integrate TCP Wrappers with syslog to
provide access control and network connection auditing. The student will also be able to identify
potentially troublesome files and network connections and understand how to audit these for
intrusion detection or incident handling purposes. Please go on to the next slide titled “Auditing

User Activity”.
4
UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
4
Auditing User Activity
utmp
wtmp
btmp
lastlog
messages
The easiest way to get started in auditing is to keep an eye on user account activity. Repeated bad
login attempts, or logins at strange times or from unexpected places, are often an indication of an
intrusion.
Some account activity is logged by default, and some must be “turned on”. This section of the
course will focus on where to find these logs, their content, and the commands necessary to examine
them.
On the next slide titled “UNIX Log Files”, we’ll take a look at some examples and their locations in
the UNIX file system.
5
UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
5
UNIX Logfiles
Logfile
/var/run/utmp
/var/log/wtmp
/var/log/btmp
/var/log/messages
/var/log/secure

Contains
Current login “snapshot”
Login-logout history
Bad login history
Messages from the syslog facility
Access and authentication
Log files are the mechanism that UNIX employs to record audit trails. There are five major log files
that the administrator should keep a watchful eye on for signs of unauthorized activity. For the most
part, these files can be found in the /var/log directory of the Linux filesystem. The notable exception
is utmp which can be found in /var/run.
It is important to understand the contents of each of these log files and how one can exploit the
information to achieve a more secure system. Starting with the next slide titled “The utmp File”, I
will discuss the details of each.
6
UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
6
The
utmp
File
• UNIX keeps a snapshot of users currently
logged into the system in /var/run/utmp
• Special binary file used by programs
– who, users, finger
•Contents are ephemeral
• For each successful login, utmp contains:
– Username, terminal, login time, remote host
I used to work in a secure facility. Our employee badges had our identity and other pertinent
information encoded on a strip on the back of the badge. People authorized to enter a building could
do so by swiping their badges through a badge reader. This would record information and unlock the

door. The exit process was exactly the same. At any given time, physical security personnel could
call up a list of people currently in the building.
The utmp file works in a similar fashion. As users log in, an entry for them is made in the
/var/run/utmp file. Upon logout, that entry is removed. The result is a file that contains a current
user snapshot at any given point in time. As such, the contents of this file are short lived and always
changing.
For every successful login, utmp records, among other things, the username, device name, time, and
origin. Unfortunately, utmp is a binary file so it cannot be viewed with a text editor or other ascii
based tool. However, programs like who, users, and finger read the utmp file and display its
contents.
On the next slide titled “Examining utmp With who” we will take a look at the contents of a sample
utmp file.
7
UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
7
Examining
utmp
With
who
# who idle heading
USER LINE LOGIN-TIME IDLE FROM
norbert pts/0 Aug 16 12:49 14:48 (:0)
norbert pts/1 Aug 16 12:49 . (:0)
dagget pts/2 Aug 16 14:48 . (okhost.mycom.com)
root pts/3 Aug 17 02:47 . (bad.org)
Here, we see the usage of the who command. Several options have been given on the command line
which control the output format, including how long a particular login has been idle.
As advertised, who shows that users norbert, dagget, and root are all currently logged in. We can see
the terminal lines that were used, as well as the actual login time. Notice that the first entry for norbert

indicates that the session has been idle for more than 14 hours, but all of the other sessions are
currently active. The final column shows the origin of the login. The :0 indicates that the login
occurred on the console itself, so we can assume that norbert sits at this computer. Dagget has logged
on from okhost.myhost.com, and root is logged in from the remote host bad.org.
It doesn’t take a computer scientist to see that something terrible is going on. Someone from an
unexpected domain has logged on to our host as root. The initial login occurred at a strange time and
the . in the idle column indicates that whoever has assumed root is still actively issuing commands.
Admittedly, typing who every now and then can be a pain, assuming that I even remember to do it.
So, what I’ve done is put the who command in my .tcshrc file. This way, whenever I open a new
window, I see who is logged on without any further action on my part.
Utmp doesn’t require any action on the administrator’s part for activation; it runs by default.
However, there are some security issues to be aware of. I’ll talk briefly about these on the next slide
titled “A Note On Securing utmp”.
8
UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
8
A Note On Securing
utmp
• utmp is sometimes distributed “out of the
box” as a world-writeable file
• Malicious users can corrupt the file or hide
themselves
• Using the ls -la command, ensure that utmp’s
file permissions are set to -rw-r r
Sometimes utmp comes installed with world or group write permission by default. As a result, a
malicious user can erase or otherwise corrupt the utmp file. The savvy hacker can hide himself or
fake entries, diverting attention from himself to others. Knowing this, be slow to react to the
contents of utmp. Consider it a piece of the puzzle and treat it appropriately.
At configuration time, always check the mode of log files to make sure that only root can write to

them. The ls command with the -la arguments can help you here.
On the next slide titled “The wtmp File” , we’ll discuss a file that is very similar to utmp in many
ways.
9
UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
9
The
wtmp
File
• UNIX keeps a record of users’ login and
logout activity in /var/log/wtmp
• Binary file, similar to utmp
,
used by programs
–who, last
• Contents are semi-permanent
• Like utmp, wtmp also contains the following
information for login or logout actions:
– Username, terminal, login time, remote host
Wtmp can be found in /var/log, and is the same as utmp in terms of file type and format. It records
the username, device, event time, and connection origin as a binary file. The major difference in file
content lies in the fact that wtmp keeps a history of all logins, logouts, and system events. This
provides a formal audit trail of user account access and host booting. Instead of being a user
snapshot, wtmp is a running account and system history. This information is critical to intrusion
detection and incident investigation efforts.
The contents of wtmp can be displayed with the who command, but the last command provides much
more information. Administrators can prune the results of the who command to display only the last
N events, or to show the account events for a particular user.
On the next slide titled “Examining wtmp With last” I will show the last command in action on a

wtmp file.
10
UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
10
Examining
wtmp
With
last
[root@myhost log]# last
root pts/3 Tue Aug 15 07:15 still logged in bad.org
norbert pts/2 Tue Aug 15 07:01 still logged in bad.org
norbert pts/1 Tue Aug 14 06:56 still logged in :0
dagget pts/1 Mon Aug 13 10:24 - 10:24 (00:00) ok.com
seap pts/0 Thu Aug 12 15:07 - 15:07 (00:00) :0
runlevel (to lvl 5) Thu Aug 12 09:54 - 08:01 (4+22:06)
reboot system boot Thu Aug 12 09:54
norbert pts/0 Thu Aug 12 09:17 - crash (00:36) :0
dagget pts/0 Thu Aug 12 09:09 - 09:16 (00:07) ok.com
norbert pts/0 Wed Aug 4 11:19 - 09:45 (6+22:25) :0
wtmp begins Mon Aug 2 14:57:03 1999
When using last, the first thing to be aware of is that it displays the contents of the wtmp file in a most-
recent to least-recent time order. Said differently, entries at the top of the output occurred most recently.
The start date of the file is on the very last line. This wtmp began on August 2nd at almost 3 PM.
Scanning left to right, we see the username, the tty, the login and logout time and the host of origin.
Elapsed activity time is displayed in parentheses to the right of event times. Also, for those users still
logged in, a corresponding message is displayed in place of the logout time.
If we examine the output from the bottom up, we can read a history of the activity on the host. The entries
look fairly normal until norbert’s entry on August 12th at 9:17. Apparently, while norbert was logged on,
the system crashed. For some reason, the system rebooted at 9:54 and reached runlevel 5 less than a

minute later. Unexpected reboots should always be investigated.
At the top of the output, we see that norbert logged in from the console at 6:56 on August 14th and was still
logged in when the last command was run. The frightening lines are the top two. Apparently someone is
using norbert’s account from the host bad.org. In this example, the hacker also acquired root 14 minutes
later. Could a sniffed password have been the vehicle for a local compromise?
As you can see, the wtmp file is a necessity for reconstructing system events in an investigation, but be
warned! Wtmp must be activated or no such logs are collected. The next slide titled “Activating The wtmp
Logfile” shows what must be done to record this audit trail.
11
UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
11
Activating The
wtmp
Logfile
• Entries are only logged in /var/log/wtmp if it
exists
• Use the ls command to verify file existence
ls -la /var/log/wtmp
•
wtmp
can be created using the touch
command
touch /var/log/wtmp
chmod 644 /var/log/wtmp
All that is required to collect this historical account activity is the existence of the wtmp file in
/var/log. However, on many Linux boxes there is no wtmp file installed by default. A simple ls of
/var/log/wtmp can be used to determine if it exists.
In order to start the data collection, as root simply use the touch command to create the wtmp file.
Since wtmp is vulnerable to the same attacks as utmp, make sure to change its mode to be readable

and writeable by root only, and readable by everyone else.
When managing and reviewing logfiles, remember that cron is your friend. Most administrators that
I know use a cron job to run the last command every morning before they get into work. The output
is sent to them every day via email. With just a glance, they can identify suspicious activity that may
have happened the night before.
Although utmp and wtmp can go a long way towards providing the security professional with the
information needed to detect and investigate intrusions, one element is still missing: bad login
attempts.
With a list of bad login attempts, hackers trying to crack weak passwords or default accounts can be
easily identified. Admittedly, such a list is subject to false alarms because of typos and forgotten
passwords; it should nevertheless be a tool in the security professional’s toolbox.
The next slide titled “The btmp File” describes a file containing this list.
12
UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
12
The
btmp
File
• UNIX keeps a record of bad login attempts in
/var/log/btmp
• Binary file, similar to wtmp
,
used by
–lastb
• Contents are semi-permanent
• Like wtmp, btmp must exist for logging activity
to occur
/var/log/btmp is the file used to log bad login attempts. It records the username, the device, the time,
and the origin of the failed login attempt. The command lastb can be used to examine its contents

since, like the others, it is a binary file.
Like wtmp, the btmp file must exist in the /var/log/ directory in order for bad logins to be recorded.
We can use the ls command to check for the file’s existence. If it doesn’t exist, create btmp using
the touch command as described earlier. Make sure that btmp’s permissions are set so that only root
can write to it.
(Editor’s note: You may want to ensure that only root can read
from the btmp file as well. The
reason for this is that folks sometimes mistakenly type in their password when they mean to type in
their username. As a result, the password appears in plain text on the login line and is dutifully
recorded in the btmp file. If the file is world readable, anyone can come along and look for such
entries. They can then guess, using the who command and login times, which userid belongs to that
password. Since there is no real reason why individual users need to view their failed login attempts,
removing world permission from btmp should cause no harm. - SE)
The same administrators that run last in a morning cron job also run lastb that way. I’ve found that
using cron to automate repetitive tasks like these makes it much more likely that I will continually
audit these sources of information. The first thing that I do in the morning is read email from the
night before, so I’m always assured of catching suspicious activity early.
On the next slide titled “Examining btmp With lastb”, we can see the contents of a btmp file.
13
UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
13
Examining
btmp
With
lastb
#lastb -adx
pts/3 Fri Aug 20 07:59 - 07:59 (00:00) 192.168.30.21
norbert pts/3 Fri Aug 20 07:59 - 07:59 (00:00) 192.168.30.21
norbert pts/3 Fri Aug 20 07:59 - 07:59 (00:00) 192.168.30.21

pts/7 Tue Aug 17 07:13 - 07:13 (00:00) 192.168.45.19
pts/7 Tue Aug 17 07:13 - 07:13 (00:00) 192.168.45.19
' pts/7 Tue Aug 17 07:13 - 07:13 (00:00) 192.168.45.19
root pts/7 Tue Aug 17 07:13 - 07:13 (00:00) 192.168.45.19
pts/7 Tue Aug 17 07:05 - 07:05 (00:00) 192.168.45.19
pts/7 Tue Aug 17 07:05 - 07:05 (00:00) 192.168.45.19
pts/7 Tue Aug 17 07:05 - 07:05 (00:00) 192.168.45.19
root pts/7 Tue Aug 17 07:05 - 07:05 (00:00) 192.168.45.19
btmp begins Mon Aug 16 06:15:20 1999
Note how similar the output of last and lastb are. This is because the operating system writes this
information from the same data structure. For those who may be curious, the data structure can be
found in /usr/include/utmp.h.
Is there anything here that might raise a warning flag? Maybe. Here, it looks like several attempted
logins from the same class B address space, but from different subnets. If this wasn’t my own
address space, I’d be concerned.
This is probably a good time to point out that the operating system handles rotating log files for us.
At given intervals, current copies of the log files are moved to a backup, and new files are created.
As an example, this btmp says it began on August 16th at 6:15 AM. Prior to the creation of this
btmp file, the old one was moved to btmp.0; if a btmp.0 existed, it was moved to btmp.1 and so on.
Although this provides a form of online backup, it isn’t sufficient to safely protect your audit trail.
The first thing that a good hacker will do is cover his or her tracks by editing or nuking these files.
On the next slide titled “Protecting Your Audit Trails”, I’ll discuss some measures that can be taken
to reduce the risk to these files.
14
UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
14
Protecting Your Audit Trail
• Backup, backup, backup
• Store backups on a tape or alternate disk

• Automate daily backups with a cron job!
#!/bin/csh
cd /backup/disk/.vlb
mv varlogbackup.6.tar.gz varlogbackup.7.tar.gz
mv varlogbackup.5.tar.gz varlogbackup.6.tar.gz
:: :
mv varlogbackup.tar.gz varlogbackup.1.tar.gz
tar cf - /var/log | gzip best > varlogbackup.tar.gz
One of my friends uses the old hacker technique of storing sensitive files in a hidden directory for
protection. He uses a simple script to archive the /var/log directory daily. This script will keep a
seven day moving record of all of the important logfiles. Since some of these files can grow quite
large, it is compressed using gzip called with the “best” argument for optimal compression.
It’s a good idea to write this archive to another disk, or even to tape. Although this won’t stop the
hacker with root privileges, it will provide another layer of complexity for him to deal with, in
addition to keeping us from losing this information due to a disk failure. It is certainly possible to
encrypt the resulting file or to create a checksum to add a layer of integrity assurance.
With a good backup plan in place, all of the basics have been covered with respect to UNIX log files
and the role that they play in auditing. On the next slide titled “Auditing Account Activity: Step By
Step” I will review the procedures that administrators should perform to insure that account auditing
is in place.
15
UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
15
Auditing Account Activity:
Step By Step
• Make sure wtmp and btmp files exist
• Run who to look for unexpected users
• Run last to look for unexpected logins
• Run lastb to look for failed login attempts

•Backup log files
Whenever I set up a new UNIX system, the first thing that I do is ensure that user account auditing is
activated and secured. I do this by following these simple steps:
First, I check to see if wtmp and btmp were installed by default. If not, then I create them using the
touch command. I use the ls command to check the mode of the files, making sure that only root can
write to them.
Second, I edit my .tcshrc or equivalent shell resource file so that the who command is executed
whenever I start a new shell. I then create two cron jobs. One runs last, and one runs lastb. Both
jobs execute in the morning just before I get in, and email any results to my account. Then I can
review, review, review.
The final thing that I do is to ensure that sufficient measures have been taken to backup the log files.
If there is a tape drive available, I use that as my backup device, otherwise I use a hidden directory
on a different disk.
Armed with these audit processes, administrators can spot intruders early, before any (or much)
damage can be done. If necessary, system events can be reconstructed to aid investigations and to
assess damage.
With account auditing in place, we are ready to move on to syslog. The next slide titled “Making The
Most Of syslogd” introduces this topic.
16
UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
16
Making The Most Of
syslogd
syslog
syslog.conf
messages
secure
Syslog is perhaps one of the most important security tools we have, yet few administrators fully
understand its capabilities. Although syslog can get pretty complex, the basics are easy. So, in this

section, I’ll introduce syslog and what it does. I’ll spend some time discussing remote logging and
how to configure syslog to send the messages of interest to various places, including some well
known files.
Let’s take a look at the syslog daemon starting with the next slide titled “Syslogd -System Log
Facility”.
17
UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
17
Syslogd
- System Log Facility
• System utility that provides centralized
support for logging of system messages
•Log messages contain
– timestamp, hostname, program name, message
• Provides support for remote logging
• Configuration file is /etc/syslog.conf
Syslog provides a centralized utility for managing and logging system messages. Both system
routines and user programs can send messages to the syslog facility for handling.
Syslog is important because it provides a single utility from which any and all messages can be
controlled and distributed. This significantly eases the burden of the system or security administrator
when it comes to log file management.
Typically, messages sent to syslog contain a timestamp, a hostname, a program name, and an
associated message. When syslog receives a message from a program, it sends it to a file, a named
pipe, or a remote host.
Ultimately, a message is logged in a location specified in the syslog configuration file. Syslog.conf
can be found in the /etc directory. Its entries dictate how to handle messages of various types.
On the next slide titled “Remote syslog Servers” I’ll discuss the motivations and procedures for
creating a remote syslog server.
18

UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
18
Remote
syslog
Servers
• Syslog messages can be forwarded to a
remote host
• Syslogd on the remote host must be started
with the -r argument
• /etc/services on both hosts must contain the
line:
syslog 514/udp
As mentioned earlier, one of the first things a hacker does to cover his tracks is to eliminate any trace of
activity in the logfiles. This is easy to do as root on the local machine.
Syslog provides some functionality to combat this. It can forward messages to a syslog server on a remote
host. Even if the local host is compromised and the audit trails are modified, the logs on the remote syslog
server will remain intact.
Keep in mind that it is easy to review the logs for a single machine, but system and security administrators
always have a one-to-many relationship with the hosts that they are responsible for. A single syslog server
can collect system messages from hundreds of machines. This single file can then be examined for events
of interest, providing an audit trail for an entire enterprise.
By default, most UNIX hosts, including Linux, are configured to log locally. In order for the syslog
daemon to receive messages from remote machines, two actions must be taken.
First, the syslogd on the syslog server must be started with the -r argument. This tells the syslogd to listen
for messages from remote machines on udp port 514. Second, the /etc/services file on both the local and
remote machines must have a line containing the word syslog followed by a tab and the entry 514/udp.
This permits messages to be sent and received on syslog’s well known port. If this line does not exist in
the remote syslog server’s services file, the syslogd started with the -r argument will die.
Once this is done, we can start configuring a local syslog to send the messages where we want them to go.

The next slide titled “Configuring syslog” discusses this process.
19
UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
19
Configuring
syslog
• /etc/syslog.conf dictates where messages are
logged, e.g.
*.info;mail.none;authpriv.none /var/log/messages
authpriv.* /var/log/secure
• Each line consists of two parts
– selector (which messages to log)
– action (where to send the message)
The configuration parameters for syslog can be found in /etc/syslog.conf. Each line in syslog.conf
defines what actions are taken for a given set of message types.
The entries in the middle of this slide are examples. We can see that each line consists of two parts, a
selector and an action.
The selector defines which messages are to be logged, and is a list of facility-priority combinations
separated by a semicolon. As this example shows, both facilities and priorities can be “wildcarded”
with a “*”. I’ll discuss facilities and priorities in more detail later.
The action defines how or where the given message types should be logged. Most often, this entry is a
filename, indicating that the messages should simply be written there. However, the action field can
also contain email addresses, named pipes, and remote hosts. When these options are specified, the
messages defined by the selector will be sent as email, written to the standard input file descriptor of a
program, or forwarded to a remote host, as discussed earlier.
In this example, all messages with a priority of info or higher are logged in the file /var/log/messages.
However, no mail or authentication messages are logged. All authentication messages are to be
logged in a separate file, /var/log/secure.
Let’s take a closer look at the message type definitions on the next slide titled “Syslog.conf selectors”.

20
UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
20
Syslog.conf
Selectors
• Facility
– authpriv
– cron
– daemon
– kern
– lpr
– mail
– news
– syslog
– user
– uucp
• Priority
– emerg (highest)
– alert
– crit
– err
– warning
– notice
– info
– debug (lowest)
At first glance, selectors can seem a little confusing. A selector has two parts, a facility definition
and a priority definition joined by a dot. The facility is the program that generates the message and
the priority is the alert level.
Every message has a priority. Debug is the lowest priority and emerg, or emergency is the highest.

Note that when a priority is defined in a selector, it tells syslog to log all messages with that priority
and above. As an example, lpr.warning would define that the messages from the lpr facility that
have a priority of warning or higher should be logged.
For the most part, the authpriv facility is most interesting, since it is responsible for generating
authentication and authorization errors. So let’s take a look at an example syslog file on the next
slide titled “Sample Syslog.conf entries”
21
UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
21
Sample
Syslog.conf
Entries
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none /var/log/messages
# The authpriv file has restricted access, plus log on
# another machine.
authpriv.* /var/log/secure
authpriv.* @somelogserver.mycom.com
# Everybody gets emerg messages, plus log them on
# another machine.
*.emerg *
*.emerg @somelogserver.mycom.com
It’s important to separate the messages that may indicate trouble from those that may not. This makes
reviewing logs quicker and easier, and reduces the chance that something important may be missed.
In the examples on this slide, notice that comments start with a pound sign. The first entry in this
syslog.conf file, like before, defines that all messages with a priority of info and higher should be
logged in the /var/log/messages file. Mail.none and authpriv.none indicate that no mail or authpriv
messages will be logged in the messages file.

The authpriv message actions are defined in the next two entries. All authpriv messages will be sent to
two places. They are logged to the local file /var/log/secure, in addition to being sent to the syslog
server running on somelogserver.mycom.com.
The final two entries define what should be done with emergency messages. Emergency messages get
sent to all users, as indicated by the wildcard symbol “*”. Syslog uses the “wall” command to
accomplish this. They are also sent to the remote syslog server.
Sending critical messages to a secondary server provides a backup method, in addition to forcing the
hacker to break into another system in order to cover his tracks. Obviously, the central syslog server
should be as secure as possible to keep this from happening.
On the next slide titled “The messages File”, we’ll take a look at some of the system messages that get
stored there.
22
UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
22
The
messages
File
• A copy of each system message that is
displayed on the console is stored in the
/var/log/messages log file
• Messages is a very rich source of information
Aug 16 16:02:25 myhost kernel: eth0: Setting promiscuous mode.
Aug 17 06:49:05 myhost pam_rhosts_auth[4076]:
denied to as root:
access not allowed
Aug 17 06:49:10 myhost in.rlogind[4076]:
PAM authentication failed for in.rlogind
Aug 18 10:03:16 myhost login: FAILED LOGIN 1 FROM badguy.org
FOR root, Authentication failure

Each system message that gets sent to the console is also written to the messages file. Collectively, these
messages are an incredibly rich source of information. Savvy system administrators can review the
messages file to look for events that might indicate system trouble. Filled file systems, failing devices, and
system misconfigurations are just some of the tidbits that can be found in the messages file.
In the example on this slide, we see that a sniffer has been installed on our host. The first entry is a
message from the kernel. It tells us that the eth0 network interface has gone into promiscuous mode and is
sniffing the network traffic. This is not a good sign. The subsequent entries indicate that dagget tried to
login as root but was rejected and, on the 18th, someone from badguy.org was trying to login as root but
failed as well.
One of the researchers in my organization is always the first person to detect a scan. He is by no means a
security expert, but he knows the basics. By reviewing the messages file occasionally, he learned which
signs might indicate trouble and subsequently wrote a small script to grep the messages file for these
regular expressions. He emails the results to himself at regular intervals, twice a day. This way he can
easily see anyone attempting to connect or login to his computer. Words like promiscuous, failed, failure,
and denied are all good choices for grepping.
Earlier, we configured logging so that all authpriv messages will be logged to /var/log/secure. On the next
slide titled “The secure File”, we’ll take a look at the contents of this file.
23
UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
23
The
secure
File
• Contains any security and authorization
messages
• Especially interested in messages from TCP
Wrapper, e.g.
Aug 11 17:26:23 myhost in.ftpd[32727]:
refused connect from badguy.org

Aug 11 17:26:24 myhost in.rshd[3379]:
refused connect from badguy.org
Aug 11 17:26:25 myhost in.fingerd[3383]:
refused connect from badguy.org
Later in this course, I will talk about a tool that should be installed on each and every UNIX system
in your organization. This tool is call TCP Wrapper. For the most part, messages logged in
/var/log/secure will be generated by this program.
In the log file excerpt shown on this slide, it is evident that on August 11th at 5:26 pm someone from
badguy.org scanned the computer myhost and tried to connect to the ftp, rsh, and finger services.
Luckily, TCP Wrapper was in place to refuse the connection.
Armed with this knowledge about syslog, we can begin to pull all of the auditing pieces together to
make large deployments easier to manage and the resulting log files easier to review. On the next
slide, I will summarize what it takes to setup syslog, step by step.
24
UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
24
Syslogging Step By Step
• Select a host to be a central syslog server
• Edit /etc/services to include the syslog service
• Edit /etc/syslog.conf to send messages to the
appropriate files or hosts
• Insure that syslogd is started with the -r
argument on syslog server and clients
When setting up basic auditing via syslog, the first thing that I do is to identify a host that can be a
syslog server for the network in question. I make sure that an entry for syslog exists in the
/etc/services file, and that the syslogd daemon is started with the -r argument to enable remote
logging.
Then, when configuring syslog on each local host, I edit the /etc/syslog.conf file and define the
selectors and actions so that important messages are stored in a separate file as well as being sent to

the remote syslog server.
I then test the configuration to make sure that syslog is performing the way I intended. When
testing, I intentionally fumble finger passwords, try non-existent logins, and attempt to connect from
unauthorized hosts. I then take a look at the appropriate log files, both local and remote, to make
sure that messages are being sent to the right places.
My final step is to install a cron job to search these files for signs of trouble and mail the results to
me, daily.
It is important to understand that syslog is vulnerable to the same types of mischief that the utmp file
is. On the next slide titled “security warnings” we’ll take a look at some of the security issues
associated with syslog.
25
UNIX/Linux Auditing – SANS GIAC LevelOne
© 2000, 2001
25
Security Warnings
• Syslog servers are vulnerable to denial of
service attacks, if not adequately protected
• Users can write messages to syslog too, this
means that entries can be faked!
A common attack against a syslog server is to bomb it with bogus messages until the disk fills up.
Unfortunately, there isn’t a simple solution to this problem if the attack is originating from a
compromised host on the local network. One administrator that I know has written a small script to
check the amount of disk space that is available. This scripts runs from a cron job every 5 minutes.
If the available disk space drops below a hard coded threshold, he is notified via email.
Since user programs can write to syslog too, it is important to understand that entries can be faked.
With all user writeable log files, we encounter the issues of file integrity and trust.
What information should we trust? How do we know it is authentic? The best defense against bogus
log entries is to be aware that it can happen. Again, be slow to react to entries, but for heaven’s sake,
please don’t ignore them. Remember that they are a piece of a larger puzzle; with all of the pieces in
place, the big picture is often evident.

Let’s move on to the next slide titled “Auditing Internet Service Use”.