myguisystem$ telnet auditedsystem.mycompany.com
..
auditedsystem$ /bin/su -
[password]
auditedsystem# export DISPLAY=myguisystem.mycompany.com:80
auditedsystem# snare &

4.   Setting the Audit Configuration

4.1   The audit configuration is stored as /etc/audit/audit.conf. This file contains all the details required by the audit daemon to successfully execute. Failure to specify a correct configuration file will not "crash" the daemon, but may result in selected events not being able to be read.

Note: Manual editing of the audit.conf configuration file is possible, but care should be taken to ensure that it conforms to the required format for the audit daemon. Also, any use of the graphical SNARE tool to modify security objectives or selected events, may result in manual configuration file changes being overwritten. Details on the configuration file format can be viewed in Annex C - SNARE Configuration File .

Auditing Control
4.3   The initial audit configuration parameters to consider are:

a.    The type of reporting required, and
b.    The destination for audit events. (File or Network)

Figure 2:  Audit Configuration Window - Auditing Control Tab

4.5   Linux uses a mechanism whereby active system tasks all share the system processor(s). Because audit events can potentially be generated by any or all active processors, the audit kernel module must 'cache' audit events until the audit daemon "grabs" it's slice of processor time, and can retrieve the data from the cache. In order to best meet the goals of effective audit delivery, and best use of system resources, version 0.9 of the SNARE module now stores event details in a dynamically allocated linked list. As system memory resources become scarce, the Kernel slows down other tasks, in order to reclaim memory resources. This gives the SNARE auditing subsystem the chance to retrieve audit data, and return more memory to the active pool.

4.6   The type of auditing may either be by "raw kernel events" or by "objectives" (user defined filters). Auditing by raw kernel events will result in all selected system calls being written to the log file (or network), without any form of filtering (other than selecting which system calls are to be audited). The system calls to be audited can be selected via the "Kernel" tab in the Audit Configuration window, as shown in Figure 3 below. This method of auditing is more suited to the classic "C2" style of auditing, where all calls are recorded. It should be noted that the "Kernel" and "Objectives" tabs are mutually exclusive. Turning on events within the "Kernel" tab, does not mean that they will be turned on if you are in 'audit by objectives' mode. Similarly, just because you have an objective defined for "open files or directories" in the objective tab, this does not imply that the open() system call will be audited if you are auditing by "raw kernel events" (unless you have specifically checked the "open" event in the "Kernel" tab.

Figure 3:  "Kernel" Tab

4.7   A more refined method of auditing is available by selecting events via the advanced auditing "objectives" capability. Any number of objectives may be specified, and are listed in the "Objectives" tab, within the audit configuration window, as shown in Figure 4.

Figure 4:  "Objectives" Tab

4.8   Each of the objectives provides a high level of control over which events are selected and reported. Events are selected from a group of high level requirements, and further refined using selected filters.  All events detailed in Annex A - List of Audited System Calls are contained within all the following high level groups:

1. Open or create a file or directory.
2. Open a file for reading only.
3. Write or create a file or directory.
4. Remove a file or directory.
5. Start or stop program execution.
6. Modify system, file or directory attributes.
7. Change user or group identity.
8. Open a network connection
9. Accept a network connection
10. Administrative events

4.11   The following filters can be applied to incoming audit events:

a.    Filter on the event-specific matchable item.
Each event contains a particular piece of information that represents the core data that needs to be communicated. For the "Open or create a file or directory" group, for example, this would be the name of the file and/or directory opened or created. For the "Start or stop program execution" group, this would be the name of the program in question. The event match allows a "partial", "exact" or "regular expression" match term to check against the event-specific matchable item. A "partial " match will look for the sequence of characters specified somewhere within the event-specific matchable item. For example, if the partial match of "pass" is specified for "Read, write or create a file or directory", then the following example filenames would all match the term:

• /etc/passwd
• /usr/lib/passfilt.so
• /home/red/khyber_pass.txt

An "exact" match will match the specified term exactly. For example, if the term is /etc/passwd, then the file /etc/passwd would match, but the file /etc/passwd.backup will NOT match.

A "regular expression " match matches the supplied extended regular expression against the event-specific matchable item. Regular expressions are an advanced form of specifying filters, and should only be used by those with regular expression experienced. For example, the term ".*[Pp]ass(word|wd).*" would match the following:

• /etc/passwd
• /tmp/PasswordFile

but would not match:

• /etc/PASSWD
• /home/red/PaSsWoRd .txt
  

b.    Filter on user.
Any number of users can be selected, and should be entered with commas separating each user. If no users are entered, ALL users are assumed to be audited. Alternatively, specific users may be EXCLUDED from any individual objective, leading to objectives such as "tell me whenever any user except 'root' or 'red' generate an event" . If the user exclusion function is selected, SNARE will only report users that DO NOT match the supplied list of users.

c.   Filter on return value
An audit event will either return a success or failure return code. SNARE allows a user to filter on the return value.

d.  Filter on special, event-specific fields
Some events, including open() and socketcall(), allow additional filters to be specified, to provide more flexible search criteria.

i.   open()
The open event provides the additional capability to filter on open-flags. The flags are specified in regular expression format, and can include (in the following order):

    O_WRONLY
    O_RDWR
    O_RDONLY
    O_CREAT
    O_EXCL
    O_NOCTTY
    O_TRUNC
    O_APPEND
    O_NONBLOCK
    O_SYNC
    O_NOFOLLOW
    O_DIRECTORY
    O_LARGEFILE

For Example, the following flags can be logically 'or'ed together (in regular expression form) to specify an objective that translates to "Let me know whenever a file is opened in WRITE mode.

open(O_WRONLY|O_RDWR|O_CREAT|O_TRUNC|O_APPEND)

Whereas the following three examples all specify "Read or Write":
    open(.*)
    open(O_.*)
open(O_WRONLY|O_RDWR|O_RDONLY|
O_CREAT|O_EXCL|O_NOCTTY|
O_TRUNC|O_APPEND|O_NONBLOCK|
O_SYNC|O_NOFOLLOW|O_DIRECTORY|
O_LARGEFILE)

More information on the flags associated with the open() system call are available from the Linux manual pages (see 'man open').

ii. socketcall()
The Linux kernel uses the 'socketcall' system call to serve the requirements of the 'connect', 'accept' and related system calls. In order to monitor 'connect' and 'accept' calls only, the system call 'type' can be included within the objective.

For example, socketcall(ACCEPT) only monitors accept() calls. socketcall(CONNECT) only monitors connect() calls.
socketcall(.*) or socketcall(CONNECT|ACCEPT) monitor both accept and connect.
 

5.1   The main SNARE window also contains the events that have been recorded from the audit log file. Events collected, which meet the filtering requirements as per the Audit Configuration, will be displayed in the main window.

5.2   A summary version of the event is displayed on the main window. For more details on a specific event, the relevant row from the main window can be selected using the mouse. A pop-up window will then display more comprehensive details related to the event. The details are event context dependant; For example, an "execution" event will display the executed program name, whilst a "file open" event will display the path name of the opened file. The event details window is shown in Figure 5. Note that only certain fields are shown, and others are "greyed out". The fields which are displayed depend entirely on the event (system call) that is being displayed. Once an event window is displayed, other events may be displayed by selecting the "prev" and "next" key.

5.3   The fields shown in the event window relate to the parameters of the system call that was audited. The brief interpretation of the individual fields is discussed below:

Figure 5: Event Details Window

5.4   In order to view all previous events contained in the log file, the "Reload" menu item can be selected from Activity->Reload Log File, or from the corresponding button from the toolbar. Note that displaying the entire log file may take some time, depending on the size of the file. Alternatively, the main window event list may be cleared from the menu by selecting the item Activity->Clear all Current Events, or from the corresponding button from the toolbar. Note that clearing the main event viewer, DOES NOT clear the log file.

5.5   The main display will alert the user as to whether the events being generated by the audit daemon are being filtered using the defined objectives, or if events are being passed on without any filtering. This wil be shown to the user via the graphic display at the bottom of the main window which will show either "Display Mode: Objective Information" or "Display Mode: Raw Event Log Data". If events are being passed exclusively to a remote networked host, then a blue coloured graphic will be displayed stating "No Events Displayed: Network Transfer Active". The graphic is shown at the bottom of Figure 1 .

6.   Audit Management Functions

6.1   The audit daemon is a separate standalone component of the SNARE system, as described in the section on SNARE Overview. However, the SNARE graphical tool can be used to control a number of aspects of its operation. Primarily, the audit configuration can be developed and set using the graphical tool, as described in the previous sections. However, two other functions are available to manage the audit daemon.

6.2   The audit daemon can be restarted directly from the menu item Activity->Apply and Restart Audit. This will instruct the audit daemon to re-read the configuration file, clear the buffers and restart. This function is useful when changes to the audit configuration have simply been saved to the configuration file, without being "applied". The user can therefore select when to activate a new configuration by selecting this menu item, or its corresponding button on the toolbar.

6.3   The audit daemon status can be viewed by selecting the View->Audit Status menu item, or its corresponding toolbar button. This will display whether the audit daemon is active, its process ID, the SNARE version (specifically of the version of the dynamic kernel module, but will apply to all SNARE components), and the total number of events processed by the kernel module. Note that the total events reported are those that have been collected by the kernel, before filtering (if any) by the audit daemon. The audit status window is shown in Figure 6 below.
 

Figure 6: Audit Status Window (under KDE): 28 million events processed

Log Rotation
6.4   Depending on the SNARE configuration, the log file may be small or large. In any case, it is normal houskeeping practice that logs either be rotated or archived. Depending on the site requirements, a rotation scheme that keeps old copies of the last (say) 7 days may be sufficient. In this case, it may be sufficient to simply include a CRON or ANACRON job, and use a program such as logrotate to ensure the current log file does not grow to an unmanageable size. Alternatively, you may wish to archive all log files to backup media such as tape or CD-ROM. This may be scheduled using CRON or undertaken manually. In either case, it is important to note that the audit daemon should restarted, so that it opens the new log file for writing the events.

7.   Setting the Network Configuration

7.1   SNARE provides the facility to send events to a remote host, using UDP. In conjunction with the audit log archive script provided within the SNARE distribution, this will facilitate the remote storage of audit logs for later analysis.

7.2   The settings for these options are available from the Setup menu on the main window, or their corresponding toolbar. Note that if events are being sent exclusively to a remote machine via the network, they will not be displayed within the GUI. In order to display events in the GUI, as well as sending the data to a remote system, set the "Auditing Control" options to "Log events to the networked host and a local file.

7.3   A simple collection and archive script for receiving logs from a remote SNARE node, is available from the SNARE project page. The collection / archive script receives data from one or more SNARE clients, and saves the data off to a file per-date, per-system in /var/log/audit. Files will be given names based on the date, and the audit source, in the format YYYYMMDD-host.name.LinuxAudit (eg: /var/log/audit/20020321-test.intersectalliance.com.LinuxAudit).

8.   About Intersect Alliance

8.1   InterSect Alliance is a team of leading information technology security specialists in both the "technical" and "policy" areas. In particular, Intersect Alliance are noted leaders in key aspects of IT Security, including host intrusion detection. Our solutions have been used, and continue to be used in the most sensitive areas of Government and business sectors. Intersect Alliance consult and contract to number of agencies in Australia and in Asia Pacific, for both the business and Government sectors.

8.2   The Intersect Alliance business strategy includes demonstrating our committment and expertise in IT security by releasing Open Source products such as SNARE. Intersect Alliance intend to continue releasing tools that enable users, administrators and clients worldwide to achieve a greater level of productivity and effectiveness in the area of IT Security, by simplifying, abstracting and/or solving complex security problems.

8.3   The team at InterSect Alliance are happy to assist you with tools and processes to best integrate intrusion detection (including SNARE) into your organisations.

8.4   Please visit the Intersect Alliance website for more information.

The Linux Kernel has many system calls available at its disposal. However, SNARE Version 0.9 only implements an auditing facility for those calls that are considered to be the most critical and useful from a security perspective. The list of system calls that can be intercepted by SNARE Version 0.9 is shown in the table below.

List of System Calls Implemented in SNARE Version 0.9

System Call	Description
open	open and possibly create a file or device
creat	open and possibly create a file or device
execve	execute program
exit	terminate the current process
mkdir	create a directory
unlink	delete a name and possibly the file it refers to
mknod	create a directory or special or ordinary file
rmdir	delete a directory
chown	change ownership of a file
lchown	change ownership of a file
chown32	change ownership of a file
lchown32	change ownership of a file
chmod	change permissions of a file
symlink	make a new name for a file
link	make a new name for a file
rename	change the name or location of a file
reboot	reboot or enable/disable Ctrl-Alt-Del
truncate	truncate a file to a specified length
chroot	change root directory
setuid	set user identity
setreuid	set real and / or effective user ID
setresuid	set real, effective and saved user ID
setuid32	set user identity
setreuid32	set real and / or effective user ID
setresuid32	set real, effective and saved user ID
setgid	set group identity
setregid	set real and / or effective group ID
setresgid	set real, effective and saved group ID
setgid32	set group identity
setregid32	set real and / or effective group ID
setresgid32	set real, effective and saved group ID
truncate64	truncate a file to a specified length
socketcall	Network functions, including connect and accept.
create_module	Load a kernel module

The core of the SNARE audit subsystem is the loadable kernel module. The module is designed to intercept selected linux system calls, save auditable details associated with the event in question, and store the information in a temporary buffer until it can be read by the audit daemon process.

The module implements a dynamically allocated linked list kernel buffer to cache event information prior to being read by an application that reads data from /proc/audit. The features of the module are:

a.   Events with a path of 1024 bytes can be processed. Paths greater than this size are truncated as of version 0.9.

b.   The module is instructed by the audit daemon to audit only selected system calls. System calls that are not specifically selected will not be audited.

insmod auditmodule.o all=1

Instead of the "all=1" option, the following classes can be added. For example, the command insmod  auditmodule.o file_class=1 will ensure the auditmodule records all the events related to file operations related events. The following audit classes are defined.

file_class - File-related audit events

a_open
a_creat
a_mkdir
a_unlink
a_mknod
a_rmdir
a_symlink
a_link
a_rename
a_truncate
a_truncate64

a_chown
a_lchown
a_chown32
a_lchown32
a_chmod

a_execve
a_setuid
a_setreuid
a_setresuid
a_setuid32
a_setreuid32
a_setresuid32
a_setgid
a_setregid
a_setresgid
a_setgid32
a_setregid32
a_setresgid32
a_exit

a_reboot
a_chroot
a_create_module

a_socketcall

Note that when an f* system call (eg: fchmod) is called by a program, the corresponding non-f* call is generally called by Linux. Hence, although fchmod is not available in the list above, calls to fchmod() will create a chmod() event. In addition, there are a number of system calls which are dependant on the kernel version and architecture of the host. These are designated by the numbers "32" or "64" appended to some of the system calls. Which system calls are called in any given situation (eg; setuid versus setuid32) will depend on the system architecture of the host system .

C.   The SNARE Audit Subsystem - Configuration File Description

Details on the audit configuration are discussed in the Audit Configuration section. The purpose of this section is to discuss the makeup of the configuration file. The SNARE configuration file is located at /etc/audit/audit.conf , and this location may not be changed. If the configuration file does not exist, the audit daemon will execute, but will not actively audit events until a correctly formatted configuration file is present, or unless specific instructions are passed to the audit module at load time.

SNARE can be configured in several different ways, namely:

a.   Via the graphical tool (Recommended), or
b.   By setting module options at load time, or
c.   By manually editing the configuration file

The user-space audit daemon reads data from the dynamic kernel audit module via the device "/proc/audit". It converts the binary audit data into text format , and separates information out into a series of token/data groups. Three different field separators are used in order to facilitate follow-on processing - TABS separate 'tokens', COMMAS separate data within each token, and SPACES separate elements within data.

A 'Token' is a group of related data, comprising a 'header', and a series of comma separated fields which make up data that relates to the header.

Examples of tokens:

• process,1628,gcc
• return,0
• path,/etc/audit/audit.conf
• arguments,ls -al

testsnare.intersectalliance.com    LinuxAudit    objective,clear,Mon Aug  6 19:43:25 2001,The program /usr/bin/gimp has been executed by the user leigh    event,execve(),Mon Aug  6 19:43:25 2001    user,leigh(500),users(500),leigh(500),users(500)    process,1651,sh    path,/usr/bin/gimp    arguments,gimp    return,0    sequence,12937

#!/usr/bin/perl
# Usage: cat /var/log/audit/audit.log | ./extract.pl
# Creates an associative array containing the elements of the event record, and prints the data.

while($input=<STDIN>) {
    chomp($input);
    %Record=();
    @tokens=split(/\t/,$input);    # Split the line into TAB delimited tokens.
    foreach $token (@tokens) {
        @elements=split(/,/,$token);    # Pick out the elements within each token.
        $header=$elements[0];
        if($header eq "objective") {
            $Record{$header}{"criticality"} = $elements[1];
            $Record{$header}{"datetime"} = $elements[2];
            $Record{$header}{"description"} = $elements[3];
        } elsif ($header eq "event") {
            $Record{$header}{"eventid"} = $elements[1];
            $Record{$header}{"datetime"} = $elements[2];
        } elsif ($header eq "user") {
            $Record{$header}{"uid"} = $elements[1];    # User ID
            $Record{$header}{"gid"} = $elements[2];    # Group ID
            $Record{$header}{"euid"} = $elements[3];   # Effective User ID
            $Record{$header}{"egid"} = $elements[4];   # Effective Group ID
        } elsif ($header eq "process") {
            $Record{$header}{"pid"} = $elements[1];    # Process ID
            $Record{$header}{"name"} = $elements[2];   # Process Name (max 16 chars)
        } elsif ($header eq "path") {
            $Record{$header}{"path"} = $elements[1];
        } elsif ($header eq "destpath") {
            $Record{$header}{"destpath"} = $elements[1];    # Destination path
        } elsif ($header eq "arguments") {
            $Record{$header}{"args"} = $elements[1];
        } elsif ($header eq "attributes") {
            $Record{$header}{"attrib"} = $elements[1];
        } elsif ($header eq "return") {
            $Record{$header}{"code"} = $elements[1];
        } elsif ($header eq "target") {
            $Record{$header}{"user"} = $elements[1];
        } elsif ($header eq "owner") {
            $Record{$header}{"user"} = $elements[1];
            $Record{$header}{"group"} = $elements[2];
        } elsif ($header eq "socket") {
            $Record{$header}{"sourceip"} = $elements[1];
            $Record{$header}{"destip"} = $elements[2];
            $Record{$header}{"sourceport"} = $elements[3];
            $Record{$header}{"destport"} = $elements[4];
        } elsif ($header eq "sequence") {
            $Record{$header}{"number"} = $elements[1];
        }
    }
    # We now have the data in an associative array.
    # Roll through the array, and print the data in token groups.
    foreach $header (keys(%Record)) {
        print "Header: $header\n";
        foreach $element (keys(%{$Record{$header}})) {
            print "$element = " . $Record{$header}{$element} . "\n";
        }
    }

    # In addition, if the event is execve, the effective user ID
    # is 'root', but the real user ID is NOT, then display an alert.
    if($Record{"event"}{"eventid"} eq "execve" && $Record{"user"}{"euid"} eq "root" && $Record{"user"}{"uid"} ne "root") {
        print "Danger: SetUID program " . $Record{"arguments"}{"args"} . " has been run by the user " . $Record{"user"}{"uid"} . " .\n";
     }

    print "\n";
}

print "----- Done -----\n";