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

UNIX/Linux Auditing – SANS GIAC LevelOne© 2000, 2001 4Auditing User Activity utmp wtmp btmp lastlog messages The easiest way to get started in auditing is to keep an eye on user account

UNIX/Linux Auditing – SANS GIAC LevelOne© 2000, 2001 1

Basic UNIX and Linux Auditing

John Green jegreen@crosslink.net

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

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

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

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

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

UNIX/Linux Auditing – SANS GIAC LevelOne© 2000, 2001 5

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

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

UNIX/Linux Auditing – SANS GIAC LevelOne© 2000, 2001 7

# 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”.

UNIX/Linux Auditing – SANS GIAC LevelOne© 2000, 2001 8

• 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

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

– 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

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-most-recent time order Said differently, entries at the top of the output occurred most 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

UNIX/Linux Auditing – SANS GIAC LevelOne© 2000, 2001 11

Activating The wtmp Logfile

• Entries are only logged in /var/log/wtmp if it

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.

UNIX/Linux Auditing – SANS GIAC LevelOne© 2000, 2001 12

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

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

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!

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

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.

UNIX/Linux Auditing – SANS GIAC LevelOne© 2000, 2001 16

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”

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

UNIX/Linux Auditing – SANS GIAC LevelOne© 2000, 2001 18

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

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

UNIX/Linux Auditing – SANS GIAC LevelOne© 2000, 2001 19

• 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”.

UNIX/Linux Auditing – SANS GIAC LevelOne© 2000, 2001 20

– 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”

UNIX/Linux Auditing – SANS GIAC LevelOne© 2000, 2001 21

# Log anything (except mail) of level info or higher.

# Don't log private authentication messages!

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

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 dagget@myhost.com 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.

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

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