[logs] Syslog and Windows

[Eric Fitzgerald]

I have been watching the syslog working group; it will be interesting to
see what you all come up with.

Yes, when objects are deleted in Active Directory, they are mostly
stripped of their attributes, renamed and moved to a holding area (the
"Deleted Objects" container) for a period of time called the tombstone
lifetime, which is 60 days by default.  After that time they are garbage
collected and gone forever.

http://technet2.microsoft.com/windowsserver/en/library/1465d773-b763-45e
c-b971-c23cdc27400e1033.mspx?mfr=true

The reason for the complex deletion semantics is because of multi-master
replication- it's necessary to take great pains to ensure that all
domain controllers become aware that the object has been deleted, prior
to actually removing all traces of the object.  Otherwise all DCs would
have to be online for deletes, or you'd have to have a "delete master"
DC.

Best regards,
Eric


-----Original Message-----
From: Rainer Gerhards [mailto:rgerhards at hq.adiscon.com] 
Sent: Monday, June 25, 2007 2:11 PM
To: Eric Fitzgerald; loganalysis
Subject: RE: [logs] Syslog and Windows

Hi Eric,

indeed :) The data on syslog packet sizes is also interesting:

http://www.monitorware.com/Common/en/articles/ihe-syslog.php

In short, everything above 4k is problematic (not that it not could be
done, but the defaults and stacks tend to make your life miserable). All
of this, btw, was a reason for us using our own protocol (SETP).
Upcoming new syslog-standards will hopefully remove much of the problem
-if (big if) they will ever materialize.

On the topic of AD object deletion - as far as I remember, deleted
objects stay in AD for at least some time to serve as reference. Am I
right here?

Thanks again for posting.
Rainer 

> -----Original Message-----
> From: Eric Fitzgerald [mailto:Eric.Fitzgerald at microsoft.com] 
> Sent: Monday, June 25, 2007 10:43 PM
> To: Rainer Gerhards; loganalysis
> Subject: RE: [logs] Syslog and Windows
> 
> Thanks Rainer,
> 
> I just wanted to make sure everyone was aware of idiosyncrasies of
> Windows events.  There has been discussion elsewhere on this thread of
> several different syslog solutions for Windows; it would be 
> in the best
> interest of those choosing to implement any of those to find out the
> limitations of each of those solutions.
> 
> Best regards,
> Eric
> 
> 
> -----Original Message-----
> From: Rainer Gerhards [mailto:rgerhards at hq.adiscon.com] 
> Sent: Monday, June 25, 2007 1:03 PM
> To: Eric Fitzgerald; loganalysis
> Subject: RE: [logs] Syslog and Windows
> 
> Hi Eric,
> 
> Thanks for the explanation, really appreciated. But I need to 
> comment on
> the syslog issue ;) 
> 
> > If you have a solution which does all these lookups and 
> > translations and
> > combines the event message text with the raw event data prior to
> > transmission, the average event length will likely increase 
> > up to 4x, to
> > the vicinity of 2k-3k per event record in the security event log.
> > 
> > Syslog only supports 1k per message per RFC 3164.
> 
> RFC 3164 is informational and NOT realy describing what can be seen in
> practice. The typical (unpatched) syslogd on Linux does 
> indeed have the
> 2K limit, but there are many other syslog-based solutions out 
> (including
> on *nix) which support for larger sizes.
> 
> > 
> > Any syslog-based solution for gathering Windows logs is 
> likely either
> > truncating a large percentage of Windows events, or not collecting
> > Windows events in a way that they can be analyzed by human 
> beings (in
> > that case don't blame Windows; blame your SEM).
> 
> Or it ignores the artificial limit in old-day syslog.
> 
> > In summary, syslog is probably a poor solution for Windows security
> > events for the reasons described above.  Other logs on 
> > Windows typically
> > have shorter events but you might still have many of the same
> > shortcomings with syslog.
> 
> The good thing about syslog is that it is universally 
> available and thus
> can be used to build cross-platfomr solutions.
> 
> Rainer
>