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
>

Reply via email to