The Audit Log Route Configuration File selogrd.cfg

Reference Guide › Configuration Files › The Audit Log Route Configuration File selogrd.cfg

The Audit Log Route Configuration File selogrd.cfg

Valid on UNIX

The following is the format of the configuration file, followed by a detailed explanation.

section‑name‑1
routing‑method destination
[{include|exclude} match‑field(match‑pattern) ...]
...
.
section‑name‑2
routing‑method destination
[{include|exclude} match‑field(match‑pattern) ...]
...
.
...

Specifying Audit Records

The configuration file is a list of which audit records to route-and which not to route-to various destinations. To specify audit records, you describe the contents of one or more particular fields. You can use the standard UNIX pattern matching (the wildcards * and ?).

For example, to specify records that deal with users whose user names begin with the letters dbms, you would enter the following:

User(dbms*)

This example matches users with names like dbms1, dbms_mgr, and so on.

To specify the same users, but only the records that deal with their login attempts, you would enter:

User(dbms*) Class(LOGIN)

Note: When a line specifies records in terms of more than one field, it specifies only the records that match all those fields.

At the beginning of the same line that specifies the records, you specify whether you want the records included or excluded. For example, to include those records in the routing enter the following:

include User(dbms*) Class(LOGIN).

This type of line appears in the overall format as:

[{include|exclude} match‑field(match‑pattern) ... .]

Here, the “...” means that the first match‑field(match‑pattern) pair can be followed by further pairs.

You can use any of the following for match‑field(match‑pattern):

Access(access‑type)

For the type of access required; access‑type is any one of the following:

ACL, Chdir, Chgrp, Chmod, Chown, Connect, Control, Create, Erase, Exec, Kill, Modify, Owngrp, Password, Read, Rename, Replace, Update, Utimes, and Write.

Class(LOGIN)

For login records.

Class(LOGOUT)

For logout records.

Class(PWCHANGE)

For password administration.

Class(HOST)

For TCP/IP records.

Class(UPDATE CA ControlMinder‑class)

For database administration. CA ControlMinder‑class is any of the accessor or resource classes (such as USER, GROUP, FILE, HOSTNP...) or a pattern for the class name to match. Thus for all database administration, you can specify UPDATE *.

Class(CA ControlMinder‑class)

For access to protected resources. For example, Class(FILE) refers to records reporting file access attempts.

Note that you can use an asterisk to combine Class(CA ControlMinder‑class) and Class(UPDATE CA ControlMinder‑class) as Class(*CA ControlMinder‑class). For example, specifying Class(*FILE) is like specifying both Class(FILE) and Class(UPDATE FILE). It refers both to attempts to access files and to attempts to update records in the FILE class.

Code(return‑code)

For the CA ControlMinder return code indicating what happened; return‑code can take the following values. (See also Example 1 in this section.)

A-An attempt to log in failed because an invalid password was entered repeatedly.

D-CA ControlMinder denied access to a resource, did not permit a login, or did not permit an update to the database because the accessor did not have sufficient authorization.

E-Serevu enabled a disabled user account.

F-An attempt to update the database failed.

I-Serevu disabled a user account.

M-The executed command started or shut down a daemon.

O-A user logged out.

P-CA ControlMinder permitted access to a resource or permitted a login.

S-The database was successfully updated.

T-An audit record was written because all the actions of the user are being traced.

U-A Trusted program (setuid or setgid) was changed; therefore it is no longer Trusted.

W-Access to the resource violated the access rules for the resource. However, CA ControlMinder allowed the access because warning mode is set in the resource.

Host(host‑name)

For the host involved in a TCP/IP connection.

Object(resource‑name)

For the resource that the user is attempting to access.

Reason(reason‑number)

For the reason that the audit record is triggered.

Service(service‑name)

For the name of the service requested from the remote host, such as telnet, ftp, or port number.

Source Host(hostname)

For the name of the host that contributed the record to the consolidated audit.

Stage(stage‑number)

For the stage at which access was granted or denied. (See the lists of stage codes in the Reference Guide.)

Terminal(terminal‑name)

For the terminal that is attempting access or administration.

Uid(uid‑number)

For the uid of the user who is attempting access or administration.

User(username)

For users attempting access or administration; username is a name or pattern.

Note: Although some variables are more likely to be specified as patterns, you can use a pattern for any variable-even for something like a stage number.

Refining with Further Lines

To refine your specifications, you can filter by differing criteria at the same time. Simply add one include/exclude line after another. For example:

include User(dbms*) Class(*LOGIN*).
exclude Terminal(console_*).

The example specifies all login attempts by users whose names begin with dbms and who are at terminals that do not have names beginning with console_.

Specifying the Destination

Use a line above your sequence of include and exclude lines to specify the destination for the audit records you are including. For example:

mail weekwatch
include User(dbms*) Class(*LOGIN*).
exclude Terminal(console_*).

The example specifies that the email address weekwatch receives a report on all login attempts by users whose names begin with dbms and who are at terminals that do not have names beginning with console_.

This type of line appears in the format of the log route configuration file as:

routing‑method destination

You can use any of the following methods:

mail address

To email the audit record; address is the destination address. If it is not in the form user@host, it is checked against local user lists and the NIS mail alias map.

Note: If address is a user name and surrogate requests to that user's account are audited, the audit records accumulate endlessly.

screen username

To display the audit record on the screen of the specified user, if that user is logged in at the current host when selogrd forwards the audit record. If the user is not logged in, the display is canceled, not postponed.

cons hostname

To send the audit record to the Security Administrator GUI of the secmon utility on the specified host. If that host is not available, the display is terminated, not postponed.

file textfilename

To write the audit record in the specified ASCII file; textfilename must be an absolute path name and selogrd must have access to the file.

host hostname

To send the audit record to the audit log collector on the specified host. If that host is not available, selogrd tries again later.

notify mail or notify default

To email the audit record to the address that the audit record itself specifies.

notify screen

To display the audit record on the screen of the user that the audit record itself specifies. If the user is not logged on, the display is canceled, not postponed.

syslog priority

To send the audit records to the syslog with a specified log priority:

LOG_EMERG—System is unusable.
LOG_ALERT—Action must be taken immediately.
LOG_CRIT—Critical conditions.
LOG_ERR—Error conditions.
LOG_WARNING—Warning conditions.
LOG_NOTICE—Normal but significant condition.
LOG_INFO—Informational.
LOG_DEBUG—Debug-level messages.

uni hostname

To send the audit record to the Unicenter TNG event manager on the specified host. You must also set selogrd to load the uni.so shared library, which is found in the ACInstallDir/lib directory. Note that the installation performs this task for you if it finds Unicenter TNG installed on the specified host and you choose to do it.

Proper Sequence for Lines

It is important to arrange your include and exclude lines in proper sequence, properly delimited.

You must precede each sequence of lines (or single line) that you want to treat as a single complex filter with a title line, and end it with a terminating line that consists of a single dot; for example:
dbms login from non‑console
```
	mail weekwatch
```
include User(dbms*) Class(*LOGIN*).
```
	exclude Terminal(console_*).
	.
```

The full sequence, including the title line and terminating line, is called a section of the file.

If both include and exclude lines match the same audit record in the same section, the last match overrides all others.
If no lines match a particular audit record, then the first line of the section is the deciding line for that record. (If the first line is an include line, then the failure to match excludes the record. If the first line is an exclude line, then the failure to match includes the record for routing.)
If the section includes no include and exclude lines, then it includes all audit records for routing.

How Sections Coexist

Whereas the lines of a section work together to produce a single decision as to whether or not a record is to be sent, different sections in the configuration file work entirely independently. Whether or not an audit record is sent by one section, has no influence on whether the same audit record is sent by another section.

You can send the same selection of audit records to more than one destination, and the same destination can receive more than one selection of audit records.

In your configuration file, the total of all the include and exclude lines-from all the sections together-must not exceed 64 lines.

Including Comments

To add a comment line to the configuration file, begin the line with a semicolon.

Example 1

The following is a sample configuration file, followed by its explanation.

 ; Product : CA ControlMinder
 ; Module  : selogrd
 ; Purpose : route table for audit log routing daemon
 ;
 ;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑
  Rule#1
  mail jones@admhost
  include       Class(*LOGIN*) Code(D).
  .
  Rule#2
  mail smith
  include       Class(*SURROGATE*) Object(USER.root*).
  .
  Rule#3
  host venus
  exclude       Class(UPDATE SU*).
  .
  Rule#4
  host venus
  include       Class(*PROGRAM*) Object(/usr/bin/ps).
  .

The first five lines are comment lines.

The next four lines make up the first section, named Rule#1. They tell selogrd to mail a log record to the address jones@admhost whenever a login request is denied (code D reports denial):

Rule#1
mail jones@admhost
include       Class(*LOGIN*) Code(D).
.

The next section is named Rule#2. It tells selogrd to mail a log record to the address smith whenever someone attempts to use the su command to enter the root account (the objects in the SURROGATE class are targets for the su command):

Rule#2
mail smith
include       Class(*SURROGATE*) Object(USER.root*).
.

The next section is named Rule#3. It tells selogrd to send a log record to the collector on host venus whenever someone attempts database administration, unless the class name begins with the letters SU (the matching classes are SURROGATE and SUDO):

Rule#3
host venus
exclude       Class(UPDATE SU*).

The last section is named Rule#4. It tells selogrd to send a log record to the collector on host venus whenever someone attempts to use the ps command:

(Code 1 8pt) Rule#4
host venus
include       Class(*PROGRAM*) Object(/usr/bin/ps).
.

Example 2

The following configuration file sends all audit records to the collector on the station named loghost:

 ; Product : CA ControlMinder
 ; Module  : selogrd
 ; Purpose : route table for audit log routing daemon
 ;
 ;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑
  Rule#1
  host loghost
  .

Return Codes

You can associate each type of record in the configuration file with one or more CA ControlMinder return code. (For a complete list of the return codes see the description of code(return‑code) in Specifying Audit Records in this section.) The following table describes the record types and their associated return codes.

Record Type	Class or Event	Associated Return Codes
Login	LOGIN LOGINDISABLE LOGINENABLE	D, P, W I E
Logout	LOGOUT	O
TCP/IP	HOST	D, P
Resource classes	Class name	D, P, W
Watchdog	PROGRAM SECFILE	U U
Password administration	PWCHANGE	D
Down	SHUTDOWN	D, S
Start	START	S
CA ControlMinder database administration	UPDATE	D, F, S

Manage JCS Connector Log File Names and Log Levels

You can use the following configuration file to manage log file names for SSH, Network-device, Sybase, ACF2, and RACF JCS log file connectors.

<JCS-directory>\conf\log4j.properties

This file is used to set the log file names for each of the preceding connectors. The log file names are:

ssh.log
network_device.log
sybase.log
acf2.log
racf.log

You can configure the log detail level for each connector according to the following level scale:

Trace
Debug
Info
Warn
Error
Fatal

The SSH connector collects only logs from the level that is set on the scale and lower. For example, the SSH connector collects logs only from the debug, info, warn, error, and fatal levels when set as follows:

log4j.logger.com.ca.jcs.sshdyn=INFO, ssh
log4j.logger.com.ca.sessame.conn.unix=INFO, ssh

Note: Each connector log file is saved to a back-up and a new log is started each day.