Re: [ossec-list] ossec server 2.9.0 WinEvt problems
My only counter argument to your response is that if I do the same tests with a 2.8.3 ossec server all the tests pass with the expected match of a windows log type. So something changed somewhere in the ossec server. Whether this is a new bug recently introduced between 2.8.3 and 2.9.0 or it was broken before and now correctly works, I'm not sure, but definitely something changed. On Thursday, February 9, 2017 at 3:37:13 PM UTC-5, dan (ddpbsd) wrote: > > On Thu, Feb 9, 2017 at 3:25 PM, Chris Snyder <dago...@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. > -- --- 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.
Re: [ossec-list] ossec server 2.9.0 WinEvt problems
update on your new code. I replaced the following code: windows ^\d\d\d\d \w\w\w \d\d \d\d:\d\d:\d\d WinEvtLog: |^WinEvtLog: ^\.+: (\w+)\((\d+)\): (\.+): (\.+): \.+: (\S+): status, id, extra_data, user, system_name name, location, user, system_name with what you sent me and restarted the server, Now, I'm getting matches for windows stuff (and they all looks correct so far), but when it does find something to alert on, it send a notice of multiple audit failures when there aren't multiple items: Received From: (testbox01.EXAMPLE.COM) 192.168.20.45->WinEvtLog Rule: 18153 fired (level 10) -> "Multiple Windows audit failure events." User: (no user) Portion of the log(s): 2017 Feb 09 16:00:54 WinEvtLog: Security: AUDIT_FAILURE(4771): Microsoft-Windows-Security-Auditing: (no user): no domain: testbox01.EXAMPLE.COM: Kerberos pre-authentication failed. Account Information: Security ID: S-1-5-21-963706601-603035142-3281641605-1106 Account Name: user1 Service Information: Service Name: krbtgt/EXAMPLE.COM Network Information: Client Address: :::192.168.20.9 Client Port: 60429 Additional Information: Ticket Options: 0x10 Failure Code: 0x18 Pre-Authentication Type: 2 Certificate Information: Certificate Issuer Name:Certificate Serial Number:Certificate Thumbprint:Certificate information is only provided if a certificate was used for pre-authentication. Pre-authentication types, ticket options and failure codes are defined in RFC 4120. If the ticket was malformed or damaged during transit and could not be decrypted, then many fields in this event might not be present. 2017 Feb 09 16:02:23 WinEvtLog: Security: AUDIT_SUCCESS(4624): successful windows logging stuff from different host #2 2017 Feb 09 16:02:21 WinEvtLog: Security: AUDIT_SUCCESS(4634): successful windows logging stuff from different host #3 2017 Feb 09 16:02:21 WinEvtLog: Security: AUDIT_SUCCESS(4769): successful windows logging stuff from different host #2 2017 Feb 09 16:02:21 WinEvtLog: Security: AUDIT_SUCCESS(4769): successful windows logging stuff from different host #2 2017 Feb 09 16:00:44 WinEvtLog: Security: AUDIT_SUCCESS(4634): successful windows logging stuff from different host #2 Any idea why it seems to see multiple failures here when there's only one failure and a bunch of successes? It didn't do that before. 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: > > windows > ^WinEvtLog > > > > windows > windows > ^\.+: (\w+)\((\d+)\): (\.+): > (\.+): \.+: (\S+): > status, id, extra_data, user, system_name > name, location, system_name > > > > windows > windows >Source Network Address: (\S+) > srcip > > > > windows > windows >Account Name: (\S+) Account > user > > > > 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. >
Re: [ossec-list] ossec server 2.9.0 WinEvt problems
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: windows ^\d\d\d\d \w\w\w \d\d \d\d:\d\d 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: > > windows > ^WinEvtLog > > > > windows > windows > ^\.+: (\w+)\((\d+)\): (\.+): > (\.+): \.+: (\S+): > status, id, extra_data, user, system_name > name, location, system_name > > > > windows > windows >Source Network Address: (\S+) > srcip > > > > windows > windows >Account Name: (\S+) Account > user > > > > 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:
[ossec-list] ossec server 2.9.0 WinEvt problems
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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
