-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Daniel,
I think I mentioned the trusted MD5/SHA1 sums idea. I've given it very
little thought (sorry about that) and was out of town for a bit. And I just
did a very little poking around that makes me wonder if it's even possible. My
hope, if there was a sane way to accomplish it, is to reduce the file integrity
alerts for folks with several systems running the same OS. I would love to be
able to roll out updates to my most secure, trusted machine, get the syscheck
alerts and approve the changes. Then roll those updates out to the rest of my
machines and (this is where the magic wand is waved) add the changed metadata
from the trusted machine to the syscheck databases for the other machines.
Ideally, the database would allow currently approved metadata and the
"pre-approved" metadata gathered from my trusted machine. In my case that most
trusted machine is my OSSEC server, so a shell script to push the updated data
around would be a perfect mechanism -- if the basic idea is s
ane.
However, when I just looked at a couple example files, it appears that
the checksums don't match between machines. Maybe I'm not looking at the
database files properly but the two long hex strings don't match:
one
machine:+++25916:33261:0:0:25bd8afd2329fc2345969ee28bfdf963:a70ccae947f8b7bd92899d4ad9e0ea35e84b7994
!1216135876 /bin/login
second
machine:+++25916:33261:0:0:f8962bdadff7e944a95e821485203cba:a275c93e16490912c226a553c5246e0727d3f331
!1216134653 /bin/login
Maybe this is a symptom of precompiled headers? I thought that came up
once before in reference to files changing when the should not have. At any
rate, unless those strings are encrypted checksums, it seems like my idea
wouldn't work anyway.
And I do understand that file integrity testing is of limited value and
that there may not be enough interest in the OSSEC community for this type of
change to an already very solid tool.
-David
Daniel Cid wrote:
| Hi Matthias,
|
| I agree with Michael regarding the usefulness on integrity checking on
| most cases. In fact,
| whenever I deploy it, I configure OSSEC to only alert me via email on
| changes to /etc (configuration
| files) and on critical system-specific files (like htdocs on web
| servers or /var/named on my
| dns servers, etc). I still store the changes to the binaries and
| libraries, just in case I need to
| find something out later. However, I generally care most about files
| that are not supposed to
| change even on update/patch day.
|
| Now, on the interface for feeding trusted md5/sha1 sums into OSSEC,
| what do you have in
| mind? Mainly a command line interface that you provide the file and
| the new md5/sha1?
| Or something else at all? I like the idea and we might try to
| implement something
| like that...
|
| *The agent always do a scan when it starts and then after that it
| follows the scan_time/scan_day
| or frequency options. You can disable the scan on start, by setting
| <scan_on_start> to "no"
| on your config (only available on the snapshots, not on v1.5.1).
|
| Thanks,
|
| --
| Daniel B. Cid
| dcid ( at ) ossec.net
|
|
| On Thu, Jul 10, 2008 at 6:27 AM, Matthias Schmidt
| <[EMAIL PROTECTED]> wrote:
|> Hi all
|>
|> Thanks a lot for your input! It's very interesting to hear different
|> opinions. I've learned: Which mtime you need depends really on the
|> type of problem you have. For me, the real mtime would be better.
|>
|> But this:
|>>> I imagine something like approved updated MD5s, etc. [...]
|> would be the perfect solution, sure. A thin interface for feeding
|> trusted md5/sha1 sums into OSSEC would improve it to a powerful change
|> management solution, more powerful than Tripwire (my opinion, because
|> Tripwire depends only on checksums and is hard to integrate). I played
|> around with updating the metadata in .../queue/syscheck/syscheck but
|> had no success.
|>
|> Michaels idea with hooking into the kernel would also be great, but I
|> think the implementation of this functionality depends too much on
|> the used OS. Correct me if i'm wrong.
|>
|> And - coming back to the <scan_time>-Parameter (sorry...): Last three
|> days I played around with this parameter on several machines. They
|> always perfom syscheck once after restarting ossec, then no longer.
|> Has anyone similar problems? Or is this maybe an OS or timezone
|> dependend problem?
|>
|> Thanks & 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
iEYEARECAAYFAkh878UACgkQCzuSgviBh01RegCeO4cDRzJrK3HfUoGsLptMXwLW
ErUAoJXe6S8mDnp1LiERmOTiONg2yS9F
=IVMW
-----END PGP SIGNATURE-----
