Manual, Full Capacity re-scan with ossec-syscheckd

[Michael Altfield]

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

[cnk]

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

[Michael Altfield]

> 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

[cnk]

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

[Michael Altfield]

Thank you!

At the default settings (syscheck.sleep=2 and
syscheck.sleep_after=15), it took about 50 minutes to complete a
syscheck of about 6500 files. When I changed the source, recompiled,
and changed syscheck.sleep=2 to syscheck.sleep=0, I was able to drop
this time down to under 10 minutes!

Is there any way I can request that this source change is made in the
official release? I see no reason why OSSEC shouldn't at least
*support* running syscheck without sleeping after calculating X number
of file checksums...


Thanks again,
Michael

On Jun 16, 3:11 pm, cnk <lists.canuck...@gmail.com> wrote:
> 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<michael...@gmail.com> 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<lists.canuck...@gmail.com> 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
>

[Daniel Cid]

Hi Michael,

We fixed that in the code on the latest snapshot:

http://ossec.net/files/snapshots/ossec-hids-090626.tar.gz

The idea for this restriction was to prevent the user from killing himself, but
since the internal_options.conf file already has a warning, we will let the
user decide :)

Thanks,

--
Daniel B. Cid
dcid ( at ) ossec.net