Hi Mathias, On Mar 2, 8:11m, matthias platzer <[email protected]> wrote: > Maybe you have Windows Server 2003 and 672 or 673 are for both success > and failure events on w2k3?
Indeed w2k3 and the client is installed on a DC. Thanks for the links confirming both success and failure using these event id (672, 673). > > see http://www.ultimatewindowssecurity.com/securitylog/event.aspx?eventID... > http://www.windowsecurity.com/articles/Kerberos-Authentication-Events... I am new to this so let me take a stab at it. I understand these are pre-authentication events. In the case of a success I might choose to ignore these depending on whether or not I expect *any* logons. However it might be useful to monitor failure events as a number of those in a specific period might signal brute force password cracking attempts. So... if we want to do that I guess we should look at either the string "Failure Audit" in an evaluation or look for the failure codes themselves line from eventlog: " Event Type: Failure Audit ... Failure Code: 24 " Here is the table ripped from the first link you sent: Failure Codes, Causes 6, The username doesn’t exist. 12, Workstation restriction; logon time restriction. 18, Account disabled, expired, or locked out. 23, The user’s password has expired. 24, Pre-authentication failed; usually means bad password 32, Ticket expired. This is a normal event that get frequently logged by computer accounts. --- probably want to ignore this !?! -- 37, The workstation’s clock is too far out of synchronization with the DC’s clock. In order to match just the failures do we add something like: <match>^Event Type: Failure Audit$</match> inside 18139? Would that work? but am i right, would we need a second rule to ignore the krb ticket expiry? level 0 does this I think. how about this as a second rule? <rule id="100010" level="0"> <if_sid>18105</if_sid> <id>^672|^673</id> <match>Failure Code: 32</match> <description>Windows DC kerberos ticket expiry</description> <group>kerberos,</group> </rule> Thoughts? B > > regards > > On Feb 23, 3:53 pm, b <[email protected]> wrote: > > > Hi list, > > > I have seen receiving level 10 alerts. It appears that 18139 is > > triggering 18152 though I'm not sure how to verify that. Can someone > > clarify the following compound rule near line 269 and 394 in > > "msauth_rules.xml" or help me understand what is really going on? > > > Here are the lines that I think are relevant. (ossec1.6.1 installed on > > the server): > > > 269 <rule id="18139" level="5"> > > 270 <if_sid>18105</if_sid> > > 271 <id>^672|^673|^675|^676|^681|^4769</id> > > 272 <description>Windows DC Logon Failure.</description> > > 273 <group>win_authentication_failed,</group> > > 274 </rule> > > 275 > > ... > > 394 <rule id="18152" level="10" frequency="$MS_FREQ" > > timeframe="240"> > > 395 <if_matched_group>win_authentication_failed</ > > if_matched_group> > > 396 <description>Multiple Windows Logon Failures.</ > > description> > > 397 <group>authentication_failures,</group> > > 398 </rule> > > > Can someone help me out? I see event id 672 and 673. Why are they in > > the win_authentication_failed group (in rule id 18139)? Aren't they > > success events?
