From: Russ [Russ.Cooper@RC.ON.CA]
Sent: Wednesday, August 04, 1999 8:55 AM
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Re: Event Log Settings - Do Not Overwrite Events

Numerous people responded to Sven's question about the lack of
notification when the Security Events log filled up. Most said this has
always been the case, although TArnold@vp.com said it could be
configured with a combination of Alerter, Messenger, and Server Manager.

On my test systems, I could not make a pop-up occur indicating that the
Security Event log is full. The Event Viewer help states that such
messages will occur, yet not matter what I tried (Alerter, Messenger,
configuring Server Manager), I could not make a pop-up come up despite
being able to fill the logs and stop Security Event logging.

There is a registry key, described as being a C2 requirement, that will
cause the machine to crash/halt when the Security Event log fills up.

http://support.microsoft.com/support/kb/articles/Q140/0/58.asp

Subsequent logon attempts by non-Administrator users will fail with the
message;

"Your account is configured to prevent you from using this workstation.
Please try another workstation"

An Administrator user must log onto the system and clear the Security
Event log for normal operation to continue, however, there is no message
presented to an Administrator when logging onto a system with a full
Security Events log, so they must somehow know that it is full. Of
course this also means that all events generated by the actions of an
Administrator prior to clearing the Security Events log will not be
audited...somehow I thought this violated C2 compliance??? Presumably
the NSA accepted this caveat?

The incredibly stupid description of what an Administrator should do
after a crash/halt can be found at;

http://support.microsoft.com/support/kb/articles/Q232/5/64.asp
("Disable Auditing", yeah, right! Too bad whoever wrote this KB didn't
have a clue as to why auditing was enabled in the first place, or,
assumed it was some home user who was just playing around and managed to
set auditing on everything by mistake. A far more appropriate KB could
have recommended the 3rd party providers of Audit Log management systems
that Microsoft neglects to provide themselves.)

A system is far more secure when it is configured to manually clear the
Security Event log, there is no doubt about this. However, its just as
obvious that this setting in NT sucks big time as Microsoft provides no
mechanism to automate the archival of the Security Event log and, it
would appear, provides no way to tell you that the log is full.

There are certainly 3rd party tools out there to provide you with
automated archival of the event logs, but there's definitely a bug here
in that there's no way for an Administrator to be pro-active about
avoiding a system crash/halt due to a filled Security Event log.

One such freeware utility is Frank Heyne's EventSave;

http://www.heysoft.de/nt/eventlog/ep-es.htm

If a machine is configured to send Alerts on Crash and a BSOD occurs due
to a filled Security Events log then whomever you have configured (via
Server Manager/Alerts) to receive such messages (assuming, foolishly,
that you're running the Messenger service...like its safe to have that
running) will get a notification of the fact. So you do get to find out
who's about to call you and scream at you because they've just lost all
of their current work. How nice.

FYI, Joseph M. Minckler (jminck@microsoft.com), Microsoft Platforms
Support - NT Setup, said;

>That entry is really thought to be used in conjunction with the
>CrashOnAuditFail reg entry. With this key enabled, the machine will
>crash with the following:
>
>STOP: C0000244 {Audit Failed}
>   An attempt to generate a security audit failed.
>
>See the following for details:

citing the KB articles mentioned above.

FWIW, the idea of auditing is that it is the fundamental component of C2
compliance. Without full, complete, enforceable, and non-bypassable
auditing (i.e. it must not possible to perform an action within the
running OS that is not auditable), *all* auditing is useless.

While "CrashOnAuditFail" would appear, superficially, to satisfy that
requirement, the fact that actions taken by the Administrator after
restart are *not* audited would appear to violate the principle. Paul
Leach might come back and argue that the Administrator can simply delete
the audit logs, and while that's true, it should not mean that their
actions do not get audited (it is possible to retrieve deleted files
from systems, you know).

My tests would seem to indicate that NT continues to perform auditing
despite not writing events to the now-full Security Events log. It would
be possible to have those events written to the pagefile (or memory) and
then inserted into the cleared Security Events log when the
Administrator performs the necessary actions required to restore
Security Event auditing. This is already being done, somehow?? If you do
the following test you will see what I mean;

1. Enable substantial auditing of Administrator access (turn on all user
auditing and enable file auditing of Administrator use).

2. Clear the Security Events log.

3. Clear it again.

4. Notice that the last entry recorded (time-wise, the one that just
happened) is a 517 event indicating that the logs have been cleared.

5. Notice that there are numerous entries in the just cleared log that
occur, timewise, before the 517 event. Meaning that clearing the log
does not actually clear it. All events that occur during the "clearing"
process are recorded in the freshly cleared log.

This would, to me, indicate it would be possible to cache the events and
insert them into the Security Events log when the appropriate actions
are taken by the Administrator. This *should* be done.

Administrators should also receive a pop-up indicating the Security
Events log is full when logging into such a box after a crash/halt.

Finally, when a domain machine has its Security Events log cleared, that
action should be recorded by the PDC as a domain event. Separate Event
logs should be kept for each domain the machine can participate in (i.e.
if I log into the local machine itself, those events should be stored in
a separate Security Events log and access to the "domain Security Events
log" should have default permissioning preventing non-domain user
access.

Just some ramblings from early in the morning, sorry if they came across
harshly...caffeine fix is now starting to set in so I'm a little calmer
finishing this message than when I started...;-]

Cheers,
Russ - NTBugtraq Editor