date:20170209

Re: [ossec-list] Inconsistencies with syscheck realtime + report_changes

2017-02-09 Thread Victor Fernandez

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.

[ossec-list] Inconsistencies with syscheck realtime + report_changes

2017-02-09 Thread Chris Decker

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] ossec server 2.9.0 WinEvt problems

2017-02-09 Thread dan (ddp)

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

Re: [ossec-list] ossec server 2.9.0 WinEvt problems

2017-02-09 Thread Chris Snyder

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

Re: [ossec-list] ossec server 2.9.0 WinEvt problems

2017-02-09 Thread dan (ddp)

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

Re: [ossec-list] ossec server 2.9.0 WinEvt problems

2017-02-09 Thread Chris Snyder

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

Re: [ossec-list] Debugging Unprocessed Log Entries

2017-02-09 Thread dan (ddp)

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

2017-02-09 Thread dan (ddp)

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.

[ossec-list] ossec server 2.9.0 WinEvt problems

2017-02-09 Thread Chris Snyder

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.

[ossec-list] Debugging Unprocessed Log Entries

2017-02-09 Thread Quintin Beukes

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.

Re: [ossec-list] Debugging agent connectivity

2017-02-09 Thread Quintin Beukes

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.

Re: [ossec-list] Inconsistencies with syscheck realtime + report_changes

[ossec-list] Inconsistencies with syscheck realtime + report_changes

Re: [ossec-list] ossec server 2.9.0 WinEvt problems

Re: [ossec-list] ossec server 2.9.0 WinEvt problems

Re: [ossec-list] ossec server 2.9.0 WinEvt problems

Re: [ossec-list] ossec server 2.9.0 WinEvt problems

Re: [ossec-list] Debugging Unprocessed Log Entries

Re: [ossec-list] ossec server 2.9.0 WinEvt problems

[ossec-list] ossec server 2.9.0 WinEvt problems

[ossec-list] Debugging Unprocessed Log Entries

Re: [ossec-list] Debugging agent connectivity

11 matches

Site Navigation

Mail list logo

Footer information