-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthias,
        Since you asked for more community input:
        I don't think mtime is overly useful; it's not very reliable from a 
system integrity standpoint.  And, at least for me, in the case of software 
updates, the mtime of the updated files is carried over from the system the 
updated software was built on, not the time the update was applied.  For 
example, I updated perl two days ago, but ls -l shows 6 days ago as date of the 
binary.  And I think using the time of the syscheck run which noted a change in 
the file is, for me, less confusing than mtime given the possibility for files 
to change several times between runs.
        I would love to see OSSEC augmented with a feature that allowed 
"golden" metadata about files to be used to limit the alerts about file 
changes.  I imagine something like approved updated MD5s, etc. on one machine 
after the update being used as OK for the same files on other machines in 
addition to the MD5s, etc. that OSSEC currently knows about those files.  As 
long as you are comfortable with the first machine's files, it would be nice to 
be able to tell OSSEC those file are OK on any machine.  However, that does not 
seem to me to be a very simple or straightforward change to the program and 
might not be the best use of developer time.  I'm not sure how many OSSEC uses 
enable syscheck, nor how many of those update their machines often.
        Just my 2 cents,
        -David

Matthias Schmidt wrote:
| Hi Daniel, Hi List
| 
| Thanks a lot for your fast answer! Please don't get me wrong, Ossec
| ist really fantastic software. Every open source developer has my
| greatest respect. I just want to discuss some points which are not
| clear to me. You know, the best ideas often come out from
| discussions :-)
| 
| In my opinion, the last modified time (ls -l) of a file is a (more or
| less) reliable source. This is what I want to see: When did the file
| change. The last access time (ls -lu) is not important, because it is
| changed by every backup, auditing, ... tool. What's the opinion of the
| community?
| 
| For me it would be great to have the real mtime of the files in
| ossec.
| 
| Example: We have a software update at 18:00. Ossec runs at 20:00, once
| a day. I have to create a local rule for avoiding getting all the
| syscheck messages from the update. The time in this local rule has to
| be 20:00 - ~21:00. This means, I loose ALL information for the whole
| day, which files are changed. If I could use the real mtime, I could
| create a local rule for 18:00 - ~18:30, losing only the syscheck
| information for this period.
| 
| And another point: I set <scan-time> to 02:00 last evening,
| uncommented <frequency>, restarted ossec... The scan was from 18:50 to
| 20:50 (slow machine, a lot of files...), not at 2:00. I don't get it.
| 
| Thanks a lot and sorry about my bad english...
| 
| Regards,
| Matthias
| 

- -- 
_______________________________________________
GPG (http://www.gnupg.org/) key available from:
http://www.kayakero.net/per/david/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhzhe0ACgkQCzuSgviBh01vwwCfZltbPykPGAtplG1LYJI9YHzU
8qsAoL2+khUYypgCVgEPNRE5dTGV8vSP
=NK8K
-----END PGP SIGNATURE-----

Reply via email to