On Thu, Feb 9, 2017 at 3:25 PM, Chris Snyder <dagop...@gmail.com> wrote: > You're new windows decoder rules work great! I'm going to throw them at my > hosts right now (better than what I've got at the moment!). > > However, I'm thinking there's a bug somewhere in some pattern matching code > somewhere. However, I don't know yet if it's a bug in the current atomic > RPMs or the ossec code. But, I did some further testing and here's what I > found. >
I think it's a quirk.More details inline. > Set up fresh install of ossec server 2.9.0, edited ossec.conf and removed > all rules and then created an empty etc/decoder.xml with following: > > <decoder name="windows"> > <type>windows</type> > <prematch>^\d\d\d\d \w\w\w \d\d \d\d:\d\d</prematch> > </decoder> > > <!-- EOF --> > > > Then fired up 'ossec-logtest -vd' and executed the following test entries > against it: > > > full test with a string that should work - complete fail > > 2017 Feb 08 19:00:00 WinEvtLog > > **Phase 1: Completed pre-decoding. > full event: '2017 Feb 08 19:00:00 WinEvtLog' > hostname: 'gopher-test' > program_name: '(null)' > log: 'WinEvtLog' > In this case the "log" field only sees "WinEvtLog." Your decoder doesn't match because the log doesn't include what you're looking for in the prematch. > **Phase 2: Completed decoding. > No decoder matched. > > > > short string - remove everything except the date stamp, no whitespace at end > – everything works > > 2017 Feb 08 19:00:00 > > **Phase 1: Completed pre-decoding. > full event: '2017 Feb 08 19:00:00' > hostname: 'gopher-test' > program_name: '(null)' > log: '2017 Feb 08 19:00:00' > In this case the log event doesn't include enough to determine that the timestamp is part of the metadata, so it's included in the log field. > **Phase 2: Completed decoding. > decoder: 'windows' > > > same short string - ADD ONE SPACE AT END - EVERYTHING FAILS. That pattern > match should NOT be puking because of an extra space at the end as far as I > can tell. > > > 2017 Feb 08 19:00:00 > > **Phase 1: Completed pre-decoding. > full event: '2017 Feb 08 19:00:00 ' > hostname: 'gopher-test' > program_name: '(null)' > log: '' > Empty log field, apparently the space was enough for analysisd to recognize the timestamp for what it is. > **Phase 2: Completed decoding. > No decoder matched. > > > Anyway, thanks for the help! I'll keep you posted if there's any more > headaches with my windows logs. > > > > > On Thursday, February 9, 2017 at 2:57:57 PM UTC-5, dan (ddpbsd) wrote: >> >> Thanks for pointing this out. It's definitely shown me a(nother) gap >> in our rules testing setup. >> I'm guessing a 2.9.1 will be coming in shortly with the changes we >> made to the windows decoders backported from master. >> Here are the new decoders if you want to give them a spin: >> <decoder name="windows"> >> <type>windows</type> >> <program_name>^WinEvtLog</program_name> >> </decoder> >> >> <decoder name="windows1"> >> <type>windows</type> >> <parent>windows</parent> >> <regex offset="after_parent">^\.+: (\w+)\((\d+)\): (\.+): </regex> >> <regex>(\.+): \.+: (\S+): </regex> >> <order>status, id, extra_data, user, system_name</order> >> <fts>name, location, system_name</fts> >> </decoder> >> >> <decoder name="windows1"> >> <type>windows</type> >> <parent>windows</parent> >> <regex> Source Network Address: (\S+)</regex> >> <order>srcip</order> >> </decoder> >> >> <decoder name="windows1"> >> <type>windows</type> >> <parent>windows</parent> >> <regex> Account Name: (\S+) Account</regex> >> <order>user</order> >> </decoder> >> >> >> On Thu, Feb 9, 2017 at 10:50 AM, Chris Snyder <dago...@gmail.com> wrote: >> > I just updated my CentOS 6 OSSEC server using the Atomic RPMs from >> > 2.8.3-53 >> > to 2.9.0-48. >> > >> > Before the updates, my Windows server logs were process fine. After the >> > updates, ALL my windows logs are no longer being decoded correctly. >> > >> > Using ossec-logtest, and a test log entry of >> > >> > 2017 Feb 08 19:00:00 WinEvtLog: Security: AUDIT_SUCCESS(4738): >> > Microsoft-Windows-Security-Auditing: (no user): >> > >> > With 2.8.3-53, logtest reports: >> > >> > **Phase 1: Completed pre-decoding. >> > full event: '2017 Feb 08 19:00:00 WinEvtLog: Security: >> > AUDIT_SUCCESS(4738): Microsoft-Windows-Security-Auditing: (no user):' >> > hostname: 'mybox' >> > program_name: '(null)' >> > log: '2017 Feb 08 19:00:00 WinEvtLog: Security: >> > AUDIT_SUCCESS(4738): >> > Microsoft-Windows-Security-Auditing: (no user):' >> > >> > **Phase 2: Completed decoding. >> > decoder: 'windows' >> > >> > With 2.9.0, logtest reports: >> > >> > **Phase 1: Completed pre-decoding. >> > full event: '2017 Feb 08 19:00:00 WinEvtLog: Security: >> > AUDIT_SUCCESS(4738): Microsoft-Windows-Security-Auditing: (no user):' >> > hostname: 'mybox' >> > program_name: 'WinEvtLog' >> > log: 'Security: AUDIT_SUCCESS(4738): >> > Microsoft-Windows-Security-Auditing: (no user):' >> > >> > **Phase 2: Completed decoding. >> > No decoder matched. >> > >> > BUT! If I drop off the date stamp prefix and just use the rest of the >> > line, >> > IT WORKS! >> > >> > WinEvtLog: Security: AUDIT_SUCCESS(4738): >> > Microsoft-Windows-Security-Auditing: (no user): >> > >> > **Phase 1: Completed pre-decoding. >> > full event: 'WinEvtLog: Security: AUDIT_SUCCESS(4738): >> > Microsoft-Windows-Security-Auditing: (no user):' >> > hostname: 'tmgweb01' >> > program_name: '(null)' >> > log: 'WinEvtLog: Security: AUDIT_SUCCESS(4738): >> > Microsoft-Windows-Security-Auditing: (no user):' >> > >> > **Phase 2: Completed decoding. >> > decoder: 'windows' >> > >> > I've tried to play with the windows WinEvt decoder definition but I >> > haven't >> > had any luck getting it to match with the date stamp. >> > >> > I will say that my Windows servers are still running the 2.8.3 clients >> > because I can't find an install package for 2.9.0 yet. >> > >> > Any ideas what's going on here? Help! >> > >> > -- >> > >> > --- >> > You received this message because you are subscribed to the Google >> > Groups >> > "ossec-list" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> > an >> > email to ossec-list+...@googlegroups.com. >> > For more options, visit https://groups.google.com/d/optout. > > -- > > --- > You received this message because you are subscribed to the Google Groups > "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ossec-list+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
