Re: Audit Failures/READ_CONTROL SYNCHRONIZE
From: Eric Fitzgerald [MSFT] (ericf@online.microsoft.com)Date: 03/28/02
- Previous message: Eric Fitzgerald [MSFT]: "Re: Bypass Traverse Checking not working"
- In reply to: Binesh Bannerjee: "Re: Audit Failures/READ_CONTROL SYNCHRONIZE"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Eric Fitzgerald [MSFT]" <ericf@online.microsoft.com> Date: Thu, 28 Mar 2002 11:52:40 -0800
Hey Binesh,
> Is there a way to not log specific Event ID's? Then I just wouldn't log
Event
> ID 560, and I could simply open up the Security Log from time to time, and
> as long as there are no lock symbols in the log, then I know everything
> is OK... ? Or, am I trying to use auditing for something it was not
intended?
In the next version of Windows after .NET Server we are considering the
feature of allowing events to be turned on/off individually, however you
can't do that now. Turning off event 560 would not be a good idea in any
case, it contains information that is not available anywhere else (object
name), other events must be correlated with this event.
> The other thing I was hoping to find was rogue programs that seem to
insist
> on writing to c:\winnt... How would I go about making the C drive be fully
> read only? (I've already created a D drive, changed the TEMP and TMP
> environments to D:\TEMP and changed the print spool folder to
> D:\printspool...
I have done this before. You must turn on object access success auditing,
and then set the following custom SACL on %windir% (you need to manually
clear the SACL on certain subdirs such as \temp afterwards):
Everyone: Create Folders/Write Data, Create Files/Append Data,
Delete Subfolders and Files, Delete, Write Permissions, Take Ownership
Do NOT audit Write Attributes or Write Exteneded attributes. Normal
Explorer behavior will cause a huge amount of audit if you do.
Also you will start to notice that certain system components regularly write
to specific directories; you'll probably want to disable the SACL on those
directories.
Lastly, if you use this strategy in conjunction with an Antivirus program
the results are unpredictable- many Antivirus programs open a file with more
access than they need when they want to scan it for viruses and reset the
last accessed time, and you can end up with a flood of events.
Eric
-- Eric Fitzgerald Program Manager, Windows Auditing and Intrusion Detection Microsoft Corporation"Binesh Bannerjee" <binesh-dated-1017922749.387722@hex21.com> wrote in message news:a7v1q4$43s$1@bob.news.rcn.net... > Eric Fitzgerald [MSFT] <ericf@online.microsoft.com> wrote: > : The 560 object access event does not record what actions were performed on > : the file, it records what accesses were requested to the file. It does not > : mean that the program performed those operations on the file or even > : intended to do so. > > : If you're using Windows 2000 then you're going to see a lot of yucky events > : like this. Access failures often occur normally, Explorer in particular > : often tries to open files with maximum privilege (which will often fail), > : and then use the failure as a UI cue- it will display the file differently. > : For instance, if you don't have Full Control on a file, Explorer will notice > : and disable parts of the security dialog. Unfortunately if you've enabled > : failure auditing then you will get an event. > > : Lastly, "Read Control" and "Synchronize" are two of the standard rights- > : they are requested with almost every access. Read Control is the ability to > : read the security descriptor on the file. Synchronize is the ability to > : have the operating system notify the program of changes to the file. > > : For Windows XP and Windows .NET Server we've added a new event, 567, which > : is logged when an operation is actually performed on a file. This will not > : be back-ported to Windows 2000. > > Thanks, this was very helpful! > > Is there a way to not log specific Event ID's? Then I just wouldn't log Event > ID 560, and I could simply open up the Security Log from time to time, and > as long as there are no lock symbols in the log, then I know everything > is OK... ? Or, am I trying to use auditing for something it was not intended? > > The other thing I was hoping to find was rogue programs that seem to insist > on writing to c:\winnt... How would I go about making the C drive be fully > read only? (I've already created a D drive, changed the TEMP and TMP > environments to D:\TEMP and changed the print spool folder to > D:\printspool... > > Anything else you might recommend? > > Thanks, > Binesh Bannerjee > > : -- > : Eric Fitzgerald > : Program Manager, Windows Auditing and Intrusion Detection > : Microsoft Corporation >
- Previous message: Eric Fitzgerald [MSFT]: "Re: Bypass Traverse Checking not working"
- In reply to: Binesh Bannerjee: "Re: Audit Failures/READ_CONTROL SYNCHRONIZE"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
