Yes, but the patch is just a hook to the real logic. A simple AR script to
verify once you can pass filename with this patch might look like this:
#!/bin/sh
filename=$6
pkg=$(rpm -q --whatprovides $filename)
if [ ! -z "$pkg" ]; then
rpm -V $pkg
rc=$?
if [ $rc -ne 0 ]; then
logger -t ossec-ar-verify "fim file:$filename managed:yes manager:rpm
pkg:$pkg change:verified"
else
(($DEBUG)) && echo "File was changed by an RPM install";
fi;
else
logger -t ossec-ar-verify "fim file:$filename managed:no change:verified"
fi;
Then you write an ossec decoder and rules around those log lines tied to
the 'ossec-ar-verify' program_name.
On Tue, May 28, 2013 at 9:40 PM, mntbighker <[email protected]> wrote:
>
>
> Is this patch going to apply to yum update as well? Or what method is
> suggested for addressing the same concerns as apt-get?
>
>
> On Tuesday, May 28, 2013 10:55:23 AM UTC-7, Brad Lhotsky wrote:
>>
>> Working on a fix for that specifically after running into a problem with
>> Active Response trying to implement it.
>>
>> The first piece is to abuse ActiveResponse, and to enable that this patch
>> (https://gist.github.com/**reyjrar/5663893<https://gist.github.com/reyjrar/5663893>)
>> allows the passing of filename using "<expect>filename</expect>" in the
>> command definition. My colleagues are using this to build scripts to
>> verify checksums against Puppet, Git, and rpm. The same architecture could
>> be leveraged to check against apt or whatever else.
>>
>> I haven't tested this patch yet, but it does compile, I'll have a battle
>> tested patch tomorrow.
>>
>> On Monday, May 27, 2013 10:57:12 PM UTC+2, Gerard Petersen wrote:
>>>
>>> Hi All,
>>>
>>> After updating my servers with the cyclic apt-get updates I get
>>> notifications over time right thereafter from all updated agents. But those
>>> are predicted and thus somewhat useless, moreover .. flooding my mailbox.
>>> What I'm looking for is an instant 'new snapshot' of my servers. What I've
>>> found sofar is this:
>>>
>>> # Clearing an agents database
>>> /var/ossec/bin/syscheck_**control -u 002
>>>
>>> # force a syscheck scan (and re-populating the database)
>>> /var/ossec/bin/agent_control -r -u 002
>>>
>>> But 'dropping' the database and refilling it seems overkill and
>>> possibly resulting in unnecessary server load. Anybody a better way to
>>> manage this?
>>>
>>> Thanx in advance.
>>>
>>>
>>> Kind regards,
>>>
>>> Gerard.
>>>
>>> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ossec-list" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/ossec-list/oI7TY38f9P0/unsubscribe?hl=en
> .
> To unsubscribe from this group and all its topics, send an email to
> [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
Brad Lhotsky
--
---
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
