You could setup auditd or snoopy logger and have OSSEC monitor the
auditd/snoopy logs and alert on whenever a file is accessed. This wouldn't
be *true* file integrity monitoring the way that OSSEC performs it (via file
hashes) but it would at least tell you if anyone might be tampering with
files.

On Wed, Apr 6, 2011 at 6:32 AM, Valentin Avram <[email protected]> wrote:

> Hello.
>
> From your experience with OSSEC, which way would you best (in terms of less
> false-positive-emails) implement "log files integrity checks"? It should
> provide checks to make sure log files are not being tampered with, either
> old log files or those being used.
>
> For the sake of discussion, let's presume the following:
> - all log files are kept in /var/log
> - some files are being rotated by logrotate (rotated, archived and kept for
> X days)
> - some files are being rotated by cron jobs (due to the nature of the
> logging taking place)
> - some files are not rotated at all (manually when need be, in case they
> grow by 1-2 KB per month or less)
>
> What do you think is the best configuration for the agent's syscheck
> subsystem and server's setup?
>
> The agent's syscheck should have an entry like this:
> <directories realtime="yes" check_all="yes">/var/log</directories>
>
> but the above line would send alot of false positives because:
> - current logs change size - This might be corrected by the auto_ignore
> setting on the server.
> - a cronjob rotated file would have one file grow steadily (the "collector"
> logfile) and one file be random size depending on the check time (the "being
> processed" logfile)
>     > example. imagine a logfile that gets alot of data, like 1 MB / sec.
> Since the actually relevand data is just part of all that log data, a
> cronjob would periodically run (like every 30-60 seconds) and extract the
> information from that file (the "being processed" log) and append it to
> another file (the "collector" file), then truncate the "being processed"
> logfile.
> - log files that get very little data in them once in a while will also
> trigger an alert since they don't change that fast to be ignored (via
> auto_ignore in the server).
>
> I guess a solution would be to ignore the currently in use log file, but
> that would be against the purpose of  "log file integrity checking". And
> besides, once a new logfile is added on the system (after installing a new
> service for instance) that file should be added to the ignore list.
>
> So, what are your thoughts / experiences on this scenarios?
>
> Thank you for your time.
>
>

Reply via email to