Whitespace-only fixes. Translators, please ignore.
This commit is contained in:
Warren Block
parent
c0ce3355ee
commit
94bfe9a16b
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=39825
1 changed files with 329 additions and 296 deletions
|
|
@ -44,18 +44,19 @@ requirements. -->
|
|||
changes, and file and network access. These log records can be
|
||||
invaluable for live system monitoring, intrusion detection, and
|
||||
postmortem analysis. &os; implements &sun;'s published
|
||||
<acronym>BSM</acronym> API and file format, and is interoperable with
|
||||
both &sun;'s &solaris; and &apple;'s &macos; X audit implementations.</para>
|
||||
<acronym>BSM</acronym> API and file format, and is interoperable
|
||||
with both &sun;'s &solaris; and &apple;'s &macos; X audit
|
||||
implementations.</para>
|
||||
|
||||
<para>This chapter focuses on the installation and configuration of
|
||||
Event Auditing. It explains audit policies, and provides an example
|
||||
audit configuration.</para>
|
||||
<para>This chapter focuses on the installation and configuration
|
||||
of Event Auditing. It explains audit policies, and provides an
|
||||
example audit configuration.</para>
|
||||
|
||||
<para>After reading this chapter, you will know:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>What Event Auditing is and how it works.</para>
|
||||
<para>What Event Auditing is and how it works.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
|
@ -64,8 +65,8 @@ requirements. -->
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>How to review the audit trail using the audit reduction and
|
||||
review tools.</para>
|
||||
<para>How to review the audit trail using the audit reduction
|
||||
and review tools.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
|
|
@ -90,59 +91,60 @@ requirements. -->
|
|||
</itemizedlist>
|
||||
|
||||
<warning>
|
||||
<para>The audit facility has some known limitations which include
|
||||
that not all security-relevant system events are currently auditable,
|
||||
and that some login mechanisms, such as X11-based display managers
|
||||
and third party daemons, do not properly configure auditing for user
|
||||
login sessions.</para>
|
||||
<para>The audit facility has some known limitations which
|
||||
include that not all security-relevant system events are
|
||||
currently auditable, and that some login mechanisms, such as
|
||||
X11-based display managers and third party daemons, do not
|
||||
properly configure auditing for user login sessions.</para>
|
||||
|
||||
<para>The security event auditing facility is able to generate very
|
||||
detailed logs of system activity: on a busy system, trail file
|
||||
data can be very large when configured for high detail, exceeding
|
||||
gigabytes a week in some configurations. Administrators should take
|
||||
into account disk space requirements associated with high volume
|
||||
audit configurations. For example, it may be desirable to dedicate
|
||||
a file system to the <filename>/var/audit</filename> tree so that
|
||||
other file systems are not affected if the audit file system becomes
|
||||
<para>The security event auditing facility is able to generate
|
||||
very detailed logs of system activity: on a busy system, trail
|
||||
file data can be very large when configured for high detail,
|
||||
exceeding gigabytes a week in some configurations.
|
||||
Administrators should take into account disk space
|
||||
requirements associated with high volume audit configurations.
|
||||
For example, it may be desirable to dedicate a file system to
|
||||
the <filename>/var/audit</filename> tree so that other file
|
||||
systems are not affected if the audit file system becomes
|
||||
full.</para>
|
||||
</warning>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="audit-inline-glossary">
|
||||
<title>Key Terms in This Chapter</title>
|
||||
|
||||
<para>Before reading this chapter, a few key audit-related terms must be
|
||||
explained:</para>
|
||||
<para>Before reading this chapter, a few key audit-related terms
|
||||
must be explained:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><emphasis>event</emphasis>: An auditable event is any event
|
||||
that can be logged using the audit subsystem.
|
||||
<para><emphasis>event</emphasis>: An auditable event is any
|
||||
event that can be logged using the audit subsystem.
|
||||
Examples of security-relevant events include the creation of
|
||||
a file, the building of a network connection, or a user logging in.
|
||||
Events are either <quote>attributable</quote>,
|
||||
a file, the building of a network connection, or a user
|
||||
logging in. Events are either <quote>attributable</quote>,
|
||||
meaning that they can be traced to an authenticated user, or
|
||||
<quote>non-attributable</quote> if they cannot be.
|
||||
Examples of non-attributable events are any events that occur
|
||||
before authentication in the login process, such as bad password
|
||||
<quote>non-attributable</quote> if they cannot be. Examples
|
||||
of non-attributable events are any events that occur before
|
||||
authentication in the login process, such as bad password
|
||||
attempts.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>class</emphasis>: Event classes are named sets of
|
||||
related events, and are used in selection expressions. Commonly
|
||||
used classes of events include <quote>file creation</quote> (fc),
|
||||
<quote>exec</quote> (ex) and <quote>login_logout</quote>
|
||||
(lo).</para>
|
||||
<para><emphasis>class</emphasis>: Event classes are named sets
|
||||
of related events, and are used in selection expressions.
|
||||
Commonly used classes of events include
|
||||
<quote>file creation</quote> (fc), <quote>exec</quote> (ex)
|
||||
and <quote>login_logout</quote> (lo).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>record</emphasis>: A record is an audit log entry
|
||||
describing a security event. Records contain a record event type,
|
||||
information on the subject (user) performing the action,
|
||||
date and time information, information on any objects or
|
||||
arguments, and a success or failure condition.</para>
|
||||
<para><emphasis>record</emphasis>: A record is an audit log
|
||||
entry describing a security event. Records contain a record
|
||||
event type, information on the subject (user) performing the
|
||||
action, date and time information, information on any
|
||||
objects or arguments, and a success or failure
|
||||
condition.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
|
@ -156,30 +158,31 @@ requirements. -->
|
|||
|
||||
<listitem>
|
||||
<para><emphasis>selection expression</emphasis>: A selection
|
||||
expression is a string containing a list of prefixes and audit
|
||||
event class names used to match events.</para>
|
||||
expression is a string containing a list of prefixes and
|
||||
audit event class names used to match events.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>preselection</emphasis>: The process by which the
|
||||
system identifies which events are of interest to the administrator
|
||||
in order to avoid generating audit records describing events that
|
||||
are not of interest. The preselection configuration
|
||||
uses a series of selection expressions to identify which classes
|
||||
of events to audit for which users, as well as global settings
|
||||
that apply to both authenticated and unauthenticated
|
||||
processes.</para>
|
||||
<para><emphasis>preselection</emphasis>: The process by which
|
||||
the system identifies which events are of interest to the
|
||||
administrator in order to avoid generating audit records
|
||||
describing events that are not of interest. The
|
||||
preselection configuration uses a series of selection
|
||||
expressions to identify which classes of events to audit for
|
||||
which users, as well as global settings that apply to both
|
||||
authenticated and unauthenticated processes.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>reduction</emphasis>: The process by which records
|
||||
from existing audit trails are selected for preservation, printing,
|
||||
or analysis. Likewise, the process by which undesired audit
|
||||
records are removed from the audit trail. Using reduction,
|
||||
administrators can implement policies for the preservation of audit
|
||||
data. For example, detailed audit trails might be kept for one
|
||||
month, but after that, trails might be reduced in order to preserve
|
||||
only login information for archival purposes.</para>
|
||||
<para><emphasis>reduction</emphasis>: The process by which
|
||||
records from existing audit trails are selected for
|
||||
preservation, printing, or analysis. Likewise, the process
|
||||
by which undesired audit records are removed from the audit
|
||||
trail. Using reduction, administrators can implement
|
||||
policies for the preservation of audit data. For example,
|
||||
detailed audit trails might be kept for one month, but after
|
||||
that, trails might be reduced in order to preserve only
|
||||
login information for archival purposes.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect1>
|
||||
|
|
@ -187,11 +190,11 @@ requirements. -->
|
|||
<sect1 id="audit-install">
|
||||
<title>Installing Audit Support</title>
|
||||
|
||||
<para>User space support for Event Auditing is installed as part of the
|
||||
base &os; operating system. Kernel support for
|
||||
Event Auditing is compiled in by default, but support for this
|
||||
feature must be explicitly compiled into the custom kernel by adding
|
||||
the following line to the kernel configuration file:</para>
|
||||
<para>User space support for Event Auditing is installed as part
|
||||
of the base &os; operating system. Kernel support for Event
|
||||
Auditing is compiled in by default, but support for this feature
|
||||
must be explicitly compiled into the custom kernel by adding the
|
||||
following line to the kernel configuration file:</para>
|
||||
|
||||
<programlisting>options AUDIT</programlisting>
|
||||
|
||||
|
|
@ -199,14 +202,14 @@ requirements. -->
|
|||
the kernel via the normal process explained in
|
||||
<xref linkend="kernelconfig"/>.</para>
|
||||
|
||||
<para>Once an audit-enabled kernel is built, installed, and the system
|
||||
has been rebooted, enable the audit daemon by adding the following line
|
||||
to &man.rc.conf.5;:</para>
|
||||
<para>Once an audit-enabled kernel is built, installed, and the
|
||||
system has been rebooted, enable the audit daemon by adding the
|
||||
following line to &man.rc.conf.5;:</para>
|
||||
|
||||
<programlisting>auditd_enable="YES"</programlisting>
|
||||
|
||||
<para>Audit support must then be started by a reboot, or by manually
|
||||
starting the audit daemon:</para>
|
||||
<para>Audit support must then be started by a reboot, or by
|
||||
manually starting the audit daemon:</para>
|
||||
|
||||
<programlisting>/etc/rc.d/auditd start</programlisting>
|
||||
</sect1>
|
||||
|
|
@ -215,8 +218,9 @@ requirements. -->
|
|||
<title>Audit Configuration</title>
|
||||
|
||||
<para>All configuration files for security audit are found in
|
||||
<filename class="directory">/etc/security</filename>. The following
|
||||
files must be present before the audit daemon is started:</para>
|
||||
<filename class="directory">/etc/security</filename>. The
|
||||
following files must be present before the audit daemon is
|
||||
started:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
|
|
@ -233,8 +237,8 @@ requirements. -->
|
|||
|
||||
<listitem>
|
||||
<para><filename>audit_event</filename> - Textual names and
|
||||
descriptions of system audit events, as well as a list of which
|
||||
classes each event is in.</para>
|
||||
descriptions of system audit events, as well as a list of
|
||||
which classes each event is in.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
|
@ -244,10 +248,11 @@ requirements. -->
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename>audit_warn</filename> - A customizable shell script
|
||||
used by <application>auditd</application> to generate warning messages in exceptional
|
||||
situations, such as when space for audit records is running low or
|
||||
when the audit trail file has been rotated.</para>
|
||||
<para><filename>audit_warn</filename> - A customizable shell
|
||||
script used by <application>auditd</application> to generate
|
||||
warning messages in exceptional situations, such as when
|
||||
space for audit records is running low or when the audit
|
||||
trail file has been rotated.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
|
|
@ -260,70 +265,76 @@ requirements. -->
|
|||
<sect2>
|
||||
<title>Event Selection Expressions</title>
|
||||
|
||||
<para>Selection expressions are used in a number of places in the
|
||||
audit configuration to determine which events should be audited.
|
||||
Expressions contain a list of event classes to match, each with
|
||||
a prefix indicating whether matching records should be accepted
|
||||
or ignored, and optionally to indicate if the entry is intended
|
||||
to match successful or failed operations. Selection expressions
|
||||
are evaluated from left to right, and two expressions are
|
||||
combined by appending one onto the other.</para>
|
||||
<para>Selection expressions are used in a number of places in
|
||||
the audit configuration to determine which events should be
|
||||
audited. Expressions contain a list of event classes to match,
|
||||
each with a prefix indicating whether matching records should
|
||||
be accepted or ignored, and optionally to indicate if the
|
||||
entry is intended to match successful or failed operations.
|
||||
Selection expressions are evaluated from left to right, and
|
||||
two expressions are combined by appending one onto the
|
||||
other.</para>
|
||||
|
||||
<para>The following list contains the default audit event classes
|
||||
present in <filename>audit_class</filename>:</para>
|
||||
<para>The following list contains the default audit event
|
||||
classes present in <filename>audit_class</filename>:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><literal>all</literal> - <emphasis>all</emphasis> - Match all
|
||||
event classes.</para>
|
||||
<para><literal>all</literal> - <emphasis>all</emphasis> -
|
||||
Match all event classes.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><literal>ad</literal> - <emphasis>administrative</emphasis>
|
||||
- Administrative actions performed on the system as a
|
||||
whole.</para>
|
||||
<para><literal>ad</literal> -
|
||||
<emphasis>administrative</emphasis> - Administrative
|
||||
actions performed on the system as a whole.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><literal>ap</literal> - <emphasis>application</emphasis> -
|
||||
Application defined action.</para>
|
||||
<para><literal>ap</literal> -
|
||||
<emphasis>application</emphasis> - Application defined
|
||||
action.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><literal>cl</literal> - <emphasis>file close</emphasis> -
|
||||
Audit calls to the <function>close</function> system
|
||||
call.</para>
|
||||
<para><literal>cl</literal> -
|
||||
<emphasis>file close</emphasis> - Audit calls to the
|
||||
<function>close</function> system call.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><literal>ex</literal> - <emphasis>exec</emphasis> - Audit
|
||||
program execution. Auditing of command line arguments and
|
||||
environmental variables is controlled via &man.audit.control.5;
|
||||
using the <literal>argv</literal> and <literal>envv</literal>
|
||||
parameters to the <literal>policy</literal> setting.</para>
|
||||
<para><literal>ex</literal> - <emphasis>exec</emphasis> -
|
||||
Audit program execution. Auditing of command line
|
||||
arguments and environmental variables is controlled via
|
||||
&man.audit.control.5; using the <literal>argv</literal>
|
||||
and <literal>envv</literal> parameters to the
|
||||
<literal>policy</literal> setting.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><literal>fa</literal> - <emphasis>file attribute access</emphasis>
|
||||
- Audit the access of object attributes such as
|
||||
&man.stat.1;, &man.pathconf.2; and similar events.</para>
|
||||
<para><literal>fa</literal> -
|
||||
<emphasis>file attribute access</emphasis> - Audit the
|
||||
access of object attributes such as &man.stat.1;,
|
||||
&man.pathconf.2; and similar events.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><literal>fc</literal> - <emphasis>file create</emphasis>
|
||||
- Audit events where a file is created as a result.</para>
|
||||
<para><literal>fc</literal> -
|
||||
<emphasis>file create</emphasis> - Audit events where a
|
||||
file is created as a result.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><literal>fd</literal> - <emphasis>file delete</emphasis>
|
||||
- Audit events where file deletion occurs.</para>
|
||||
<para><literal>fd</literal> -
|
||||
<emphasis>file delete</emphasis> - Audit events where file
|
||||
deletion occurs.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><literal>fm</literal> - <emphasis>file attribute modify</emphasis>
|
||||
- Audit events where file attribute modification occurs,
|
||||
such as &man.chown.8;, &man.chflags.1;, &man.flock.2;,
|
||||
etc.</para>
|
||||
<para><literal>fm</literal> -
|
||||
<emphasis>file attribute modify</emphasis> - Audit events
|
||||
where file attribute modification occurs, such as
|
||||
&man.chown.8;, &man.chflags.1;, &man.flock.2;, etc.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
|
@ -333,36 +344,40 @@ requirements. -->
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><literal>fw</literal> - <emphasis>file write</emphasis> -
|
||||
Audit events in which data is written, files are written
|
||||
or modified, etc.</para>
|
||||
<para><literal>fw</literal> -
|
||||
<emphasis>file write</emphasis> - Audit events in which
|
||||
data is written, files are written or modified,
|
||||
etc.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><literal>io</literal> - <emphasis>ioctl</emphasis> - Audit
|
||||
use of the &man.ioctl.2; system call.</para>
|
||||
<para><literal>io</literal> - <emphasis>ioctl</emphasis> -
|
||||
Audit use of the &man.ioctl.2; system call.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><literal>ip</literal> - <emphasis>ipc</emphasis> - Audit
|
||||
various forms of Inter-Process Communication, including POSIX
|
||||
pipes and System V <acronym>IPC</acronym> operations.</para>
|
||||
<para><literal>ip</literal> - <emphasis>ipc</emphasis> -
|
||||
Audit various forms of Inter-Process Communication,
|
||||
including POSIX pipes and System V <acronym>IPC</acronym>
|
||||
operations.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><literal>lo</literal> - <emphasis>login_logout</emphasis> -
|
||||
Audit &man.login.1; and &man.logout.1; events occurring
|
||||
on the system.</para>
|
||||
<para><literal>lo</literal> -
|
||||
<emphasis>login_logout</emphasis> - Audit &man.login.1;
|
||||
and &man.logout.1; events occurring on the system.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><literal>na</literal> - <emphasis>non attributable</emphasis> -
|
||||
Audit non-attributable events.</para>
|
||||
<para><literal>na</literal> -
|
||||
<emphasis>non attributable</emphasis> - Audit
|
||||
non-attributable events.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><literal>no</literal> - <emphasis>invalid class</emphasis> -
|
||||
Match no audit events.</para>
|
||||
<para><literal>no</literal> -
|
||||
<emphasis>invalid class</emphasis> - Match no audit
|
||||
events.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
|
@ -384,19 +399,19 @@ requirements. -->
|
|||
|
||||
</itemizedlist>
|
||||
|
||||
<para>These audit event classes may be customized by modifying the
|
||||
<filename>audit_class</filename> and
|
||||
<para>These audit event classes may be customized by modifying
|
||||
the <filename>audit_class</filename> and
|
||||
<filename>audit_event</filename> configuration files.</para>
|
||||
|
||||
<para>Each audit class in the list is combined with a prefix
|
||||
indicating whether successful/failed operations are matched, and
|
||||
whether the entry is adding or removing matching for the class
|
||||
and type.</para>
|
||||
indicating whether successful/failed operations are matched,
|
||||
and whether the entry is adding or removing matching for the
|
||||
class and type.</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>(none) Audit both successful and failed instances of the
|
||||
event.</para>
|
||||
<para>(none) Audit both successful and failed instances of
|
||||
the event.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
|
@ -410,45 +425,44 @@ requirements. -->
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><literal>^</literal> Audit neither successful nor failed
|
||||
events in this class.</para>
|
||||
<para><literal>^</literal> Audit neither successful nor
|
||||
failed events in this class.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><literal>^+</literal> Do not audit successful events in this
|
||||
class.</para>
|
||||
<para><literal>^+</literal> Do not audit successful events
|
||||
in this class.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><literal>^-</literal> Do not audit failed events in this
|
||||
class.</para>
|
||||
<para><literal>^-</literal> Do not audit failed events in
|
||||
this class.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
<para>The following example selection string selects both successful
|
||||
and failed login/logout events, but only successful execution
|
||||
events:</para>
|
||||
<para>The following example selection string selects both
|
||||
successful and failed login/logout events, but only successful
|
||||
execution events:</para>
|
||||
|
||||
<programlisting>lo,+ex</programlisting>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Configuration Files</title>
|
||||
|
||||
<para>In most cases, administrators will need to modify only two files
|
||||
when configuring the audit system: <filename>audit_control</filename>
|
||||
and <filename>audit_user</filename>. The first controls system-wide
|
||||
audit properties and policies; the second may be used to fine-tune
|
||||
auditing by user.</para>
|
||||
<para>In most cases, administrators will need to modify only two
|
||||
files when configuring the audit system:
|
||||
<filename>audit_control</filename> and
|
||||
<filename>audit_user</filename>. The first controls
|
||||
system-wide audit properties and policies; the second may be
|
||||
used to fine-tune auditing by user.</para>
|
||||
|
||||
<sect3 id="audit-auditcontrol">
|
||||
<title>The <filename>audit_control</filename> File</title>
|
||||
<title>The <filename>audit_control</filename> File</title>
|
||||
|
||||
<para>The <filename>audit_control</filename> file specifies a number
|
||||
of defaults for the audit subsystem. Viewing the contents of this
|
||||
file, we see the following:</para>
|
||||
<para>The <filename>audit_control</filename> file specifies a
|
||||
number of defaults for the audit subsystem. Viewing the
|
||||
contents of this file, we see the following:</para>
|
||||
|
||||
<programlisting>dir:/var/audit
|
||||
flags:lo
|
||||
|
|
@ -457,71 +471,73 @@ naflags:lo
|
|||
policy:cnt
|
||||
filesz:0</programlisting>
|
||||
|
||||
<para>The <option>dir</option> option is used to set one or more
|
||||
directories where audit logs will be stored. If more than one
|
||||
directory entry appears, they will be used in order as they fill.
|
||||
It is common to configure audit so that audit logs are stored on
|
||||
a dedicated file system, in order to prevent interference between
|
||||
the audit subsystem and other subsystems if the file system fills.
|
||||
</para>
|
||||
<para>The <option>dir</option> option is used to set one or
|
||||
more directories where audit logs will be stored. If more
|
||||
than one directory entry appears, they will be used in order
|
||||
as they fill. It is common to configure audit so that audit
|
||||
logs are stored on a dedicated file system, in order to
|
||||
prevent interference between the audit subsystem and other
|
||||
subsystems if the file system fills.</para>
|
||||
|
||||
<para>The <option>flags</option> field sets the system-wide default
|
||||
preselection mask for attributable events. In the example above,
|
||||
successful and failed login and logout events are audited for all
|
||||
users.</para>
|
||||
<para>The <option>flags</option> field sets the system-wide
|
||||
default preselection mask for attributable events. In the
|
||||
example above, successful and failed login and logout events
|
||||
are audited for all users.</para>
|
||||
|
||||
<para>The <option>minfree</option> option defines the minimum
|
||||
percentage of free space for the file system where the audit trail
|
||||
is stored. When this threshold is exceeded, a warning will be
|
||||
generated. The above example sets the minimum free space to
|
||||
twenty percent.</para>
|
||||
percentage of free space for the file system where the audit
|
||||
trail is stored. When this threshold is exceeded, a warning
|
||||
will be generated. The above example sets the minimum free
|
||||
space to twenty percent.</para>
|
||||
|
||||
<para>The <option>naflags</option> option specifies audit classes to
|
||||
be audited for non-attributed events, such as the login process
|
||||
and system daemons.</para>
|
||||
<para>The <option>naflags</option> option specifies audit
|
||||
classes to be audited for non-attributed events, such as the
|
||||
login process and system daemons.</para>
|
||||
|
||||
<para>The <option>policy</option> option specifies a comma-separated
|
||||
list of policy flags controlling various aspects of audit
|
||||
behavior. The default <literal>cnt</literal> flag indicates that
|
||||
the system should continue running despite an auditing failure
|
||||
(this flag is highly recommended). Another commonly used flag is
|
||||
<literal>argv</literal>, which causes command line arguments to
|
||||
the &man.execve.2; system call to be audited as part of command
|
||||
execution.</para>
|
||||
<para>The <option>policy</option> option specifies a
|
||||
comma-separated list of policy flags controlling various
|
||||
aspects of audit behavior. The default
|
||||
<literal>cnt</literal> flag indicates that the system should
|
||||
continue running despite an auditing failure (this flag is
|
||||
highly recommended). Another commonly used flag is
|
||||
<literal>argv</literal>, which causes command line arguments
|
||||
to the &man.execve.2; system call to be audited as part of
|
||||
command execution.</para>
|
||||
|
||||
<para>The <option>filesz</option> option specifies the maximum size
|
||||
in bytes to allow an audit trail file to grow to before
|
||||
<para>The <option>filesz</option> option specifies the maximum
|
||||
size in bytes to allow an audit trail file to grow to before
|
||||
automatically terminating and rotating the trail file. The
|
||||
default, 0, disables automatic log rotation. If the requested
|
||||
file size is non-zero and below the minimum 512k, it will be
|
||||
ignored and a log message will be generated.</para>
|
||||
default, 0, disables automatic log rotation. If the
|
||||
requested file size is non-zero and below the minimum 512k,
|
||||
it will be ignored and a log message will be
|
||||
generated.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3 id="audit-audituser">
|
||||
<title>The <filename>audit_user</filename> File</title>
|
||||
|
||||
<para>The <filename>audit_user</filename> file permits the
|
||||
administrator to specify further audit requirements for specific
|
||||
users.
|
||||
Each line configures auditing for a user via two fields: the
|
||||
first is the <literal>alwaysaudit</literal> field, which specifies
|
||||
a set of events that should always be audited for the user, and
|
||||
administrator to specify further audit requirements for
|
||||
specific users. Each line configures auditing for a user
|
||||
via two fields: the first is the
|
||||
<literal>alwaysaudit</literal> field, which specifies a set
|
||||
of events that should always be audited for the user, and
|
||||
the second is the <literal>neveraudit</literal> field, which
|
||||
specifies a set of events that should never be audited for the
|
||||
user.</para>
|
||||
specifies a set of events that should never be audited for
|
||||
the user.</para>
|
||||
|
||||
<para>The following example <filename>audit_user</filename> file
|
||||
audits login/logout events and successful command execution for
|
||||
the <username>root</username> user, and audits file creation and successful command
|
||||
execution for the <username>www</username> user.
|
||||
If used with the example <filename>audit_control</filename> file
|
||||
above, the <literal>lo</literal> entry for <username>root</username>
|
||||
is redundant, and login/logout events will also be audited for the
|
||||
<username>www</username> user.</para>
|
||||
<para>The following example <filename>audit_user</filename>
|
||||
file audits login/logout events and successful command
|
||||
execution for the <username>root</username> user, and audits
|
||||
file creation and successful command execution for the
|
||||
<username>www</username> user. If used with the example
|
||||
<filename>audit_control</filename> file above, the
|
||||
<literal>lo</literal> entry for <username>root</username> is
|
||||
redundant, and login/logout events will also be audited for
|
||||
the <username>www</username> user.</para>
|
||||
|
||||
<programlisting>root:lo,+ex:no
|
||||
www:fc,+ex:no</programlisting>
|
||||
|
||||
</sect3>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
|
@ -532,29 +548,32 @@ www:fc,+ex:no</programlisting>
|
|||
<sect2>
|
||||
<title>Viewing Audit Trails</title>
|
||||
|
||||
<para>Audit trails are stored in the BSM binary format, so tools must
|
||||
be used to modify or convert to text. The &man.praudit.1;
|
||||
command converts trail files to a simple text format; the
|
||||
&man.auditreduce.1; command may be used to reduce the
|
||||
audit trail file for analysis, archiving, or printing purposes.
|
||||
<command>auditreduce</command> supports a variety of selection
|
||||
parameters, including event type, event class, user, date or time of
|
||||
the event, and the file path or object acted on.</para>
|
||||
<para>Audit trails are stored in the BSM binary format, so tools
|
||||
must be used to modify or convert to text. The
|
||||
&man.praudit.1; command converts trail files to a simple text
|
||||
format; the &man.auditreduce.1; command may be used to reduce
|
||||
the audit trail file for analysis, archiving, or printing
|
||||
purposes. <command>auditreduce</command> supports a variety
|
||||
of selection parameters, including event type, event class,
|
||||
user, date or time of the event, and the file path or object
|
||||
acted on.</para>
|
||||
|
||||
<para>For example, the <command>praudit</command> utility will dump
|
||||
the entire contents of a specified audit log in plain text:</para>
|
||||
<para>For example, the <command>praudit</command> utility will
|
||||
dump the entire contents of a specified audit log in plain
|
||||
text:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>praudit /var/audit/AUDITFILE</userinput></screen>
|
||||
|
||||
<para>Where <filename><replaceable>AUDITFILE</replaceable></filename> is the audit log to
|
||||
dump.</para>
|
||||
<para>Where
|
||||
<filename><replaceable>AUDITFILE</replaceable></filename> is
|
||||
the audit log to dump.</para>
|
||||
|
||||
<para>Audit trails consist of a series of audit records made up of
|
||||
tokens, which <command>praudit</command> prints sequentially one per
|
||||
line. Each token is of a specific type, such as
|
||||
<literal>header</literal> holding an audit record header, or
|
||||
<literal>path</literal> holding a file path from a name
|
||||
lookup. The following is an example of an
|
||||
<para>Audit trails consist of a series of audit records made up
|
||||
of tokens, which <command>praudit</command> prints
|
||||
sequentially one per line. Each token is of a specific type,
|
||||
such as <literal>header</literal> holding an audit record
|
||||
header, or <literal>path</literal> holding a file path from a
|
||||
name lookup. The following is an example of an
|
||||
<literal>execve</literal> event:</para>
|
||||
|
||||
<programlisting>header,133,10,execve(2),0,Mon Sep 25 15:58:03 2006, + 384 msec
|
||||
|
|
@ -565,112 +584,124 @@ subject,robert,root,wheel,root,wheel,38439,38032,42086,128.232.9.100
|
|||
return,success,0
|
||||
trailer,133</programlisting>
|
||||
|
||||
<para>This audit represents a successful <literal>execve</literal>
|
||||
call, in which the command <literal>finger doug</literal> has been run. The
|
||||
arguments token contains both the processed command line presented
|
||||
by the shell to the kernel. The <literal>path</literal> token holds the path to the
|
||||
executable as looked up by the kernel. The <literal>attribute</literal> token
|
||||
describes the binary, and in particular, includes the file mode
|
||||
which can be used to determine if the application was setuid.
|
||||
The <literal>subject</literal> token describes the subject process, and stores in
|
||||
sequence the audit user ID, effective user ID and group ID, real
|
||||
user ID and group ID, process ID, session ID, port ID, and login
|
||||
address. Notice that the audit user ID and real user ID differ:
|
||||
the user <username>robert</username> has switched to the
|
||||
<username>root</username> account before running this command, but
|
||||
it is audited using the original authenticated user. Finally, the
|
||||
<literal>return</literal> token indicates the successful execution, and the <literal>trailer</literal>
|
||||
<para>This audit represents a successful
|
||||
<literal>execve</literal> call, in which the command
|
||||
<literal>finger doug</literal> has been run. The arguments
|
||||
token contains both the processed command line presented by
|
||||
the shell to the kernel. The <literal>path</literal> token
|
||||
holds the path to the executable as looked up by the kernel.
|
||||
The <literal>attribute</literal> token describes the binary,
|
||||
and in particular, includes the file mode which can be used to
|
||||
determine if the application was setuid. The
|
||||
<literal>subject</literal> token describes the subject
|
||||
process, and stores in sequence the audit user ID, effective
|
||||
user ID and group ID, real user ID and group ID, process ID,
|
||||
session ID, port ID, and login address. Notice that the audit
|
||||
user ID and real user ID differ: the user
|
||||
<username>robert</username> has switched to the
|
||||
<username>root</username> account before running this command,
|
||||
but it is audited using the original authenticated user.
|
||||
Finally, the <literal>return</literal> token indicates the
|
||||
successful execution, and the <literal>trailer</literal>
|
||||
concludes the record.</para>
|
||||
|
||||
<para><command>praudit</command> also supports
|
||||
an XML output format, which can be selected using the
|
||||
<option>-x</option> argument.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Reducing Audit Trails</title>
|
||||
|
||||
<para>Since audit logs may be very large, an administrator will
|
||||
likely want to select a subset of records for using, such as records
|
||||
associated with a specific user:</para>
|
||||
likely want to select a subset of records for using, such as
|
||||
records associated with a specific user:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>auditreduce -u trhodes /var/audit/AUDITFILE | praudit</userinput></screen>
|
||||
|
||||
<para>This will select all audit records produced for the user
|
||||
<username>trhodes</username> stored in the
|
||||
<filename><replaceable>AUDITFILE</replaceable></filename> file.</para>
|
||||
<filename><replaceable>AUDITFILE</replaceable></filename>
|
||||
file.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Delegating Audit Review Rights</title>
|
||||
|
||||
<para>Members of the <groupname>audit</groupname> group are given
|
||||
permission to read audit trails in <filename>/var/audit</filename>;
|
||||
by default, this group is empty, so only the <username>root</username> user may read
|
||||
audit trails. Users may be added to the <groupname>audit</groupname>
|
||||
group in order to delegate audit review rights to the user. As
|
||||
the ability to track audit log contents provides significant insight
|
||||
into the behavior of users and processes, it is recommended that the
|
||||
delegation of audit review rights be performed with caution.</para>
|
||||
<para>Members of the <groupname>audit</groupname> group are
|
||||
given permission to read audit trails in
|
||||
<filename>/var/audit</filename>; by default, this group is
|
||||
empty, so only the <username>root</username> user may read
|
||||
audit trails. Users may be added to the
|
||||
<groupname>audit</groupname> group in order to delegate audit
|
||||
review rights to the user. As the ability to track audit log
|
||||
contents provides significant insight into the behavior of
|
||||
users and processes, it is recommended that the delegation of
|
||||
audit review rights be performed with caution.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Live Monitoring Using Audit Pipes</title>
|
||||
|
||||
<para>Audit pipes are cloning pseudo-devices in the device file system
|
||||
which allow applications to tap the live audit record stream. This
|
||||
is primarily of interest to authors of intrusion detection and
|
||||
system monitoring applications. However, for the administrator the
|
||||
audit pipe device is a convenient way to allow live monitoring
|
||||
without running into problems with audit trail file ownership or
|
||||
log rotation interrupting the event stream. To track the live audit
|
||||
event stream, use the following command line:</para>
|
||||
<para>Audit pipes are cloning pseudo-devices in the device file
|
||||
system which allow applications to tap the live audit record
|
||||
stream. This is primarily of interest to authors of intrusion
|
||||
detection and system monitoring applications. However, for
|
||||
the administrator the audit pipe device is a convenient way to
|
||||
allow live monitoring without running into problems with audit
|
||||
trail file ownership or log rotation interrupting the event
|
||||
stream. To track the live audit event stream, use the
|
||||
following command line:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>praudit /dev/auditpipe</userinput></screen>
|
||||
|
||||
<para>By default, audit pipe device nodes are accessible only to the
|
||||
<username>root</username> user. To make them accessible to the members of the
|
||||
<groupname>audit</groupname> group, add a <literal>devfs</literal> rule
|
||||
to <filename>devfs.rules</filename>:</para>
|
||||
<para>By default, audit pipe device nodes are accessible only to
|
||||
the <username>root</username> user. To make them accessible
|
||||
to the members of the <groupname>audit</groupname> group, add
|
||||
a <literal>devfs</literal> rule to
|
||||
<filename>devfs.rules</filename>:</para>
|
||||
|
||||
<programlisting>add path 'auditpipe*' mode 0440 group audit</programlisting>
|
||||
|
||||
<para>See &man.devfs.rules.5; for more information on configuring
|
||||
the devfs file system.</para>
|
||||
<para>See &man.devfs.rules.5; for more information on
|
||||
configuring the devfs file system.</para>
|
||||
|
||||
<warning>
|
||||
<para>It is easy to produce audit event feedback cycles, in which
|
||||
the viewing of each audit event results in the generation of more
|
||||
audit events. For example, if all network I/O is audited, and
|
||||
&man.praudit.1; is run from an SSH session, then a continuous stream of
|
||||
audit events will be generated at a high rate, as each event
|
||||
being printed will generate another event. It is advisable to run
|
||||
<command>praudit</command> on an audit pipe device from sessions without fine-grained
|
||||
I/O auditing in order to avoid this happening.</para>
|
||||
<para>It is easy to produce audit event feedback cycles, in
|
||||
which the viewing of each audit event results in the
|
||||
generation of more audit events. For example, if all
|
||||
network I/O is audited, and &man.praudit.1; is run from an
|
||||
SSH session, then a continuous stream of audit events will
|
||||
be generated at a high rate, as each event being printed
|
||||
will generate another event. It is advisable to run
|
||||
<command>praudit</command> on an audit pipe device from
|
||||
sessions without fine-grained I/O auditing in order to avoid
|
||||
this happening.</para>
|
||||
</warning>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Rotating Audit Trail Files</title>
|
||||
|
||||
<para>Audit trails are written to only by the kernel, and managed only
|
||||
by the audit daemon, <application>auditd</application>. Administrators
|
||||
should not attempt to use &man.newsyslog.conf.5; or other tools to
|
||||
directly rotate audit logs. Instead, the <command>audit</command>
|
||||
management tool may be used to shut down auditing, reconfigure the
|
||||
audit system, and perform log rotation. The following command causes
|
||||
the audit daemon to create a new audit log and signal the kernel to
|
||||
switch to using the new log. The old log will be terminated and
|
||||
<para>Audit trails are written to only by the kernel, and
|
||||
managed only by the audit daemon,
|
||||
<application>auditd</application>. Administrators should not
|
||||
attempt to use &man.newsyslog.conf.5; or other tools to
|
||||
directly rotate audit logs. Instead, the
|
||||
<command>audit</command> management tool may be used to shut
|
||||
down auditing, reconfigure the audit system, and perform log
|
||||
rotation. The following command causes the audit daemon to
|
||||
create a new audit log and signal the kernel to switch to
|
||||
using the new log. The old log will be terminated and
|
||||
renamed, at which point it may then be manipulated by the
|
||||
administrator.</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>audit -n</userinput></screen>
|
||||
|
||||
<warning>
|
||||
<para>If the <application>auditd</application> daemon is not currently
|
||||
running, this command will fail and an error message will be
|
||||
produced.</para>
|
||||
<para>If the <application>auditd</application> daemon is not
|
||||
currently running, this command will fail and an error
|
||||
message will be produced.</para>
|
||||
</warning>
|
||||
|
||||
<para>Adding the following line to
|
||||
|
|
@ -682,23 +713,24 @@ trailer,133</programlisting>
|
|||
<para>The change will take effect once you have saved the
|
||||
new <filename>/etc/crontab</filename>.</para>
|
||||
|
||||
<para>Automatic rotation of the audit trail file based on file size is
|
||||
possible via the <option>filesz</option> option in
|
||||
&man.audit.control.5;, and is described in the configuration files
|
||||
section of this chapter.</para>
|
||||
<para>Automatic rotation of the audit trail file based on file
|
||||
size is possible via the <option>filesz</option> option in
|
||||
&man.audit.control.5;, and is described in the configuration
|
||||
files section of this chapter.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Compressing Audit Trails</title>
|
||||
|
||||
<para>As audit trail files can become very large, it is often desirable
|
||||
to compress or otherwise archive trails once they have been closed by
|
||||
the audit daemon. The <filename>audit_warn</filename> script can be
|
||||
used to perform customized operations for a variety of audit-related
|
||||
events, including the clean termination of audit trails when they are
|
||||
<para>As audit trail files can become very large, it is often
|
||||
desirable to compress or otherwise archive trails once they
|
||||
have been closed by the audit daemon. The
|
||||
<filename>audit_warn</filename> script can be used to perform
|
||||
customized operations for a variety of audit-related events,
|
||||
including the clean termination of audit trails when they are
|
||||
rotated. For example, the following may be added to the
|
||||
<filename>audit_warn</filename> script to compress audit trails on
|
||||
close:</para>
|
||||
<filename>audit_warn</filename> script to compress audit
|
||||
trails on close:</para>
|
||||
|
||||
<programlisting>#
|
||||
# Compress audit trail files on close.
|
||||
|
|
@ -707,11 +739,12 @@ if [ "$1" = closefile ]; then
|
|||
gzip -9 $2
|
||||
fi</programlisting>
|
||||
|
||||
<para>Other archiving activities might include copying trail files to
|
||||
a centralized server, deleting old trail files, or reducing the audit
|
||||
trail to remove unneeded records. The script will be run only when
|
||||
audit trail files are cleanly terminated, so will not be run on
|
||||
trails left unterminated following an improper shutdown.</para>
|
||||
<para>Other archiving activities might include copying trail
|
||||
files to a centralized server, deleting old trail files, or
|
||||
reducing the audit trail to remove unneeded records. The
|
||||
script will be run only when audit trail files are cleanly
|
||||
terminated, so will not be run on trails left unterminated
|
||||
following an improper shutdown.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
|
|
|||
Loading…
Reference in a new issue