We have a pull request to allow for a whitelist of hashes to be stored
in an sqlite database. I think Wazuh already has this feature.
(https://github.com/ossec/ossec-hids/pull/1091)
You could pre-populate it with the appropriate hashes before an upgrade.

On Fri, Jun 2, 2017 at 3:45 AM,  <andrii.pravdy...@gmail.com> wrote:
> It will be great if you implement this.
> I'll wait with impatience.
>
>
> On Wednesday, May 31, 2017 at 8:22:24 PM UTC+3, Pedro Sanchez wrote:
>>
>> Great! Good to know its working!
>>
>> Thanks for coming back to tell us.
>>
>> I believe we will develop a easier way to do this on the future, something
>> like "Disable Syscheck for 2h starting day 05/20/2017" for example, so we
>> can plan massive upgrades on a enterprise environment.
>>
>> Best,
>> Pedro.
>>
>>
>>
>> On Wed, May 31, 2017 at 6:12 PM, <andrii.p...@gmail.com> wrote:
>>>
>>> Hi, Pedro.
>>>
>>> I tested it again few days ago. I followed the next steps:
>>>
>>> 1. Stop agent on the host.
>>> 2. update OS  or  what are you going to do?
>>> 3. run   /var/ossec/bin/syscheck_control -u AGENT_ID - on the
>>> ossec-server
>>> 4. restart  ossec-server ( In my case : systemct restart ossec-hids )
>>> 5. start agent on the host.
>>>
>>> It works well. I did not get any alerts.
>>>
>>> On Wednesday, May 24, 2017 at 6:28:45 PM UTC+3, Pedro Sanchez wrote:
>>>>
>>>> Hi,
>>>>
>>>> If you want to disable syscheck component for specific folders, you
>>>> could push an <ignore> setting for syscheck block using agent.conf
>>>> centralized configuration.
>>>> For example, you could ignore something like:
>>>>
>>>>> <ignore>/etc/</ignore>
>>>>
>>>>
>>>> Reference here.
>>>>
>>>> Same way you could totally disable syscheck using <disabled> setting.
>>>>
>>>> When the OS update be done, modify again agent.conf to restore back the
>>>> configuration.
>>>>
>>>> To prevent alerts for "new file" you could:
>>>>
>>>>> /var/ossec/bin/syscheck_control -u AGENT_ID
>>>>> Remove .cpt files in /var/ossec/queue/syscheck
>>>>> Restart Manager.
>>>>
>>>>
>>>>
>>>> I hope someone could add more ideas for this use case.
>>>>
>>>> Best,
>>>> Pedro.
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, May 23, 2017 at 9:33 PM, <andrii.p...@gmail.com> wrote:
>>>>>
>>>>> I am going to update my Linux servers and I tried to disable the
>>>>> ossec-agent for this time.
>>>>> I was the following workarounds:
>>>>> 1. stop agent on a host
>>>>> 2. run   /var/ossec/bin/syscheck_control -u AGENT_ID
>>>>> 3. update
>>>>> 4. up agent
>>>>> But after start agent I got lots of trigger "new files in the server"
>>>>> alarms.  (alert_new_file  - yes)
>>>>>
>>>>> How to properly disable the ossec-agent on a host during the Linux
>>>>> update or for modifying files?
>>>>>
>>>>> --
>>>>>
>>>>> ---
>>>>> 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 ossec-list+...@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>> --
>>>
>>> ---
>>> 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 ossec-list+...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
> --
>
> ---
> 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 ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 

--- 
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 ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to