次の方法で共有

Auditing Changes in Windows Server 2003 SP1

  • [アーティクル]

DISCLAIMER: To the best of my knowledge the information here is correct. However the lawyers make me say, that this information is provided "AS-IS" with no warranty, and confers no rights. In other words, if this stuff isn't in SP1, you can't sue us, because this isn't a promise, ok?

 

-----

 

We introduced a feature in Windows Server 2003 RTM where exceptions to audit policy can be set on a per-user basis. For example, audit logon/logoff activity for everyone, but audit all activity for EricF. Or, audit all activity for everyone, except SQLServiceAccount. This feature is required for Common Criteria evaluation. We anticipate it will mainly be used to either reduce noise or track suspicious individuals. This feature is called "Per-user auditing" colloquially; the official name of the feature is "Per-User Selective Audit".

 

In Windows 2003 RTM for some reason the command-line admin tool, auditusr.exe, was not checked in. It was added for SP1 (and for XPSP2, which also has the per-user auditing feature).

 

Per-user auditing cannot exclude events for members of the Administrators group- such policy can be created but will be ignored by the auditing system. Per-user auditing cannot be set for groups, only individual user accounts. Use of AuditUsr.exe is documented in the comand-line help (auditusr /?).

 

Next, we had two auditing problems in Windows Server 2003 that caused higher-than-anticipated audit volumes when logon/logoff success auditing was enabled, and both of them are now fixed in SP1.

 

As background for the first problem, in Windows Server 2003 RTM, we "re-purposed" event 576. Originally, event 576 was generated when Privilege Use success auditing was enabled, and non-audited privileges were assigned to a new logon session. As background, some privileges are not audited when used:

  • ChangeNotifyPrivilege
  • AuditPrivilege
  • CreateTokenPrivilege
  • AssignPrimaryTokenPrivilege
  • BackupPrivilege
  • RestorePrivilege
  • DebugPrivilege

And event 576 recorded that these privileges were granted, since no other audit record would be generated for them unless the "FullPrivilegeAuditing" registry value was modified.

 

In Windows Server 2003, this is the privilege list that was supposed to be used for event 576:

  • AssignPrimaryTokenPrivilege
  • AuditPrivilege
  • BackupPrivilege
  • CreateTokenPrivilege
  • DebugPrivilege
  • EnableDelegationPrivilege
  • ImpersonatePrivilege
  • LoadDriverPrivilege
  • RestorePrivilege
  • SecurityPrivilege
  • SystemEnvironmentPrivilege
  • TakeOwnershipPrivilege
  • TcbPrivilege

These privileges could potentially be used to elevate the user's capabilities to that of an administrator or to tamper with the audit trail. They all either allow modification of the TCB or TCB configuration, or bypass access or audit controls. We decided to change event 576 so that it would reflect "administrator logon". All that was necessary was to change the privilege list for event 576, and also to allow this event to be generated when logon/logoff success auditing was enabled. Then we'd get this event whenever an administrator (or a user equivalent in privilege) logged on.

 

However we forgot to update the privilege list when we changed the category designation of event 576. That, coupled with the fact that everyone has SeChangeNotifyPrivilege which is in the original list, and that this event can now be controlled by logon/logoff auditing, effectively doubles the number of logon events.

 

This is fixed in SP1; the new list is noted above- if any of those privileges are added to the token during logon and logon/logoff success auditing is turned on, event 576 is generated.

 

The second problem is that NetworkService and LocalService accounts were added for Windows Server 2003, with special treatment in LogonUser() so that they always use the same logon sessions, but without an exception for auditing- so even though Windows does not create new logon sessions when an existing logon session exists for one of these accounts (which is almost always the case), an event is always generated. So consequently a large number of logon/logoff events for these accounts are generated. We corrected the code to bypass audit if no logon session was actually created, since technically a logon didn't occur.

 

The net result of these changes is that the audit volume for Windows Server 2003 should drop significantly in SP1.

 

Eric

Comments

  • Anonymous
    December 20, 2004
    > As background, some privileges are not audited when used...

    What is the reason for this? Performance?

  • Anonymous
    December 20, 2004
    Sounds useful but its a pity that this could not be set on a group by group basis. Unless I am missing something... (more than likely!)

  • Anonymous
    December 22, 2004
    The privileges originally excluded from audit were just too noisy- for example, SeChangeNotifyPrivilege (bypass traverse checking) is used in practically every access to the file & registry.

    Per-group auditing is under consideration post-Longhorn. It poses significant technical challenges to implement.

  • Anonymous
    December 22, 2004
    I discovered that one of the colleagues on my team - Eric Fitzgerald, the

  • Anonymous
    December 22, 2004
    I discovered that one of the colleagues on my team - Eric Fitzgerald, the

  • Anonymous
    March 13, 2007
    PingBack from http://winblogs.security-feed.com/2004/12/20/auditing-changes-in-windows-server-2003-sp1/

  • Anonymous
    April 17, 2007
    Deşi subiectul este destul de sensibil, risc. Mă frămîntă de vreo cîteva zile unele lucruri descoperite