On Thursday, May 10, 2012 11:50:53 AM Jeffrey Blank wrote:
Not necessarily. There are plenty of files that could qualify
(including /var/log/tallylog) for being added to this Rule. This is
really about deciding where to stop / priorities.
Right. In the stig.rules file its commented out. If you are super paranoid you
could use it. This reminds me that it needs updating for pam_faillock...
This particular Rule does not exist to satisfy a requirement: it is
really quite optional in itself and fits in the "best practices realm".
It exists to provide additional information about what may be going on.
(The actual requirements in OS SRG include auditing login/logout, and
auditing unsuccessful accesses to files, and we have Rules for those.)
The stig.rules file in
/usr/share/doc/audit-VERSION provides explanation.
On 05/08/2012 06:01 PM, Shawn Wells wrote:
> On 5/4/12 5:43 PM, Michael Palmiotto wrote:
>> +<Rule id="audit_manual_logon_edits">
>> +<title> Record Attempts to Alter Logon and Logout Events</title>
>> +<description>
>> +The audit system already collects login info for all users and root.
>> To watch for attempted manual edits of
>> +files involved in storing logon events, add the following
>> to<tt>/etc/audit/audit.rules</tt>:
>> +<pre>
>> +-w /var/log/faillog -p wa -k logins
>> +-w /var/log/lastlog -p wa -k logins
>> +</pre>
>> +</description>
>> +<ident cce="14904-7" />
>> +<oval id="audit_rules_login_events" />
>> +<ref nist="TODO" />
>> +</Rule>
>
> Based on the <description> shouldn't /var/log/secure be added to the
> watch list too?
Nothing in syslog is authoritative. It can be spoofed by any application or
user. The audit logs are the only reliable source of security events.
-Steve