On Mon, Oct 17, 2016 at 2:46 PM, Sunny Day <t4251...@gmail.com> wrote:
> Is there a hard limit on the rate at which syscheck will report new/changed
> I have roughly 120 clients reporting to one server. I see frequent
> occasions where new or changed files (sometimes with realtime enabled,
> sometimes not) seem to be reported by syscheck days, weeks, or even months
> after they were known to be added or modified.
> This usually coincides with updates to the OS and/or kernel. Looking through
> the logs, it looks to me like the server is limiting reports to roughly (but
> not always exactly) 10 reports at a time, a second or two apart. For
> updates involving many thousands of files on 120 hosts, this can take so
> long that syscheck is simply not useful.
> I have documented specific examples of files that I know were added to the
> system months before they were actually reported by syscheck. Here is one.
> As an example, this is from the ossec server's alert log on Sept. 25:
> ** Alert 1474812143.8448019: mail - ossec, syscheck,
> 2016 Sep 25 07:02:23 (sampleclient) 10.0.0.9->syscheck
> Rule: 554 (level 10) -> 'File added to the system.'
> New file '/usr/lib/klibc/bin/cpio' added to the file system.
> Yet this file was present at least as far back as May 18:
> $ dpkg -S /usr/lib/klibc/bin/cpio
> klibc-utils: /usr/lib/klibc/bin/cpio
> $ zgrep -h -B2 klibc-utils /var/log/apt/history.log*
> Start-Date: 2016-05-18 10:58:30
> Commandline: /usr/bin/apt-get -y -o Dpkg::Options::=--force-confdef -o
> Dpkg::Options::=--force-confold dist-upgrade
> Upgrade: libnl-genl-3-200:amd64 (3.2.21-1, 3.2.21-1ubuntu1.1),
> libnl-3-200:amd64 (3.2.21-1, 3.2.21-1ubuntu1.1), klibc-utils:
> (2.0.3-0ubuntu1, 2.0.3-0ubuntu1.14.04.1), lsb-base:amd64
> (4.1+Debian11ubuntu6, 4.1+Debian11ubuntu6.1), lsb-release:amd64
> (4.1+Debian11ubuntu6, 4.1+Debian11ubuntu6.1), libklibc:amd64
> (2.0.3-0ubuntu1, 2.0.3-0ubuntu1.14.04.1)
> $ stat /usr/lib/klibc/bin/cpio
> File: /usr/lib/klibc/bin/cpio
> Size: 5168 Blocks: 16 IO Block: 4096 regular file
> Device: 802h/2050d Inode: 2360114 Links: 1
> Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
> Access: 2016-09-30 08:33:46.193812724 -0700
> Modify: 2016-04-27 21:27:30.000000000 -0700
> Change: 2016-05-18 10:58:33.066735324 -0700
> Birth: -
> Below are the syscheck-related configurations on the server side which
> affect /usr on the client:
> <!-- global options -->
> <! -- global exclusions -->
> And here are the relevant client-side directives:
> <!-- Frequency in seconds that syscheck is executed -->
> I have verified that syscheck is taking about 3 hours to run, which is well
> within the specified excecution frequency.
> 2016/09/25 06:28:55 ossec-syscheckd: INFO: Starting syscheck scan
> (forwarding database).
> 2016/09/25 06:28:55 ossec-syscheckd: INFO: Starting syscheck database
> 2016/09/25 09:38:29 ossec-syscheckd: INFO: Ending syscheck scan (forwarding
> 2016/09/25 21:39:02 ossec-syscheckd: INFO: Starting syscheck scan.
> 2016/09/26 00:48:32 ossec-syscheckd: INFO: Ending syscheck scan
> If there's something obvious that I screwed up or overlooked, can anyone
> hit me on the head with it?
Is there a specific directory or area of the file system that is
exhibiting these issues?
How big is the syscheck db for the agents with this issue?
Could you try clearing the db and running a new baseline?
> 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
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.