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.
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 tr
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:0
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
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/L
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 th
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 do
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 res
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_
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
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.l
11 matches
Mail list logo