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.
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'
**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'
**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: ''
**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
> <javascript:>> 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 <javascript:>.
> > 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.
