Re: [ossec-list] Debugging agent connectivity
The ownership and permissions are the same as yours. An unfortunate and rare event just occurred: all the agents are now showing online. This happens occasionally and sticks for a few days. I'll keep monitoring it and when the agents start giving problems again I'll refer back to this message. They're problematic most of the time, so I'm hoping for failures again soon. -- --- 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.
[ossec-list] Debugging Unprocessed Log Entries
Hi group, Server uname: Linux 2.6.32-642.13.1.el6.x86_64 #1 SMP Wed Jan 11 20:56:24 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Agent uname: Linux 2.6.32-642.13.1.el6.x86_64 #1 SMP Wed Jan 11 20:56:24 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux I am generating 5 log messages at 2 second intervals to trigger rule 1002. 16:40:43 [quintinb@ho-pri-vm-quintindev ~]$ for x in {11..15}; do logger test error$x; date; sleep 2; done Thu Feb 9 16:40:48 SAST 2017 Thu Feb 9 16:40:50 SAST 2017 Thu Feb 9 16:40:52 SAST 2017 Thu Feb 9 16:40:54 SAST 2017 Thu Feb 9 16:40:56 SAST 2017 A tcpdump on the server indicates all 5 are received: 16:40:49.197974 IP 10.10.10.100.41074 > 10.10.12.171.1514: UDP, length 121 16:40:51.200118 IP 10.10.10.100.41074 > 10.10.12.171.1514: UDP, length 121 16:40:53.202224 IP 10.10.10.100.41074 > 10.10.12.171.1514: UDP, length 121 16:40:55.204480 IP 10.10.10.100.41074 > 10.10.12.171.1514: UDP, length 121 16:40:57.206407 IP 10.10.10.100.41074 > 10.10.12.171.1514: UDP, length 121 Though alerts.log only shows 3 of the 5. ** Alert 1486651295.2432248: mail - syslog,errors, 2017 Feb 09 16:41:35 (quintindev) 10.10.10.100->/var/log/messages Rule: 1002 (level 2) -> 'Unknown problem somewhere in the system.' Feb 9 16:40:48 ho-pri-vm-quintindev quintinb: test error11 ** Alert 1486651298.2432494: mail - syslog,errors, 2017 Feb 09 16:41:38 (quintindev) 10.10.10.100->/var/log/messages Rule: 1002 (level 2) -> 'Unknown problem somewhere in the system.' Feb 9 16:40:52 ho-pri-vm-quintindev quintinb: test error13 ** Alert 1486651305.2432740: mail - syslog,errors, 2017 Feb 09 16:41:45 (quintindev) 10.10.10.100->/var/log/messages Rule: 1002 (level 2) -> 'Unknown problem somewhere in the system.' Feb 9 16:40:56 ho-pri-vm-quintindev quintinb: test error15 Sometimes it alerts on all 5. Though upon inspection it seems OSSEC misses 50%+ of my messages, even though I see the packets delivered to the server. Is there an explanation for this? Any way I can get more verbose logging on this to investigate deeper? Quintin -- --- 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.
[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.
Re: [ossec-list] ossec server 2.9.0 WinEvt problems
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 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+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.
Re: [ossec-list] Debugging Unprocessed Log Entries
On Thu, Feb 9, 2017 at 9:48 AM, Quintin Beukes wrote: > Hi group, > > Server uname: Linux 2.6.32-642.13.1.el6.x86_64 #1 SMP Wed Jan 11 20:56:24 > UTC 2017 x86_64 x86_64 x86_64 GNU/Linux > Agent uname: Linux 2.6.32-642.13.1.el6.x86_64 #1 SMP Wed Jan 11 20:56:24 UTC > 2017 x86_64 x86_64 x86_64 GNU/Linux > > I am generating 5 log messages at 2 second intervals to trigger rule 1002. > 16:40:43 [quintinb@ho-pri-vm-quintindev ~]$ for x in {11..15}; do logger > test error$x; date; sleep 2; done > Thu Feb 9 16:40:48 SAST 2017 > Thu Feb 9 16:40:50 SAST 2017 > Thu Feb 9 16:40:52 SAST 2017 > Thu Feb 9 16:40:54 SAST 2017 > Thu Feb 9 16:40:56 SAST 2017 > A tcpdump on the server indicates all 5 are received: > 16:40:49.197974 IP 10.10.10.100.41074 > 10.10.12.171.1514: UDP, length 121 > 16:40:51.200118 IP 10.10.10.100.41074 > 10.10.12.171.1514: UDP, length 121 > 16:40:53.202224 IP 10.10.10.100.41074 > 10.10.12.171.1514: UDP, length 121 > 16:40:55.204480 IP 10.10.10.100.41074 > 10.10.12.171.1514: UDP, length 121 > 16:40:57.206407 IP 10.10.10.100.41074 > 10.10.12.171.1514: UDP, length 121 > > Though alerts.log only shows 3 of the 5. > ** Alert 1486651295.2432248: mail - syslog,errors, > 2017 Feb 09 16:41:35 (quintindev) 10.10.10.100->/var/log/messages > Rule: 1002 (level 2) -> 'Unknown problem somewhere in the system.' > Feb 9 16:40:48 ho-pri-vm-quintindev quintinb: test error11 > > ** Alert 1486651298.2432494: mail - syslog,errors, > 2017 Feb 09 16:41:38 (quintindev) 10.10.10.100->/var/log/messages > Rule: 1002 (level 2) -> 'Unknown problem somewhere in the system.' > Feb 9 16:40:52 ho-pri-vm-quintindev quintinb: test error13 > > ** Alert 1486651305.2432740: mail - syslog,errors, > 2017 Feb 09 16:41:45 (quintindev) 10.10.10.100->/var/log/messages > Rule: 1002 (level 2) -> 'Unknown problem somewhere in the system.' > Feb 9 16:40:56 ho-pri-vm-quintindev quintinb: test error15 > > > Sometimes it alerts on all 5. Though upon inspection it seems OSSEC misses > 50%+ of my messages, even though I see the packets delivered to the server. > > Is there an explanation for this? Any way I can get more verbose logging on > this to investigate deeper? > OSSEC does discard some duplicate messages, and I'm not sure if the timestamp is taken into account or not off hand. > Quintin > > -- > > --- > 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.
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 > 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. > > >
Re: [ossec-list] ossec server 2.9.0 WinEvt problems
On Thu, Feb 9, 2017 at 3:25 PM, Chris Snyder 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: > > > 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' > 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: >> >> 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 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(
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 > 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):' > >hos
Re: [ossec-list] ossec server 2.9.0 WinEvt problems
On Thu, Feb 9, 2017 at 4:09 PM, Chris Snyder wrote: > 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. > No clue. Without log samples it's difficult to track down as well. I avoid the Windows stuff as much as I can. > 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 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_
[ossec-list] Inconsistencies with syscheck realtime + report_changes
All, I have hundreds of machines that are (supposed to be) all configured exactly the same way via kickstarts and periodic Puppet runs. I've noticed that sometimes a Puppet push will modify a file across all of our machines, and the resulting syscheck notifications are a mixed bag - some have the report_change included (the *diff*), and others generate an alert but lack the report_change details. I'm scratching my head trying to figure out why it's working on some and not others. Below are some details on a machine where report_change is failing: *OSSEC Agent Version:* ossec-hids-agent-2.9.0-48.el6.art.x86_64 ossec-hids-2.9.0-48.el6.art.x86_64 *inotify-tools Version:* rpm -qa | grep -i inotify inotify-tools-3.14-1.el6.x86_64 *E-mail Notification:* Received From: (removed) 1.2.3.4->syscheck Rule: 102907 fired (level 7) -> "File integrity changed, likely security relevant" Portion of the log(s): Integrity checksum changed for: '/etc/security/limits.conf' Size changed from '1885' to '1927' Old md5sum was: 'a639c5c0ea72bcb59c6a1379f6baa797' New md5sum is : '301d246e310c78c2c76ef69cdefe00d1' Old sha1sum was: '579006cf4e04899e05ff7812dc6a6c17500753fb' New sha1sum is : '714e5ffa5da1b684d0d591b5a822460b8c8ba4c3' *OSSEC Manager syscheck_control Output:* /var/ossec/bin/syscheck_control -i 2337 -f /etc/security/limits.conf Integrity changes for agent 'removed (2337) - 1.2.3.4': Detailed information for entries matching: '/etc/security/limits.conf' 2017 Jan 31 12:55:42,0 - /etc/security/limits.conf File added to the database. Integrity checking values: Size: 1885 Perm: rw-r--r-- Uid: 0 Gid: 0 Md5: a639c5c0ea72bcb59c6a1379f6baa797 Sha1: 579006cf4e04899e05ff7812dc6a6c17500753fb 2017 Feb 09 15:51:49,0 - /etc/security/limits.conf File changed. - 1st time modified. Integrity checking values: Size: >1927 Perm: rw-r--r-- Uid: 0 Gid: 0 Md5: >301d246e310c78c2c76ef69cdefe00d1 Sha1: >714e5ffa5da1b684d0d591b5a822460b8c8ba4c3 *The logs on the Agent do show that real-time monitoring was started prior to this change…* 2017/02/07 20:56:23 ossec-syscheckd: INFO: Initializing real time file monitoring (not started). … 2017/02/07 21:30:07 ossec-syscheckd: INFO: Real time file monitoring started. *Strangely enough, the diff file does exist on the filesystem for this machine:* cat /var/ossec/queue/diff/local/etc/security/limits.conf/diff.1486673498 52a53,54 > * soft stack 10240 > * hard stack unlimited # 1486673498 converts to Thursday February 09, 2017 15:51:38 (pm) *As far as I can tell my agent.conf is correct (and remember I use this agent.conf across hundreds of nodes):* no 79200 /etc … *Permissions of /var/ossec/tmp:* ls -ld /var/ossec/tmp/ dr-xr-x--- 2 root ossec 4096 Feb 9 16:27 /var/ossec/tmp/ Any thoughts on what could be causing this? -- --- 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] Inconsistencies with syscheck realtime + report_changes
Hi Chris, It's really curious that Syscheck creates the diff file but doesn't send it. There should be no difference between configuring it in real-time or not. I see that the diff file matches the actual change by the size difference. However, did you see any error at the /var/ossec/logs/ossec.log file that could be related to this issue? Anything like: ERROR: Unable to generate diff alert. Best regards. On Thu, Feb 9, 2017 at 1:51 PM, Chris Decker wrote: > All, > > I have hundreds of machines that are (supposed to be) all configured > exactly the same way via kickstarts and periodic Puppet runs. I've noticed > that sometimes a Puppet push will modify a file across all of our machines, > and the resulting syscheck notifications are a mixed bag - some have the > report_change included (the *diff*), and others generate an alert but > lack the report_change details. > > I'm scratching my head trying to figure out why it's working on some and > not others. Below are some details on a machine where report_change is > failing: > > *OSSEC Agent Version:* > > ossec-hids-agent-2.9.0-48.el6.art.x86_64 > ossec-hids-2.9.0-48.el6.art.x86_64 > > > *inotify-tools Version:* > > rpm -qa | grep -i inotify > inotify-tools-3.14-1.el6.x86_64 > > > *E-mail Notification:* > > Received From: (removed) 1.2.3.4->syscheck > Rule: 102907 fired (level 7) -> "File integrity changed, likely security > relevant" > Portion of the log(s): > > Integrity checksum changed for: '/etc/security/limits.conf' > Size changed from '1885' to '1927' > Old md5sum was: 'a639c5c0ea72bcb59c6a1379f6baa797' > New md5sum is : '301d246e310c78c2c76ef69cdefe00d1' > Old sha1sum was: '579006cf4e04899e05ff7812dc6a6c17500753fb' > New sha1sum is : '714e5ffa5da1b684d0d591b5a822460b8c8ba4c3' > > > *OSSEC Manager syscheck_control Output:* > > /var/ossec/bin/syscheck_control -i 2337 -f /etc/security/limits.conf > > Integrity changes for agent 'removed (2337) - 1.2.3.4': > Detailed information for entries matching: '/etc/security/limits.conf' > > 2017 Jan 31 12:55:42,0 - /etc/security/limits.conf > File added to the database. > Integrity checking values: >Size: 1885 >Perm: rw-r--r-- >Uid: 0 >Gid: 0 >Md5: a639c5c0ea72bcb59c6a1379f6baa797 >Sha1: 579006cf4e04899e05ff7812dc6a6c17500753fb > > 2017 Feb 09 15:51:49,0 - /etc/security/limits.conf > File changed. - 1st time modified. > Integrity checking values: >Size: >1927 >Perm: rw-r--r-- >Uid: 0 >Gid: 0 >Md5: >301d246e310c78c2c76ef69cdefe00d1 >Sha1: >714e5ffa5da1b684d0d591b5a822460b8c8ba4c3 > > > *The logs on the Agent do show that real-time monitoring was started prior > to this change…* > > 2017/02/07 20:56:23 ossec-syscheckd: INFO: Initializing real time file > monitoring (not started). > … > 2017/02/07 21:30:07 ossec-syscheckd: INFO: Real time file monitoring > started. > > > *Strangely enough, the diff file does exist on the filesystem for this > machine:* > > cat /var/ossec/queue/diff/local/etc/security/limits.conf/diff.1486673498 > 52a53,54 > > * soft stack 10240 > > * hard stack unlimited > > > # 1486673498 converts to Thursday February 09, 2017 15:51:38 (pm) > > > *As far as I can tell my agent.conf is correct (and remember I use this > agent.conf across hundreds of nodes):* > > > > no > 79200 > > /etc directories> > > … > > > *Permissions of /var/ossec/tmp:* > > ls -ld /var/ossec/tmp/ > dr-xr-x--- 2 root ossec 4096 Feb 9 16:27 /var/ossec/tmp/ > > > > > Any thoughts on what could be causing this? > > > -- > > --- > 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. > -- Victor M. Fernandez-Castro IT Security Engineer Wazuh Inc. -- --- 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.