thanks for the replies Michael. We are going to leave the decoder as is and just customize/regroup the events I think and then do some post-filtering in splunk to weed out anything else that we can't tune out in rules.
Got an example of the sub rule matching you mentioned? thanks. Zate On Thu, May 17, 2012 at 8:29 PM, Michael Starks < ossec-l...@michaelstarks.com> wrote: > On 05/16/2012 11:49 PM, Zate wrote: > > So the rule is classsifying anything that is 4769 as Windows DC logon >> Failure. Even that is too generic. Was is bad password? Bad username? >> something else? Ideally I'd like to lump all the bad password >> codes/sub codes together. >> > > I don't remember if I wrote this rule or not, but now that I look at it, I > can't see much value in the TGS events. One of us might have read a white > paper at one point seeing an attack vector :). As to the logon failures, > the 5xx events have more value. > > > what we are having problems with right now is writing a sub decode that >> pulls the Result Code from the 4769 event so we can have a rule that say >> generates an event of "Password has expired" for 0x17 instead of just >> lumping everything into the one area. >> >> ID 675 >> (http://www.**ultimatewindowssecurity.com/**securitylog/encyclopedia/** >> event.aspx?eventid=675<http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=675> >> ) >> is the same, shows up as "windows DC logon failure" but gives no >> indication of what the failure code is. Again, we'd like to put in a >> sub decoder to pull failure code so we could use it in rules to more >> accurately label the type of failure. >> > > You don't necessarily need a sub-decoder to do that. You can just write a > subordinate rule that matches on the failure code string in the event. > Decoders are only needed when you want to extract a specific part of the > log and match it up with a specific tag for correlation purposes. > > > Am I missing something? this is how I am understanding it looking at >> what I have in front of me. >> > > One thing to keep in mind is that many of these rules were written by > different people at different times (myself included) and one of the > challenges was not to break backwards compatibility and mess with people > who had already tuned their systems. At some point I may just rewrite the > whole darn thing from the ground up and include it as a rule set that is > disabled by default. >
