[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ossec-list
Subject:    [ossec-list] Re: ossec and system updates: forcing immediate syscheck
From:       Reggie Griffin <regomatic () gmail ! com>
Date:       2009-01-26 17:04:23
Message-ID: 497DED17.9010606 () gmail ! com
[Download RAW message or body]


Daniel,

Thank you for the response. Mostly I want to be able to set a specific
time and/or time/day that will
coincide with system updates and also have a regular scan schedule.

The syscheck default is every two hours.

<!-- Frequency that syscheck is executed - default every 2 hours -->
    <frequency>21600</frequency>

OSSEC is a pretty amazing tool. We have been reviewing commercial event
correlation tools that are
very expensive. As of yet we haven't found anything that I would say
outclasses OSSEC other than
some have a nicer web interface or have specific support for a few
proprietary log formats.

Keep up the good work!

-Reggie

Daniel Cid wrote:
> Hi Reggie,
>
> Yes, you can set the scan time on the client side, but you can only have one per
> agent. I don't think it is very useful to scan more than once per day,
> but we can
> add support for this in the future.
>
> thanks,
>
> --
> Daniel B. Cid
> dcid ( at ) ossec.net
>
> On Mon, Jan 26, 2009 at 12:01 PM, Reggie Griffin <regomatic@gmail.com> wrote:
>   
>> I have a few questions related to this thread.
>>
>> 1. I noticed that <syscheck><frequency></frequency><syscheck> exists on
>> the client side. Is it possible to set
>>    the <scan_time></scantime> there?
>>
>> 2. Is it possible to set multiple <scan_time>s?
>>
>> This is my 4th post to the list in the last few months. Hopefully this
>> one gets a response.
>>
>> -Reggie
>>
>> Daniel Cid wrote:
>>     
>>> Hi Eric,
>>>
>>> I understand your pain in there :) What I have done in the past (which
>>> worked for me) was to do the
>>> following:
>>>
>>>
>>> 1-Configured syscheck to run at a determined interval instead of a
>>> frequency (in my case to run
>>> every day after 9pm):
>>>
>>> <syscheck>
>>>   <scan_time>21:00</scan_time>
>>>   <scan_on_start>no</scan_on_start>
>>> </syscheck>
>>>
>>>
>>> 2-After that, I created a sample local rule to ignore syscheck alerts
>>> from 9am to 7pm:
>>>
>>> <rule id="102246" level="3">
>>>    <if_group>syscheck</if_group>
>>>    <time>9 am - 7 pm</time>
>>>    <description>Administrator initiated syscheck during business
>>> hours.</description>
>>> </rule>
>>>
>>> The reason I did that was because since the scans were only initiated
>>> after 9pm, if we ever got
>>> one during "normal" business hours is because the administrator
>>> initiated them and we should ignore.
>>>
>>>
>>> 3-Whenever anything got updated, we would run agent control to perform
>>> a integrity checking
>>> immediately (in this case on all the agents):
>>>
>>> # /var/ossec/bin/agent_control -r -a
>>>
>>> *If you wanted only in one agent:
>>> # /var/ossec/bin/agent_control -r -u <agent_id>
>>>
>>> Since we would run that during normal business hours, the alert would
>>> be ignored and reduce tremendously
>>> the noise ...
>>>
>>>
>>> So, that's what we did to deal with this issue. Not the perfect
>>> solution, but worked... Note that we didn't
>>> completely ignore the changes, but set them to level 3, in case we
>>> needed to review it later...
>>>
>>>
>>> Hope it helps and gives some ideas.
>>>
>>> --
>>> Daniel B. Cid
>>> dcid ( at ) ossec.net
>>>
>>>
>>> On Fri, Nov 14, 2008 at 4:20 PM, Eric Hankins <erhankins@gmail.com> wrote:
>>>
>>>       
>>>> All,
>>>>
>>>> Wanted to ping the group for thoughts/opinions on interactions between
>>>> file integrity checks and administrative operating system updates.
>>>>
>>>> For example, in the case of a large-scale ossec implementation where
>>>> multiple groups are tasked with updating various pieces of the system,
>>>> i.e. one group is responsible for the OS installs themselves, and
>>>> another group handles the apps/services running on them, and they
>>>> might not always know what each other are up to. The result is a
>>>> stream of alerts that are effectively false positives, because the
>>>> file checksum changes are due to purposeful maintenance taking place.
>>>>
>>>> The task to overcome this is to make ossec a functional component of
>>>> the update process, by making it play nice with scheduled system
>>>> maintenance. There are two components to this:
>>>>
>>>> 1) Be able to force an immediate syscheck to 're-baseline' the file
>>>> integrity checksum database immediately following whatever
>>>> admin-triggered action resulted in changes to things on the
>>>> filesystem. Ideally this 're-baseline' mode would ignore syscheck file
>>>> scanning throttles like syscheck.sleep and syscheck.sleep_after
>>>> because an administratively-triggered syscheck operation during a
>>>> scheduled maintenance window should probably run as fast as possible.
>>>>
>>>> 2) Be able to squelch the alerts that result from the 're-baseline'
>>>> syscheck, as everything found by this operation will likely be
>>>> purposeful and not worthy of an alert.
>>>>
>>>> So, with these objectives in mind, some questions spring to mind:
>>>>
>>>> Is there currently a way to force a syscheck? Will a simple agent
>>>> restart result in it beginning one?  A potentially useful feature here
>>>> would be to send the agent a signal, say, SIGUSR1 to trigger this
>>>> special syscheck, ignoring any throttling options in the process.
>>>>
>>>> As for alerting, it gets a little complicated. The obvious,
>>>> oversimplified method would be for the agent to simply not alert when
>>>> it executes the special 're-baseline' syscheck. But this is (equally
>>>> obviously) a horrible idea, as any intruder with a clue will simply
>>>> send SIGUSR1 or whatever should trigger the immediate syscheck and
>>>> happily have his rootkit rolled into the file integrity checksum list
>>>> without being noticed.
>>>>
>>>> So, the alert squelching clearly needs to happen at the ossec server.
>>>> Extending the concept of maintenance windows, time slices in which
>>>> alerts may safely be ignored and not emailed out, to the server could
>>>> be one way to accomplish this. Preferably, this would be implemented
>>>> such that maintenance windows could be updated dynamically without
>>>> restarting the ossec server.  One could do this in a custom fashion
>>>> today by writing alerts to a database, and layer some custom scripts
>>>> atop it that simply purge alerts for a host during a time period as
>>>> dictated by the maintenance window.
>>>>
>>>> Anyway, just curious what the community thinks about this. Happy to
>>>> submit feature requests based on what we come up with.
>>>>
>>>> best,
>>>> -e
>>>>
>>>>
>>>>         
[prev in list] [next in list] [prev in thread] [next in thread]