You could most likely increase the limit of 128 on sleep_after by
modifying the src. A quick search and you'll find the following in
these 2 files:
syscheckd/syscheck-baseline.c
syscheckd/syscheck.c
{
syscheck.tsleep = getDefine_Int("syscheck","sleep",1,64);
syscheck.sleep_after = getDefine_Int("syscheck","sleep_after",1,128);
}
If you comb through it some more I think you'll also find some process
priority code which you could also modify. Obviously in *most* cases
we don't want syscheck to interfere with system operation hence the
current restrictions in place. Once again YMMV and proceed with
caution.
cheers,
cnk
On Tue, Jun 16, 2009 at 11:57 AM, Michael Altfield<[email protected]> wrote:
>
>> Just remember that this could have a [significant] performance impact
>> on the system.
>
> I'm aware of the impact. I'll be forcing the syscheck when I have
> taken the machine out of production for maintenance--hence, it will
> need to be finished as quickly as possible so that it can be put back
> into production as quickly as possible. This also means that nothing
> will be running on the machine when the sycheck is forced, so there is
> no reason to reduce the process' priority.
>
>> To decrease the amount of time a scan takes you could look at changing
>> the following parameters in internal_options.conf (on the agent):
>>
>> syscheck.sleep=2
>> syscheck.sleep_after=15
>
> I've already tried tuning these values, but they have limits. It
> appears that syscheck.sleep_after has a maximum value of 128, and
> syscheck.sleep has a minimum value of 1.
>
> Is there any better way to do this so that I can *truly* execute the
> syscheck without any limitations?
>
>
> Thanks,
> Michael
>
> On Tue, Jun 16, 2009 at 7:19 AM, cnk<[email protected]> wrote:
>>
>> Hey Michael,
>>
>> You can manually force a syscheck from the ossec server with the
>> following command:
>>
>> # /var/ossec/bin/agent_control -r -u <agent_id>
>>
>> To decrease the amount of time a scan takes you could look at changing
>> the following parameters in internal_options.conf (on the agent):
>>
>> syscheck.sleep=2
>> syscheck.sleep_after=15
>>
>> Just remember that this could have a [significant] performance impact
>> on the system.
>>
>> For more information check out these links:
>>
>> http://www.ossec.net/main/manual/manual-syscheck/
>> http://www.ossec.net/main/manual/manual-agent_control-tool/
>> http://www.ossec.net/wiki/index.php/Know_How:Syscheck_Perf
>>
>> cheers,
>>
>> cnk
>>
>>
>>
>>
>>
>>
>> On Mon, Jun 15, 2009 at 6:25 PM, Michael Altfield<[email protected]>
>> wrote:
>>>
>>> Hello ossec gurus,
>>>
>>> I was wondering if it is possible to force the execution of a
>>> full-capacity re-scan of the files' checksum DB.
>>>
>>> Basically, when preforming system maintenance on a per-server basis,
>>> I'd like to be able to:
>>> 1) turn off ossec and disable alerting for this box in ossec.conf
>>> 2) update the box with our current application version (modifying
>>> monitored files and, thus, altering their checksums)
>>> 3) issue a fast-as-possible rescan of the files on the server
>>> (generate checksums of the new files), and
>>> 4) restart ossec with alerting re-enabled
>>>
>>> Ideally, the only alerts that I will receive after this process are:
>>> "ossec agent disconnected" and "ossec agent connected"
>>>
>>> The problem with this is: normally, ossec-syscheckd would be niced
>>> *way* down so that #3 above would take an unreasonably high amount of
>>> time. Is there a way to make it a #1 priority?
>>>
>>>
>>> Cheers,
>>> Michael Altfield
>>>
>>
>
